[Ffmpeg-devel] Re: [PATCH] Machine endian bytestream functions

[Michael Niedermayer]

Hi

On Sun, Mar 11, 2007 at 12:55:18AM -0300, Ramiro Polla wrote:
[...]
> >>Index: configure
> >>===================================================================
> >>--- configure	(revis?o 8316)
> >>+++ configure	(c?pia de trabalho)
> >>@@ -602,6 +602,7 @@
> >>     dlopen
> >>     fast_64bit
> >>     fast_cmov
> >>+    fast_unaligned
> >>     freetype2
> >>     imlib2
> >>     inet_aton
> >>@@ -737,6 +738,7 @@
> >> mmx="default"
> >> cmov="no"
> >> fast_cmov="no"
> >>+fast_unaligned="no"
> >> armv5te="default"
> >> armv6="default"
> >> iwmmxt="default"
> >>@@ -951,9 +953,11 @@
> >> case "$arch" in
> >>   i386|i486|i586|i686|i86pc|BePC)
> >>     arch="x86_32"
> >>+    enable fast_unaligned
> >>   ;;
> >>   x86_64|amd64)
> >>     arch="x86_32"
> >>+    enable fast_unaligned
> >>     canon_arch="`$cc -dumpmachine | sed -e 's,\([^-]*\)-.*,\1,'`"
> >>     if [ x"$canon_arch" = x"x86_64" -o x"$canon_arch" = x"amd64" ]; then
> >>       if [ -z "`echo $CFLAGS | grep -- -m32`"  ]; then
> >>    
> >
> >maybe configure should rather have a generic test which checks which 
> >version
> >is faster? (it would be much easier to maintain instead of keeping track 
> >what
> >is faster for which cpu ...)
> >
> >
> >  
> 
> Sorry, but I failed to find a simple way for this in configure. Three 
> issues came up:
> 1. Unaligned data accesses will crash on some processors, and I don't 
> think it's a good idea to have configure throw exceptions. (e.g. it 
> would open the "Send report" dialog on Windows).

since when does windows support such hardware? and no real OS opens a
dialog box if a program crahshes furthermore you could install a handler
which catches the exception


> 2. Checking the speed for an x ammount of time would slow down configure.

yes thats a problem


> 3. Different cpu loads during the configure script would cause 
> unreliable results.

yes that too is a problem


> 
> So, for the moment, I'm sending the patch with the same check. (It's 
> just like the fast_64bit or fast_cmov check).

yes the number of these things increase and the number of cpus for which
we know which is faster decreases

what about a simple configure like script which tests them?
the time such a script would need wouldnz affect conigure as its not
run by configure but rather manually and so theres also no load problem
the user just has to stop every other application to get reliable results


[...]
> 
> cosmetics.diff reorders definitions from endianess to bit-depth.

looks ok


> functional.diff makes special cases for fast_unaligned.

looks ok


> 
> Regression tests pass. Final ffmpeg.exe is a few kbs smaller. Altough 
> not benchmarked with real-world applications, that simple test I made 
> showed from 20% to 40% speedup on the macros alone.
[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070316/f762c037/attachment.pgp>