Re: confused about performance
Douglas Allan Tutty wrote:
> I meant the whole shebang.
>
> I don't mean to distribute it. More of a massive benchmark to compare
> the gcc with the best commercial compiler and see what difference it
> made to applications we use all the time.
>
> It would be interesting to do this for both 32-bit and 64-bit. Since
> 32-bit gcc is quite mature it could provide some insight into how to
> make it better.
"We have the technology." :) Part of the charm of gcc is that it has
multiple targets, multiple source languages, is extremely well
documents, and can be used as a cross-compiler. On top of that it
supports language-level application coverage analysis and profiling.
I suspect that the language-independent and target hardware independent
parts of gcc are as good as they can be, given the constraints imposed
by such things as NP-completeness for a lot of the guts of compile-time
optimization. And given the trend towards dynamic languages like Perl,
Python, JavaScript, Ruby and the bastard cousin of Perl called PHP, the
focus of the open source communities seems to be on making *them* run
more efficiently -- gcc is "good enough" for a Ruby interpreter, a
Python bytecode interpreter, etc. But not, apparently, good enough for
the Parrot virtual machine -- aren't they using Haskell?
In any event, for most of the Intel chips (Pentium MMX and later) and
the AMD64 chips (*before* Barcelona, I think) the resources at
http://www.agner.org/optimize
are freely available and can help both compiler writers and compiler
users if they don't have the budget for a chip-specific compiler.
>
> As for debian's free software roots, as a comparison, even OpenBSD which
> rants against the GPL at any opportunity still uses gcc since there's no
> other alternative; they're too small to be able to make a bsdcc.
Speaking of which, another bit of nostalgia. I was a happy Red Hat 9
user when Red Hat announced there would not be a Red Hat 10. So I went
and looked at all the distros. I ended up on Debian for a number of reasons:
1. The primary application I had in mind was algorithmic composition and
synthesis of music. Most of the projects used either Red Hat or Debian,
and since I had ruled out Red Hat, Debian was the logical choice.
2. I was also interested in alternative kernels, and the Gnu Hurd kernel
was hosted by Debian
3. The size of the repositories: Woody (stable at the time) had
something like 8 or 9 thousand packages, and Sarge had something like 15
thousand.
After about six months, though, it looked like the Hurd was a dead
project. It depended on specific technologies that weren't active, and
there were a number of more interesting and more active kernel research
projects, like the Dresden Real-Time Operating System (DROPS).
Eventually I just got too busy with other projects to pursue alternate
kernels, and the Linux kernel's audio-specific pieces were stabilizing
and improving rapidly, so I quit pursuing the alternative kernels.
Reply to: