7 ms·

Note that it's from 1995. Back then, many people still thought that machines with multiple processors were exotic things of little interest even in the enterpr

Note that it's from 1995. Back then, many people still thought that machines with multiple processors were exotic things of little interest even in the enterprise. That list most notably included one Linus Torvalds. It also included OP author John Osterhout, who should also have known better - even more so, since Stanford was one of the places where such things were not so exotic. He even says, right up front, that threads still have their uses when you need true CPU concurrency. Now that's a common case. Generalizing from this presentation to the current day is probably a worse idea than threads ever were.

bbatha 9y ago
Clearly they never wrote for the butterfly[0] ;). [0] https://en.wikipedia.org/wiki/BBN_Butterfly https://en.wikipedia.org/wiki/BBN_Butterfly
winstonewert 9y ago
Your comment implies that the presentation says you shouldn't use thread. But that's not what it says. The conclusion is that you should only use threads when you are actually trying to achieve cpu concurrency.
- notacoward 9y ago
  "Only" In the context of that time, "only when you're trying to achieve CPU concurrency" was meant as "only if you're doing something exotic" (though it wasn't as exotic as Osterhout thought - I'd already been working on MP machines for years). In the context of this time, it means "only" in an extremely common case. The difference matters. People who read the presentation without putting it in historical context will be misled, even if Osterhout weasel-worded his conclusions because he kind of knew he was wrong already.
greglindahl 9y ago
Today, there are many places that have big clusters of multi-processor machines, and none of their code is threaded. They get cpu concurrency by message passing between heavy-weight processes and with other nodes.
- openasocket 9y ago
  I assume you're referencing MPI? It all depends on your problem domain. There are plenty of classes of problems where message passing incurs far more overhead than just sharing memory.
  - greglindahl 9y ago
    MPI is indeed something I used to do, but I was thinking more of large NoSQL setups like blekko's search engine, which was 100% event-driven code running in separate, heavy-weight processes. (OK, in the guts, we did have some utility software that did async disk I/O using a few C threads per heavyweight process, but that was due to the limited kernel API more than us wanting threads.)
    - openasocket 9y ago
      Sure, but the point is that outside of embarrassingly parallel problems you need shared memory access. You can simulate that with message passing, but for many problems the overhead of message passing is too great. I'm specifically thinking of linear algebra routines. I'd like to see someone write a performant BLAS implementation that doesn't make extensive use of threading
      - zzzcpan 9y ago
        Message passing lets you amortize synchronization and should always be faster if properly implemented.
        openasocket 9y ago
        Not really, no. You've still got the overhead of copying, which can be significant. There's no way you could implement something like, for example, Gaussian elimination with message passing in a way that's just as fast as using locks and barriers.
        9y ago

bbatha 9y ago

Clearly they never wrote for the butterfly[0] ;). [0] https://en.wikipedia.org/wiki/BBN_Butterfly https://en.wikipedia.org/wiki/BBN_Butterfly

winstonewert 9y ago

Your comment implies that the presentation says you shouldn't use thread. But that's not what it says. The conclusion is that you should only use threads when you are actually trying to achieve cpu concurrency.

notacoward 9y ago
"Only" In the context of that time, "only when you're trying to achieve CPU concurrency" was meant as "only if you're doing something exotic" (though it wasn't as exotic as Osterhout thought - I'd already been working on MP machines for years). In the context of this time, it means "only" in an extremely common case. The difference matters. People who read the presentation without putting it in historical context will be misled, even if Osterhout weasel-worded his conclusions because he kind of knew he was wrong already.

greglindahl 9y ago

Today, there are many places that have big clusters of multi-processor machines, and none of their code is threaded. They get cpu concurrency by message passing between heavy-weight processes and with other nodes.

openasocket 9y ago
I assume you're referencing MPI? It all depends on your problem domain. There are plenty of classes of problems where message passing incurs far more overhead than just sharing memory.
- greglindahl 9y ago
  MPI is indeed something I used to do, but I was thinking more of large NoSQL setups like blekko's search engine, which was 100% event-driven code running in separate, heavy-weight processes. (OK, in the guts, we did have some utility software that did async disk I/O using a few C threads per heavyweight process, but that was due to the limited kernel API more than us wanting threads.)
  - openasocket 9y ago
    Sure, but the point is that outside of embarrassingly parallel problems you need shared memory access. You can simulate that with message passing, but for many problems the overhead of message passing is too great. I'm specifically thinking of linear algebra routines. I'd like to see someone write a performant BLAS implementation that doesn't make extensive use of threading
    - zzzcpan 9y ago
      Message passing lets you amortize synchronization and should always be faster if properly implemented.
      - openasocket 9y ago
        Not really, no. You've still got the overhead of copying, which can be significant. There's no way you could implement something like, for example, Gaussian elimination with message passing in a way that's just as fast as using locks and barriers.
        9y ago