By: Vincent Diepeveen (diep.delete@this.xs4all.nl), November 10, 2009 8:36 am
Room: Moderated Discussions
MoTheG (better@not.tell) on 11/9/09 wrote:
---------------------------
>a reader (a@b.c) on 11/9/09 wrote:
>---------------------------
>>stop blabbering.
>>
>>do you have access to GPU nda docs or not?
>
>I do not.
>Does one have to?
Yes of course,
Give me for Nvidia cpu's a listing of which hardware instructions the hardware supports and what latency which instruction has please.
Rather trivial to get for cpu's. Real important for gpu's of course. You're not coding for a gpu to get generic code to work without performance incentives.
AMD seems to have released the instructions the gpu hardware supports. This is good and makes AMD more attractive to me to program for. Note i was amazed by the many conditional move equivalent type instructions the hardware supported.
>The data on the old parts is disclosed.
>
>We had to learn about CPUs too.
You can download from cpu's about everything. Just tiny small things are difficult like that documentation doesn't show some hidden thigns like which units get blocked when and for how long depending upon what instruction you execute. Sometimes there is also nasty surprises in that specific instructions are not 2 cycles but 7+ cycles (example: shifting right at P4).
>As DK wrote there is optimised CPU code and not so optimised code as well. Just
>slapping something together in a high level language without architectual concerns
>doesn't work for a CPU as well (and if it does, it is not the credit of the programmer,
>but the compiler and the CPU guys).
>The average programmer will not get in contact with problems that would gain from GPGPU anyhow.
the average programmer is not writing code to get executed fast. Only a few on this planet do that. I'm one of them.
>This is why I think arguing that one needs to be able to programm a GPU just like
>we used to programm single core CPUs is to much asked.
Lucky just 1 guy has to solve the problem for each number crunching product. A single programmer can have a huge impact on an entire field there. There is LOTS of people who help you out then theoretically, as i figured out.
---------------------------
>a reader (a@b.c) on 11/9/09 wrote:
>---------------------------
>>stop blabbering.
>>
>>do you have access to GPU nda docs or not?
>
>I do not.
>Does one have to?
Yes of course,
Give me for Nvidia cpu's a listing of which hardware instructions the hardware supports and what latency which instruction has please.
Rather trivial to get for cpu's. Real important for gpu's of course. You're not coding for a gpu to get generic code to work without performance incentives.
AMD seems to have released the instructions the gpu hardware supports. This is good and makes AMD more attractive to me to program for. Note i was amazed by the many conditional move equivalent type instructions the hardware supported.
>The data on the old parts is disclosed.
>
>We had to learn about CPUs too.
You can download from cpu's about everything. Just tiny small things are difficult like that documentation doesn't show some hidden thigns like which units get blocked when and for how long depending upon what instruction you execute. Sometimes there is also nasty surprises in that specific instructions are not 2 cycles but 7+ cycles (example: shifting right at P4).
>As DK wrote there is optimised CPU code and not so optimised code as well. Just
>slapping something together in a high level language without architectual concerns
>doesn't work for a CPU as well (and if it does, it is not the credit of the programmer,
>but the compiler and the CPU guys).
>The average programmer will not get in contact with problems that would gain from GPGPU anyhow.
the average programmer is not writing code to get executed fast. Only a few on this planet do that. I'm one of them.
>This is why I think arguing that one needs to be able to programm a GPU just like
>we used to programm single core CPUs is to much asked.
Lucky just 1 guy has to solve the problem for each number crunching product. A single programmer can have a huge impact on an entire field there. There is LOTS of people who help you out then theoretically, as i figured out.
Topic | Posted By | Date |
---|---|---|
Article: Computational Efficiency in Modern Processors by DK | MoTheG | 2009/11/08 07:02 AM |
Article: Computational Efficiency in Modern Processors by DK | none | 2009/11/08 07:15 AM |
Silverthorne and OoO vs. InOrd | MoTheG | 2009/11/08 07:22 AM |
Silverthorne and OoO vs. InOrd | David Kanter | 2009/11/08 04:11 PM |
Magical 100x speedups | AM | 2009/11/09 09:03 AM |
Magical 100x speedups | David Kanter | 2009/11/09 12:41 PM |
Magical 100x speedups | none | 2009/11/09 01:36 PM |
Magical speedups | David Kanter | 2009/11/09 03:24 PM |
Magical speedups | none | 2009/11/09 03:40 PM |
Hardware Specs | MS | 2009/11/09 05:49 PM |
44x faster than a single cpu core | Vincent Diepeveen | 2009/11/10 08:17 AM |
Magical speedups | Vincent Diepeveen | 2009/11/10 08:02 AM |
Xeon 130x speedup vs Xeon | Eric Bron | 2009/11/10 08:20 AM |
Magical 100x speedups | AM | 2009/11/10 10:42 AM |
Magical 100x speedups | Linus Torvalds | 2009/11/10 01:19 PM |
Mega speedups | AM | 2009/11/11 06:21 AM |
Bogus 100x speedups | David Kanter | 2009/11/10 01:26 AM |
No speedups for CPUs for the general programming populace | MoTheG | 2009/11/10 05:26 AM |
Bogus 100x speedups | ? | 2009/11/10 05:45 AM |
Bogus 100x speedups | hobold | 2009/11/10 07:31 AM |
Bogus 100x speedups | Vincent Diepeveen | 2009/11/10 08:26 AM |
Bogus 100x speedups | sylt | 2009/11/10 10:00 AM |
Bogus 100x speedups | AM | 2009/11/10 10:47 AM |
GPU vs. CPU | MoTheG | 2009/11/09 11:30 AM |
GPU vs. CPU | a reader | 2009/11/09 07:58 PM |
ease of programming | MoTheG | 2009/11/09 11:45 PM |
yes for GPU programming you need non-public info | Vincent Diepeveen | 2009/11/10 08:36 AM |
yes for GPU programming you need non-public info | Potatoswatter | 2009/11/11 08:06 AM |
yes for GPU programming you need non-public info | Vincent Diepeveen | 2009/11/11 11:23 AM |
yes for GPU programming you need non-public info | Potatoswatter | 2009/11/11 01:26 PM |
Real businesses use GPGPU. | Jouni Osmala | 2009/11/11 11:00 PM |
GPU vs. CPU | ? | 2009/11/10 06:01 AM |
2. try but most is said, just clarifying | MoTheG | 2009/11/10 10:24 AM |
2. try but most is said, just clarifying | ? | 2009/11/11 01:11 AM |
you missread me | MoTheG | 2009/11/12 12:33 AM |
you missread me | ? | 2009/11/12 01:18 AM |
2. try but most is said, just clarifying | Potatoswatter | 2009/11/11 08:22 AM |
2. try but most is said, just clarifying | ? | 2009/11/12 01:22 AM |
loose, not so orderly | MoTheG | 2009/11/12 12:47 PM |
loose, not so orderly | Potatoswatter | 2009/11/12 06:50 PM |
2. try but most is said, just clarifying | rwessel | 2009/11/12 01:01 PM |
2. try but most is said, just clarifying | Gabriele Svelto | 2009/11/13 12:39 AM |
2. try but most is said, just clarifying | ? | 2009/11/13 01:14 AM |
2. try but most is said, just clarifying | Gabriele Svelto | 2009/11/13 01:30 AM |
2. try but most is said, just clarifying | rwessel | 2009/11/13 01:24 PM |
2. try but most is said, just clarifying | Michael S | 2009/11/14 01:08 PM |
2. try but most is said, just clarifying | Gabriele Svelto | 2009/11/14 11:38 PM |
2. try but most is said, just clarifying | Andi Kleen | 2009/11/15 01:19 AM |
2. try but most is said, just clarifying | Michael S | 2009/11/15 01:58 AM |
2. try but most is said, just clarifying | Eric Bron | 2009/11/15 02:25 AM |
/MP option | Eric Bron | 2009/11/15 02:33 AM |
/MP option | Paul | 2009/11/15 09:42 AM |
/MP option | Eric Bron | 2009/11/15 01:22 PM |
2. try but most is said, just clarifying | ? | 2009/11/15 03:13 AM |
2. try but most is said, just clarifying | Michael S | 2009/11/15 05:14 AM |
2. try but most is said, just clarifying | Eugene Nalimov | 2009/11/14 09:24 PM |
Atom point | AM | 2009/11/09 09:00 AM |
Atom TDP | David Kanter | 2009/11/09 12:48 PM |
Atom TDP | hobold | 2009/11/10 07:41 AM |
Atom TDP | AM | 2009/11/10 10:49 AM |