Re: Semaphore assembly-code bug

Re: Semaphore assembly-code bug

[Andi Kleen]

dean gaudet <dean-list-linux-kernel@arctic.org> writes:
> 
> it's worse than that in general -- lea typically goes through the AGU 
> which has either less throughput or longer latency than the ALUs... 
> depending on which x86en.  it's 4 cycles for a lea on p4, vs. 1 for a pop.  
> it's 2 cycles for a lea on k8 vs. 1 for a pop.

On D stepping and later K8 the lea is 1 cycle latency because the
decoder optimizes the lea into an add.

-Andi

Re: Semaphore assembly-code bug

[Andi Kleen]

Linus Torvalds <torvalds@osdl.org> writes:

> Anyway, it's quite likely that for several CPU's the fastest sequence ends 
> up actually being 
> 
> 	movl 4(%esp),%ecx
> 	movl 8(%esp),%edx
> 	movl 12(%esp),%eax
> 	addl $16,%esp
> 
> which is also one of the biggest alternatives.

For K8 it should be the fastest way. K7 probably too.

-Andi

Re: Semaphore assembly-code bug

[Denis Vlasenko]

On Saturday 30 October 2004 05:13, Andi Kleen wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > Anyway, it's quite likely that for several CPU's the fastest sequence ends 
> > up actually being 
> > 
> > 	movl 4(%esp),%ecx
> > 	movl 8(%esp),%edx
> > 	movl 12(%esp),%eax
> > 	addl $16,%esp
> > 
> > which is also one of the biggest alternatives.
> 
> For K8 it should be the fastest way. K7 probably too.

Pity. I always loved 1 byte insns :)

/me hopes that K8 rev E or K9 will have optimized pop.
--
vda

Re: Semaphore assembly-code bug

[Linus Torvalds]

On Sat, 30 Oct 2004, Denis Vlasenko wrote:
>
> On Saturday 30 October 2004 05:13, Andi Kleen wrote:
> > Linus Torvalds <torvalds@osdl.org> writes:
> > 
> > > Anyway, it's quite likely that for several CPU's the fastest sequence ends 
> > > up actually being 
> > > 
> > > 	movl 4(%esp),%ecx
> > > 	movl 8(%esp),%edx
> > > 	movl 12(%esp),%eax
> > > 	addl $16,%esp
> > > 
> > > which is also one of the biggest alternatives.
> > 
> > For K8 it should be the fastest way. K7 probably too.
> 
> Pity. I always loved 1 byte insns :)

I personally am a _huge_ believer in small code. 

The sequence

	popl %eax
	popl %ecx
	popl %edx
	popl %eax

is four bytes. In contrast, the three moves and an add is 15 bytes. That's 
almost 4 times as big.

And size _does_ matter. The extra 11 bytes means that if you have six of
these sequences in your program, you are pretty much _guaranteed_ one more
icache miss from memory. That's a few hundred cycles these days.  
Considering that you _maybe_ won a cycle or two each time it was executed,
it's not at all clear that it's a win, except in benchmarks that have huge
repeat-rates. Real life doesn't usually have that. In many real-life
schenarios, repeat rates are in the tens of hundreds for most code...

And that's ignoring things like disk load times etc.

Sadly, the situation is often one where when you actually do all the 
performance testing, you artificially increase the repeat-rates hugely: 
you run the same program a thousand times in order to get a good profile, 
and you keep in the the cache all the time. So performance analysis often 
doesn't actually _see_ the downsides.

			Linus

Re: Semaphore assembly-code bug

[Denis Vlasenko]

On Saturday 30 October 2004 20:53, Linus Torvalds wrote:
> > > > 	movl 4(%esp),%ecx
> > > > 	movl 8(%esp),%edx
> > > > 	movl 12(%esp),%eax
> > > > 	addl $16,%esp
> > > > 
> > > > which is also one of the biggest alternatives.
> > > 
> > > For K8 it should be the fastest way. K7 probably too.
> > 
> > Pity. I always loved 1 byte insns :)
> 
> I personally am a _huge_ believer in small code. 

Thankfully you are not alone - a horde of uclibc/dietlibc/busybox
users shares these views. Also see http://smarden.org/pape/

> The sequence
> 
> 	popl %eax
> 	popl %ecx
> 	popl %edx
> 	popl %eax
> 
> is four bytes. In contrast, the three moves and an add is 15 bytes. That's 
> almost 4 times as big.
> 
> And size _does_ matter. The extra 11 bytes means that if you have six of
> these sequences in your program, you are pretty much _guaranteed_ one more
> icache miss from memory. That's a few hundred cycles these days.  
> Considering that you _maybe_ won a cycle or two each time it was executed,
> it's not at all clear that it's a win, except in benchmarks that have huge
> repeat-rates. Real life doesn't usually have that. In many real-life
> schenarios, repeat rates are in the tens of hundreds for most code...

If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more...

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
15364 root      15   0 38008  26M 28496 S     0,0 10,8   0:57   0 kmail
20022 root      16   0 40760  24M 23920 S     0,1 10,0   0:04   0 mozilla-bin
 1627 root      14  -1 71064  19M 53192 S <   0,1  7,9   3:16   0 X
 1700 root      15   0 25348  16M 23508 S     0,1  6,5   0:46   0 kdeinit
 3578 root      15   0 24032  14M 21524 S     0,5  5,8   0:23   0 konsole
--
vda

code bloat [was Re: Semaphore assembly-code bug]

[Lee Revell]

On Sun, 2004-10-31 at 00:00 +0300, Denis Vlasenko wrote:
> If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more...
> 
>   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
> 15364 root      15   0 38008  26M 28496 S     0,0 10,8   0:57   0 kmail
> 20022 root      16   0 40760  24M 23920 S     0,1 10,0   0:04   0 mozilla-bin
>  1627 root      14  -1 71064  19M 53192 S <   0,1  7,9   3:16   0 X
>  1700 root      15   0 25348  16M 23508 S     0,1  6,5   0:46   0 kdeinit
>  3578 root      15   0 24032  14M 21524 S     0,5  5,8   0:23   0 konsole

Wow. evolution is now more bloated than kmail.

 1424 rlrevell  15   0  125m  47m  29m S  7.8 10.1   1:41.78 evolution
 1508 rlrevell  15   0 92432  30m  29m S  0.0  6.4   0:14.15 mozilla-bin
 1090 root      16   0 55676  18m  40m S 24.8  3.9   0:46.98 XFree86
 1379 rlrevell  15   0 33776  16m  18m S  0.3  3.5   0:06.65 nautilus
 1377 rlrevell  15   0 19392  11m  15m S  0.0  2.5   0:03.29 gnome-panel
 1458 rlrevell  16   0 28188  11m  15m S  3.9  2.5   0:10.44 gnome-terminal
 1307 rlrevell  15   0 20828  11m  17m S  0.0  2.4   0:03.08 gnome-settings-

Lee

Re: code bloat [was Re: Semaphore assembly-code bug]

[Denis Vlasenko]

On Sunday 31 October 2004 00:14, Lee Revell wrote:
> On Sun, 2004-10-31 at 00:00 +0300, Denis Vlasenko wrote:
> > If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more...
> > 
> >   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
> > 15364 root      15   0 38008  26M 28496 S     0,0 10,8   0:57   0 kmail
> > 20022 root      16   0 40760  24M 23920 S     0,1 10,0   0:04   0 mozilla-bin
> >  1627 root      14  -1 71064  19M 53192 S <   0,1  7,9   3:16   0 X
> >  1700 root      15   0 25348  16M 23508 S     0,1  6,5   0:46   0 kdeinit
> >  3578 root      15   0 24032  14M 21524 S     0,5  5,8   0:23   0 konsole
> 
> Wow. evolution is now more bloated than kmail.
> 
>  1424 rlrevell  15   0  125m  47m  29m S  7.8 10.1   1:41.78 evolution
>  1508 rlrevell  15   0 92432  30m  29m S  0.0  6.4   0:14.15 mozilla-bin
>  1090 root      16   0 55676  18m  40m S 24.8  3.9   0:46.98 XFree86
>  1379 rlrevell  15   0 33776  16m  18m S  0.3  3.5   0:06.65 nautilus
>  1377 rlrevell  15   0 19392  11m  15m S  0.0  2.5   0:03.29 gnome-panel
>  1458 rlrevell  16   0 28188  11m  15m S  3.9  2.5   0:10.44 gnome-terminal
>  1307 rlrevell  15   0 20828  11m  17m S  0.0  2.4   0:03.08 gnome-settings-

Well, I can try to compile packages with different options
for size, I can link against small libc, but I feel this
does not solve the problem: the code itself is bloated...

I am not a code genius, but want to help.

Hmm probably some bloat-detection tools would be helpful,
like "show me source_lines/object_size ratios of fonctions in
this ELF object file". Those with low ratio are suspects of
excessive inlining etc.

More ideas, anyone?
--
vda

Re: code bloat [was Re: Semaphore assembly-code bug]

[Lee Revell]

On Sun, 2004-10-31 at 01:11 +0300, Denis Vlasenko wrote:
> Well, I can try to compile packages with different options
> for size, I can link against small libc, but I feel this
> does not solve the problem: the code itself is bloated...
> 
> I am not a code genius, but want to help.
> 
> Hmm probably some bloat-detection tools would be helpful,
> like "show me source_lines/object_size ratios of fonctions in
> this ELF object file". Those with low ratio are suspects of
> excessive inlining etc.
> 
> More ideas, anyone?

I ageww it's a hard problem.  Right now there is massive pressure on
Linux application developers to add features to catch up with MS and
Apple.  This inevitably leads to bloat, we all know that efficiency is
the first thing to go out the window in that situation, the problem is
exacerbated by the wide availability of fast machines.  It's an old,
depressing story...

That being said it would indeed be nice if we had more tools to quantify
bloat. 

Lee

Re: code bloat [was Re: Semaphore assembly-code bug]

[Diego Calleja]

El Sat, 30 Oct 2004 18:25:38 -0400 Lee Revell <rlrevell@joe-job.com> escribió:

> I ageww it's a hard problem.  Right now there is massive pressure on
> Linux application developers to add features to catch up with MS and
> Apple.  This inevitably leads to bloat, we all know that efficiency is

I don't think it's so bad (ie: it could be _worse_)

There's some work going on to fix some "bloat problems" too, for example
the x.org people are working in a sort of xlib complement/replacement (i
don't know its real purpose) xcb which should help latency and code
size. Composite itself is a nice way of avoiding that apps redraw their
windows all the time. KDE "speed" is better is much better than a year 
ago, gnome 2.8 is also somewhat "faster" (compare nautilus in gnome 2.6
vs the one in 2.8). Openoffice 2.0 also will have some "performance
improvements" (see http://development.openoffice.org/releases/q-concept.html#4.1.3.Performance|outline
and http://development.openoffice.org/releases/q-concept.html#3.1.3.Performance|outline)

Re: code bloat [was Re: Semaphore assembly-code bug]

[Z Smith]

Diego Calleja wrote:

> I don't think it's so bad (ie: it could be _worse_)

But not everyone can tolerate today's level of bloat.

Imagine a small charity in a rural town in Bolivia or
Colorado. They have no budget for computers and no one
is offering donations. A local person put Linux on their 200 MHz
system after Windows crashed and the Windows CD couldn't
be found, but he can't put KDE or Gnome on it as well because
that would bring it to a crawl. The only way to make the
computer usable is to install an old distribution of Linux
from 1998 which has Netscape 4 but no office app. Eventually
they will give up on the computer and just throw it out,
because they can't wait forever for programmers to write
non-bloated software to make good use of their system.
The machine ends up at a landfill where it leeches chemicals
into the local water supply.

Zack

Re: code bloat [was Re: Semaphore assembly-code bug]

[Rogério Brito]

Z Smith wrote:
> But not everyone can tolerate today's level of bloat.
> 
> Imagine a small charity in a rural town in Bolivia or
> Colorado. They have no budget for computers and no one
> is offering donations.

Well, let me jump into this thread. I don't live in Bolivia or Colorado, 
but I do live in Brazil.

The fastest computer that I have at my disposal is this one with a Duron 
600MHz processor. My father uses a Pentium MMX 200MHz with 64MB of RAM. 
Unfortunately, for financial reasons, I don't see we upgrading our 
computers too soo.

It is nice to read Alan Cox saying that the Gnome team can make Gnome 
use less memory in the future. I'm anxiously looking forward to that. In 
the mean time, I will be using fluxbox and hoping that other parts of 
the system (libraries etc) don't grow too fast for my computers.

I know plenty of people in the same situation that I am. Given the 
choice of purchasing a book for my education or upgrading my computer, I 
guess that I should spend money on the former.

And the same is true for many of my relatives and friends.


Rogério Brito.

-- 
Learn to quote e-mails decently at:
http://pub.tsn.dk/how-to-quote.php
http://learn.to/quote
http://www.xs4all.nl/~sbpoley/toppost.htm

Re: code bloat [was Re: Semaphore assembly-code bug]

[Z Smith]

Rogério Brito wrote:
> Z Smith wrote:

> The fastest computer that I have at my disposal is this one with a Duron 
> 600MHz processor. My father uses a Pentium MMX 200MHz with 64MB of RAM. 
> Unfortunately, for financial reasons, I don't see we upgrading our 
> computers too soo.

It seems that as time goes by, more and more people are
coming to be financially limited. In some cases the cause
is clearly the IMF / World Bank / WTO triad.

Some casual reading:
http://www.gregpalast.com/printerfriendly.cfm?artid=96

Zack

Re: code bloat [was Re: Semaphore assembly-code bug]

[Diego Calleja]

El Sun, 31 Oct 2004 12:53:21 -0800 Z Smith <plinius@comcast.net> escribió:

> But not everyone can tolerate today's level of bloat.

Sadly it's true, but in the other hand I haven't seen something like gnome/kde
which don't eats lots of resources (mac os x and XP are not better, beos was
better they say), which makes me think that building a  desktop environment
without eating lots of resources is not easy. Well, and your projct is also
bloat in some ways...it's small and all that but putting a graphics system
inside the kernel is one of the best definitions of "bloat" you can find...

[OT] Re: code bloat [was Re: Semaphore assembly-code bug]

[Russell Miller]

On Monday 01 November 2004 08:48, Diego Calleja wrote:

> Sadly it's true, but in the other hand I haven't seen something like
> gnome/kde which don't eats lots of resources (mac os x and XP are not
> better, beos was better they say)

Part of the problem with KDE is the QT library underneath it all.  QT 4 is 
supposed to be leaner and faster.  The KDE folks seem to be trying pretty 
hard to reduce bloat whenever possible.  But when you have software that's 
expected to have the kitchen sink, it's especially challenging to reduce the 
footprint while keeping all of the functionality.

I use openbox on my laptop.  It's nothing near KDE in terms of functionality, 
but it also runs reasonably snappy on a Pentium 266, so I can't complain too 
much.

So far I'm pretty glad that the linux kernel developers have resisted putting 
graphics calls and routines into the kernel.  It slows things down a bit, but 
I'd like to think you guys have learned from MS's mistakes.  IMO one of the 
biggest mistakes they ever made was to pollute the NT kernel with the 
graphics subsystem.  That said, FBUI looks like an interesting add-on 
project.

Enough of my off topic ranting...

--Russell

-- 

Russell Miller - rmiller@duskglow.com - Le Mars, IA
Duskglow Consulting - Helping companies just like you to succeed for ~ 10 yrs.
http://www.duskglow.com - 712-546-5886

Re: code bloat [was Re: Semaphore assembly-code bug]

[Tim Hockin]

On Sun, Oct 31, 2004 at 01:11:07AM +0300, Denis Vlasenko wrote:
> I am not a code genius, but want to help.
> 
> Hmm probably some bloat-detection tools would be helpful,
> like "show me source_lines/object_size ratios of fonctions in
> this ELF object file". Those with low ratio are suspects of
> excessive inlining etc.

The problem with apps of this sort is the multiple layers of abstraction.

Xlib, GLib, GTK, GNOME, Pango, XML, etc.

No one wants to duplicate effort (rightly so).  Each of these libs tries
to do EVERY POSSIBLE thing.  They all end up bloated.  Then you have to
link them all in.  You end up bloated.  Then it is very easy to rely on
those libs for EVERYTHING, rather thank actually thinking.

So you end up with the mindset of, for example, "if it's text it's XML".
You have to parse everything as XML, when simple parsers would be tons
faster and simpler and smaller.

Bloat is cause by feature creep at every layer, not just the app.

Youck.

Re: code bloat [was Re: Semaphore assembly-code bug]

[Jeff Garzik]

Tim Hockin wrote:
> So you end up with the mindset of, for example, "if it's text it's XML".
> You have to parse everything as XML, when simple parsers would be tons
> faster and simpler and smaller.


hehehe.  One of the reasons why I like XML is that you don't have to 
keep cloning new parsers.

	Jeff

Re: code bloat [was Re: Semaphore assembly-code bug]

[Tim Hockin]

On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote:
> Tim Hockin wrote:
> >So you end up with the mindset of, for example, "if it's text it's XML".
> >You have to parse everything as XML, when simple parsers would be tons
> >faster and simpler and smaller.
> 
> 
> hehehe.  One of the reasons why I like XML is that you don't have to 
> keep cloning new parsers.

I'm fine with XML, when it makes sense.  In fact, I wrote an XML parser.
It's blazingly fast.  But it doesn't try to do everything for everyone.
It does just as much as I needed.  And Whn I need XML, I don;t have any
problem linking it in.  It's only a couple hundred lines of C.

What irks me is best demonstrated by this:

At OLS last year or the year before, at a talk about DBUS, someone asked
about the DBUS protocol.  When told that it was binary, they asked if
there was any advantage to that over text.  The reply "We didn't want to
link an XML parser in".

Now, I am fine with not wanting to ad bloat.  But umm, the question was
about TEXT, not XML.  They are not the same thing.  Not all text should be
XML.

Re: code bloat [was Re: Semaphore assembly-code bug]

[Theodore Ts'o]

On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote:
> Tim Hockin wrote:
> >So you end up with the mindset of, for example, "if it's text it's XML".
> >You have to parse everything as XML, when simple parsers would be tons
> >faster and simpler and smaller.
> 
> hehehe.  One of the reasons why I like XML is that you don't have to 
> keep cloning new parsers.

.... if you don't mind bloating your application:

% ls -l /usr/lib/libxml2.a
4224 -rw-r--r--  1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a

						- Ted

Re: code bloat [was Re: Semaphore assembly-code bug]

[Jeff Garzik]

Theodore Ts'o wrote:
> On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote:
> 
>>Tim Hockin wrote:
>>
>>>So you end up with the mindset of, for example, "if it's text it's XML".
>>>You have to parse everything as XML, when simple parsers would be tons
>>>faster and simpler and smaller.
>>
>>hehehe.  One of the reasons why I like XML is that you don't have to 
>>keep cloning new parsers.
> 
> 
> .... if you don't mind bloating your application:
> 
> % ls -l /usr/lib/libxml2.a
> 4224 -rw-r--r--  1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a

GLib's is a lot smaller :)

	Jeff

Re: code bloat [was Re: Semaphore assembly-code bug]

[Jan Engelhardt]

>.... if you don't mind bloating your application:
>
>% ls -l /usr/lib/libxml2.a
>4224 -rw-r--r--  1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a

Whoa. Bet its creator compiled with -g -O2 rather than -g0 -O2. ANd with
-static instead of with <dynamic>. Yay look at this:

22:06 io:~ # l /usr/lib/libxml2.so -L
#SUSE# -rwxr-xr-x  1 root root 1145089 Apr  6  2004 /usr/lib/libxml2.so

4x smaller!



Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: code bloat [was Re: Semaphore assembly-code bug]

[Alan Cox]

On Sul, 2004-10-31 at 20:15, Theodore Ts'o wrote:
> .... if you don't mind bloating your application:
> 
> % ls -l /usr/lib/libxml2.a
> 4224 -rw-r--r--  1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a

Except that
1. The file size has nothing to do with the binary size as it is full of
symbols and maybe debug
2. Most of the pages of libxml2.so don't get paged in by a typical
application
3. If you have existing apps using it then its cost to you is nearly
zero because its already loaded.

libxml2 is a very complete validating all singing all dancing XML
parser. There are small non-validating parsers without every conceivable
glue interface that come down to about 10K.

Re: code bloat [was Re: Semaphore assembly-code bug]

[Denis Vlasenko]

On Monday 01 November 2004 13:27, Alan Cox wrote:
> 2. Most of the pages of libxml2.so don't get paged in by a typical
> application

This assumes that 'needed' functions are close together.
This can be easily not the case, so you end up using only
a fraction of fetched page's content.

Also this argument tend to defend library growth.
"It's mostly unused, don't worry". What if that
is not true? How to compare RAM footprint
of new versus old lib in this case?
Just believe that it didn't get worse?

This can't be checked easily:
even -static compile can fail to help.
glibc produce nearly 400kb executable for

int main() { return 0; }

because init code uses printf on error paths and
that pulls i18n in. How many kilobytes is really
runs - who knows...
--
vda

Re: code bloat [was Re: Semaphore assembly-code bug]

[Alan Cox]

On Llu, 2004-11-01 at 13:40, Denis Vlasenko wrote:
> This assumes that 'needed' functions are close together.
> This can be easily not the case, so you end up using only
> a fraction of fetched page's content.

And gprof will help you sort that out, along with -ffunction-sections
you can do pretty fine grained tidying

Re: code bloat [was Re: Semaphore assembly-code bug]

[Denis Vlasenko]

On Sunday 31 October 2004 01:27, Tim Hockin wrote:
> On Sun, Oct 31, 2004 at 01:11:07AM +0300, Denis Vlasenko wrote:
> > I am not a code genius, but want to help.
> > 
> > Hmm probably some bloat-detection tools would be helpful,
> > like "show me source_lines/object_size ratios of fonctions in
> > this ELF object file". Those with low ratio are suspects of
> > excessive inlining etc.
> 
> The problem with apps of this sort is the multiple layers of abstraction.
> 
> Xlib, GLib, GTK, GNOME, Pango, XML, etc.

I think it makes sense to start from lower layers first:

Kernel team is reasonably aware of the bloat danger.

glibc is worse, but thanks to heroic actions of Eric Andersen
we have mostly feature complete uclibc, 4 times (!)
smaller than glibc.

Xlib, GLib.... - didn't look into them apart from cases
when they do not build or in bug hunting sessions.
Quick data point: glib-1.2.10 is 1/2 of uclibc in size.
glib-2.2.2 is 2 times uclibc. x4 growth :(

> No one wants to duplicate effort (rightly so).  Each of these libs tries
> to do EVERY POSSIBLE thing.  They all end up bloated.  Then you have to
> link them all in.  You end up bloated.  Then it is very easy to rely on
> those libs for EVERYTHING, rather thank actually thinking.
> 
> So you end up with the mindset of, for example, "if it's text it's XML".
> You have to parse everything as XML, when simple parsers would be tons
> faster and simpler and smaller.
> 
> Bloat is cause by feature creep at every layer, not just the app.

I actually tried to convince maintainers of one package
that their code is needlessly complex. I did send patches
to remedy that a bit while fixing real bugs. Rejected.
Bugs were planned to be fixed by adding more code.
I've lost all hope on that case.

I guess this is a reason why bloat problem tend to be solved
by rewrite from scratch. I could name quite a few cases:

glibc -> dietlibc,uclibc
coreutils -> busybox
named -> djbdns
inetd -> daemontools+ucspi-tcp
sendmail -> qmail
syslogd -> socklog (http://smarden.org/socklog/)

It's sort of frightening that someone will need to
rewrite Xlib or, say, OpenOffice :(
--
vda

Re: code bloat [was Re: Semaphore assembly-code bug]

[Alan Cox]

The gnome/gtk folks know they have a lot of code bloat, and know how to
shave about 10Mb off the desktop size already. What they don't have is
enough hands and brains to do this and the other stuff that is pressing.
So if the desktop stuff is annoying you join gnome-love or whatever the
kde equivalent is 8)

Alan

Re: code bloat [was Re: Semaphore assembly-code bug]

[Z Smith]

Alan Cox wrote:

> So if the desktop stuff is annoying you join gnome-love or whatever the
> kde equivalent is 8)

Or join me in my effort to limit bloat. Why use an X server
that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
of code with very minimal kmallocing?

home.comcast.net/~plinius/fbui.html

Zack Smith
Bloat Liberation Front

Re: code bloat [was Re: Semaphore assembly-code bug]

[Jim Nelson]

Z Smith wrote:
> Alan Cox wrote:
> 
>> So if the desktop stuff is annoying you join gnome-love or whatever the
>> kde equivalent is 8)
> 
> 
> Or join me in my effort to limit bloat. Why use an X server
> that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
> of code with very minimal kmallocing?
> 
> home.comcast.net/~plinius/fbui.html
> 
> Zack Smith
> Bloat Liberation Front
> 

Because some of us use remote X clients on big iron with an X server on your 
desktop.  IIRC (been a long time since my CAD classes), a whole bunch of FEA and 
CAE/CAD applications worked this way.

There is a lot more flexibility inherent in user-space compared to kernel-space. 
You can use PAM, Kerberos, and a whole host of other security devices that would 
be difficult to implement efficiently in kernel-space.

Dude, that's a cool hack, but just about everything you did could be done with 
svgalib and the input core interface.  The advantage to svgalib is that if that 
interface dies, you can recover the machine pretty easily, whereas kernel panics 
are a bit more disruptive.

Still - it would be a nifty add-on for POS terminals, etc., just not the kind of 
thing I'd expect to see in the kernel anytime soon.  Once 2.7 is started, see if 
people are more receptive.  Take the time to flesh it out, get some more people on 
board, see if Sourceforge will host the project, and lose the advertising campaign 
- that's not likely to win any friends or supporters around here.

I don't mean to be harsh, but c'mon - "Bloat Liberation Front" - err... okaaay...

Good luck,

Jim

Re: code bloat [was Re: Semaphore assembly-code bug]

[Alan Cox]

On Sul, 2004-10-31 at 01:21, Z Smith wrote:
> Alan Cox wrote:
> 
> > So if the desktop stuff is annoying you join gnome-love or whatever the
> > kde equivalent is 8)
> 
> Or join me in my effort to limit bloat. Why use an X server
> that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
> of code with very minimal kmallocing?

My X server seems to be running at about 4Mbytes, plus the frame buffer
mappings which make it appear a lot larger. I wouldn't be suprised if
half the 4Mb was pixmap cache too, maybe more.

I've helped write tiny UI kits (take a look at nanogui for example) but
they don't have the flexibility of X.

Alan

Re: code bloat [was Re: Semaphore assembly-code bug]

[Z Smith]

Alan Cox wrote:

> My X server seems to be running at about 4Mbytes, plus the frame buffer
> mappings which make it appear a lot larger. I wouldn't be suprised if
> half the 4Mb was pixmap cache too, maybe more.

At first sight that sounds like a plausible explanation, however
the facts in my case suggest something else is going on:

My laptop's framebuffer is only 800x600x24bpp VESA, or 1406kB.
But look at what X is doing:

root       632  6.1 17.5 22024 16440 ?       S    12:05   0:17 X :0

The more apps in use, the more memory is used, but at the moment
I've only got xterm, rxvt, thunderbird, xclock and xload. My wm is
blackbox which is using 5 megs.

Also, just curious but why would memory-mapped I/O be counted
in the memory usage anyway? Shouldn't there be a separate number
for framebuffer memory and the like?

> I've helped write tiny UI kits (take a look at nanogui for example) but
> they don't have the flexibility of X.

In my experience, most of the flexibility is not necessary for
97% of what I do, yet it evidently costs a lot in memory usage
and speed.

Zack

Re: code bloat [was Re: Semaphore assembly-code bug]

[Alan Cox]

On Sul, 2004-10-31 at 20:18, Z Smith wrote:
> My laptop's framebuffer is only 800x600x24bpp VESA, or 1406kB.
> But look at what X is doing:

X has the frame buffer mapped as reported by VESA sizing not the 
minimal for the mode. (Think about RandR and you'll see why)

> root       632  6.1 17.5 22024 16440 ?       S    12:05   0:17 X :0
> 
> The more apps in use, the more memory is used, but at the moment
> I've only got xterm, rxvt, thunderbird, xclock and xload. My wm is
> blackbox which is using 5 megs.

Mostly shared with the other apps, you did remember to divide each page
by the number of users ?

> Also, just curious but why would memory-mapped I/O be counted
> in the memory usage anyway? Shouldn't there be a separate number
> for framebuffer memory and the like?

Actually there is probably not enough information in /proc to do the
maths on it. The kernel itself has a clear idea which vma's are not
backed by ram in the usual sense as they are marked VM_IO.

> > I've helped write tiny UI kits (take a look at nanogui for example) but
> > they don't have the flexibility of X.
> 
> In my experience, most of the flexibility is not necessary for
> 97% of what I do, yet it evidently costs a lot in memory usage
> and speed.

So my X server is 1Mb larger because I can run networked apps and play
bzflag. Suits me as a tradeoff - I'm not saying it always is the right
decision - nanogui works well in restricted environments like video
recorders for example.

[OT] Re: code bloat [was Re: Semaphore assembly-code bug]

[Lee Revell]

On Sun, 2004-10-31 at 02:13 +0300, Denis Vlasenko wrote:
> It's sort of frightening that someone will need to
> rewrite Xlib or, say, OpenOffice :(

I think very few application developers understand the point Linus made
- that bigger code IS slower code due to cache misses.  If this were
widely understood we would be in pretty good shape.

Lee

Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug]

[Alan Cox]

On Sul, 2004-10-31 at 00:20, Lee Revell wrote:
> I think very few application developers understand the point Linus made
> - that bigger code IS slower code due to cache misses.  If this were
> widely understood we would be in pretty good shape.

On my laptop both Openoffice and gnome are measurably faster if you
build the lot with -Os (except a couple of image libs)

Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug]

[Ken Moffat]

On Sat, 30 Oct 2004, Alan Cox wrote:

> On Sul, 2004-10-31 at 00:20, Lee Revell wrote:
> > I think very few application developers understand the point Linus made
> > - that bigger code IS slower code due to cache misses.  If this were
> > widely understood we would be in pretty good shape.
>
> On my laptop both Openoffice and gnome are measurably faster if you
> build the lot with -Os (except a couple of image libs)
>

Depends how much of gnome you use.  I used to swear by -Os for
non-toolchain stuff, but in the end I got bitten by gnumeric on x86.
http://bugs.gnome.org/show_bug.cgi?id=128834 is similar, but in my case
opening *any* spreadsheet would cause gnumeric to segfault (gcc-3.3
series).  Add in the time spent rebuilding gnome before I found this bug
report, and adding extra parts of gnome just in case I missed something,
and the time to load it is irrelevant.  Since then I've had an anecdotal
report that -Os is known to cause problems with gnome.  I s'pose people
will say it serves me right for doing my initial testing on ppc which
didn't have this problem ;)  The point is that -Os is *much* less tested
than -O2 at the moment.

Ken
-- 
 das eine Mal als Tragödie, das andere Mal als Farce

Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug]

[Tim Connors]

Ken Moffat <ken@kenmoffat.uklinux.net> said on Sun, 31 Oct 2004 01:09:54 +0000 (GMT):
> and the time to load it is irrelevant.  Since then I've had an anecdotal
> report that -Os is known to cause problems with gnome.  I s'pose people
> will say it serves me right for doing my initial testing on ppc which
> didn't have this problem ;)  The point is that -Os is *much* less tested
> than -O2 at the moment.

Because people suck, and don't use it and hence test it.

Ie, test it!

I can't, because I prefer to stay away from gnome instead.

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
"Warning: Do not look into laser with remaining eye" -- a physics experiment
"Press emergency laser shutdown button with remaining hand" -- J.D.Baldwin @ ASR

Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug]

[Paul]

Tim Connors <tconnors+linuxkernel1099190446@astro.swin.edu.au>, on Sun Oct 31, 2004 [01:42:34 PM] said:
> Ken Moffat <ken@kenmoffat.uklinux.net> said on Sun, 31 Oct 2004 01:09:54 +0000 (GMT):
> > and the time to load it is irrelevant.  Since then I've had an anecdotal
> > report that -Os is known to cause problems with gnome.  I s'pose people
> > will say it serves me right for doing my initial testing on ppc which
> > didn't have this problem ;)  The point is that -Os is *much* less tested
> > than -O2 at the moment.
> 
> Because people suck, and don't use it and hence test it.
> 
> Ie, test it!
> 
> I can't, because I prefer to stay away from gnome instead.
> 

	Hi;

	Ive been using -Os as my default compile flag under
Gentoo for probably over 2 years now. Havent noted any real
problems, and thats nearly 3gig of compressed source code
compiled on what is just my current system image.
	(Well, I might suck a little because I havent done any
benchmarks or comparisons as to the actual benifits of doing
so. Also, I use fvwm;)

Paul
set@pobox.com

> -- 
> TimC -- http://astronomy.swin.edu.au/staff/tconnors/

Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug]

[Alan Cox]

On Sul, 2004-10-31 at 01:09, Ken Moffat wrote:
> and the time to load it is irrelevant.  Since then I've had an anecdotal
> report that -Os is known to cause problems with gnome.  I s'pose people
> will say it serves me right for doing my initial testing on ppc which
> didn't have this problem ;)  The point is that -Os is *much* less tested
> than -O2 at the moment.

I've seen no real problems - x86-32 or x86-64, and my gnumeric appears
happy. Could be that the Red Hat gcc 3.3 has the relevant fixes already
in it from upstream I guess.

Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug]

[Andi Kleen]

On Sat, Oct 30, 2004 at 07:20:04PM -0400, Lee Revell wrote:
> On Sun, 2004-10-31 at 02:13 +0300, Denis Vlasenko wrote:
> > It's sort of frightening that someone will need to
> > rewrite Xlib or, say, OpenOffice :(
> 
> I think very few application developers understand the point Linus made
> - that bigger code IS slower code due to cache misses.  If this were
> widely understood we would be in pretty good shape.

It's true in some cases, but not true in others. Don't make it your
gospel. 

-Andi

Re: code bloat [was Re: Semaphore assembly-code bug]

[Tim Hockin]

On Sun, Oct 31, 2004 at 02:13:37AM +0300, Denis Vlasenko wrote:
> > Bloat is cause by feature creep at every layer, not just the app.
> 
> I actually tried to convince maintainers of one package
> that their code is needlessly complex. I did send patches
> to remedy that a bit while fixing real bugs. Rejected.
> Bugs were planned to be fixed by adding more code.
> I've lost all hope on that case.

See, there is an ego problem, too.  If you rewrite my code, it means
you're better than I am.  Rejected.

Features win over efficiency.  Seriously, look at glibc.  Hav eyou ever
tried to fix a bug in it?  Holy CRAP is that horrible code.  Each chunk of
code itself is OK (though it abuses macrso so thoroughly I hesitate to
call it C code).  But it tried to support every architecture x every OS.
You know what?  I don't CARE if the glibc code compiles on HPUX or not.
HPUX has it's own libc.

> I guess this is a reason why bloat problem tend to be solved
> by rewrite from scratch. I could name quite a few cases:

From-scratch is a huge risk.  But yeah, sometimes it has to be.

> It's sort of frightening that someone will need to
> rewrite Xlib or, say, OpenOffice :(

Never gonna happen.

Re: code bloat [was Re: Semaphore assembly-code bug]

[Michael Clark]

On 10/31/04 07:28, Tim Hockin wrote:
> On Sun, Oct 31, 2004 at 02:13:37AM +0300, Denis Vlasenko wrote:
> 
>>>Bloat is cause by feature creep at every layer, not just the app.
>>
>>I actually tried to convince maintainers of one package
>>that their code is needlessly complex. I did send patches
>>to remedy that a bit while fixing real bugs. Rejected.
>>Bugs were planned to be fixed by adding more code.
>>I've lost all hope on that case.
> 
> 
> See, there is an ego problem, too.  If you rewrite my code, it means
> you're better than I am.  Rejected.
> 
> Features win over efficiency.  Seriously, look at glibc.  Hav eyou ever
> tried to fix a bug in it?  Holy CRAP is that horrible code.  Each chunk of
> code itself is OK (though it abuses macrso so thoroughly I hesitate to
> call it C code).  But it tried to support every architecture x every OS.
> You know what?  I don't CARE if the glibc code compiles on HPUX or not.
> HPUX has it's own libc.
> 
> 
>>I guess this is a reason why bloat problem tend to be solved
>>by rewrite from scratch. I could name quite a few cases:
> 
> 
> From-scratch is a huge risk.  But yeah, sometimes it has to be.
> 
> 
>>It's sort of frightening that someone will need to
>>rewrite Xlib or, say, OpenOffice :(

Well, the xlib rewrite is happening (XCB/XCL).
One of the reasons cited is the size of xlib.

   http://www.freedesktop.org/Software/xcb

~mc

Re: code bloat [was Re: Semaphore assembly-code bug]

[Jan Engelhardt]

>> Hmm probably some bloat-detection tools would be helpful,
>> like "show me source_lines/object_size ratios of fonctions in
>> this ELF object file". Those with low ratio are suspects of
>> excessive inlining etc.

Hm, I've got a (very simple) line determining utility,
http://linux01.org:2222/f/UHXT/bin/sourcefuncsize
maybe someone can pipe it together with ls -l or whatever.

>The problem with apps of this sort is the multiple layers of abstraction.
>
>Xlib, GLib, GTK, GNOME, Pango, XML, etc.

At least they know one thing: that thou should not stuff everything into one
.so but multiple ones (if it's a lot). That /may/ reduce the size-in-memory,
because not all .so's need to be loaded. OTOH, most apps load /all/ anyway.
Heh, there we go.

>Bloat is cause by feature creep at every layer, not just the app.

I sense Java and C# being the best example.


Z Smith wrote:
>Or join me in my effort to limit bloat. Why use an X server
>that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
>of code with very minimal kmallocing?

FBUI does not have 3d acceleration?

Ken Moffat wrote:
>>The point is that -Os is *much* less tested
>>than -O2 at the moment.

>Because people suck, and don't use it and hence test it.

I doubt even the -O2-only-people use gprof/gcov frequently. :(



Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: code bloat [was Re: Semaphore assembly-code bug]

[Z Smith]

Jan Engelhardt wrote:

> FBUI does not have 3d acceleration?

The problem is 3d non-acceleration i.e. VESA and VGA
would still have to be supported. I'm no 3d expert but
I think there must be some software-based 3d function
would require using floating point, which isn't allowed
in the kernel.

Also, might not software 3d open the kernel up to
patent issues?

Zachary Smith

Re: code bloat [was Re: Semaphore assembly-code bug]

[Jan Engelhardt]

>> FBUI does not have 3d acceleration?
>
>The problem is 3d non-acceleration i.e. VESA and VGA
>would still have to be supported. I'm no 3d expert but
>I think there must be some software-based 3d function
>would require using floating point, which isn't allowed
>in the kernel.
>
>Also, might not software 3d open the kernel up to
>patent issues?

Whatever you do, 3D at the software level is slow, even with a fast comp.
See MESA.



Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: code bloat [was Re: Semaphore assembly-code bug]

[Z Smith]

Jan Engelhardt wrote:

>>Also, might not software 3d open the kernel up to
>>patent issues?
> 
> Whatever you do, 3D at the software level is slow, even with a fast comp.
> See MESA.

Well it might be nice to add support for hardware 3-D, once 2-D
is mature. In fact I imagine it could be very convenient for
some people.

ZS

Re: code bloat [was Re: Semaphore assembly-code bug]

[Alan Cox]

On Sul, 2004-10-31 at 21:13, Jan Engelhardt wrote:
> Whatever you do, 3D at the software level is slow, even with a fast comp.
> See MESA.

If you are willing to lose a few bits of OpenGL you can do 3D pretty
fast in software for gaming. Take a look at stuff like TinyGL

Re: code bloat [was Re: Semaphore assembly-code bug]

[Jan Engelhardt]

>> Whatever you do, 3D at the software level is slow, even with a fast comp.
>> See MESA.
>
>If you are willing to lose a few bits of OpenGL you can do 3D pretty
>fast in software for gaming. Take a look at stuff like TinyGL

Ok, you're right. But to be honest, it does not need to be GL. Just look at
UnrealTournament (runs fine on a PII W98 w/233MHz, in software mode!)



Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: code bloat [was Re: Semaphore assembly-code bug]

[Lee Revell]

On Sun, 2004-10-31 at 07:49 +0100, Jan Engelhardt wrote:
> Z Smith wrote:
> >Or join me in my effort to limit bloat. Why use an X server
> >that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
> >of code with very minimal kmallocing?
> 
> FBUI does not have 3d acceleration?

Um I don't think chucking X is the answer.  The problem is that it's
embarassingly slow compared to any modern GUI.  If the display were as
snappy as WinXP I don't care if it's 200MB.  On my desktop I constantly
see windows redrawing every freaking widget in situations where XP would
just blit from an offscreen buffer or something.

Anyway please keep replies off LKML and on the Xorg list...

Lee

Re: code bloat [was Re: Semaphore assembly-code bug]

[Kristian Høgsberg]

Lee Revell wrote:
> On Sun, 2004-10-31 at 07:49 +0100, Jan Engelhardt wrote:
> 
>>Z Smith wrote:
>>
>>>Or join me in my effort to limit bloat. Why use an X server
>>>that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes
>>>of code with very minimal kmallocing?
>>
>>FBUI does not have 3d acceleration?
> 
> 
> Um I don't think chucking X is the answer.  The problem is that it's
> embarassingly slow compared to any modern GUI.  If the display were as
> snappy as WinXP I don't care if it's 200MB.  On my desktop I constantly
> see windows redrawing every freaking widget in situations where XP would
> just blit from an offscreen buffer or something.
> 
> Anyway please keep replies off LKML and on the Xorg list...

Actually, please keep replies off the Xorg list as well.

Thanks,
Kristian

Re: code bloat [was Re: Semaphore assembly-code bug]

[Jan Engelhardt]

>> If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more...
>>
>>   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
>> 15364 root      15   0 38008  26M 28496 S     0,0 10,8   0:57   0 kmail
>> 20022 root      16   0 40760  24M 23920 S     0,1 10,0   0:04   0 mozilla-bin
>>  1627 root      14  -1 71064  19M 53192 S <   0,1  7,9   3:16   0 X
>>  1700 root      15   0 25348  16M 23508 S     0,1  6,5   0:46   0 kdeinit
>>  3578 root      15   0 24032  14M 21524 S     0,5  5,8   0:23   0 konsole

Heh, and guess what: the people in #kde (irc.freenode.net for example) deny
that it's their fault with the statement "bah, that's shared libraries"!
If that's a lie or not, or a semi-lie, I'm definitely sure THAT libdcop libmcop
and every shitcrap that's running makes it almost impossible to run even on
Duron-800 w/256.

>Wow. evolution is now more bloated than kmail.
>
> 1424 rlrevell  15   0  125m  47m  29m S  7.8 10.1   1:41.78 evolution
> 1508 rlrevell  15   0 92432  30m  29m S  0.0  6.4   0:14.15 mozilla-bin
> 1090 root      16   0 55676  18m  40m S 24.8  3.9   0:46.98 XFree86
> 1379 rlrevell  15   0 33776  16m  18m S  0.3  3.5   0:06.65 nautilus
> 1377 rlrevell  15   0 19392  11m  15m S  0.0  2.5   0:03.29 gnome-panel
> 1458 rlrevell  16   0 28188  11m  15m S  3.9  2.5   0:10.44 gnome-terminal
> 1307 rlrevell  15   0 20828  11m  17m S  0.0  2.4   0:03.08 gnome-settings-

Gnome is no better. (Flamewar: I like ICEWM)

The only thing more bloated is the X server itself when it runs with the
proprietary NV GL core:

USER   PID MEM%    VSZ   RSZ STAT START   TIME COMMAND
root  5220  7.8 417872 20220 SL   08:37   0:03 X -noliste[...]


Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

Re: Semaphore assembly-code bug

[Andi Kleen]

> I personally am a _huge_ believer in small code. 
> 
> The sequence
> 
> 	popl %eax
> 	popl %ecx
> 	popl %edx
> 	popl %eax
> 
> is four bytes. In contrast, the three moves and an add is 15 bytes. That's 
> almost 4 times as big.

Using the long stack setup code was found to be a significant
win when enough registers were saved (several percent in real benchmarks) 
on K8 gcc. It speed up all function calls considerably because it 
eliminates several stalls for each function entry/exit.  The popls
will all depend on each other because of their implicied reference
to esp.  

Yes, it bloats the code, but function calls happen so often that having them
faster is really noticeable. 

The K8 has quite big caches and is not decoding limited, so it 
wasn't a too bad tradeoff there.

Ideally you would want to only do it on hot functions and optimize
rarely called functions for code size, but that would require profile 
feedback which is often not feasible (JITs have an advantage here) 

Unfortunately I don't think it is practically feasible for the kernel because
we rely on to be able to recreate the same vmlinuxs for debugging.
[It's a pity actually because modern compilers do a lot better
with profile feedback] 

On P4 on the other hand it doesn't help at all and only makes
the code bigger. I did it from hand in the x86-64 syscall
code too (that was before there was EM64T, but I still think it was a 
good idea). Perhaps AMD adds special hardware in some future CPU that
also makes it unnecessary, but currently it's like this and it helps.

-Andi

Re: Semaphore assembly-code bug

[Linus Torvalds]

On Sun, 31 Oct 2004, Andi Kleen wrote:
> 
> Using the long stack setup code was found to be a significant
> win when enough registers were saved (several percent in real benchmarks) 
> on K8 gcc. 

For _what_?

Real applications, or SpecInt?

The fact is, SpecInt is not very interesting, because it has almost _zero_
icache footprint, and it has generally big repeat-rates, and to make
matters worse, you are allowed (and everybody does) warm up the caches by
running before you actually do the benchmark run.

_None_ of these are realistic for real life workloads. 

>  It speed up all function calls considerably because it 
> eliminates several stalls for each function entry/exit. 

.. it shaves off a few cycles in the cached case, yes.

> The popls will all depend on each other because of their implicied
> reference to esp.

Which is only true on moderately stupid CPU's. Two pop's don't _really_ 
depend on each other in any real sense, and there are CPU's that will 
happily dual-issue them, or at least not stall in between (ie the pop's 
will happily keep the memory unit 100% busy).

		Linus

Re: Semaphore assembly-code bug

[Andi Kleen]

On Sat, Oct 30, 2004 at 06:43:21PM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 31 Oct 2004, Andi Kleen wrote:
> > 
> > Using the long stack setup code was found to be a significant
> > win when enough registers were saved (several percent in real benchmarks) 
> > on K8 gcc. 
> 
> For _what_?
> 
> Real applications, or SpecInt?

iirc gcc itself was faster (the modern one,  not the old version in SpecInt) 

KDE startup ended up being faster too, but that may have been due to other
improvements too.

This was all tested on CPUs with very large caches (1MB L2), you
can pack a lot of code into that.

Also when people benchmark -m64 code compared to -m32 they often
see large improvements on AMD64 (as long as the code isn't long or pointer
memory bound), and I suspect at least part of that can be explained
by the -m64 gcc defaulting to the long function prologues.

Another example of larger code usually being better is x87 vs SSE2 floating
point math. 

> The fact is, SpecInt is not very interesting, because it has almost _zero_
> icache footprint, and it has generally big repeat-rates, and to make

I don't think it's generally true. one counter example is the gcc subtest
in SpecInt. 


> >  It speed up all function calls considerably because it 
> > eliminates several stalls for each function entry/exit. 
> 
> .. it shaves off a few cycles in the cached case, yes.

I would expect it to help in the uncached case too because
the CPU does very aggressive prefetching of code. Once 
it gets started on a function it will fetch it very quickly.

> 
> > The popls will all depend on each other because of their implicied
> > reference to esp.
> 
> Which is only true on moderately stupid CPU's. Two pop's don't _really_ 

I don't see the K8 as a stupid CPU.

> depend on each other in any real sense, and there are CPU's that will 
> happily dual-issue them, or at least not stall in between (ie the pop's 
> will happily keep the memory unit 100% busy).

Yes, there are. And there are others that don't.

-Andi