Worldwide demand for more oil sources is huge, and it isn't
going away anytime soon. Oil exploration companies have turned to
the highest tech possible to try and find the next big fields,
and increasingly this mean deep searches, and under deep water.
In order to analyze data collected by ocean research ships, one
of the bright spots now is the use of tuned algorithms being run
on custom
supercomputers using the Cell CPU, because it is outstanding
for 3-d modeling. One company using this tech is reporting that
they are getting results six times faster than current industry
efforts.
"Fidelity of the RTM images reduces the risks associated
with oil exploration in these prolific but complex areas,"
said Francisco Ortigosa, director of Geophysics, Repsol.
"However, the universal use of this technology is limited by
processing speed. The IBM PowerXCell 8i processor's
unparalleled speed for the imaging algorithm allows extensive use
of the technology. By speeding up seismic imaging, we foresee a
revolution in exploration that will be comparable to the
revolution in medical imaging technologies, such as MRIs, that
today routinely yield detailed images from inside the
body."ed.z.: OK, this is off the wall, but I wonder if
they have though of starting a distributed computer project with
the goal of finding more oil sources? I bet if they offered say
small shares in any ultimate finds they would get a lot of
takers. Just a thought.
"...but I wonder if they have though of starting a
distributed computer project with the goal of finding more oil
sources..."
Dont know. But not every problem is amenable to
decomposition such that a distributed project is worthwhile.
I wish I was part of a project using cell processors. I
have been interested in them since I first heard about
them. Of course, I have been wishing I was on a project not
involving .net for longer than that, and I can tell you it has
not gotten me far to date...... Course, I am kinda tangled
in my current money tree.
So, get yourself a PS3 and install Linux on it. Even the
low-end model is fine. The PS3 partitioning scheme is a
little strange. You can either have 10 GB for Linux and the
rest of the drive for the Game OS, or 10 GB for the Game OS and
the rest for Linux. Because I do game I gave most of the
space to the Game OS. But Linux can see USB 2.0 external
hard disks just fine. So I made the 10 GB for software and
mounted my home directory from the USB drive.
But anyway, the Cell processor is an interesting beast. The
256k local store which is all that an SPU (Cell core) can see for
both program and data puts me back into the mindset of years
past. Plus, all the real work is done with SIMD intrinsics;
although I'm using C formatting it feels much more like
assembly. I really love programming the thing, it is almost
zen-like for me.
Get yourself a toy, play with it in your free time, and make
yourself a more valuable programmer so you get can out of that
.Net.
Good idea. I dont know why I hadnt thought of it. I
had guessed that you would have to get close to the hardware to
do more than have an expensive PPC machine. What compiler,
gcc? Or is it something more specialized?
Of course, I will have the kids bemoaning my ruining ( from their
view ) a perfectly good gaming machine ( with them asking me to
buy another... ).
It will have to wait a while till I can afford it.
The Cell in the PS3 are the ones which have only 7 of the 8 SPUs
functioning. Helps IBM improve yields--if a chip is
slightly defective they give it to Sony for the PS3. When
booted into Linux one more of the SPUs is used to run the
hypervisor. You still get 6 to play with, and a dual-core
64-bit PPC which runs the kernel and most other programs.
But you do get full, direct access to those 6 SPUs. So,
while not exactly the same as a Cell blade from IBM or an add-in
card from Mercury, it is about a third of the price and
everything you learn there can be directly applied to the real
hardware.
Yes, the compiler is GCC, but called as spu-gcc to generate the
SPU code. You get a subset of the standard C library, and
even limited C++ support. But I've found the C++ pretty
useless as the overhead of all the extra language features makes
even the most simple program take most of the 256k.
There's also a ppu-gcc which is just a standard PPC compiler
set to generate 64-bit code by default. Yellowdog has their
straight gcc set to built 32-bit executables (unless given the
-m64 flag).
As for "ruining" the PS3. You can't install
just Linux. The Game OS will still be there. Even if
you're booting Linux by default, just running the util
ps3-boot-gameos will turn it back into a game machine. So
while daddy's away the kids can still play.
I use Yellow Dog, because Terra Soft were the first to get Linux
booting on the PS3, and they've been working in the PPC field
forever. The only other choice worth reviewing is
Fedora. Both are well supported. Fedora may be a
slightly more modern distro, but I'm really only interested
in the compiler tools and both are exactly the same in that
respect.
If you just look at available flops, Nvidia's video cards
that are programmable with CUDA would seem to be a good choice.
CUDA comes with libraries such as fft and blas, so any
numerical codes with heavy use of the Fourier transform or linear
algebra would be a good fit, without the need to due
assembly-type programming that the Cell seems to require.
For the project on which I'm working I did first think of
CUDA but while nVidia's GPUs can pull off more FLOPS than the
Cell, they do so because they are more limited in what they can
do.
The the Cell is somewhere between a traditional CPU and a GPU.
While my comment about the SIMD intrinsics made it sound like the
Cell requires assembly-like programming that holds true for any
of the modern MMX, SSE, AltaVec, etc. instructions. CUDA is
just as bad with it's vectorized instructions. And
worse because you aren't actually compiling the code with GCC
but with the CUDA compiler and have to deal with it's
limitations and it's subset of C. The only big thing
the Cell is missing is memory allocations (hell, the Linux kernel
even emulates a basic printf if you want to spit debugging info
from your SPU code).
There are also math libs written to run on the Cell that include
FFTs and everything else of which you can think. You just
call the functions and someone else has already written the SIMD
intrinsics.
I don't know about nVidia's newest 200-series GPUs but
the 8s and 9s were limited to single precision floating
point. There was no way to get them to natively do double
precision work. The Cell on the other hand can. It
does take a speed hit, as the 128-bit SIMD register can only hold
2 DP floats at a time, but it is possible. (I just checked;
the 200-series GPUs do have a single, dedicated, double precision
unit in each shader core so that's 30 in the fully functional
GT200 vs. the 240 single prec units. So that is 1/8 the speed vs.
the 1/2 on the Cell.)
What I'm saying is programming on the Cell feels like
you're programming a regular CPU which has been distilled to
the very essentials. The 256k local store is like doing
your own cache management. Plus it is really cool that the
PPUs can be used to double- (or multi-) buffer the local store so
the SPU can just keep issuing SIMD instructions in a non-stop
fashion.
While I've not actually written any CUDA code that is because
as I started to read up; it really just felt like an awkward
system. I just kept thinking there had to be an easier way
to interface with a streaming, vector processor. That is
when I came across the documentation for the Cell, and it was
like a light came on. IBM and Sony did a good job designing
this processor's ABI. It is quite different but it
makes sense (and libraries are there to cover up the differences
if you don't like banging on the hardware).
Thanks for the first-hand advice. I've been considering
either the PS-3 or an Nvidia card for projects outside of work,
but unfortunately the main issue for me is a lack of energy for
this sort of hobby given its similarity to my job.
In case I ever get far enough along to justify the investment:
Dollar-wise, I think picking up a slightly older Nvidia card that
still supports CUDA might be the way to go, since I already have
a PC with 4 GB memory and a PCI-express 16 slot. On the
other hand, I'll take your enjoyment of programming the PS3
into account.
The Cell for Oil-it's No Game
Worldwide demand for more oil sources is huge, and it isn't going away anytime soon. Oil exploration companies have turned to the highest tech possible to try and find the next big fields, and increasingly this mean deep searches, and under deep water. In order to analyze data collected by ocean research ships, one of the bright spots now is the use of tuned algorithms being run on custom supercomputers using the Cell CPU, because it is outstanding for 3-d modeling. One company using this tech is reporting that they are getting results six times faster than current industry efforts.
"Fidelity of the RTM images reduces the risks associated with oil exploration in these prolific but complex areas," said Francisco Ortigosa, director of Geophysics, Repsol. "However, the universal use of this technology is limited by processing speed. The IBM PowerXCell 8i processor's unparalleled speed for the imaging algorithm allows extensive use of the technology. By speeding up seismic imaging, we foresee a revolution in exploration that will be comparable to the revolution in medical imaging technologies, such as MRIs, that today routinely yield detailed images from inside the body."ed.z.: OK, this is off the wall, but I wonder if they have though of starting a distributed computer project with the goal of finding more oil sources? I bet if they offered say small shares in any ultimate finds they would get a lot of takers. Just a thought.