5 ms·

Agreed. But don't undervalue the difference in mindset. At least for me, threading makes me think "what can I peel off of my main task to run in threads" vers

by sanj 18y ago

Agreed. But don't undervalue the difference in mindset. At least for me, threading makes me think "what can I peel off of my main task to run in threads" versus share-nothing which makes me think "here are the 3 shared resources that I anticipate will be bottlenecks".

jmtulloss 18y ago
And I would argue that this is The Right Way to think about things. When you're working in a shared-nothing world, suddenly the lines you draw between components become much more important. Thinking about these lines and drawing them carefully almost always results in more modular and more flexible software.
- anamax 18y ago
  "much more important" is actually "much more expensive to cross". Expensive lines make systems less flexible, not more. They lead to copies for efficiency, aka denormalization, which is another word for "bug waiting to happen". While this can be dealt with, doing so involves lots of nasty tradeoffs, with bugs a common outcome. More to the point "more modular and more flexible" is neither necessary nor sufficient for producing good software.
  - MicahWedemeyer 18y ago
    "more modular and more flexible" is neither necessary nor sufficient for producing good software I'm glad I'm not the only one that thinks this way. I wish I could upmod by 1 million.
  - jmtulloss 18y ago
    I would argue that it is necessary, though not sufficient. Writing black box tests for non-modular code is a nightmare.
anamax 18y ago
> At least for me, threading makes me think "what can I peel off of my main task to run in threads" Don't do that. > "here are the 3 shared resources that I anticipate will be bottlenecks". Do something like that. The difference between threads and processes is in the mechanisms for sharing. While those mechanisms affect how you organize computation (different things are cheap), they don't mandate an organization.

by sanj 18y ago

jmtulloss 18y ago

And I would argue that this is The Right Way to think about things. When you're working in a shared-nothing world, suddenly the lines you draw between components become much more important. Thinking about these lines and drawing them carefully almost always results in more modular and more flexible software.

anamax 18y ago
"much more important" is actually "much more expensive to cross". Expensive lines make systems less flexible, not more. They lead to copies for efficiency, aka denormalization, which is another word for "bug waiting to happen". While this can be dealt with, doing so involves lots of nasty tradeoffs, with bugs a common outcome. More to the point "more modular and more flexible" is neither necessary nor sufficient for producing good software.
- MicahWedemeyer 18y ago
  "more modular and more flexible" is neither necessary nor sufficient for producing good software I'm glad I'm not the only one that thinks this way. I wish I could upmod by 1 million.
- jmtulloss 18y ago
  I would argue that it is necessary, though not sufficient. Writing black box tests for non-modular code is a nightmare.

anamax 18y ago

> At least for me, threading makes me think "what can I peel off of my main task to run in threads" Don't do that. > "here are the 3 shared resources that I anticipate will be bottlenecks". Do something like that. The difference between threads and processes is in the mechanisms for sharing. While those mechanisms affect how you organize computation (different things are cheap), they don't mandate an organization.