Re: gcc 3.2 not faster
On Wed, Jan 08, 2003 at 06:10:42PM +0100, Russell Coker wrote:
> On Wed, 8 Jan 2003 17:00, Michael Stone wrote:
> > On Wed, Jan 08, 2003 at 03:38:04PM +0100, Russell Coker wrote:
> > >I thought that gcc 3.2 was supposed to be faster, however I have just done
> > >some benchmarks to show the opposite:
> > >
> > >GCC 2.95:
> > >Version 1.93b write read putcNT getcNT putc getc putcU
> > > getcU lyta 437 559 9052 9478 1694 1734
> > > 24757 48029
> > >
> > >GCC 3.2:
> > >Version 1.93b write read putcNT getcNT putc getc putcU
> > > getcU 441 568 7955 8573 1617 1698 18731 28544
> >
> > It's helpful when posting benchmarks to give some indication of what the
> > numbers represent. Is it operations per time? Or elapsed seconds? Or
> > bogomips?
>
> Thousands of operations per second.
>
> The "default" for reporting any benchmark results is that bigger numbers are
> better.
That's hardly true. Most of the benchmarks I work with report times.
This is why it's important to specify.
> The relevant fact here is not the absolute numbers, but the fact that GCC 3.2
> produces code that is slower.
But the important question is why.
> I wonder what will happen when libc6 is compiled with GCC 3.2... For
> getc/putc operations what happens in the libc6 is more complex than what
> happens in the application. If the same performance hit occurs when
> compiling libc6 then things will really suck, and I'll probably get CC'd on
> some more amusing flame-wars.
You're missing two important details:
- glibc has been building with GCC 3.2 since well before the
transition; two or three months now at least.
- You can't build glibc 2.3.1 with any earlier version of GCC anyway.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: