Lambda the Ultimate

Sony and IBM plan to sell these chips in huge volumes. Two new fabs is a huge investment in such a down chip market as we have seen these last few years. They don't even need the PC desktop to succeed. Paul merely opines that cell PCs don't need video cards, audio cards, etc. So they are both cheaper and more powerful. That will be a hard combination for the market to resist. People are already putting Linux on just about everything in sight, even Apple iPods. It will be a natural fit.

You may recall when the IBM PC emerged. There were better machines around. What IBM PC had going for it was not Charlie Chaplin, nor technical merits, but cost.

Languages should not focus exclusively on the desktop. Language research struggles for wider and better abstractions, but then cripples itself by narrow desktop strategies. There are more embedded processors manufactured each year than exist people on the planet. These processors include DSPs and FPGAs. Even PIC microcontrollers are getting downright respectable. It is time that language researchers started thinking about parallel computing, real-time, microcontrol, etc. As I keep saying, governments around the world are dropping money for that sort of thing.

I know one thing for sure- getting "classic" threads and mutexs based multithreaded programs to scale that far is nigh onto impossible.

I disagree, since the parallel support is on the processor, it makes software simpler than threads and mutexes. But why does old code have to scale at all? It will just run 100 times faster as-is, under emulation if need be.

The problem is that to take advantage of the increased performance, you will have to write super-parallel programs. We're not just talking about two or a dozen parallel threads, we're talking about hundreds or thousands.

You are right that only naturally parallel languages will make the cut. These languages exist today, and yes, they handle thousands of lightweight threads: Oz, Erlang, Felix, Alice ML, etc. In my mind that outcome will be a very, very good thing. Goodbye, dumbed-down, single-track languages; hello to parallel power.

I disagree, since the parallel support is on the processor, it makes software simpler than threads and mutexes. But why does old code have to scale at all? It will just run 100 times faster as-is, under emulation if need be.

The problem with architecture today is that we have essentially given up on trying to speed up serial algorithms. The emphasis is on parallelism, instruction-level and up. This is certainly easier on the designer, but Amdahl eventually bites you in the ass.

I don't understand how the old code is going to run a 100 times faster as-is.

Oh, gosh, that is simple. What changes is the thread/mutex library (that is the emulation). Wrap the old thread library's API around the new chips, leaving the application code alone. Recompile and link. So now ultra-fast hardware imitates a thread/mutex library that was once purely software. There are two speedups. One is the move to hardware. The other is the change from serial thread multiplexing to real parallel threads. One may argue about the tantalizing performance reports on this chip as a third speedup factor, i.e., it's just a faster chip.

I don't see any need for x86 emulation per se. Sorry if I confused you. The code just needs to be recompiled, modulo the thread library port, which is more involved, but of limited scope. All of which is just for backwards compatibility anyway. What is exciting is the prospect of new, parallel programs in new, parallel languages.

Serializing a parallel algorithm is easy; parallelizing a serial one is hard.

I proposed no such thing. Presumably, an old program using threads is already parallelized. Algorithms qua algorithms are not programs, and have their own issues. At least with parallel hardware we'll be only theory-constrained, not hardware-constrained.

How does parallel programming become easier when it is supported in hardware?

Parallel programming becomes easier with proper language support. Well, I said "since the parallel support is on the processor" but later qualified with "only naturally parallel languages will make the cut," making my notions explicit, I hope. The idea is of parallel processors coupled to languages that exploit the hardware and remove complexity. A huge difference separates good languages from bad ones on this score. The bad ones create an illusion that parallel work is intrinsically hard, as the CTM preface observes:

Concurrency in Java [and its ancestor, C/C++] is complex...and expensive....Because of these difficulties, Java-taught [and C-taught] programmers conclude that concurrency is a fundamentally complex and expensive concept. Program specifications are designed around the difficulties, often in a contorted way. But these difficulties are not fundamental at all. There are forms of concurrency that are quite useful and yet as easy to program with as sequential programs....Furthermore, it is possible to implement threads, the basic unit of concurrency, almost as cheaply as procedure calls. If the programmer were taught about concurrency in the correct way, then he or she would be able to specify for and program in systems without concurrency restrictions (including improved versions of Java).

As for your comment that scaling doesn't matter, I agree that it will be fine as long as there are a LOT of threads with no dependencies between them. Otherwise, the speed of that code is going to be very reliant on the "third speedup factor", and the memory performance of the chip.

I earlier interpreted your comment to mean that the emulator magically translated an x86 program with a few threads to a massively threaded native Cell one. I think that would be difficult to accomplish.

Language support is helpful, but constructing efficient parallel algorithms is always hard, particularly when you have to take into account communications costs (including memory). Coding for Cell sounds a lot like coding for NUMA machines. Performance there is always dependent on memory access costs where the languages are unlikely to be of much benefit.

As for your comment that scaling doesn't matter

Sigh. Note what I said: why does old code have to scale at all? and exciting is the prospect of new, parallel programs in new, parallel languages. The old code contrasts new, parallel programs. How you derive from these remarks "scaling doesn't matter," is beyond me. Old code just needs a transitional phase, not perpetual maintenance. No one writes 16-bit code anymore, and that change did not take forever. The change to parallel hardware and software may well resemble it.

I earlier interpreted your comment to mean [something that is] difficult to accomplish.

Irrelevant misinterpretation, then.

constructing efficient parallel algorithms is always hard

In the first place, disambuiguate algorithms from programs. In the second place, there exist parallel-friendly "algorithms," too. Finite-element simulation engineers would beg to disagree with your assessment, as would graphics programmers. Some algorithms can be naturally parallel, just as others can be naturally serial. The problem today is that we have only one form of hardware, so the constraint is tighter than the algorithm itself.

This yes-it-is/no-it-isn't debate feels like Slashdot now, so I will bow out. Sony and IBM appreciate the merits of parallel processors to the tune of a billion dollars, along with the authors of CTM, so I stand in good company.

Maybe Peter Van Roy will offer some thoughts. I have spilled enough electrons.

First, my comment was made in the context of Hurt's original remarks on legacy code and I think it accurately reflects your comment: "Why does old code have to scale at all?"

I don't think it's clear that Cell will run old code faster in emulation or even with a recompile. It's going to depend on specifics within the architecture.

Legacy code is important. No one writes 16 bit code anymore, but I know plenty of people who still run it. Cell will have a hard time gaining traction (beyond game machines and supercomputers) if everything needs to be rewritten for it.

Next, the two examples about parallel friendly algorithms are only friendly on SMP machines. I haven't read anything technical on Cell, but it doesn't appear to have SMP behavior. You keep writing that I need to keep programs separate from algorithms, but the suitability of an algorithm is going to be affected by the architecture, not just its expression. Once you move away from von neumann, you have to choose some other abstraction. Languages assume those abstractions and performance suffers if the abstraction doesn't match the underlying architecture. Concurrency in C is painful because C's assumptions don't match what the programmer is trying to accomplish. Similarly, Cell seemingly specifies a very odd set of assumptions that I don't think match the languages you mentioned (I'm not familiar with all of them, but aren't they all PRAM?) Perhaps a clever compiler can hide that complexity, but I doubt it.

Cell looks like an interesting architecture. If it's successful I will be happy, since it will spur compiler research. But your comment about Sony and IBM and a billion dollars brings to mind the obvious parallel of Intel and Itanium (also an interesting architecture).

I doubt that most applications as found on linux will function correctly if taken from emulated threading to real threading.
From the description of cell computing it seems to biggest profit would be in the local memory, a concept that is not very compatible with the global memory model for which most c programs are written.

I agree that languages should not focus on the desktop. But if you're going to predict the death of the x86, then you have to predict a change of CPU on the desktop- or the death of the desktop.

Yes, there are several attempts at serious multi-threading (you forgot Cilk and JoCaml, among others). It's quite possible that one of them is the solution. But notice- the existance of the language doesn't make it popular. None of the languages we've listed come close to being popular compare to Java or C++. As a crude measure of popularity, wander down to your local bookstore and compare the number of books on Java or C++ to the number of books *total* on all Lisp derivitives.

This isn't right, isn't fair, and isn't good, I agree- but it *is*.

Recall I said that Languages should not focus exclusively on the desktop. Also, Abandonment is relative means that I personally expect the x86 to live longer than does the author. Nor do I forget Cilk. You should also review Flow Java from the CTM folks. On popularity, well, 16-bit code was popular once, too.

The problem isn't the dependency in the order of the operations, but in the possible side-effects of such operations. The compiler should be able to prove that doing these things in parallel is equivalent to doing them serially, so it should be able to prove that the piece of code is thread-safe.

What if the programmer simply specifies that it is safe to do the items in parallel, would it work then? Or are there other problems?

the program would crash or give wrong results. This is very tricky if you don't have referential transparency. OTOH if you have RT then the compiler can do any tricks as long as the code isn't explicitly serialized (e.g. monads).

I think this is where there is much to be gained.
Personally i would use java with a few added keywords to spawn these subtasks, still how do you manage to only push the needed pages to the cells local memory ?
A kind of two stage paging ? where the main ram becomes a cache before the virtual memory stored on disk ?

Side effect free funcitonal programming and array oriented languages could have an advantage on cell processors.

JITting for emulation of older architectures (x86) may be one such application, perhaps something like a parallel version of the SoftPear approach. So one branch translates x86 opcodes into native opcodes, while the other pipe executes them.

A small response on Ars Technica winces at some parts of Blachford's analysis.

--Shae Erisson - ScannedInAvian.com

After reading the "analysis" article yesterday I felt the urge to post some flamebait; glad that Ars Technica already responded in a nicer way :-)