Re: [MP3 ENCODER] Windows Binaries
Mathew Hendry wrote: Can you name a compiler which will do this on normal code, i.e. without the use of MMX/3DNow-specific functions and macros or [inline] assembler? I'm afraid I can't. Normally special-case code will be required to take advantage of these enhanced instruction sets. If that is the only option then maybe specialised code could be written into LAME to support MMX. I think most computers these days are running MMX processors. I'm not sure what the actual speed improvement would be and maybe it's not worth the effort. However, there are some customised versions of LAME around. Take a look atthe GOGO-no-coda, which I believe has MMX and 3DNow! enhancements, amongst other things. Yes, however, I prefer some of the later ammendments of LAME. Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Windows Binaries
The Intel compiler attempts to do this. Unfortunately, detecting vectorizable code is a very difficult problem. I tried the Intel compiler and it didn't vectorize any of the floating point loops, and only one rarely-called integer loop. I have lots of problems getting VTune to work on lame to gather adequate profiling information, but would be happy to write some assembly for FFT, etc. It may be possible to speed up the quantize_xrpow even more with 3DNow or KNI. - Original Message - From: Mathew Hendry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, 07 January, 2000 20:17 Subject: Re: [MP3 ENCODER] Windows Binaries From: "Ross Levis" [EMAIL PROTECTED] Is there any chance of compiling a Windows version that takes advantage of MMX or 3DNow? Can you name a compiler which will do this on normal code, i.e. without the use of MMX/3DNow-specific functions and macros or [inline] assembler? Normally special-case code will be required to take advantage of these enhanced instruction sets. However, there are some customised versions of LAME around. Take a look at the GOGO-no-coda, which I believe has MMX and 3DNow! enhancements, amongst other things. http://www.kurims.kyoto-u.ac.jp/~shigeo/gogo_e.html Note that GOGO is based on an earlier version of LAME (3.29 IIRC). -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Windows Binaries
On Sat, 8 Jan 2000, Acy Stapp wrote: I have lots of problems getting VTune to work on lame to gather adequate profiling information, but would be happy to write some assembly for FFT, etc. It may be possible to speed up the quantize_xrpow even more with 3DNow or KNI. If you'd like, us poor Linux users would be happy to generate gprof profiling (it works fine), I doubt the execution paths differ between platforms. :) If you are fammilar with the GNU toolset, I can provide you with a shell on a Linux box, otherwise I can just give general profiling info. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Windows Binaries
Hello, I'm a newbie, and I wonder how the Windows binary found in the Russian site (http://www.chat.ru/~dkutsanov/index.htm) was compiled. I supposed it's done with Microsoft Visual C, but I want to know if it is optimized for i586, i686 or anything else. I don't own MSVC myself, so I can't understand the parameters in the Makefile. I'm personnally using the CygWin package (Freeware, http://sourceware.cygnus.com/cygwin/) to compile the Lame sources, but even with the i686 tweaks (I have a good old PentiumPro), it's slower than the Russian binary (Well, it's 3-4% slower, not too bad...) and a lot, lot bigger (But with today's drives, who cares...) Thanks for the replies, Pierre Darbon P.S : Sorry for this bad English, I'm French... :) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Windows Binaries
Hello Pierre, Friday, January 07, 2000, 6:51:27 PM, you wrote: PDeHJS I'm a newbie, and I wonder how the Windows binary found in the Russian PDeHJS site (http://www.chat.ru/~dkutsanov/index.htm) was compiled. I supposed PDeHJS it's done with Microsoft Visual C, but I want to know if it is optimized PDeHJS for i586, i686 or anything else. I don't own MSVC myself, so I can't PDeHJS understand the parameters in the Makefile. :D . it was done with msvc++ 5.0 with optimization for pentium pro (i have celeron 366 overclocked to 550) Best regards, Dmitrymail to: [EMAIL PROTECTED] ps: please note url is http://www.chat.ru/~dkutsanov/~index.htm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Windows Binaries
From: Pierre Darbon et Hurgon J.Sebastien [mailto:[EMAIL PROTECTED]] I'm a newbie, and I wonder how the Windows binary found in the Russian site (http://www.chat.ru/~dkutsanov/index.htm) was compiled. I supposed it's done with Microsoft Visual C I think so. , but I want to know if it is optimized for i586, i686 or anything else. I don't own MSVC myself, so I can't understand the parameters in the Makefile. If it's been built using the MSVC Makefile, it will be optimised for P6 (Pentium Pro or Pentium II). I think the workspace/project files (for building within the MSVC IDE) use the same setting (/G6). I'm personnally using the CygWin package (Freeware, http://sourceware.cygnus.com/cygwin/) to compile the Lame sources, but even with the i686 tweaks (I have a good old PentiumPro), it's slower than the Russian binary (Well, it's 3-4% slower, not too bad...) There are some optimisations in the MSVC version not present in the gcc/iX86 version - namely the full assembly implementation of quantize_xrpow[_ISO] in quantize-pvt.c. On top of that, MSVC is very good with floating point code, better than gcc and (I think) better even than Intel's reference compiler. pgcc (a custom version of gcc for Pentium CPUs) might fare better if you can find/build it for Windows. pgcc is the default compiler on my "experimental" Linux system (Mandrake 6.something) and does seem to improve speed a little over regular gcc. and a lot, lot bigger (But with today's drives, who cares...) You probably only need to strip the debug info out of the executable. Try "strip lame.exe" after compiling. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
