Re: optimizing compilers
Re: optimizing compilers
- Subject: Re: optimizing compilers
- From: "Erik M. Buck" <email@hidden>
- Date: Fri, 1 Feb 2002 16:09:41 -0600
As far as I can tell, building an optimizing C++ compiler is about as hard
as building a Space Shuttle. Is there a single C++ compiler that completely
conforms to the ANSI standard yet ? Getting the grammar and hidden
semantics and assumed side effects of C++ is hard enough without
optimization. Then the linker has to be built to resolve all template
expansions and possibly generate code. (Yes, there are C++ linkers that
generate code). A lot of optimization has to take place in the linker. If
you have a compiler that compiles C++ correctly without any optimization at
all, consider yourself lucky. That is more than most people have.
Mac OS X is slow for many reasons that have nothing to do with compiler
optimizations. I am sure a better compiler would help, but many parts of OS
X are slow because the algorithms used are bad and no compiler can fix that.
For example, Quartz is very powerful and produces beautiful results, but it
is very slow IMHO. Interpreted Display Postscript running in a separate
process was faster for most operations than Quartz as far as I can tell. If
all drawing is slow, that has a huge impact of perceived performance. Font
rendering is very slow in OS X. OS-X uses much more memory than either OS 9
or NeXTstep/Openstep because it is effectively running both simultaneously.
Core Foundation seems much slower than its Openstep predecessor and since
both Carbon and Cocoa applications are using Core Foundation, they all
suffer.
I am sure that Apple will tune and optimize OS-X in successive releases.
Getting a large complex operating system with multiple legacy support issues
and many new technologies to work at all is a huge achievement. They will
improve it slowly for years.
IMHO they should start the improvement with Quartz optimization and
Application Kit display semantics.
Second they should improve Core Foundation performance.
Third they should improve the Foundation and Application Kit classes that
got much slower between Rhapsody DR2 and OS-X.
Forth they should reduce the number of frameworks/shared libraries that must
be resident at the same time for typical applications to work. I suspect a
lot of performance is lost jumping all over memory to call one routine from
Carbon and one from the Foundation framework in quick succession.
----- Original Message -----