Intel: an expensive many-core future is ahead of us | Hacker News Reader

Intel: an expensive many-core future is ahead of us

arstechnica.com

28 pointscadalac22 comments

I remain unconvinced that software development will ever be able to make that kind of a titanic shift; people naturally think in serial and accomplish tasks in serial, and many programming tasks simply don't break down neatly into highly-parallelizable chunks. For example, you can parallelize at the web request level, but are you really going to start parallelizing the rendering of the output of that request? Would you bet your website on you being able to get that 100% correct, or would you rather trade off some speed for the sake of correctness and implementation ease?

To put it another way, parallelization is a cost-benefit analysis; having more cores changes the "benefit" side of the equation but not the "cost" side, and I don't see any magic bullet coming that will drastically alter the "cost" side. Increased use of multiple cores at the lowest level will only happen thanks to better tools and frameworks that keep people from having to think about threading/parallelization themselves. As soon as you have to worry about ordering dependencies, you've entered a world where implementation is very difficult and testing/verification is nearly impossible. Most applications right now are "fast enough" to make correctness and implementation ease far more important concerns than raw speed.

So you might see people migrate to frameworks that allow for easier parallelization, and web applications will obviously benefit, but I doubt you'll see any fundamental change in how people write software.

  many programming tasks simply don't break down neatly into highly-parallelizable chunks.

You're exactly right. The answer to multi-core programming isn't to run serial programs in parallel. The answer to multi-core programming is to solve a different class of problems.

There are large categories of problems that have been known to be embarassingly parallel for decades. It's those problems where the growth will be in the computer industry: graphics rendering, video and audio processing, data mining, etc...

My bet is that OS's are going to have a lot more eye candy in the next decade or so.

This is good news for great programmers. Anything which helps to easily stratify (and hence appropriately reward) the great from the average is welcome.

While I want to believe that, I think that there will always be a place for mediocre programmers, and the factors that make mediocre programmers better or worse have roughly the same effect on great programmers.

It IS, however, great news for great languages. Our existing set of programming languages are great for abstracting away the nuts and bolts of registers and processor commands, but not so great for making it straightforward for programming on a cluster instead of a single processor.

Long live Erlang! :)

"Having to write programs of that scale on systems with hundreds of processors is difficult and totally alien to the vast majority of developers out there."

Since when is writing multi threaded applications an "alien" concept. haven't preemptive multi tasking operating systems been around for decades?

This basically marks the transition from software engineering transforming into hardware engineering. No longer is it about sequential algorithms, it's not about linearity. It's about destroying sequential algorithms; breaking down large sequential algorithms into smaller algorithms manipulating the same data at the same time. This requires a great amount of brain power and essentially helps us understand algorithms in greater detail, and make them run faster, but in no way would I agree that it helps software functionality.

EDIT: It provides more power to the programmer. Power that is useless for a programmer that wants to develop functional software. This is why new languages and more CS/EE research will be involved. More power == more levels of abstraction. It depends on the level of abstraction that you're working with to decide whether you're going to benefit from performance or expressiveness (code expressiveness, which I like to directly correlate to software functionality independent of code performance).

I love shitting my brains out on this type of stuff; Could be right, could be wrong. All I know is that the future is undef... and I enjoy it...

Intel Thread Building Blocks http://www.intel.com/cd/software/products/asmo-na/eng/294797...

It makes writing apps that take advantage of multi-core architectures almost trivial. We've benchmarked it on our machines and on Amazon EC2 with very impressive results.

Also, RapidMind has some nice libraries that allow you to fairly easily parallelize code to optimally take advantage of multi-cores and GPUs. Although their licensing is obscenely expensive at the moment.

I'm sure this works great when you can split up your application to 2-10 threads. But how well will your programs work when you have to cope with 200-2000+ cores?

It looks like we're going to be wishing the GHz wars were still going on pretty soon.... All my software is multi-threaded, but not in a way that would make it any faster on 200 threads than maybe 4 maximum. It's not (as Ars makes it seem) an issue of my deciding to split the code into only 4 sections; it's a matter of launching new threads when you need them instead of whenever you can just for the hell of it.

For instance, my usage of multi-threaded code is to to keep the UI alive and responsive while firing off threads in the background to accomplish different things. A thread for each independent procedure being done in the background - but the problem is that there simply aren't enough procedures happening at once to go around!

Not all programs are just a single big mathematical problem being analyzed that can be split to an arbitrary number of threads, most of the time, most of the software, you just can't spread your code to an infinite number of CPUs - it would be stupid to even try.

Instead of getting into a pissing contest over core counts (anyone remember the tri-core AMDs?!?) the chip giants should be focus on better instruction sets, improved pipelining, lowered energy consumption, and - yes - even faster clock speeds... just not at the cost of performance as they had in the past.

Intel would like to charge people more for multi core CPU's because they are easy to design, but don't forget each of those new cores can still do 1,000,000,000's of operations per second. If your app works fine on say a 1GHz single core PIII then nothing is wrong and there is no point in writing multi core code. Anyway, it's not like Intel is going to build a CPU than can't run single core code as fast as their current crop of CPU's so I don't see any problems.

Adding cores to a CPU is not quite as trivial as all that. You have to consider the implications of shared memory and caches and the overhead of bus traffic between the cores. As the number of cores increases the overhead begins to dominate the design rather than the cores themselves.... there's been lots of good research on how to overcome those issues but it's very much an open problem at this point.

That's mistaken. It's likely that they will start stepping down per-core CPU speeds in the name of reducing the heat given off by each core. This would let them pack even more cores in and improve the 'overall capability' of the "chip".

There's at least one advantage to such a future.

Correct me if I'm wrong, but a great many of the techniques you use to scale to multiple cores in one machine can be used to scale to multiple machines. So you can practice your parallel processing skills and improve your tools in that area by just buying one computer instead of buying or leasing, say, 32. Programming for clusters won't be quite so arcane anymore.

Not really. You can practice cluster programming on a single core and your OpenMP, TBB, and Cilk++ programs won't run on a cluster.

While it's true that a Cilk++ app will run within a shared memory node, you can certainly run multiple Cilk++ apps on a cluster of nodes, if the goal is to increase app throughput.

You know -- there aren't a vast number of consumer-facing applications that really need this kind of power.

Video games? Ripping a DVD? Editting video?

And what does this mean? As a hacker, am I forced to target my tiny little application to multiple cores?

"640K ought to be enough for anybody"

Multicore is nothing special if you are doing web apps. So I guess the trend towards multicore and the trend towards web apps will reinforce each other.

Yep, let the people writing the web servers, app servers, languages, and libraries deal with multicore. I'll happily run on those uber-optimized platforms.

Well as good as this sounds, if you want to scale you will need to know more then just how to use free software.

Untrue.

Now that CPU time is really cheap, memory is expensive again. For example, I have a $30/month slicehost and only get 512M of RAM. Even though I have 4 cores on that box, my application uses too much memory per instance for me to be able to run 4 separate processes. So if I needed to scale, I would either need to buy more memory, or design my app better. Buying more memory works for 4 cores, but what about 128? Probably not.

Yeah, memory handling of Ruby is severely broken. Enterprise Ruby might help you.

If you use thread-based model for handling web requests (JVM or .NET application), you won't have this problem. I think even Python processes would share most of their memory.

Reply on news.ycombinator.com