Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Trouble with Multicore

spectrum.ieee.org

Post reply on HN
Print view View original

11–20 of 27 posts

Re: The Trouble with Multicore

#11

Post by tptacek »

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.

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.

Re: The Trouble with Multicore

#12

Post by wmf »

Nwallins wrote: post #9

The "trouble" is only when you want a single process to monopolize the entirety of CPU resources. In today's (and even yesterday's?) processing environment, there are often tens if not hundreds of processes running at once, and 5 or 15 of them may be "performance critical". Are multicore architectures not able to distribute this sort of load?

On PCs it's common to have hundreds of processes sleeping, but rare to have more than one or two threads runnable.

Re: The Trouble with Multicore

#13

Post by whyenot »

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.

Re: The Trouble with Multicore

#14

Post by ewjordan »

SeriousGuy wrote: post #10
shin_lao wrote: post #8

Earlier quoted context omitted.

This is untrue. First there is a stable boost::thread library available for a while, and second threads made it to the standard as well as futures. I don't think the problem is the lack of a thread library, concurrency requires more than just being able to spawn and wait for threads. Things like tasks managers, concurrent containers and transactional memory wrappers are better answers to the problem.

As someone who learned C++ few years back let me tell you that professors in Universities actively discourage use of Boost. There is C++0x or which contains hashset and hashtable but even use of it is discouraged. I think C++ standardization effort has become a joke and I doubt when we will see them being used in real life. Even funny are people who claim to be waiting for emergence of D.(my professor said that he wa…

As someone who learned C++ few years back let me tell you that professors in Universities actively discourage use of Boost.

I'm curious - why is this? Do they just not like students leaning on libraries at all, or is it something specific about Boost? I suppose supporting an entire classroom of students trying to install/build the thing across a dozen different operating system versions might be something that a professor would want to avoid, but this is a general problem with most tools, so I don't think it should be such a show stopper...

For me, Boost is to C++ as Apache Commons is to Java: literally the first thing I drop in to any project where I'm going to be doing heavy lifting. To some extent, these two mature and highly useful libraries (I guess I should say collections of libraries, really) are the main things the corresponding languages have going for them.

C++ without Boost is just an exercise in pain and humiliation, IMHO...

Re: The Trouble with Multicore

#15

Post by 10ren »

1. Perhaps we need to actually have the hardware before we can start playing with it, and come up with solutions. That's how it usually goes.

2. Maybe they are jumping ahead to "many-core". Instead ask: what can we do with this extra silicon? In the past this lead to cache; pipelining; a faster multiplication technique; on-board maths "co"-processor. Today, it gives us systems-on-a-chip; hardware video-decoding; absurd GPUs; and even physics PUs.

I spoke to the person who developed that multiplication technique, and he said that it was due to extra silicon being available - it was inconceivable before then, in that people did not conceive of it because they could not conceive of something so wasteful of silicon.

Re: The Trouble with Multicore

#16

Post by SeriousGuy »

ewjordan wrote: post #14
SeriousGuy wrote: post #10

Earlier quoted context omitted.

As someone who learned C++ few years back let me tell you that professors in Universities actively discourage use of Boost. There is C++0x or which contains hashset and hashtable but even use of it is discouraged. I think C++ standardization effort has become a joke and I doubt when we will see them being used in real life. Even funny are people who claim to be waiting for emergence of D.(my professor said that he wa…

As someone who learned C++ few years back let me tell you that professors in Universities actively discourage use of Boost. I'm curious - why is this? Do they just not like students leaning on libraries at all, or is it something specific about Boost? I suppose supporting an entire classroom of students trying to install/build the thing across a dozen different operating system versions might be something that a prof…

I wish my professor would listen, this is the course i took http://www.ecs.syr.edu/faculty/fawcett/handouts/webpages/CSE.... The worst part was that we were supposed to parse C++ code without use of any standard grammar system. even regexp werent allowed. We only got a tokenizer.

Re: The Trouble with Multicore

#17

Post by pvg »

tptacek wrote: post #11
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.

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

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.

Re: The Trouble with Multicore

#18

Post by aristus »

tptacek wrote: post #11
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.

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

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?

Re: The Trouble with Multicore

#19

Post by ewjordan »

SeriousGuy wrote: post #16
ewjordan wrote: post #14

Earlier quoted context omitted.

As someone who learned C++ few years back let me tell you that professors in Universities actively discourage use of Boost. I'm curious - why is this? Do they just not like students leaning on libraries at all, or is it something specific about Boost? I suppose supporting an entire classroom of students trying to install/build the thing across a dozen different operating system versions might be something that a prof…

I wish my professor would listen, this is the course i took http://www.ecs.syr.edu/faculty/fawcett/handouts/webpages/CSE... . The worst part was that we were supposed to parse C++ code without use of any standard grammar system. even regexp werent allowed. We only got a tokenizer.

Yowza, Microsoft all over the place in that course...I weep for the commuter student that runs OS X at home and has no desire (or disk space) to dual boot Windows.

That said, the restriction against Boost may be primarily to ensure that people don't rely too much on its features, which would make a lot of those projects almost trivial to solve without actually demonstrating mastery of the underlying concepts. So I suppose it's a worthwhile exercise, but it does bring attention to the main problem with many CS courses, which is that there's never enough emphasis on reusing what other people have already done, whereas when you're programming outside academia, the first thing you should always do is check if someone's already written the code you're about to waste a week on...

Re: The Trouble with Multicore

#20

Post by tptacek »

aristus wrote: post #18
tptacek wrote: post #11

Earlier quoted context omitted.

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

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?

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.

Post reply on HN