jer@peora.UUCP (J. Eric Roskos) (03/02/85)
Recently a number of Sieve benchmarks have been posted for the Macintosh demonstrating various compilers. Such benchmarks are beneficial (although they don't substitute for a simple visual examination of the generated object code), but merely posting the results of existing compilers has always seemed to me to be only half the task, albeit the harder one. To know whether a given benchmark result is "good", you need to have something to compare it to --- otherwise, you could have a lot of slow compilers, and never know it. I have posted to net.sources.mac an assembly-language version of the Sieve benchmark. A BINHEX version 4 object file is included, along with the source for the sieve part of the program. (For a variety of reasons, I have not posted the startup or termination code, or the runtime routines: they are long, not particularly interesting, and make the program hard to read -- and, of course, they don't influence the benchmark time.) My attempt in writing this program was to produce the sort of code that a reasonably good globally-optimizing compiler could be expected to produce: a fairly algorithmic translation from the Pascal source code, but with some traditional optimizations such as allocation of loop variables to registers, common subexpression elimination, etc. At the same time, I've TRIED not to do anything that would be unreasonable for a non-human compiler to do; though I leave it to the experienced compiler-writers reading this to say if this effort succeeded. Regarding the program itself: in order to get enough space for the flags array, I allocated the array on the heap. Thus the variable "flags" con- tains a pointer to the array, rather than being the first element of the array. Also, the routine prd3 which prints the D3 register does so in hexadecimal (because it was a little easier to do). Other than that, the program is straightforward, and comments show (in Pascal) what's going on in the assembly language code. Hopefully this will show something near a lower-bound for Sieve execution time (though it would be nice if a compiler eventually produced code even faster). The optimization techniques used are not those that are common for microcomputer compilers (although, judging from their previous products, some of the compiler writers currently producing compilers are capable of producing such optimizers); so it is not really fair to fault those whose execution times do not come close. Rather, one should aspire to see compilers that fast (and maybe compiler writers should take it as a challenge!)