[Ffmpeg-devel] [PATCH] dead code elimination

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 27 February 2007 at 01:20, Roman Shaposhnick wrote:
> On Tue, 2007-02-27 at 00:54 +0100, Aurelien Jacobs wrote:
> > On Mon, 26 Feb 2007 20:40:28 +0100
> > Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org> wrote:
> > 
> > > On Monday, 26 February 2007 at 01:46, M?ns Rullg?rd wrote:
> > > [...]
> > > > Not OK.  This should be set for all 64-bit CPUs we currently have
> > > > special settings for.  These include Alpha, PPC64, and Sparc64.  We
> > > > don't seem to have any specific checks for MIPS64, a patch to rectify
> > > > this would of course be welcome.
> > > 
> > > sparc64 is unlikely to be faster than sparc32. I can benchmark it if
> > > you tell me how.
> > 
> > I don't know sparc very well, and indeed it seems that sparc32 is often
> > faster than sparc64. But here it's not about sparc32 vs. sparc64.
> > It's about sparc64 using some 32bits optimized code vs. sparc64 using
> > some 64bits optimized code (ie. the code surrounded by HAVE_FAST_64BIT).
> > 
> > To benchmark it, I used START/STOP_TIMER at begining/end of
> > idctRowCondDC(), but unfortunatly START/STOP_TIMER is not implemented
> > for sparc :-(
> > 
> > If you find a good way to benchmark it, I'm interested in the results.
> > Else I will probably commit this patch as is.
> 
>   What OS are we talking about here ? On Solaris one can use gethrtime()
> instead of rdtsc. In fact, it might be even available on Linux.

I have access to both Solaris and Linux sparc64 boxes.

Regards,
R.

-- 
MPlayer developer and RPMs maintainer: http://mplayerhq.hu http://rpm.livna.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan