Transmeta Meets Blades
The Griller writes "Gordon Bell, one of the creators of VAX, and Linus Torvalds were at the launch of a new supercomputing platform at the Los Alamos National Laboratory. Based on Crusoe processors from Transmeta and running a version of linux, it is aimed at being cheaper than conventional supercomputers by requiring no cooling and lower maintenance.
" Basically, it's blade clustering, using Beowulf.
It all comes down to "power consumption, size, reliability and ease of administration", apparently.
And the marketing people at RLX Technologies should be shot for not having a press release up for this, as it's all based on their product...
Strongarm has no FPU and is not as fast as a Crusoe.
A Pentium III still needs way more energy than a Crusoe. You have to keep in mind that those energy savings of Intel ships are usually accomplished by lowering the processor clock rate which will not help very much if you need processing power. The Crusoe also changes the clock rate, but does so dynamically, so that you always have the speed you need. Additionally, it has far fewer transistors and therefore needs less energy even at full speed.
***Quis custodiet ipsos custodes***
Obviously you are not familiar with the ARM family of processors - they are very similar to the Crusoes, and in particular they don't require any active cooling either.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Ok, finally that's a legitimate response. It's true ARM doesn't include an FPU. However, the last I checked (and I'm not real up to date on it) using libfloat it had emulation good enough to keep up with IA32 fairly well on FP.
I imagine, though, this is probably the reason. It seems reasonable that Supercomputer work would require some FP, although I don't know for sure.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Actually, vector processing is essentially useless for most scientists as long as the compiler doesn't autovectorize the code.
// init it somehow // init it somehow
// result is a vector
Thats wrong. The rest of your post also.
double x[veclen];
double y[veclen];
double scalar_product = 0;
for (int i; i less_than veclen; i++) {
scalar_product += x[i] * y[i];
}
This above is scalar code. Any compiler aware of a vector processor compiles that to a singel vector processor instruction. At least that was the case 14 years ago when I worked on vector processors.
I'm not sure if Altivect is a true vector processor, I think it supports like MMX only very limited SIMD processing, but I'm not sure as I say.
Operations on "arrays", hence vector processors, are very easy to map on vector processing units.
Regardless if it is as easy as above or if you have offsets or gaps like i+=3 in the loop above.
Same is true if the result is a vector again of course.
Manual vector processing instructions get interesting if the loop aove would calculate a vector and that vector was nput for a further stage.
Like this:
Vector a, b, c, d, e;
Scalar i, j, k;
a = i*b + j*c;
e = a + k*d;
Ususlay you would have loops calculating that, the second loop would run after a is completely calculated.
If there is a second vector processor (or just a unit on the processor) you can feed a dirctly into it tocalculate e.
AND THIS is hard to figure for a compiler. Probably youment that. As all vector units are different in that respect there exist fortran libraries with standard subroutines for that.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.