4 ms·

Yawn. Another "OMG programmers can't handle multicore!" bullshit article. I do threads all the time, and there are lots of things out there like various MapRed

by api 16y ago

Yawn. Another "OMG programmers can't handle multicore!" bullshit article. I do threads all the time, and there are lots of things out there like various MapReduce toolkits that make it even easier than dealing directly with threads if you want. Threads are not that hard. It just takes an understanding followed by some practice to get a sense for it.

dkersten 16y ago
Threads are not that hard. I wouldn't quite say that, but perhaps rephrase it to Multicore is not that hard. Or maybe Concurrency is not that hard. (Basically, threads are just one abstraction for multicore/concurrent programming and I think its harder than some of the alternatives - its certainly a lower-level approach than others). In any case, it isn't that hard. The problem is we're being educated to program sequentially and very little effort (relatively speaking) is being put into educating programmers to program concurrent/parallel multicore software. You cannot simply write a sequential program and then magically make it multi threaded. Good sequential algorithms are not good multicore algorithms and vice versa. My response to the previous time this was posted to HN (linked in my other comment) explains what I mean.
- macemoneta 16y ago
  Exactly. For example, process forks are much lighter in overhead than they used to be (depending on the platform), and for long running processes their initiation and termination is insignificant compared to the overall task time. Processes are conceptually easier for people to get started with when starting development of concurrent software. My current quad core is running about 550 processes at near-idle. Their workload is distributed across cores with no effort. Most Apache implementations use multiple processes for the workers, as an example. The idea that multi-core code has to have threading actually slows development, because it's a more difficult concept to implement correctly. Multiple processes get the job done as well in many instances, and since each process is single threaded it's easier to implement and maintain.
  - tptacek 16y ago
    Whether memory is shared by default (threads) or explicitly (processes) is a little bit of a red herring. The thing that makes parallelized designs hard happens at a higher level: it's that whatever your shared resources are (files, databases, shared memory, in-core databases hanging off message listeners, etc), you have to find a design that allows things to be shared and correct, and that's a hard balance to strike.
    - macemoneta 16y ago
      You are assuming shared memory as the communication medium. When using processes, you can use sockets for IPC for example. The advantage is that the application can then scale beyond a single system with no change - something that's impossible to do with threads. It's easier to implement and more scalable. Far from a red herring, the persistent focus on threads for concurrency imposes limitations that are unnecessary in modern systems, and slows development.
      - tptacek 16y ago
        Pretty sure you and I just said the same thing, though let me just add that just because you hang something off a socket doesn't mean your design can't serialize around it. Having 100 concurrent workers doesn't help if all of them are just lining up waiting for another program to answer their messages. Of course, this is the exact same problem you have when you try to make a naive design concurrent by wrapping all the global variables in mutexes.
  - deleted 16y ago
    [deleted]
tptacek 16y ago
Disagree. Writing programs that are correct with multiple threads is harder than writing single-threaded program (remember that if you're motivated enough to post about it, you're in the top 0.1% of programmers). But that aside, writing programs that are truly faster and, more importantly, that scale reasonably with the number of threads, compute resources, other resources, &c is far harder. Have you profiled your code? Have you had the experience of untangling serializations around locks? Have you had the experience of having to custom-code your own sync primitives because locking overhead started to kill you? Are you graphing performance over number of threads under stress? I've worked on projects like that, watched the curves flatten (and sometimes dip), and I don't think scalable multicore code is anywhere nearly as simple as "man pthread, and remember to lock and unlock in the right order". I'm not trying to say you don't know what you're talking about. I'm saying that you're underestimating the amount of work that goes into making fast multithreaded designs work; you may do all this stuff without even thinking about it, but you have to remember that this is work that you don't have to do at all in "normal" nonscalable designs.
- pvg 16y ago
  I'm not trying to say you don't know what you're talking about. Heh, maybe I'm becoming an HN cynic but I clicked 'comments' with the near certain expectation of finding an upvoted comment of someone calling David Patterson an idiot.
- aristus 16y ago
  I've a possibly silly question: since cache misses can dominate performance even in the single-core case, why don't they use all that silicon to make one core with craptons of on-die cache?
  - tptacek 16y ago
    Presumably because at a given level of performance L2 cache size and die size/complexity don't have favorable scaling properties. You can ask this question to Google almost verbatim and find articles talking about SRAM ports and stuff. The beauty of multicore scaling is that it scales.
pragmatic 16y ago
Threads are difficult. Concurrency is easier because most of it can be pushed to Databases, Web servers, ThreadPools, etc. The heavy lifting has been done almost even before the crisis started.

by api 16y ago

dkersten 16y ago

Threads are not that hard. I wouldn't quite say that, but perhaps rephrase it to Multicore is not that hard. Or maybe Concurrency is not that hard. (Basically, threads are just one abstraction for multicore/concurrent programming and I think its harder than some of the alternatives - its certainly a lower-level approach than others). In any case, it isn't that hard. The problem is we're being educated to program sequentially and very little effort (relatively speaking) is being put into educating programmers to program concurrent/parallel multicore software. You cannot simply write a sequential program and then magically make it multi threaded. Good sequential algorithms are not good multicore algorithms and vice versa. My response to the previous time this was posted to HN (linked in my other comment) explains what I mean.

macemoneta 16y ago
Exactly. For example, process forks are much lighter in overhead than they used to be (depending on the platform), and for long running processes their initiation and termination is insignificant compared to the overall task time. Processes are conceptually easier for people to get started with when starting development of concurrent software. My current quad core is running about 550 processes at near-idle. Their workload is distributed across cores with no effort. Most Apache implementations use multiple processes for the workers, as an example. The idea that multi-core code has to have threading actually slows development, because it's a more difficult concept to implement correctly. Multiple processes get the job done as well in many instances, and since each process is single threaded it's easier to implement and maintain.
- tptacek 16y ago
  Whether memory is shared by default (threads) or explicitly (processes) is a little bit of a red herring. The thing that makes parallelized designs hard happens at a higher level: it's that whatever your shared resources are (files, databases, shared memory, in-core databases hanging off message listeners, etc), you have to find a design that allows things to be shared and correct, and that's a hard balance to strike.
  - macemoneta 16y ago
    You are assuming shared memory as the communication medium. When using processes, you can use sockets for IPC for example. The advantage is that the application can then scale beyond a single system with no change - something that's impossible to do with threads. It's easier to implement and more scalable. Far from a red herring, the persistent focus on threads for concurrency imposes limitations that are unnecessary in modern systems, and slows development.
    - tptacek 16y ago
      Pretty sure you and I just said the same thing, though let me just add that just because you hang something off a socket doesn't mean your design can't serialize around it. Having 100 concurrent workers doesn't help if all of them are just lining up waiting for another program to answer their messages. Of course, this is the exact same problem you have when you try to make a naive design concurrent by wrapping all the global variables in mutexes.
- deleted 16y ago
  [deleted]

tptacek 16y ago

Disagree. Writing programs that are correct with multiple threads is harder than writing single-threaded program (remember that if you're motivated enough to post about it, you're in the top 0.1% of programmers). But that aside, writing programs that are truly faster and, more importantly, that scale reasonably with the number of threads, compute resources, other resources, &c is far harder. Have you profiled your code? Have you had the experience of untangling serializations around locks? Have you had the experience of having to custom-code your own sync primitives because locking overhead started to kill you? Are you graphing performance over number of threads under stress? I've worked on projects like that, watched the curves flatten (and sometimes dip), and I don't think scalable multicore code is anywhere nearly as simple as "man pthread, and remember to lock and unlock in the right order". I'm not trying to say you don't know what you're talking about. I'm saying that you're underestimating the amount of work that goes into making fast multithreaded designs work; you may do all this stuff without even thinking about it, but you have to remember that this is work that you don't have to do at all in "normal" nonscalable designs.

pvg 16y ago
I'm not trying to say you don't know what you're talking about. Heh, maybe I'm becoming an HN cynic but I clicked 'comments' with the near certain expectation of finding an upvoted comment of someone calling David Patterson an idiot.
aristus 16y ago
I've a possibly silly question: since cache misses can dominate performance even in the single-core case, why don't they use all that silicon to make one core with craptons of on-die cache?
- tptacek 16y ago
  Presumably because at a given level of performance L2 cache size and die size/complexity don't have favorable scaling properties. You can ask this question to Google almost verbatim and find articles talking about SRAM ports and stuff. The beauty of multicore scaling is that it scales.

pragmatic 16y ago

Threads are difficult. Concurrency is easier because most of it can be pushed to Databases, Web servers, ThreadPools, etc. The heavy lifting has been done almost even before the crisis started.