Re: Best language for implementing compilers?

Am 11.03.2019 um 18:49 schrieb Christopher F Clark:
> On Sunday, March 10, 2019 at 9:07:41 PM UTC-4, Bart wrote:


>> How fast are we talking about?
>
> I haven't measured in a long time, so I can't quote any numbers. However, as
> I recall, you can lex a buffer in roughly the same time you can access it via
> getc rather than reading with fread if your lexer code is tight. In fact, the
> fetching of the characters is often a significant factor in the lexing time.
> The other significant factors are the time spent in calls (to either the I/O
> library or passing a token back to the parser. So, really fast lexers
> actually often concentrate on that, minimizing both (e.g. reading large
> buffers and batching up a whole set of tokens to pass to the parser rather
> than one at a time).


In the age of multi-core processors and threads some parallel work can
reduce the overall processing time. Then the longest running part of
the compiler determines the total run time, not the sum of all times.


With sufficiently large memory it's possible to read (or map) entire
files into RAM, so that library function calls for reading characters
are not required any more.


With all the caches used by nowadays OSs it's hard to reproduce
benchmark times. And that's not always really required or desireable!
Imagine a fast compiler that is invoked after every single change to
the source code, which will benefit from OS caches, whereas a slow
compiler invoked once per hour or day will suffer even more from the
lack of cached files and directories. A clever IDE can do such caching
itself, and can remember which *parts* of a source file have not been
touched since the last compile, much bettter than the OS file
modification date. And it can compile updates in the background, so
that a final compilation of an entire project may run as fast as the
compilation summary is presented to the user :-)


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.