By: Potatoswatter (potswa_m.delete@this.c.com), November 11, 2009 8:22 am
Room: Moderated Discussions
MoTheG (better@not.tell) on 11/10/09 wrote:
---------------------------
>? (0xe2.0x9a.0x9b@gmail.com) on 11/10/09 wrote:
>---------------------------
>>... it seems to me that you think you can just randomly join arbitrary words together
>>to form a sentence and call the result a profound idea ...
>>
>>Please stop doing it!
>
>let me try again.
>"GPUs can react to the data nowerdays by going sequential."
>that sentece indeed stood a bit alone in space.
>What I ment to say was, that GCC can work in parallel but not at all on a GPU even though they can branch now.
>To not just claim that GCC can be somewhat parallized, I tryed to give examples,
>also of what is being done independently but perhaps sequentialy already.
>I don't see where I claimed any "profound idea".
>I only brought up stuff that is already being done but maybe not being exploited
>to the fullest.(I have no knowledge of the inner workings of GCC, but I am sure
>that there is parallism in compiling a big project, not a single file, but where
>there are many files, objects and large functions).
>
>unless asked otherwise, I will satisfy your request by not posting, for say a month.
You shouldn't leave, as long as you're learning.
Parsing is just about the least parallelizable problem there is. It's defined in terms of a single state machine. (Although surely there has been research to the contrary.)
It sounds more like you're talking about pipelining the compiler: one thread parses while another thread generates code. Unfortunately that only works when you know the relative speeds of the pipeline stages. One program might parse slowly while another program optimizes slowly due to -O3 being passed. It's too much work to modify a compiler for such an uncertain gain, although it has been done.
The way one achieves parallel compilation is by launching one compiler instance on each core. .c files are turned into .o files in parallel. Then .o's get merged together in a tree.
ANYWAY
All this is irrelevant to GPUs as they lack the data caches necessary to run any kind of compiler. A GPU could only parse C++ at a tiny fraction of CPU speed, no matter what.
---------------------------
>? (0xe2.0x9a.0x9b@gmail.com) on 11/10/09 wrote:
>---------------------------
>>... it seems to me that you think you can just randomly join arbitrary words together
>>to form a sentence and call the result a profound idea ...
>>
>>Please stop doing it!
>
>let me try again.
>"GPUs can react to the data nowerdays by going sequential."
>that sentece indeed stood a bit alone in space.
>What I ment to say was, that GCC can work in parallel but not at all on a GPU even though they can branch now.
>To not just claim that GCC can be somewhat parallized, I tryed to give examples,
>also of what is being done independently but perhaps sequentialy already.
>I don't see where I claimed any "profound idea".
>I only brought up stuff that is already being done but maybe not being exploited
>to the fullest.(I have no knowledge of the inner workings of GCC, but I am sure
>that there is parallism in compiling a big project, not a single file, but where
>there are many files, objects and large functions).
>
>unless asked otherwise, I will satisfy your request by not posting, for say a month.
You shouldn't leave, as long as you're learning.
Parsing is just about the least parallelizable problem there is. It's defined in terms of a single state machine. (Although surely there has been research to the contrary.)
It sounds more like you're talking about pipelining the compiler: one thread parses while another thread generates code. Unfortunately that only works when you know the relative speeds of the pipeline stages. One program might parse slowly while another program optimizes slowly due to -O3 being passed. It's too much work to modify a compiler for such an uncertain gain, although it has been done.
The way one achieves parallel compilation is by launching one compiler instance on each core. .c files are turned into .o files in parallel. Then .o's get merged together in a tree.
ANYWAY
All this is irrelevant to GPUs as they lack the data caches necessary to run any kind of compiler. A GPU could only parse C++ at a tiny fraction of CPU speed, no matter what.
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 |