re: self compiler questions

[craig (Craig Chambers)]

vme131!lsi4!jecel@uunet.UU.NET writes:
>Why is the Self compiler always compared with optimizing C? Since
>it does many run-time checks I would think that Self would be
>more fairly compared to Pascal.

When comparing the performance of our Self compiler to other systems,
we try to be as honest and fair as possible, in the sense of comparing
against the best commonly available system.  Comparing against a
Pascal compiler that generates slower code with extra run-time checks
might make our compiler look better, but wouldn't be as honest.
Comparing against the best traditional compiler available (e.g. an
optimizing C compiler) will give the results the most validity, and
(hopefully) convince the largest number of people that they should
switch to a nicer language like Self, now that the run-time
performance is close.

Some might argue that we should compare against an optimizing Fortran
compiler, since they tend to be better than C compilers.  This might
be more honest, in the sense of giving us the worst possible
comparison.  But I would claim that Fortran really isn't a general
purpose programming language, and is only used in numerical
applications where the limited functionality of the language is
adequate.  Also, we don't really want to find an optimizer that does a
significant number of optimizations, since our Self compiler only
includes common subexpression elimination and global register
allocation.  Presumably we'd have to implement every optimization
implemented in a competitor's compiler in order to reach comparable
code quality.  C seems to be a good thing to compare against, since
the language is general purpose, commonly used, and the optimizing
compilers produce good code, but without extreme amounts of
optimization.

reed.bitnet writes:
>And, in the interests of completeness, which C compiler are you
>comparing against.  I don't know about the Sparcstation, but on a
>Sun 3 you can get a factor-of-two performance improvement simply by
>using gcc instead of Sun cc.

We use the standard Sun optimizing C compiler.  On the SPARC, this
compiler is about the same quality as the GCC compiler, a least the
last time we compared them (a couple of years ago).

vme131!lsi4!jecel@uunet.UU.NET writes:
>I don't like C++ very much - couldn't the Self compiler be written
>in Self ( which, I hope you will agree, is much nicer ) and compile
>itself using a tiny bootstrap interpreter?

We've been asked that question many times.  When we first designed the
language, we didn't know whether we'd be able to reach Smalltalk
performance, let alone C performance, so bootstrapping was never
considered.  However, even if we were to reimplement our compiler in
Self, there are still some tricky issues left.  One is the fact that
the compiler's compiled code would be in the code cache, and so might
get flushed, in which case the system would have to fall back to the
interpreter to interpret the Self compiler to compile some application
code.  This could make compiler pauses very distracting.  Also, bugs
in the Self compiler could be very difficult to find, especially if it
compiles itself.  Finally, there would be a large dependency between
the Self code and the virtual machine.  The Self compiler would have
to communicate a lot of information to the virtual machine, and vice
versa, in order to generate the same high quality code.  Designing the
interface between the virtual machine and the Self compiler is a hard
problem.

vme131!lsi4!jecel@uunet.UU.NET writes:
>Are there any statistics on Self like those on Smalltalk in
>"Smalltalk-80: Bits of History, Words of Advice"? I'm designing a
>Self multiprocessor machine and knowing such things as average
>object size and so on would be helpful.

No real statistics yet.  I'd imagine that Self objects look a lot like
Smalltalk objects.  Perhaps a bit smaller because of differences in
coding styles.  The major differences would have to do with statistics
related to the execution engine and method lookup, which could be
wildly different with our optimizing compiler.

-- Craig Chambers