Is it possible to switch to YASM?

stan_wkc · 21 August 2005, 03:12 pm

AFAIK, NASM does not generate 64-bit code on Linux x86-64 target.
This makes some nasm-compiled object files could not link with
the encoder. mppenc's speed falls from ~20x to ~16x
on my Athlon 64 3000+(S939) with profile "standard".

From what I have heard, YASM, a replacement of NASM, could generate 64-bit code.
Currently it uses an extension of NASM syntax to support x86-64 assembly.
IMO those SSE registers do not change much. With a little modification,
is it possible to go with YASM?

Shy · 21 August 2005, 09:10 pm

The old NASM code in mppenc is related to 3dnow! and is disabled since it doesn't affect speed. You need to manually change the source code to enable it. Have you done that? If not, your speed decrease may be due to compiling as 64-bit with "optimizations" which actually slow things down a lot.

stan_wkc · 22 August 2005, 02:19 pm

No. It's only "-O2 -pipe -march=k8 -ffast-math -funroll-loops".
Adding -fweb and disabling SSE & SSE2 instructions improves a lot.
Speed boosts from ~16x to ~18x.

But it is a bit off-topic.
The situation was I could see about 3 warnings about incompatible code mixing during compile. Are they harmless?

DEATH · 22 August 2005, 04:47 pm

Let me re-phrase what Shy said.
Mppenc's assembly code (fft4gasm.nas) contains 3DNow-optimized versions of some of functions, it's deprecated and does not appear to give significant improvement on current CPUs, at least with Microsoft compilers. Fft4gasm.nas will be most likely dropped from sourcecode package in next release.
Additionally, source code needs to be modified for functions from assembly module to be actually called. If you compile current source even with assembly module included, assembly functions are never called, unless you alter relevant line of fft4g.c.

21 August 2005, 03:12 pm	#1
stan_wkc Member Join Date: Aug 2005 Posts: 2	Is it possible to switch to YASM? AFAIK, NASM does not generate 64-bit code on Linux x86-64 target. This makes some nasm-compiled object files could not link with the encoder. mppenc's speed falls from ~20x to ~16x on my Athlon 64 3000+(S939) with profile "standard". From what I have heard, YASM, a replacement of NASM, could generate 64-bit code. Currently it uses an extension of NASM syntax to support x86-64 assembly. IMO those SSE registers do not change much. With a little modification, is it possible to go with YASM?

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Replaygain's "smart" switch	drmrbrewer	General	0	03 March 2005 09:43 am

21 August 2005, 09:10 pm	#2
Shy Admin Join Date: Jul 2004 Posts: 372	The old NASM code in mppenc is related to 3dnow! and is disabled since it doesn't affect speed. You need to manually change the source code to enable it. Have you done that? If not, your speed decrease may be due to compiling as 64-bit with "optimizations" which actually slow things down a lot.

22 August 2005, 02:19 pm	#3
stan_wkc Member Join Date: Aug 2005 Posts: 2	No. It's only "-O2 -pipe -march=k8 -ffast-math -funroll-loops". Adding -fweb and disabling SSE & SSE2 instructions improves a lot. Speed boosts from ~16x to ~18x. But it is a bit off-topic. The situation was I could see about 3 warnings about incompatible code mixing during compile. Are they harmless?

22 August 2005, 04:47 pm	#4
DEATH foobar2000 developer Join Date: Jul 2004 Posts: 4	Let me re-phrase what Shy said. Mppenc's assembly code (fft4gasm.nas) contains 3DNow-optimized versions of some of functions, it's deprecated and does not appear to give significant improvement on current CPUs, at least with Microsoft compilers. Fft4gasm.nas will be most likely dropped from sourcecode package in next release. Additionally, source code needs to be modified for functions from assembly module to be actually called. If you compile current source even with assembly module included, assembly functions are never called, unless you alter relevant line of fft4g.c.