Mail Archives: djgpp-workers/1999/07/06/08:17:04
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 -