Log in

View Full Version : x264 compilation 64 bit core 2


lariva
6th October 2007, 23:45
hopefully someone can help me with this:

Ideally, i'm hoping to compile x264 with 64 bit / core 2 optimizations to run on windows platform.

There is some 64 bit x264 code floating around such as the one done by cef; so the code itself should not be the issue. Before I embark of this I figured I'll check here first:

1) if msys is used to do the compilation on windows platform - then where do you get the 64 bit version? seems like the only msys floating around is 32 bit
2) has anyone tried compiling x264 with GCC 4.2 with heavy optimizations (win 32/64 | linux 2.6) (the primary component I'm looking for isr -march=core2)

the reason why i'm trying for this is performance. 32 bit vs 64 bit gives me about 15% in favor of 64 bit; CPU specific optimizations are likely to produce another ~5% or so (hopefully)

Any suggestions / thoughts?

Thanks...


P.S. has anyone ran the tests between vmware installed OS vs native execution? with VT VMWare should carry virtually no overhead thus it makes me wonder if it makes sense to fireup 64 bit linux in a vmware session and quit screwing around with win64...

squid_80
7th October 2007, 04:41
Compilation for win64 requires VS2005 (or Intel's compiler) and yasm.

Sharktooth
8th October 2007, 13:35
heavy optimizations are useless since x264 is already optimized with hand-made assembly. trying to squeeze what you cant will only end in overoptimization and less performance.

20-40
4th November 2007, 19:04
Compilation for win64 requires VS2005 (or Intel's compiler) and yasm.

He... nope.
http://www.esnips.com/doc/ef6e129a-ae14-41a0-9753-de04cd9159f1/x264-[r682]-64-bit-athlon64-mingw

squid_80
4th November 2007, 19:27
Someone distributing avisynth.dll with no idea where it came from or source code... pthread dynamically linked... I say stick to Cef's builds.

20-40
4th November 2007, 20:00
There is nothing wrong with dynamically linked pthreadGC.dll. In Windows is pretty usual to link to dll IF that dll is in the same folder as dependent executable.

squid_80
5th November 2007, 05:49
Is it compiled with assembly enabled? It says cpu capabilities: none! and runs at about 20% of the speed of a regular build.

20-40
5th November 2007, 18:55
Is it compiled with assembly enabled? It says cpu capabilities: none! and runs at about 20% of the speed of a regular build.

Sure, with two days old yasm. Look squid, guy had said that one can compile it with M$VS.
I just have said that MinGW 64 can too...
Link was just a proof, not invitation, not a distribution or any of those things. Reaction was... strange.
I have never said anything about, and now I'll agree - as you have noticed - how much is everything slower. I agree on that one, cause anyone impartial must have noticed that on many other applications which runs faster in Wow then as native.

BTW, I get SSE3 (C was compiled with SSE5) reported, but I honestly do not know if you've used some true 64 CPU.

squid_80
6th November 2007, 03:55
Sure, with two days old yasm. Look squid, guy had said that one can compile it with M$VS.
I just have said that MinGW 64 can too...
Link was just a proof, not invitation, not a distribution or any of those things. Reaction was... strange.
It was just a proof? Then why was avisynth.dll included? Lariva said he wanted to compile with msys with core2 optimizations. That would imply he wants it to run fast - your build is extremely slow.
I have never said anything about, and now I'll agree - as you have noticed - how much is everything slower. I agree on that one, cause anyone impartial must have noticed that on many other applications which runs faster in Wow then as native.
I don't understand what you're talking about here - your build is slow because it's not using assembly optimizations. Nothing to do with windows.

BTW, I get SSE3 (C was compiled with SSE5) reported, but I honestly do not know if you've used some true 64 CPU.

IMHO, every dime spent on 64-bit Windows is throw'n away...
If I wasn't using a 64-bit cpu I couldn't run win x64 and test your build, could I? And if you think the whole OS is a waste of time then why contribute to the thread?

20-40
6th November 2007, 16:46
It was just a proof?
Yep... proof that you CAN build it without M$VS for Windows. Not for some other OS. Clear?
Compilation for win64 requires VS2005 (or Intel's compiler) and yasm.
Maybe you look for the job there?
Then why was avisynth.dll included?
Windows64 CAN run both 32-bit AND 64-bit applications. One friend asked me if I have one 64.bit avisynth. I have one. He doesn't. Clear that too?
Lariva said he wanted to compile with msys with core2 optimizations. That would imply he wants it to run fast - your build is extremely slow.
There is NO 64-bits on 4.2. There is NO -mcore2 on 4.2... Lariva said that he will try 4.2.
That is cleared now, I hope. But - you haven't seen that...
I don't understand what you're talking about here - your build is slow because it's not using assembly optimizations. Nothing to do with windows.
I talk about Wow, but you obviously have no idea what is that.
If I wasn't using a 64-bit cpu I couldn't run win x64 and test your build, could I?
That's why I have said true 64 bit. BTW, have you? Test my build, I mean. How? On what? Who asked you to try it? Why you have downloaded it at all? You are not the one who started this thread. Could you point to me where I invited you to click on link? I have tested it, and - as I have stated - I was dissapointed. In fact, you tend to compare apples and oranges, because the build you've talked about run on my system with 1.67 frames per second, and my own try runs with silly and embarrassing 6.72 fps. I call that improvement. You not. It's okay with me.
32-bit build runs at 27.39 fps.
And if you think the whole OS is a waste of time then why contribute to the thread?
I have no clue why you ask me this one. I have contributed here.
Squid... listen... sometimes you can save people from troubles by saying: "I've tried it, do not go there..." and it could mean something good. You have OVERLOOKED the facts you've mentioned yourself: msys... mingw... 4.2. Lariva talked about that.

Manao
6th November 2007, 17:30
20-40: what the hell are you talking about. You compile x264 for 64bits with msys, but without asm optimizations and you manage to conclude that Win64 is useless because your build is slower than a Win32 build with asm ? How can that make sense ?

squid manages to build for win64 with asm optimizations on, and x264 Win64 is then faster than Win32.

sh0dan
6th November 2007, 20:28
@20-40: I would strongly suggest you take a crash course in netiquette, and keep a better tone, or your stay will be quite short here.

20-40
6th November 2007, 20:29
20-40: what the hell are you talking about. You compile x264 for 64bits with msys, but without asm optimizations and you manage to conclude that Win64 is useless because your build is slower than a Win32 build with asm ? How can that make sense ?

squid manages to build for win64 with asm optimizations on, and x264 Win64 is then faster than Win32.
Exactly! It was about Mingw64, right?
BTW, yasm is assembler.
http://free-kr.t-com.hr/zeman/x264-64.jpg
1. I have said that assembler was used.
2. I have said it's a slow and bad CLI.
3. I have compiled it with GCC for mingw64.

Post which was first (by Lariva) spoke about msys (read mingw, msys is just environment) and gcc.
I have, no matter what some of you have been saying, only one who have stayed on topic.
What is wrong with you both? Mad on what?
BTW, I never had commented anyone else's x264.

READ, please, Lariva's first post here...

Bye, obviously I have stirred some minds and stale waters, and this forum slided in same direction as many, many others.
Look, I'm gone in two seconds. Forever.

foxyshadis
6th November 2007, 20:31
If you can't build with asm, you might as well be unable to build at all; it's only really useful as a reference/debug encoder in that case, not for day-to-day use. Obviously yours isn't using yasm, even if you have it available.

There's an existing 64-bit version you can try here (http://okejl.dk/dunstan/) (don't know where newer versions might be) if you want to see the difference between yours and one compiled with assembly optimization.

celtic_druid
14th November 2007, 08:10
Looks like there is a problem with cpu.c and x86_64-pc-mingw32. Notice no -DHAVE_MMX above? With it x264 fails to work. Without it, no asm.

squid_80
14th November 2007, 08:19
All the yasm commandlines should have -DWIN64, otherwise the assembly code is being built for linux's ABI.

celtic_druid
14th November 2007, 08:46
Yeah, I did that. Still had the problem with cpu.c. x264 would run, but do nothing, no message about running --help.

20-40
17th November 2007, 09:54
In common/cpu.c:

- #if defined(HAVE_PTHREAD) && defined(SYS_LINUX)
#define _GNU_SOURCE
#include <sched.h>
- #endif

and changing also in cpu.c

! #elif defined(WIN32)
-----------------------
! #elif defined(_WIN32) || defined (_WIN64)
/* To properly return pthread_num_processors_np(); for Win64 */

and then doing "configure" with

--extra-cflags='-DHAVE_PTHREADS -DAVIS_INPUT -D__X264__ -D_HAVE_MMX -DHAVE_SSE3 -DARCH_X86_64 -D_WIN64 -DSYS_MINGW -g0 -march=athlon64 -mtune=athlon64 -s' and --extra-asflags='-O2 -w -m amd64 -f win64 -D_WIN64 -D_HAVE_MMX -DHAVE_SSE3'

activated asm extensions in CLI.

Thank you all for providing hints…

celtic_druid
17th November 2007, 10:06
You might want to add mp4 output support. GPAC (at least the lib) compiled ok here.