flac dev - May 2012 - Git branch with compiling fixes for win32

El 03/05/12 12:19, Miroslav Lichvar escribi?:

> It makes the C function faster than the corresponding asm routine, so
> if it's included I'd suggest to just drop the asm function to not
keep
> around more asm code than is necessary.
With current compilers it is very likely that those routines are already 
superflous.

On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodr?guez
wrote:
> El 03/05/12 12:19, Miroslav Lichvar escribi?:
> 
> 
> > It makes the C function faster than the corresponding asm routine, so
> > if it's included I'd suggest to just drop the asm function to
not keep
> > around more asm code than is necessary.
> 
> With current compilers it is very likely that those routines are already 
> superflous.
It seems the current compilers are not that good yet :).

In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with
nasm enabled is about 7% faster in decoding than without nasm. x86_64
build is about 2% faster than the i686 build with nasm enabled.

-- 
Miroslav Lichvar

On May 7, 2012, at 06:11, Miroslav Lichvar wrote:
> On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodr?guez wrote:
>> El 03/05/12 12:19, Miroslav Lichvar escribi?:
>>> It makes the C function faster than the corresponding asm  
>>> routine, so
>>> if it's included I'd suggest to just drop the asm function
to not
>>> keep
>>> around more asm code than is necessary.
>>
>> With current compilers it is very likely that those routines are  
>> already
>> superflous.
>
> It seems the current compilers are not that good yet :).
>
> In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with
> nasm enabled is about 7% faster in decoding than without nasm. x86_64
> build is about 2% faster than the i686 build with nasm enabled.

Thank you for running these benchmarks and reporting on the results,  
Miroslav.

As a sometimes assembly coder, I believe that compilers will never be  
able to beat a human mind in all situations, even if they can in  
most.  I can't speak for the FLAC assembly developers, but when I  
write assembly, I always check the compiler's output at all  
optimization settings just to be sure I'm not wasting my time.  That  
certainly doesn't guarantee that the compiler will never improve its  
results, but keep in mind that changes to compilers sometimes produce  
less optimal results for particular cases, even if they involve  
improvements in most general cases.

But it's certainly good to double-check periodically as compilers  
"improve."

Brian Willoughby
Sound Consulting

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07.05.2012 17:11, Miroslav Lichvar wrote:
> On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodr?guez
> wrote:
>> El 03/05/12 12:19, Miroslav Lichvar escribi?:
>> 
>> 
>>> It makes the C function faster than the corresponding asm
>>> routine, so if it's included I'd suggest to just drop the
asm
>>> function to not keep around more asm code than is necessary.
>> 
>> With current compilers it is very likely that those routines are
>> already superflous.
> 
> It seems the current compilers are not that good yet :).
> 
> In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with 
> nasm enabled is about 7% faster in decoding than without nasm.
> x86_64 build is about 2% faster than the i686 build with nasm
> enabled.
> 
Was that with -O2 or -O3?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPqAQ3AAoJEOs4Jb6SI2CwsGUIAIrvJUZPPyC6snMLQxvYWCCb
OpxoxApO3+gRyAlk1702im1zBcziECit4AoNmetbLWpaYQNs6WXCEQ8HBJa7Aepq
gN85v/cG9yk0zVL5ntgbttgbDEuLI0OZo7LWtF0dKsBDRjt8U8LftZ9UvVUHmLQk
pw7v2pA6co7UXhNL/PMhHwVRsx6nAkRfHptQ2hbmLlqFlh4WJw1Pzt4rxilOHEtk
3p9PU1QgT5TQmxTuVaNjW/KGy7IgMIMS3s0y1tjLijwqFqIUsdDk5TuTKTD7QEwt
Ymn4ZT20DfyLRq8PMHiGQUc8Jksvb6enNrKe1hMK3/xof4VYDled4PdaVI+EJQg=q0Ag
-----END PGP SIGNATURE-----

El 07/05/12 09:11, Miroslav Lichvar escribi?:
> On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodr?guez wrote:
>> El 03/05/12 12:19, Miroslav Lichvar escribi?:
>>
>>
>>> It makes the C function faster than the corresponding asm routine,
so
>>> if it's included I'd suggest to just drop the asm function
to not keep
>>> around more asm code than is necessary.
>>
>> With current compilers it is very likely that those routines are
already
>> superflous.
>
> It seems the current compilers are not that good yet :).
>
> In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with
> nasm enabled is about 7% faster in decoding than without nasm. x86_64
> build is about 2% faster than the i686 build with nasm enabled.
Did you build with -fprofile-generate ... then make check .. then 
rebuild with -fprofile-use ?