? (0xe2.0x9a.0x9b@gmail.com) on 11/11/09 wrote:
>- how many percent GCC spends doing IO? What is "GCC's IO" anyway?

That certainly depends very much on the project.

>- If you parallelize the parser

I never suggested this. Read Potatoswatters reply, he understood, so I must have been lesser randomly and arbitrary than you read me.

Maybe Potatoswatter said it better.
quote:
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.

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.
end quote

>For example I am unsure whether you actually know what a Linux process is.

I do know. I even know the difference between a programm, a process and a thread. ("wow!")
I'm getting the impression that you don't only want to save me from being a backseater/know-it-all with no realworld experience, but simply bully me.