The Trouble with Multicore • Hacker News Board

Re: The Trouble with Multicore

#21

Post by macemoneta » Wed, Jul 21, 2010, 7:05 PM UTC

dkersten wrote: post #4

api wrote: post #2

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.

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 se…

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.

Re: The Trouble with Multicore

#22

Post by tptacek » Wed, Jul 21, 2010, 7:12 PM UTC

macemoneta wrote: post #21

dkersten wrote: post #4

Earlier quoted context omitted.

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 se…

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 wo…

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.

Re: The Trouble with Multicore

#23

Post by [deleted] » Wed, Jul 21, 2010, 7:19 PM UTC

macemoneta wrote: post #21

dkersten wrote: post #4

Earlier quoted context omitted.

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 se…

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 wo…

[deleted]

Re: The Trouble with Multicore

#24

Post by macemoneta » Wed, Jul 21, 2010, 7:19 PM UTC

tptacek wrote: post #22

macemoneta wrote: post #21

Earlier quoted context omitted.

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 wo…

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…

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.

Re: The Trouble with Multicore

#25

Post by InclinedPlane » Wed, Jul 21, 2010, 7:23 PM UTC

whyenot wrote: post #13

How many different things can a human being think about at once? Maybe 5? 10? probably not an order of magnitude more than that. Maybe part of the problem is that we are running into some limitations of the human brain. Education may help, but maybe we should also take care that we aren't trying to jam round pegs into square holes.

Software development passed outside the realm where a single human brain could fully comprehend the entirety of the project at every level of detail about 5 decades ago. The question is not whether abstractions are required to allow human brains to deal with threading, that's a given, the question is whether or not we have the right abstractions.

Re: The Trouble with Multicore

#26

Post by tptacek » Wed, Jul 21, 2010, 7:25 PM UTC

macemoneta wrote: post #24

tptacek wrote: post #22

Earlier quoted context omitted.

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…

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…

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.

Re: The Trouble with Multicore

#27

Post by pragmatic » Wed, Jul 21, 2010, 7:55 PM UTC

api wrote: post #2

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.

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.