Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: Best language for implementing compilers? Date: Tue, 12 Mar 2019 06:54:23 +0100 Organization: Compilers Central Lines: 36 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-03-016@comp.compilers> References: <19-02-002@comp.compilers> <19-02-004@comp.compilers> <19-02-006@comp.compilers> <19-03-009@comp.compilers> <19-03-010@comp.compilers> <19-03-015@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="56605"; mail-complaints-to="abuse@iecc.com" Keywords: design, performance Posted-Date: 12 Mar 2019 21:11:39 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2182 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