Potatoswatter (potswa_m@c.com) on 8/23/09 wrote:
---------------------------
>? (0xe2.0x9a.0x9b@gmail.com) on 8/23/09 wrote:
>---------------------------
>>EduardoS (no@spam.com) on 8/23/09 wrote:
>>---------------------------
>>>And why someone would ever want that when running those process on a normal CPU would be much more efficient?
>>>
>>>With the need to recompile (I'm being nice, you ill probably have to rewrite, like
>>>you need for OpenCL/CUDA/Brook+) code for Larrabee to get some improvement the x86
>>>compalibilty is just marketing BS, a marketing BS that works tought, with so many
>>>people repeating that Larrabee will be easier to program...
>>
>>You are underestimating the significance of "the ability to perform small incremental
>>improvements to the existing code-base". A typical scenario for optimizing *parallelizable*
>>code for LRB *will* in many cases look like this:
>>
>>1. Reprogram selected code to run with 50+ threads. Do this in C/C++/Python/whatever
>>programming language. The code can still use all Linux system calls, standard
>libraries and almost all other libraries.
>>2. Repeat step 1 until you get it right.
>>3. Reprogram selected code to take advantage of SIMD. Do this in C/C++/whatever
>>language with a library that has support for Larrabee.
>>4. Repeat step 3 until you get it right. Sometimes you will have to go to step 1.
>
>Alas, 50x multithreading isn't trivial. If things worked that way, we'd already
>be using tons of little processors. Larabee works with units equivalent to a 486,
>but why weren't we working with 50x 68000's ten years ago?

Maybe because it was technically impossible to place 50 such cores on one chip? Even if one imagines that it could have been done, the price of such a chip would be astronomical.

>see http://en.wikipedia.org/wiki/Amdahl%27s_law
>
>You're presuming that Python, Linux+Bash, whatever open-source support libraries,
>are perfectly suitable for a massively parallel HPC setup,

Well, not really. The basic idea behind my suggestion is that the "space" available to LRB is much larger than the "space" available to CUDA/OpenCL. By "space" I mean the totality of options you have at your disposal as a programmer. A hypothetical scenario involving Python might include optimized functions implemented in C which are being called from Python. In addition, the C functions will be able to do anything a usual C function can do, including invoking Python code from C. Can anyone tell the same in the context of OpenCL?

I am not implying it will be trivial.

> and they're not. HPC
>Linux has been around for ages and it's still nontrivial.

I didn't mean to imply it will be trivial.

>GPUs just as often give a boost from single-threaded SIMD operation and beefy memory chips as from being multicore.
>
>But it's easy to saturate the memory with a few pointers when there's no cache.
>It will be interesting to see how Larrabee does with GPU-like programming effort, but it will do TERRIBLY without that.

My educated guess is that single-threaded non-SIMD performance of LRB will be somewhere between the performance of Atom and Core2. I would not call this "terrible".

>A developer like your novice will repeat step 1 to frustration, and maybe then
>implement SIMD on a conventional processor to possibly some gains.
>
>>Notice that if you end at step 2, your program will be able to run *without recompilation*
>>on both Core2/Phenom/Atom/etc AND Larrabee.
>
>Running terribly without recompilation doesn't get you much of anywhere. In the
>best case where they use a programming tool which says "eliminate this mutex 4 tha
>winz", and it points into their runtime, they'll just be giving up that much faster.

1. Why?
2. Are you implying that in OpenCL it will be easier? Unlikely.

>>Notice that if SIMD-ize you program, it will be able to (sub-optimally) run *without
>>reprogramming* on Core2/Phenom/Atom/etc. You *just* need to recompile it. Why? Because
>>Intel already provided developers with a C library which is emulating all LRB instructions.
>
>Or just use SSE. Oh yeah, I forgot, SSE leaves all the performance on the table by not being 16-way.

1. The library is already able to utilize SSE. So at least it will be 4-way or 2-way (in certain cases).
2. A small speedup is caused by the fact that Core2/Phenom are out-of-order 3-4 issue cores, while LRB is not. This is quite important for estimating execution time of LRB instructions on Core2/etc.

>>And CUDA/OpenCL:
>>
>>1. Restructure your code to work without nested function calls, pointers to pointers,
>>bit-fields, system libraries, OS calls, and any other libraries you are usually
>>using. What a nice and easy step this is! You will truly feel like living in the 1950s.
>
>Nested function calls, structures, and bitfields are all fine far as I know. You're
>faster without them, but they work. You shouldn't need any libraries beside Linpack/Lapack.

I don't recall any game engine which heavily uses Linpack/Lapack. And neither any ray-tracing engine. I do not recall any dynamic code generator which uses Linpack/Lapack. I do not ...

>If you are, you'll likely be in Amdahl's law doo-doo.
>
>>2. Reprogram selected code to run efficiently in CUDA/OpenCL computing model. Do this in CUDA/OpenCL.
>
>CUDA sucks, but OpenCL shows some promise to me. In any case, HPC has always required
>some thought and will for the foreseeable future. You have to understand that you only go as fast as the weakest link.

Are you implying that the speed of data accesses in your program equals to the speed processor<->memory? Or to the speed register<->disk, or register<->network?