From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Thomas Bushnell, BSG" Message-ID: <87vgck9amg.fsf@becket.becket.net> Content-Type: text/plain; charset=us-ascii References: <20020226030240.9F8F219A2A@mail.cse.psu.edu> Subject: Re: [9fans] p9/linux/fbsd compiler shootout Date: Tue, 26 Feb 2002 10:27:01 +0000 Topicbox-Message-UUID: 5603048e-eaca-11e9-9e20-41e7f4b1d025 Interesting data! Thanks for doing the work, there is a fair bit there to ponder. I wish we had a test that controls for OS, but I understand that this is not available. My instrumentation showed that a fair bit of preprocessor time was spent looking for and reading in include files. (Like I said, that was on an HP-300 running BSD [specifically, More BSD], and I don't know how much that would be relevant to a current context.) Some observations from the data posted, however: The compile time using for the BSD/2.95/no test looks *really* low; are we sure about that number? It's a very strange outlier, isn't it? I'll mostly ignore that one, because it is *such* a surprise; GCC isn't normally thought to be that fast, but hey, maybe it really is. The test confirms that 8c is really fast at doing codegen with a compile time about one-third that of any of the GCC's. From the comments of Plan 9 folks, that was a primary goal in its design, and it does look (from this brief comparison) like they did a really good job! GCC's architecture is strongly geared towards optimization; even if no optimizing passes are done, a lot of work is set up towards enabling machine-independent optimization code, which is essentially wasted if no optimization is done. However, the speed of the resulting code under GCC seems far superior. 8c-generated code runs at about half the speed of GCC optimized code. A total curiosity is that running the Linux binaries under emulation in BSD is *faster* than running the native BSD binaries. It's hard to imagine that the BSD team specially optimized that case, does anyone have any knowledge or guesses? A real surprise for me was that non-optimized GCC also outperformed 8c, though less dramatically. I wonder if that might not be mostly because of the floating-point intensive nature of the test. Rob Pike mentioned that 8c was not so good at fp work, and the 386 especially requires extra special hair to make fp compilation anything approaching effecient. I would expect that on an integer test, we would not see much difference. Now, the BSD and Linux kernels that underlay these tests were of course compiled with optimized GCC, and this also might account for some of the difference; some of what looks like slowness in the code 8c produced might actually be slowness in the Plan 9 kernel (compiled by 8c). I don't know any good way to control for this without porting GCC to Plan 9 and compiling the kernel with it, or alternatively, porting 8c to Linux or BSD. Thomas