Message-ID:	<19990629184940.A4792@tabor.ta.jcu.cz>
Date:	Tue, 29 Jun 1999 18:49:40 +0200
From:	Jan Hubicka <hubicka AT ta DOT jcu DOT cz>
To:	djgpp-workers AT delorie DOT com
Subject:	Re: regparm... byte benchmarks
References:	<19990628165640 DOT A197 AT tabor DOT ta DOT jcu DOT cz> <3778DF4C DOT ADE7D3F4 AT inti DOT gov DOT ar>
Mime-Version:	1.0
X-Mailer:	Mutt 0.93i
In-Reply-To:	<3778DF4C.ADE7D3F4@inti.gov.ar>; from salvador on Tue, Jun 29, 1999 at 11:59:24AM -0300
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, Jun 29, 1999 at 11:59:24AM -0300, salvador wrote:
> Jan Hubicka wrote:
> 
> > Hi
> > I've found the byte benchmarks on my hdd, so here are the results:
> > (-fomit-frame-pointer -O3 -mregparm=x)
> > regparm                 0            1             2               3
> > size                100kb        98kb          97kb           96kb
> > integer             1.865239     1.867126      1.878186       1.892956
> > fp                  1.421428     1.503115      1.493591       1.494438
> >
> > so here is approx 4% difference in executable size and similar difference
> > in running speed.
> 
> I got similar results, the speed up isn't thanks to passing the parameters in the
> registers, but instead thanks to the fact that using it you don't need to adjust the
> stack! this saving is just because gcc doesn't need to emit the add $nn,%esp.
:) OK but it is the win anyway..
> 
> > So overall mregparm=3 seems to do best job
> > There are slight regresions in some tests between regparm0 and regparm3.
> > The largest slowdown is stringsort 2.06 -> 2.04 (about 1%, so it can be statistical
> > error as well, as the slowdown between mregparm=1 to mregparm=3 in fp tests)
> 
> Yes, these tests have more than 1% of error.
> 
> > Largest speedups are in the fourier (1.62 -> 1.87 and huffman 1.86->2.04)
> 
> I'll apply it to these benchmarks, currently I tried only with the numeric sort.
> BTW, try the memmove from djgpp v2.03 and you'll see a big speed up in the strings,
I've just updated my patches for the CVS tree. I am cleaning up the thinks
around and they I might try to split out some small part and try to push
it into official CVS. I am curious how much work this will take :)
> sort.
> 
> > so mregparm seems to be win.
> 
> Yes it left gcc 2.95 very close to MSVC 5.0.
Really? I didn't know that differences to MSVC are so small. I am getting much
larger speedups using new backend. Also string functions can be optimized
a bit. After this we can actually beat MSVC :))
Whats about using the string functions and math inlines from glibc.
hey are much better optimized IMO and especially math inlines brings
large speedups in apps using them. Are the licences compatible?

BTW I am pretty short on time. Are you interested in helping me to finish the
changes? I really need some help :)
If so I can place my latest patches somewhere on ftp. 
BTW2 what I need to run the tests? It is failing because rmake
and similar stuff is missing.

Honza
> 
> SET
> 
> --
> Salvador Eduardo Tropea (SET). (Electronics Engineer)
> Visit my home page: http://welcome.to/SetSoft or
> http://www.geocities.com/SiliconValley/Vista/6552/
> Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
>                     set AT ieee DOT org set-soft AT bigfoot DOT com
> Address: Curapaligue 2124, Caseros, 3 de Febrero
> Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
> 
> 

- Raw text -