Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: BartC Newsgroups: comp.compilers Subject: Re: Alternative C compilers on x86_64 Linux? Date: Fri, 30 Sep 2016 12:28:50 +0100 Organization: A noiseless patient Spider Lines: 38 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <16-09-048@comp.compilers> References: <16-09-001@comp.compilers> <16-09-033@comp.compilers> <16-09-034@comp.compilers> <16-09-035@comp.compilers> <16-09-037@comp.compilers> <16-09-042@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="7533"; mail-complaints-to="abuse@iecc.com" Keywords: C, performance Posted-Date: 30 Sep 2016 11:30:48 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:1787 On 29/09/2016 14:03, BartC wrote: > [Tokenizing 10M lines/sec is pretty impressive. In compilers that don't > do heavy optimization > the lexer is usually the slowest part since it's the only thing that has > to touch each > character of the source code individually. -John] This is what I was putting to the test. Actually I struggled to recreate that benchmark, but in the end managed to process actual C source (a monolithic file containing all CPython sources) at some 9.7Mlps. Figures do depend on the source style. On another desktop (also cheap, but with Intel rather than AMD), it managed 11.5Mlps. With non-C sources, which has less 'busy' syntax, up to nearly 13Mlps. Figures exclude file-loading (although that made little difference on the second machine). Probably some more throughput can be squeezed by applying some ASM (or by writing in native C and using more options rather than using atrocious-looking intermediate code), but at the moment this isn't a bottleneck. (This test has some bits missing, for example it parses floating point numbers but doesn't convert the character sequences to actual values, but on the input I used, floating point figures very little. On the 1Mlps I quoted for an actual working compiler (although for in-memory byte-code), that includes file-loading but expects the OS to have cached the file as will normally be the case. This compiler is case-insensitive which slows down the tokeniser a tiny bit. That's one tiny advantage of compiling C!) -- Bartc