Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: code quality, was Good practical language and OS agnostic text? Date: Sun, 22 Apr 2012 12:41:55 +0200 Organization: Compilers Central Lines: 59 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-04-061@comp.compilers> References: <12-04-019@comp.compilers> <12-04-023@comp.compilers> <12-04-033@comp.compilers> <12-04-058@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1335104614 14692 64.57.183.58 (22 Apr 2012 14:23:34 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 22 Apr 2012 14:23:34 +0000 (UTC) Keywords: optimize, benchmarks Posted-Date: 22 Apr 2012 10:23:34 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:604 BartC schrieb: > "Hans-Peter Diettrich" wrote in message >> Life is too short for writing an full-blown heavily-optimizing >> production compiler from scratch, including its whole RTL. > > Especially when there might only be difference of 2 or 3 times between > performance of the best and worst code. > > My own compiler for x86-32 generates pretty awful code, and on a small > handful of mostly numeric benchmarks, it averages out about 2.5 x as > slow as gcc on it's highest optimisation setting. But, gcc often > recognises these benchmarks as doing nothing useful, so removes whole > sections of code! I never trust benchmarks, in detail when supplied by compiler vendors :-] When we had several workstations for evaluation, the AIX workstation came with a benchmark program executing in about 3 seconds on that machine. On other machines the time ranged from 8 minutes to more than an hour. When I added a printf after the loop in the benchmark code, it also took about 8 minutes! The benchmark turned out to test the compiler *default* optimization settings, where the HP station was so incredibly slow because it had turned off *any* optimization by default. From that experience I also learned what optimization means in practice. A dumb compiler, or with all optimizations disabled, may fetch every expression operand from memory, and write back every intermediate result (SSA?), which is nice when debugging some code. Thus *register allocation* turned out to be a basic optimization of high value - I wonder how somebody could ever design a CPU (with more than 8 bit registers) with as few registers as available on most Intel processors. Dead code elimination and moving loop-invariant computations out of loops are the next optimizations to consider. And CSE... Another compiler, for an M68000, turned out to be a very quick&dirty port of an M6800 compiler. According to "an int is a pointer, a pointer is an int" it kept all operands in the M68K *address* registers, so that every logical or arithmetic operation had to be done in a subroutine, which moved the operands from A0 and A1 into *data* registers, evaluated and stored back the result into A0. The caller had to move the operands into A0 and A1 before, of course. In my test programs every single C statement resulted in about 3 pages of assembler code! [1] But despite that horrible code generation, this compiler came with a very powerful graphics and window software, with amazing runtime behaviour. This observation again relativates the need for optimization, at least in GUI applications. [1] This compiler, and my rudimentary knowledge of C and compilers and runtime libraries, made me write my first C decompiler in the late 80's. Of course in Basic, which was the language I had used on all my homecomputers before. Hereby I learned more and more about bad and good practices in compiler writing, encountering any number of workarounds for adopting old 8-bit compilers to 16/32 bit code and memory layouts. DoDi