Mail Archives: djgpp/2008/07/09/04:44:14
Oops, lack of reply-all + digest => I'll bulk reply to what I bulk-got.
> speed
Gcc is slow and yeah there is -O2 vs. -Os and such, but I speak of
two or three or more different speed issues.
gcc is slow as in gcc is slow on Linux/Unix.
Actually I don't speak much of this since I don't use Unix much. :)
gcc is slow as in gcc is slow on Cygwin.
gcc is slow as in gcc is slow in Dosbox.
And, then, likely also a factor, perf of:
gcc -c 1.c 2.c 3.c
vs. perf of:
gcc -c 1.c
gcc -c 2.c
gcc -c 3.c
These are all interesting relevant angles. Ok, DosBox isn't very interesting/relevant,
but I accidentally temporarily made it so.
I didn't 100% realize DosBox was an issue but that is very believable.
I hate managing diskspace but I'll see about either VMware or XP/x86
on another machine. Or maybe Win9x, or something DOSish
The perf of
gcc -c 1.c 2.c 3.c
is the main thing the gcc developers can fix and are responsible for, and
can be tweaked with optimzation settings, yes, understood.
Everything else is mostly "something else".
Cygwin has a copying fork, and vfork == fork. Slow.
gcc -c 1.c 2.c 3.c mitigates that somewhat, gcc already supports this, fixing
everyone's "build system" / "make" isn't gcc's job. I hope it happens some day.
Over 10 years ago, Microsoft's otherwise abysmal nmake got a "double colon"
feature that supports this.
You change:
.c.obj:
cl -c $<
to
.c.obj::
cl -c $<
and done. Faster. Esp. if running under Cygwin (or probably, DosBox).
Another way gcc developers could help here is by merging processes.
In the "gcc compilation model".
gcc -c 1.c
involves I believe three processes -- gcc, cc1, as.
In Visual C++ and many other compilers, it uses just one process -- cl.exe.
The C front end is c1.dll, C++ c1xx.dll, the backend c2.dll.
There used to be .exes for the front and backends (in a way, worse than gcc,
though the backend still output a .obj file, not assembly, so a "tie"; with
today's LTCG, the backend is actually loaded by the linker).
I understand that "extension via process" vs. "extension via .dll" is more portable.
X Windows made this transition, perhaps gcc will some day, or maybe just by
linking more static libs together (I realize it's harder to then add/remove Ada
support to a system with C support, for example; there are tradeoffs either way,
yes, really, I understand). Of course X Windows perf affects more people.
It would be great to solve all these problems:
gcc be one process, invoked on multiple source files at a time, output .o files
but my wishing won't do anything. :(
For now I'll try another OS one way or another -- VMware or XP/x86, etc.
(I don't know if gcc -c 1.c 2.c 3.c invokes cc1 1 or 3 times, but I can find out
easily. I know it runs as three times. I tried as 1.s 2.s, at least in another language,
and it considers the source files concatenated, which in my example lead to symbol
clashes, I'll have to try with C, but anyway this isn't likely the way to go, better
to output .o files directly and not run as at all.)
I did do a LITTLE bit of benchmarking and gcc -02 vs. -O0 made a particular
scenario build in twice the time. I didn't measure the difference in resulting code quality.
On a more realistic note, maybe I can help with the 2.03/2.04 issues. :)
Thanks,
- Jay
- Raw text -