

Intel: an expensive many-core future is ahead of us - cadalac
http://arstechnica.com/news.ars/post/20080702-intel-an-expensive-many-core-future-is-ahead-of-us.html

======
akeefer
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.

~~~
iamelgringo

      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.

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

~~~
IsaacSchlueter
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! :)

------
pmorici
"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?

------
brooksbp
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...

------
axiom
Intel Thread Building Blocks [http://www.intel.com/cd/software/products/asmo-
na/eng/294797...](http://www.intel.com/cd/software/products/asmo-
na/eng/294797.htm)

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.

~~~
Kaizyn
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?

------
ComputerGuru
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.

~~~
Retric
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.

~~~
LogicHoleFlaw
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.

------
Hexstream
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.

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

~~~
ibster
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.

------
bprater
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?

~~~
Tichy
"640K ought to be enough for anybody"

------
ntoshev
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.

~~~
jrockway
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.

~~~
ntoshev
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.

