Simon Marlow wrote:
[snip]
> Hmm, you're probably doing a large chunk of renaming too. I just added an
> error call right after the parser in Main.lhs.
The MLj parser/lexer doesn't actually rename, but it does tokenise all
identifiers in the lexer. Symbols already known aren't even copied out of
the input buffer. This saves time and space (the complete MLj compiler only
has about 1 distinct identifier/symbol/reserved word for every 10 lines of
code) and also means the rest of the compiler is working with integers rather
than strings, even though it doesn't know it, which also speeds things up.
>
> I'm still interested in the figures, if you want to retry your experiment.
OK, here goes. If I insert the line
error "Parsing done" >>
after the line
dumpIfSet opt_D_dump_parsed "Parser" (ppr rdr_module) >>
in main/Main.lhs, I get the revised table:
GHC MLj
wc -l 10146 4856
wc -c 312962 212902
[wc -w] 37107 11578
real 11.832 2.835
user 10.740 2.610
sys 0.870 0.150
The [wc -w] is an attempt by me to get a slightly fairer
value for the program size by removing all non-pragma comments
and using wc -w. For MLj counting words rather than characters
makes a big difference since ml-yacc encodes the parser tables as
gigantic strings.
I tried much harder to get the figures down for both GHC and MLj
this time by shutting down everything else on the system I could
find, and taking the best of three. (This makes a big difference
to the real time, which presumably includes file access, but
not the user time, which I think is probably the important
figure) However in GHC's defence I should point out
that
1) I'm still using gcc 2.7.2. On Sparc-Solaris GHC should
certainly go faster when I can get gcc 2.9.5 to work with it.
2) I didn't compile GHC with optimisation. This sounds serious
but I don't think it is since I've been told that Happy-
generated code is optimised to the bare bone anyway and so
can't be improved much by GHC's optimisations. I did try
compiling the parser with -O2-for-C (but not -O); however
surprisingly that actually seems to make it slightly slower!
Re parser combinators. I think I was obviously too rude about
these, because of my previous bad experience. Naively it seems
to me that there is a trade-off. I am not prepared to settle
for anything less than having my grammar statically checked
for potential conflicts. This obviously rules out rules
generated with complete generality at run time, and so rules
out some kinds of parser combinators. I can conceive that you
can restrict the use of parser combinators in such a way that
a preprocessor can verify the grammar statically, and
(by computing follow sets and so on) do as good a job as Yacc,
while still allowing you the advantages of abstracting
sequences. Fine.
