EduardoS (no@spam.com) on 8/23/09 wrote:
---------------------------
>? (0xe2.0x9a.0x9b@gmail.com) on 8/23/09 wrote:
>---------------------------
>>This means that while it will be potentially doable to run any Linux
>>process on LRB without reprogramming and even without recompiling, it is an absolute
>>impossibility with CUDA and OpenCL.
>
>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.

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.

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.

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.
2. Reprogram selected code to run efficiently in CUDA/OpenCL computing model. Do this in CUDA/OpenCL.

-----

In a land far far away, a novice was asking an expert about CUDA/OpenCL:

Novice: I am going to program in CUDA/OpenCL. Will you help me?

Expert: Of course, why not?

Novice: So, I know Java, some C/C++, know how to open a file, draw on the screen using Qt, and I know how to use a bunch of other libraries. So I guess, I will be using those languages and libraries while programming the GPU.

Expert: Err...actually...no.

Novice: I've got some scripts written in Bash. I am going to try to use them on the GPU.

Expert: Err...actually...you cannot do that.

Novice: Look what I did. I broken down the problem into tinier pieces. You can think of them as tiny jobs executable in parallel. I have a system with a couple of worker-threads with job-stealing. I suspect that several types of the tiny jobs could utilize SIMD. So, I am now going to try to adapt this framework to CUDA/OpenCL.

Expert: Err...actually...that is not going to work.

Novice: My younger brother just learned how to compute a factorial by using simple recursive invocation of the factorial function. He wants to run it on our shiny new GPU. He thinks that reprogramming the function performing multiplication of arbitrary precision numbers can be nicely parallelized.

Expert: Err...actually...he cannot use recursive invocation. Just tell him that he is stupid, or that recursive invocation is evil, or that the teacher in his school does not know what real computing is about, or something. But whatever you say to him, please, do not blame NVidia.

Novice: Look, look, I have my own optimized malloc! It works nicely for the allocation patterns in my program.

Expert: Err...well...actually...

-----

Citations from "Seiler, et al: Larrabee: A Many-Core x86 Architecture for Visual Computing":

The instruction decoder supports the standard Pentium processor x86 instruction set, with the addition of new instructions that are described in Sections 3.2 and 3.3.

Larrabee provides modern additions such as multi-threading, 64-bit extensions, and sophisticated prefetching. The cores support the full Pentium processor x86 instruction set so they can run existing code including operating system kernels and applications.

Citation from "Abrash: A First Look at the Larrabee New Instructions":

In short, Larrabee is an enhanced x86 architecture; it supports all the familiar general-purpose programming techniques and tools used on CPUs for decades, and is much like programming a lot of Core i7 cores at once. Because initial configurations are designed for use as GPUs, they lack chipset features needed to serve as a main CPU running, say, Windows; nonetheless, they are fully capable of running operating systems and general applications. For example, Larrabee, running as a GPU device under Windows, can bring up a BSD OS, with the Larrabee graphics pipeline running as just another BSD application.