Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Are there any x64 builds of LAME? (Read 31557 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Are there any x64 builds of LAME?

Just wondering if there are any x64 builds of LAME around. Mostly of the recommended beta, or maybe previous recommended version of LAME.

Thanks in advanced.

Are there any x64 builds of LAME?

Reply #1
Win64 support has been added last week in the VC8 projects under CVS, but this is only for 3.98alpha versions.

Are there any x64 builds of LAME?

Reply #2
actually someone has built a 64-bit version (I don't know if it works as I'm using still regular win xp).
http://okejl.dk/dunstan/ has 64-bit builds on various audio and video tools.

Are there any x64 builds of LAME?

Reply #3
Are there any advantages of using 64bits over 32bits? Just wondering...
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

Are there any x64 builds of LAME?

Reply #4
Are there any advantages of using 64bits over 32bits? Just wondering...
Not that I can see - on Linux (with both GCC 3.3 and 4.1) the 32 bit version without MMX is about 10% faster than the 64 bit version without MMX. I would put this performance difference down to a higher number of cache misses with the 64bit version (some loops stop fitting in cache because the code is bigger).

The picture might be different on Windows, but I don't expect it to change much. I would stick to the 32bit version for the time being.

Are there any x64 builds of LAME?

Reply #5
When comparing those two VC8 builds:

*32bits, Nasm and intrinsics optims
*64bits, intrinsics optims

then the 64bits one is about 10% faster (AMD processor).

Are there any x64 builds of LAME?

Reply #6
do both compiles use the same SSE extensions?

Are there any x64 builds of LAME?

Reply #7
No, the x86 build is using Nasm optims (mmx and 3dnow) AND intrinsics (sse), while the x64 build is only using  intrinsics (sse).

So in this case, the x64 version is using fewer "hand-made" optims but is still faster.
Of course, it is not magical. It is because of optims made by the compiler (additionnal registers, and perhaps "heavy" SSE/SSE2 use)

 

Are there any x64 builds of LAME?

Reply #8
So in this case, the x64 version is using fewer "hand-made" optims but is still faster.
Of course, it is not magical. It is because of optims made by the compiler (additionnal registers, and perhaps "heavy" SSE/SSE2 use)

If MVC8 compiles for x64 architecture, does this imply SSE2? If this is the case, you could compare it with x32 compiled with SSE2 enabled.

Are there any x64 builds of LAME?

Reply #9
is there a 32bit build with say SSE2?
Chaintech AV-710

Are there any x64 builds of LAME?

Reply #10
I think that x64 implies availability of SSE/SSE2.
It is likely that VC8 used some SSE/SSE2 code, but this is only a supposition, as both compiles are using default settings of VC8.

Of course, more tests are needed to reach a real conclusion.

Are there any x64 builds of LAME?

Reply #11
32 bit builds will not use SSE/SSE2 unless specifically indicated in the settings

64 bit builds *need* to use SSE/SSE2 since it is the only supported mode of floating point operation

Are there any x64 builds of LAME?

Reply #12
Quote
32 bit builds will not use SSE/SSE2 unless specifically indicated in the settings

Sure

Quote
64 bit builds *need* to use SSE/SSE2 since it is the only supported mode of floating point operation

This is a programmer's urban legend. The fpu is still there, and still usable in x64.
Is VC8 using SSE/SSE2 by default under x64? Very likely. But it might also be using a mix of SSE and x87.

Are there any x64 builds of LAME?

Reply #13
I uploaded VC8 32 and 64 builds there:
http://gabriel.mp3-tech.org/lame/x64/

Strange thing is that enabling sse2 decreases speed of the x86 compilation.

Are there any x64 builds of LAME?

Reply #14
damn, but thanks, not that speed is that big of a deal
Chaintech AV-710

Are there any x64 builds of LAME?

Reply #15
This is a programmer's urban legend. The fpu is still there, and still usable in x64.
Is VC8 using SSE/SSE2 by default under x64? Very likely. But it might also be using a mix of SSE and x87.


The MS documentation explicitly states that the only FP instructions available in long mode are SSE[1|2|3]. If the compiler is generating x87 in long mode then that is a bug.

The MS compiler hhas been using 64bit IEEE floating point by default for years rather than 80bit however it doesn't generate SSE for 32 bit code unless told to explicitly since code targeted for "blend" must still run on PII class processors which don't have SSE.

The FPU may be there, and you may even be able to execute x87 instructions in long mode on K8 and P4 or Conroe processors. However this is not the same as being specified as part of the instruction set. The x87 opcode space along with MMX and 3dNow is UNDEFINED when in long mode. Futures AMD64 processors may redefine this opcode space for new instructions.

Using x87,MMX or 3dNow in long mode is therefore hideously bad as your binaries may not work correctly under future processors which implement AMD64.

Having said that MS did change the NT kernel to save and restore the x87 registers across context switches before they released the AMD64 version of NT. Presumably they have user space code which breaks the specification and uses x87 in long mode so they had to bodge things. NT does not preserve them for kernel only context switches so using x87 in a device driver under NT for AMD64 would be a quick road to a blue screen of death.

Are there any x64 builds of LAME?

Reply #16
x87, mmx and even 3dnow are still there.
(see "AMD64 Architecture Programmer’s Manual Volume 5: 64-Bit Media and x87 Floating-Point Instructions")

x87 context is preserved in user space (sure), but I am unsure about kernel space. Anyway, the OS would have to blank the x87 registers when switching context if it did not preserved it, so it doesn't cost much more to save and restore it properly. (not saving and not blanking would lead to a security issue)

Regarding VC8, I found the answer:
Quote
The feature to see the legacy x87 registers for x64 applications is not available in VS2005.  The main reason for this is that originally the x87 registers were not available for 64bit applications at all.  We later did make them available, but only accessible through MASM.

Due to the late addition of the support for x87 and limited use cases, we weren't able to get it into the VS2005 product.

So to answer your question, you can't see them in the VS2005 debugger.  You can use the 64bit version of WinDbg though, if that helps.

Thanks for your feedback.

Kang Su Gatlin
Visual C++ Program Manager

So VC8 is not creating code that uses x87 on its own behalf.

Are there any x64 builds of LAME?

Reply #17
Interesting results on the performance. I wonder why gcc does so badly with 64 bit code?
x87, mmx and even 3dnow are still there.
(see "AMD64 Architecture Programmer’s Manual Volume 5: 64-Bit Media and x87 Floating-Point Instructions")
From Volume 1:
Quote
x87 floating-point instructions can be executed in any of the architecture’s operating modes. Existing x87 binary programs run in legacy and compatibility modes without modification.

Are there any x64 builds of LAME?

Reply #18
I wanted to post about this, but I didn't because I didn't have any benchmark numbers to back up my claims.

One of the first things I did when I got an AMD64 box was to test ~/bin/lame, /usr/bin/oggenc, etc etc.

For me, both lame and oggenc were faster as a 64bit build than a 32bit build, IIRC.

edit: And yes, I used gcc. Can't remember which version.

Are there any x64 builds of LAME?

Reply #19
I uploaded VC8 32 and 64 builds there:
http://gabriel.mp3-tech.org/lame/x64/

Strange thing is that enabling sse2 decreases speed of the x86 compilation.

Hi.

I just tested lame32 and lame64 on my Athlon64 3700+, Windows XP x64 SP1.
LAME 32bits version 3.98 (alpha 6, Jul 30 2006 11:33:12)
LAME 64bits version 3.98 (alpha 6, Aug  9 2006 22:37:22)

Track tested: David Bowie - The Man Who Sold The World (4:00)
32-bit, -V 0 --vbr-new: 22secs, 8 745 963 bytes
64-bit, -V 0 --vbr-new: 19secs, 8 746 172 bytes
32-bit, -V 6 --vbr-new: 20secs, 4 541 454 bytes
64-bit, -V 6 --vbr-new: 16secs, 4 541 243 bytes
32-bit, -b 320: 23 secs, 9 602 975 bytes
64-bit, -b 320: 20 secs, 9 602 975 bytes

64-bit is about 16% faster than 32-bit, but how come there is difference in file sizes when using VBR? I haven't ABX'ed the resulting files, so I don't know if the difference is audible.
/Agitator

Are there any x64 builds of LAME?

Reply #20
64-bit is about 16% faster than 32-bit, but how come there is difference in file sizes when using VBR? I haven't ABX'ed the resulting files, so I don't know if the difference is audible.
That is fairly interesting. The reason is that the different compilers seem to emit floating point/SSE calculations in different orders. You might know this already, but with floating point the order of the calculations can make a big difference. For example a*b+a*c is very seldom the same as a*(b+c).

An ABX test would be interesting. I got a null result from a test that I did with lame compiled with different versions of GCC earlier this year.

Are there any x64 builds of LAME?

Reply #21
Anyone who has time and interest in making x64 LAME v3.98.3 compiles. Both .exe and dll? I am wondering because some x64 programs I use need to have the lame.dll in its folder and if it is a x86 compile it won't work. Reaper for example. Regards

Are there any x64 builds of LAME?

Reply #22
This is in the change log of Reaper 3.35:
x64: now requires libmp3lame.dll or lame_enc64.dll (old x64 lame_enc.dll was broken)