delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/07/06/08:17:04

Sender: root AT delorie DOT com
Message-ID: <3781F6D6.B023ED4D@inti.gov.ar>
Date: Tue, 06 Jul 1999 09:30:14 -0300
From: salvador <salvador AT inti DOT gov DOT ar>
Organization: INTI
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: es-AR, en, es
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: .align directives in libc.a
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990701074005 DOT 22046A-100000 AT is> <377BB217 DOT 2FFBAEA8 AT inti DOT gov DOT ar> <377C5986 DOT 1B33420B AT taniwha DOT org> <377CB4A1 DOT BB72A3EA AT inti DOT gov DOT ar> <377EA4A6 DOT EB687A6D AT taniwha DOT org>
Reply-To: djgpp-workers AT delorie DOT com

Bill Currie wrote:

> salvador wrote:
> > Yes, most processors uses 32, but that's also a waste if you routine is around 32
> > bytes  and you pad it with 60 bytes ;-) (30+30).
> > 32 bytes is too much and you start losing from other things. I don't know how MSVC
> > determines when 32 bytes is good idea or not, perhaps is related to the size of the
> > functions. BTW MSVC also exploits "proximity" by moving functions closer to the
> > caller (mostly small static ones, that's usually better than inlining if the function
> > have more than a couple of lines).
>
> I beleive the goal is to land on the beginning of a cache line if you
> have to have a cache miss.  However, for small functions, I agree that
> if you can pack a more than one function into a cache line you will win
> more often.  You will also have a smaller

Yes, perhaps MSVC also exploits the fact that the compiler moves functions to make it.

> > > > But looks like the most sensitive stuff is the entry point of functions, not the
> > > > align of loops or jumps.
> > >
> > > Nope, any destination: functions, loops and jumps are all equally
> > > important.
> >
> > Not for K6 and not for Pentium MMX, I tried it. In fact MSVC do *not* align jumps or
> > loops. In K6 processors it could be even worst (if a loop is in a xxxxxC memory
> > address works slowly), in Pentium MMX de difference is very small.
>
> Hmm, interesting.  I'll believe it, as you've obviously actually
> measured it.  Hmmm, this implies an improvement in handling jump
> instruction.
>
> > I think aligning jumps and loops is only good idea for big functions, small functions
> > could need more cache lines if you add bytes inside.
>
> Agreed, mostly.  I would say from your ealier comments about loop
> alignments that even big functions could benefit from unaligned loops on
> newer processors.  I think you would have to check this out (I can't
> yet, I've only got a 486 and a 386, but not for too much longer:)

I think entry points of big loops should be well aligned, after all they are in a similar
case than functions.

> > Currently I think MSVC have better ideas than gcc because generates faster code.
>
> GCC is, unfortunatly, held back by its portability and multiple
> targets.

Right now I'm compiling the experimental new IA32 branch of gcc (a branch in the gcc 2.96
CVS tree). People in the egcs mailing list says it should beat MSVC 6.0.

>  MS gets to concentrate on just x86, and probably just the
> newer ones, and thus can do more clever tricks than gcc can ATM.

NT is available for many platforms and I think they use your own compiler ;-), of course
that's just a fraction of the huge number of CPUs supported by gcc, but I think the
difference is how they solve the problem. They have enough man-hours (how is that in
english?) to specialize each code generator. I mean: they have a team for x86, another for
MIPS, another for PPC and another for Alpha; all share the parser, etc. but the assembler
generator is not shared between teams.

> > Take a look to my compila.html page.
>
> Is this the one you posted recently?  I had a look at that one and
> noticed MSVC was a little faster, but (from memory) not always.

Yes, but I'm talking about the assembler analisis.

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019