3 ms·

I agree. However, it seems like a fundamentally simpler to build a share-nothing system than a threaded one.

by sanj 18y ago

anamax 18y ago
Yes, but "share-nothing" almost always has some sharing. (If it doesn't, it can be run somewhere else, by someone else, at some other time, including "never".)
- 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.
- iman 18y ago
  yeah, chrome tabs are not "shared-nothing". They have a common document cache, a common cookie store, a common history store, probably a common dns lookup result cache, and maybe some other things. These all need to be carefully synchronized between multiple tabs. In fact, I would argue that multi threaded would be better than multi process so that even more things could be easily shared. For example, I imagine that css stylesheets are parsed into some big fat data structure inside browsers. If I open two tabs from a website that share a stylesheet it would be optimal if they share this same internal representation (no locking would be required for the sharing since it's read-only). This has the obvious savings of memory, but it also increases speed since the css file only has to be parsed and processed once instead of multiple times. And things like sharing keep-alive connections between tabs are virtually impossible with multi process, while very possible with multiple threads.
  - anewaccountname 18y ago
    >probably a common dns lookup result cache Uhh, from the OS they get that for free.
    - iman 18y ago
      But nevertheless, browsers still maintain their own internal cache. Firefox: http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox-dns-cache/ http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox-dns-...
  - pivo 18y ago
    Except that with multi-threading you give up the OS-provided process level memory management and are back to having to track down all those memory leaks which at least Mozilla never can seem to fix satisfactorily. Even though Chrome seems plenty fast to me, I'd gladly give up some speed if I never had to close the browser and restart it because it was taking up 3/4 of available memory.
eggnet 18y ago
Multiple threads don't buy you crash protection. If one of the threads crashes, the process and all threads in it are terminated.

I agree. However, it seems like a fundamentally simpler to build a share-nothing system than a threaded one.

by sanj 18y ago

I agree. However, it seems like a fundamentally simpler to build a share-nothing system than a threaded one.

Yes, but "share-nothing" almost always has some sharing. (If it doesn't, it can be run somewhere else, by someone else, at some other time, including "never".)

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.
iman 18y ago
yeah, chrome tabs are not "shared-nothing". They have a common document cache, a common cookie store, a common history store, probably a common dns lookup result cache, and maybe some other things. These all need to be carefully synchronized between multiple tabs. In fact, I would argue that multi threaded would be better than multi process so that even more things could be easily shared. For example, I imagine that css stylesheets are parsed into some big fat data structure inside browsers. If I open two tabs from a website that share a stylesheet it would be optimal if they share this same internal representation (no locking would be required for the sharing since it's read-only). This has the obvious savings of memory, but it also increases speed since the css file only has to be parsed and processed once instead of multiple times. And things like sharing keep-alive connections between tabs are virtually impossible with multi process, while very possible with multiple threads.
- anewaccountname 18y ago
  >probably a common dns lookup result cache Uhh, from the OS they get that for free.
  - iman 18y ago
    But nevertheless, browsers still maintain their own internal cache. Firefox: http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox-dns-cache/ http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox-dns-...
- pivo 18y ago
  Except that with multi-threading you give up the OS-provided process level memory management and are back to having to track down all those memory leaks which at least Mozilla never can seem to fix satisfactorily. Even though Chrome seems plenty fast to me, I'd gladly give up some speed if I never had to close the browser and restart it because it was taking up 3/4 of available memory.

eggnet 18y ago

Multiple threads don't buy you crash protection. If one of the threads crashes, the process and all threads in it are terminated.