Slashdot Mirror
Larrabee ISA Revealed
David Greene writes "Intel has released information on Larrabee's ISA. Far more than an instruction set for graphics, Larrabee's ISA provides x86 users with a vector architecture reminiscent of the top supercomputers of the late 1990s and early 2000s. '... Intel has also been applying additional transistors in a different way — by adding more cores. This approach has the great advantage that, given software that can parallelize across many such cores, performance can scale nearly linearly as more and more cores get packed onto chips in the future. Larrabee takes this approach to its logical conclusion, with lots of power-efficient in-order cores clocked at the power/performance sweet spot. Furthermore, these cores are optimized for running not single-threaded scalar code, but rather multiple threads of streaming vector code, with both the threads and the vector units further extending the benefits of parallelization.' Things are going to get interesting."
The story title conjured up images of the boxes of ISA cards I've still got sitting around. Ah, the joys of setting IRQs... good times.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
IA64 was rejected because it was too lean. It's actually a horrendously complicated ISA which requires the compiler to do a lot of the work for it, but it turns out that compilers aren't very good at the sort of stuff the ISA requires (instruction reordering, branch prediction etc.) It also turned out that EPIC CPUs are very complex and power-hunger things, and IA32/x86-64 had easily caught up with and surpassed many of the so-called advantages that Intel had touted for IA64.
The only reason Itanium is still hanging around like a bad smell is because companies like HP were dumb enough to dump their own perfectly good RISC CPUs on a flimsy promise from Intel, and now they have no choice.
There are lots of instructions and other craft inside 80x86 processors that occupy silicon that is never used. A clean break from 80x86 is needed. Legacy 80x86 code can run perfectly in emulation (and need not be slow, using JIT techniques).
All the legacy junk takes up a pretty small fraction of the area. IIRC on a modern x86 CPU like Core2 or AMD Opteron, it's somewhere around 5%. Most of the core is functional units, register files, and OoO logic. For a simple in-order core like Larrabee the x86 penalty might be somewhat bigger, but OTOH Larrabee has a monster vector unit taking up space as well.
What I like most about Larrabee is the scatter-gather operations. One major problem in vectorized architectures is how to load the vectors with data coming from multiple sources. the Larrabee ISA solves this neatly by allowing vectors to be loaded from different sources in hardware and in parallel, thus making loading/storing vectors a very fast operation.
Yes, I agree. Scatter/gather is one of the main reason why vector supercomputers do very well on some applications. E.g. scatter/gather allows sparse matrix operations to be vectorized, and allows the CPU to keep a massive number of memory operations in flight at the same time, whereas sparse matrix ops tend to spend their time waiting on memory latency when you have just the usual scalar memory ops.
The programming languages that will benefit from Larrabee though will not be C/C++. It will be Fortran and the purely functional programming languages. Unless C/C++ has some extensions to deal with the pointer aliasing issue, that is.
There is the "restrict" keyword in C99 precisely for this reason. It's not in C++ but most compilers support it in one way or another (__restrict, #pragma noalias or whatever). That being said, I'd imagine something like OpenCL would be a more suitable language for programming Larrabee than either C, C++ or Fortran. Functional lnaguages are promising for this as you say, of course, but it remains to be seen if they manage to break out of their academic ivory towers this time around.
So that is where the term "EPIC FAIL" comes from...
Any sufficiently advanced intelligence is indistinguishable from stupidity.
I'm gonna go ahead and agree with management that maintainability is more important than any other factor. Having had to maintain a few ancient codebases is my day, I've seen way too many "clever" coders that do ridiculous tricks to save time or space. Well designed (read: maintainable) code does not imply any significant performance hit.
If you watch large teams of programmers, the managment actually force the developers to write slow code, claiming that maintainability is more important than any other factor!
I don't see why it should be one or the other - maintainability is important, as is using optimal algorithms. Fast algorithms can still be written in a clear and understandable manner.