On Nov 10, 2006, at 2:19 PM, Kevin Handy wrote:
What will the multi-core compiler design do to the old processors
(extreme slowness?)
Roughly speaking, I want it to add around 1000 extra instructions per
function compiled, in other words, nothing. The compile speed will
be what the compile speed is. Now, I will caution, the world doesn't
look kindly on people trying to bootstrap gcc on a 8 MHz m68k
anymore, even though it might even be possible. In 5 years, I'm
gonna be compiling on an 80 or 160 way box. :-) Yeah, Intel
promised. If you're trying to compile on a single 1 GHz CPU, it's
gonna be slow.... I don't want to make the compiler any slower, I
want to make it faster, others will make use of the faster compiler,
to make it slower, but that is orthogonal to my wanting to make it
faster.
4. Will you "serialize" error messages so that two compiles of a
file will always display the errors in the same order?
Yes, I think that messages should feed back into manager, so that the
manager can `manage' things. A stable, rational ordering for
messages makes sense.
Also, will the object files created be the same between compiles.
Around here, we predicate life on determinism, you can pry that away
from my cold dead fingers. We might have to switch from L472 to
L10.22 for internal labels for example. This way, each thread can
create infinite amounts of labels that don't conflict with other
threads (functions).
5. Will more "heavy" optimizations be available? i.e. Will the
multi-core
speed things up enough that really hard optimizations (speed wise)
become reasonable?
See my first paragraph.
