[MPlayer-dev-eng] icc benchmark

[Trent Piepho]

On Tue, 12 Jun 2007, Michael Niedermayer wrote:
> On Tue, Jun 12, 2007 at 03:56:53AM -0700, Trent Piepho wrote:
> > On Tue, 12 Jun 2007, Uoti Urpala wrote:
> > >
> > > > Except for namespace polution: Is there another disadvantage with global
> > > > variables?
> >
> > When building ELF shared libraries, non-static global variables require an
> > extra indirection to access (unless their visibility is changed from the
> > default).  They also make the dynamic symbol table larger and so slow down
> > dynamic linking.
>
> you compile mplayer as shared lib?

No, I can think of several good reasons for using shared libraries, but none
of them apply to mplayer or lavc.  It's just a general disadvantage with
making globals non-static when unnecessary.  Obviously, it only applies to
shared libraries.

> furthermore the access over MANGLE() will not generate
> an extra indirection and the variables we speak about are only accessed over
> that otherwise they wouldnt need attribute used

MANGLE does generate a text relocation when used in a shared object, which has
certain performance considerations.  Though is some situations (few
relocations in code that runs many times) it's entirely possible that text
relocations could be faster than the extra indirection.  But, for whatever
reason, text relocations aren't supported on x86-64.  Of course if you make
the global static, you avoid both text relocations and the extra indirection.

> > There are also optimizations that gcc can do to static globals that it can't
> > do it non-static globals.
>
> gcc limitation, but the non static global case was specifically for icc which
> i suspect does not have such limitations

icc can optimize across multiple files:
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/clin/277618.htm#ipo

But you need to do a special build for it.  And I don't think that will work
in a library (since icc doesn't know what the library's users will do).

> > > That's a very big "except". Another reason to move from MANGLE to asm
> > > arguments is that almost all current uses of MANGLE are in fact unsafe.
> > > Each asm block must either read and write only the arguments given OR
> > > have "memory" in the globber list. Most of the asm blocks that currently
> >
> > Even having "memory" in the clobber list isn't enough.  For example:
> >
> > int x;
> > main() {
> > 	int y;
> > 	x = 1;
> > 	// asm("mov x, %0" : "=r"(y)); 			// version A
> > 	// asm("mov x, %0" : "=r"(y) : : "memory");	// version B
> > 	// asm("mov %1, %0" : "=r"(y) : "m"(x));	// version C
> > 	x = 2;
> > 	printf("%d\n", y);
> > }
> >
> > The asm statement is supposed to move the global "x" to the local y, and x is
> > supposed to be 1 when this happens.  This code should print 1, but what does
> > it do?
> > Version A, prints 2
> > Version B, prints 0
> > Version C, prints 1
>
> its asm volatile not asm your code is buggy and it is clearly documented that
> non volatile asm can be moved around

Non-volatile asm can only be moved as their constraints allow.  The version
with x as an input works correctly without volatile.  By adding volatile, you
reduce the amount of optimization gcc can do.  Same with the memory clobber.