The Cell for Oil-it's No Game

Fri Jul 04 19:55:00 -0700 2008
manage

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.

The Cell for Oil-it's No Game
Fri Jul 04 21:03:45 -0700 2008
manage

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

Get a PS3

Fri Jul 04 22:08:21 -0700 2008
manage

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.

(It's also a great media player.)

Get a PS3
Fri Jul 04 22:33:22 -0700 2008
manage

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.

Thanks!

Get a PS3
Sat Jul 05 01:07:12 -0700 2008
manage

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.

Get a PS3
Sat Jul 05 10:37:52 -0700 2008
manage

Thanks for the information!

Is there any particular Linux you recommend?  I saw YellowDog mentioned in your post.

Thanks again!

Get a PS3
Sat Jul 05 12:58:19 -0700 2008
manage

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.

Get a PS3
Sat Jul 05 13:05:50 -0700 2008
manage

Thanks!

Cell vs. Nvidia's CUDA

Sat Jul 05 07:50:56 -0700 2008
manage

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.

Cell vs. Nvidia's CUDA
Sat Jul 05 13:43:20 -0700 2008
manage

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

Cell vs. Nvidia's CUDA
Sun Jul 06 11:59:22 -0700 2008
manage

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.