The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Lawrence Stewart <stewart@serissa.com>
To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe)
Date: Fri, 3 Sep 2021 15:02:00 -0400	[thread overview]
Message-ID: <7CE6F620-FABD-4C2C-905A-02919FB0BCD5@serissa.com> (raw)
In-Reply-To: <20210903172848.GF13471@mcvoy.com>

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

I don’t really think out-of-order in hardware causes trouble for programmers that wasn’t already there when you use -O3.  Compilers will already promote memory to registers and do interprocedural optimization and reorder memory references.  You have to sprinkle 
asm volatile("" ::: "memory");
around like pixie dust to make sure the compiler does things in the order you want, nevermind the hardware.

x86 has wildly complex microarchitecture, but the model for a single thread is perfectly sensible.  It seems to work like it was in-order. OOO isn’t changing that model of execution at all.  I mean you care about it when performance tuning, but not for correctness.

Other architectures, ARM, IBM, Alpha, are far worse in this respect.

The real problems are when you have multicore in a shared memory space and you have to read all the fine print in the memory ordering chapter and understand the subtle differences between LFENCE and SFENCE and MFENCE.  I get that, but I also think shared memory is a failed experiment and we should have gone with distributed memory and clusters and message passing.  It is possible for mortals to program those.    Regular folks can make 1000 rank MPI programs work, where almost noone other than Maurice Herlihy or like that can reason about locks and threads and shared data structures.

My wish for a better world is to integrate messaging into the architecture rather than have an I/O device model for communications.  It is criminal that machine to machine comms are still stuck at 800 nanoseconds or so latency.  It takes 200 instructions or so to send a message under the best circumstances and a similar number to receive it, plus bus, adapter, wire, and switch time. 

-L




[-- Attachment #2: Type: text/html, Size: 8199 bytes --]

  parent reply	other threads:[~2021-09-03 19:02 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 21:58 Dan Cross
2021-09-02  8:42 ` Tony Finch
2021-09-03  0:19   ` John Cowan
2021-09-03  3:24     ` Douglas McIlroy
2021-09-03 13:21       ` Theodore Ts'o
2021-09-08 11:14         ` Tony Finch
2021-09-16 19:27         ` Dan Cross
2021-09-17  0:34           ` Theodore Ts'o
2021-09-17  0:44             ` Larry McVoy
2021-09-17 17:07               ` Bakul Shah
2021-09-17  1:33             ` Dan Cross
2021-09-02 15:41 ` Kevin Bowling
2021-09-02 20:12   ` Marshall Conover
2021-09-03 15:56 ` Warner Losh
2021-09-03 17:10   ` Adam Thornton
2021-09-03 17:28     ` Larry McVoy
2021-09-03 17:42       ` John Floren
2021-09-03 19:02       ` Lawrence Stewart [this message]
2021-09-03 19:11       ` Clem Cole
2021-09-03 17:46     ` [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware [ really a comment on SoCs ] Jon Steinhart
2021-09-16 18:38 ` [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) Dan Cross
2021-09-16 19:34   ` Jon Steinhart
2021-09-16 19:41     ` Larry McVoy
2021-09-16 23:14       ` Marshall Conover
2021-09-16 23:44         ` Rob Pike
2021-09-17  0:37           ` Larry McVoy
2021-09-17  1:38         ` Jon Steinhart
2021-09-17  3:54         ` John Cowan
2021-09-16 23:45       ` Jon Steinhart
2021-09-17  0:06         ` Al Kossow
2021-09-17  4:06           ` John Cowan
2021-09-17  4:18             ` Al Kossow
2021-09-17  0:32         ` Larry McVoy
2021-09-16 23:54       ` David Arnold
2021-09-17  1:10         ` Jon Steinhart
2021-09-17  1:28           ` Larry McVoy
2021-09-17  1:40             ` Jon Steinhart
2021-09-17  2:04               ` Larry McVoy
2021-09-17  2:21                 ` Jon Steinhart
2021-09-17  2:48           ` Theodore Ts'o
2021-09-17 17:39         ` Bakul Shah
2021-09-17 17:51           ` Jon Steinhart
2021-09-17 18:07             ` Larry McVoy
2021-09-17 21:03               ` Derek Fawcus
2021-09-17 22:11                 ` Larry McVoy
2021-09-19  4:05                   ` Theodore Ts'o
2021-09-17 18:34             ` Bakul Shah
2021-09-17 18:56               ` Jon Steinhart
2021-09-17 19:16                 ` Bakul Shah
2021-09-17 19:35                   ` Jon Steinhart
2021-09-17 15:56     ` Bakul Shah
2021-09-17 18:24       ` ron minnich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7CE6F620-FABD-4C2C-905A-02919FB0BCD5@serissa.com \
    --to=stewart@serissa.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).