AMD does reverse GPGPU, announces OpenCL SDK for x86

[saaya]

nice post francois...
but i think you exaggerate a bit on how dificult it is to code for gpus

and talonman, i dont think this means amd has problems with opencl on their gpus... i agree with francois, if anything this shows amd is focussing on making opencl useful by delivering a cpu open cl interface... nvidia brags about having the first gpu opencl driver yet how francois pointed out, how useful that actually is remains to be seen as its rather limited afaik. you can do the same thing on a cpu and gpu with opencl i guess, more or less, but most things will be pretty slow on a gpu.

[trinibwoy]

you can do the same thing on a cpu and gpu with opencl i guess, more or less, but most things will be pretty slow on a gpu.

You've got that backwards.

[FischOderAal]

You've got that backwards.

Why? I'm a noob but I'd guess that the possibilities to use the GPUs are limited, for instance due to the need of highly parallelized workload. Does that happen often?

[trinibwoy]

Ask yourself this. Why would you need OpenCL on a CPU if you have C/C++? These languages are designed to take advantage of highly parallel machines, they provide no benefit on a CPU over existing languages.

[zanzabar]

Ask yourself this. Why would you need OpenCL on a CPU if you have C/C++? These languages are designed to take advantage of highly parallel machines, they provide no benefit on a CPU over existing languages.

they provide and advantage for x86, think of the new intel servers they have some out or close to out with 32 threads. and there is no reason to not have openCL of x86 not only do it allow for ease of testing its not like people dont use other languages that already have competitors.

[trinibwoy]

they provide and advantage for x86, think of the new intel servers they have some out or close to out with 32 threads. and there is no reason to not have openCL of x86 not only do it allow for ease of testing its not like people dont use other languages that already have competitors.

OpenCL doesn't give you any advantage over C++ no matter the number of threads. It's not magic, just a framework to help you formulate a solution. It provides an advantage on a CPU when you're testing/prototyping something you plan to run on a GPU or when you want to run the serial part of an application on a CPU with the data parallel part running on a GPU. CPU only applications won't see any benefit in OpenCL over regular programming languages. Don't get me wrong, it's great and it's needed. I'm just clarifying that most OpenCL applications will most certainly not be targeted at CPUs as there are already way more powerful and flexible options for doing so.

[Talonman]

+1

It is a positive thing to have OpenCL being able to process on a CPU, but for animal speed, OpenCL on a GPU would win.

That is why I think if Havok physics is able to run on GPU's via OpenCL, Havok will only be able to give us better performance than it currently does running on CPU's.

[Drwho?]

Ask yourself this. Why would you need OpenCL on a CPU if you have C/C++? These languages are designed to take advantage of highly parallel machines, they provide no benefit on a CPU over existing languages.

The answer to your question is simple ... OpenCL or Direct Compute are abtraction layers that facilitate the vectorization and parallelization.

when you provide the loops to a CPU, it is surprisingly fast on OpenCL.
The geniuses of Video games almost all agree: They want many cores, with Caches , fast interconnect, and fast RAM ... This architecture is closer from CPU than GPU: http://graphics.cs.williams.edu/arch...TimHPG2009.pdf
Tim makes a lot of sense in his presentation ... the title is a little misleading, so, move into the presentation, and you ll understand his overall point...
GPU will have to become so close to the CPU, that Instruction per clock will rebecome the St Grall ... and we all know who can generate the best Instruction per clock architecture ... humm hummm ;-) the x86 vendors ...
Because IPC is what drives your power saving, good instruction per clock drives your power down , because you need less MHz to archive the same Performance ...
Pentium 4 vs Athlon 64 and then Core 2 illustrate the path ... apply this to GPU converging to CPU.

does it clarify it for you?

[trinibwoy]

The answer to your question is simple ... OpenCL or Direct Compute are abtraction layers that facilitate the vectorization and parallelization. when you provide the loops to a CPU, it is surprisingly fast on OpenCL.

Which you can already do in C++. Why go through some additional layer coded by a third party that will invariably make your code slower? The entire reason for the existence of OpenCL is to make GPU programming easier.

The geniuses of Video games almost all agree: They want many cores, with Caches , fast interconnect, and fast RAM ... This architecture is closer from CPU than GPU: http://graphics.cs.williams.edu/arch...TimHPG2009.pdf

Thanks but I've already read that presentation thoroughly and posted it here. I'm not sure how you arrived at the arbitrary conclusion that the future of computing looks more like a CPU than a GPU. Lots of cores, fast interconnects and fast RAM are all GPU qualities. So even based on your own list your statement is false.

does it clarify it for you?

Not sure what point you're trying to make. x86 is far from the most efficient architecture in terms of IPC. And big caches are the exact opposite of what you want in a throughput architecture.

[Drwho?]

Which you can already do in C++. Why go through some additional layer coded by a third party that will invariably make your code slower? The entire reason for the existence of OpenCL is to make GPU programming easier.

Are you a programmer? Try to make n! work on the GPU, or any function where you have any convergence of a math function ...
like f(n) = G(F(n-1)) ...
then, you ll figure out that if n is a vector, and G a complexe function, the CPU is faster than the GPU at this kind of processing ...

try to write a ray tracer in a GPU ... you meet very quickly the problem that some pixel share rebounces for a while, but then use different pathes ... so, when they share the path, you use GPU like ... when they don't , you use the same OpenCL or Direct Compute , or Larrabee Instruction stream, but with a single vector ...
you need both, CPU and GPU like ... your vision of black and white is too simplistic ...
Intel choosed to have x86 on both path, AMD wants to have OpenCL layer ... and NV will be using a lot the nehalem cores if they want to stay competitive ... lol.



I am not talking about fake ray tracing ... it is suppose to look like this (thanks to the povray guys for their rest less work! ):




rendered on the CPU
you can render it yourself: http://www.oyonale.com/modeles.php?page=40 for the files , and http://povray.org/beta/ for the program ... it takes a very long time, it is the price to pay for 100% independant rays...

[trinibwoy]

Are you a programmer?

Yes, by profession.

A factorial is actually trivially parallelizable. It's a simple reduction that would be blazing fast on a GPU. It'll be similiar to a merge sort, simply divide and conquer.

Your comments on ray-tracing are also invalid. A GPU can produce raytraced renders that would match a CPU version pixel for pixel. The primary issue with GPU raytracing is the random memory access and divergent code paths when traversing the scene structure. This makes things slow, not impossible as you imply. And with techniques such as packet tracing and persistent threads GPUs are already attacking this problem and it will only get better with the upcoming crop of hardware.

[Junos]

[ot]

it is suppose to look like this (thanks to the povray guys for their rest less work! ):

Could you make the resolution a bit smaller please? Big pictures make the forum a lot harder to read for us with 1024res.
[/ot]

[trinibwoy]

Dr. Who, try doing 1,000,000! using Windows calculator and tell me how long it takes

[Drwho?]

Yes, by profession.

A factorial is actually trivially parallelizable. It's a simple reduction that would be blazing fast on a GPU. It'll be similiar to a merge sort, simply divide and conquer.

Your comments on ray-tracing are also invalid. A GPU can produce raytraced renders that would match a CPU version pixel for pixel. The primary issue with GPU raytracing is the random memory access and divergent code paths when traversing the scene structure. This makes things slow, not impossible as you imply. And with techniques such as packet tracing and persistent threads GPUs are already attacking this problem and it will only get better with the upcoming crop of hardware.

hehehhe ... we will see I would not be so confident in your statement if I was you ...

Please show me a n! faster on GPU than the CPU to start with ...
you forgot a little issue in the parallelization of the factorial ... the branching speed isn't it? each local thread needs it ...

So, show us how professional you are factorial is a very simple problem ... code it for tomorrow on GPU ... I ll do on CPU and we compare ?

we start from recursive or not ... I ll use the non recursive ...



===================================
int determineFactorialRecursive (int a)
{
if (a == 1)
return 1; //factorial of 1 == 1

else
return a * determineFactorialRecursive (a - 1);

// Notes::
// recursive approach - Note you are calling the function
// determineFactorial recursively.
// do some reading and you will find this helpful
}


//Another way
int DetermineFactorialOther (int myFact)
{
int value;
int value2 = 1;

for (int i = myFact; i > 1; i--)
{
value = (i * (i-1));
value2 *= value;
i--;
}

return value2;
}


===================================


here is some help for you:
http://www.luschny.de/math/factorial/Benchmark.html
The algorythm is there for // processing.

we will use 64 000 000! as goal, since it is fairly reasonable ...
you ll post your code using your GPU tomorrow, I ll post mind too

Since it is trivial ... I don t see why you can not do it for tomorrow.

deal?

[W1zzard]

good example, but integer overflow in your sample code looking forward to see your cpu implementation tomorrow. for the sake of the discussion the overflow shouldnt pose a problem though. adding "arbitrary" length number support would complicate things even more because of memory bandwidth and caches involved

64! = 12688693218588416410343338933516148080286551617454 5192198801894375214704230400000000000000

took me 0.34 seconds using an outside-of-the-box-thinking-search-algorithm

[Drwho?]

good example, but integer overflow in your sample code looking forward to see your cpu implementation tomorrow. for the sake of the discussion the overflow shouldnt pose a problem though

Well, don t worry about the overflow ... n! is an hobby of mine , but i will not cheat, create a apps in MFC ...
done with the UI:

[W1zzard]

i love mfc, but linux just prevails in some situations

# time echo "define f(x) { if (x>1) { return (x*f(x-1)) }; return (1) }; f(16384)" | bc

.. lots of numbers ..

real 0m7.470s
user 0m5.829s
sys 0m0.090s

simpler:

# time seq -s \* 16384 | bc

real 0m8.680s
user 0m5.858s
sys 0m0.088s

[Gautam]

hehehhe ... we will see I would not be so confident in your statement if I was you ...

Please show me a n! faster on GPU than the CPU to start with ...
you forgot a little issue in the parallelization of the factorial ... the branching speed isn't it? each local thread needs it ...

So, show us how professional you are factorial is a very simple problem ... code it for tomorrow on GPU ... I ll do on CPU and we compare ?

we start from recursive or not ... I ll use the non recursive ...

Why'd you list such a crummy recursive algorithm?

[Drwho?]

i love mfc, but linux just prevails in some situations

# time echo "define f(x) { if (x>1) { return (x*f(x-1)) }; return (1) }; f(16384)" | bc

.. lots of numbers ..

real 0m7.470s
user 0m5.829s
sys 0m0.090s

well, I am using Hai yi simple code ... http://www.codeguru.com/Cpp/Cpp/algo...icle.php/c2041 ... the time of installing linux would have be more than opening MSVC ... heheheh ...
Let s see if the CUDA or OpenCL version will come before next year
And he said 1000000! ... so, he will have to provide a support for bigger than long long in the GPU ... I guess he will be able to file a PhD after this ... lol

[W1zzard]

Why'd you list such a crummy recursive algorithm?

it is a very primitive algorithm that should be really easy to implement on the gpu, no ?

Let s see if the CUDA or OpenCL version will come before next year

dont think so... unless you talk to nvidia marketing, they fix up some mdf, get one of their devs to write it, give it to the OP and stick a way it's meant to be played logo on it

well, I am using Hai yi simple code ... http://www.codeguru.com/Cpp/Cpp/algo...icle.php/c2041 ...

your thoughts on using strings to store the digits instead of a list? char* s++ / s-- seems cheaper than dereferencing pointers?

[Drwho?]

it is a very primitive algorithm that should be really easy to implement on the gpu, no ?



dont think so... unless you talk to nvidia marketing, they fix up some mdf, get one of their devs to write it, give it to the OP and stick a way it's meant to be played logo on it



your thoughts about using strings to store the digits instead of a list? char* s++ / s-- seems cheaper than dereferencing pointers?

This methode is showed to bachelors ... as an exercice ... using the 1st return by google :P Even this, a GPU will not beat ... no GPU yet can branch fast enough.

[W1zzard]

Even this, a GPU will not beat ... no GPU yet can branch fast enough.

agreed, but there are some problems where gpu computing does have benefits. people must just realize that this is only a very very very small subset of computational problems

[Drwho?]

agreed, but there are some problems where gpu computing does have benefits. people must just realize that this is only a very very very small subset of computational problems

almost done coding it ... I want to go enjoy california sun while it is running

[Drwho?]

agreed, but there are some problems where gpu computing does have benefits. people must just realize that this is only a very very very small subset of computational problems

Most of the computing world is itterative, and using the result of an other process is the rule ... Too many people think that GPU can do it all, it is an absolute heritic thinking ...
We did not put all of this hardware in the processor for free ... and who ever claimed in his Q2 2009 financial claim that the GPU can do it all is somebody who lost contact with reality.

Branching when processing is still the st grall, then, intruction per clock ...
I am reinstalling quickly without Intel Compiler ... just to prove that CPU can do so much better ... even on a "trivial parrallelizable" algorithm.

you want to notice the developpement speed difference, I will have finish a system able to calculate n! over 1000 in few minutes ... or an hour or so ...
Doing it on CUDA will have days ...
The propaganda about GPGPU always forget those factors ... they only show you one very little corner of the world.

I added a CRichEditCtrl to display the results ... like this, I can copy and paste the results ... without even writting a line of code ... Do this with your GPU ... hahahahha

[trinibwoy]

Most of the computing world is itterative, and using the result of an other process is the rule ... Too many people think that GPU can do it all, it is an absolute heritic thinking ...

From day one GPU computing has been about accelerating parallelizable problems not "doing it all". Do you get some joy from spreading this nonsense?

Since it is trivial ... I don t see why you can not do it for tomorrow.

Yeah because I'm gonna buy Visual Studio, learn to program in CUDA and implement a factorial algorithm all by tomorrow Btw, how is your little algorithm above there dealing with precision? There's no way an "int" can store the result of 1,000,000!

The entire premise of your argument is false. Factorial isn't a strictly iterative calculation as all mutliplications of every two numbers in the sequence can happen in parallel. For example, 10!, using 4 threads.

Clock #1
Thread 1: 10*9
Thread 2: 8*7
Thread 3: 6*5
Thread 4: 4*3
Clock #2
Thread 1: 90*56
Thread 2: 30*12
Clock #3
Thread 1: 5040 * 360
Clock #4
Thread 1: 1814400 * 2

Only 4 clocks on a theoretical 4 core processor. How is your naive iterative algorithm supposed to be faster when it takes 8 clocks? You really need to read up on parallel scans, there isn't even any branching in this algorithm so I'm really curious where you're getting all of this bad info from.