x264 compiling error with Visual Studio 2008

[LoRd_MuldeR]

the profiling paths (series of settings) are:
--crf 30 -b1 -m1 -r1 --me dia --no-cabac --pre-scenecut --direct temporal --no-ssim --no-psnr
--crf 16 -b2 -m3 -r3 --me hex -8 --direct spatial --no-dct-decimate
--crf 26 -b2 -m5 -r2 --me hex -8 -w --cqm jvt --nr 100
--crf 18 -b3 -m9 -r5 --me umh -8 -t1 -A all --mixed-refs -w --b-pyramid --direct auto --no-fast-pskip
--crf 22 -b3 -m7 -r4 --me esa -8 -t2 -A all --mixed-refs
--frames 50 --crf 24 -b3 -m9 -r3 --me tesa -8 -t1 --mixed-refs
--frames 50 -q0 -m9 -r2 --me hex -Aall
--frames 50 -q0 -m2 -r1 --me hex --no-cabac

I wonder why the profiling paths don't use threads :confused:

Would multi-threading corruption the profiling results? Or would it be even better to take threading into account?

At least it would make compile time a lot shorter :D

[Shinigami-Sama]

I wonder why the profiling paths don't use threads :confused:

Would multi-threading corruption the profiling results? Or would it be even better to take threading into account?

At least it would make compile time a lot shorter :D

or have JOBS = # of cores ;)

[kemuri-_9]

I wonder why the profiling paths don't use threads :confused:

Would multi-threading corruption the profiling results? Or would it be even better to take threading into account?

At least it would make compile time a lot shorter :D

common/mc.c:421: error: corrupted profile info: number of executions for edge 19-20 thought to be 391620
common/mc.c:421: error: corrupted profile info: number of executions for edge 19-21 thought to be -1

that's what happens when you try to fprofile with threads, it doesn't work.
(you can't have -1 executions)

[LoRd_MuldeR]

common/mc.c:421: error: corrupted profile info: number of executions for edge 19-20 thought to be 391620
common/mc.c:421: error: corrupted profile info: number of executions for edge 19-21 thought to be -1

that's what happens when you try to fprofile with threads, it doesn't work.
(you can't have -1 executions)

I see. Is this a knwon bug/limitation in GCC's profiling code?


[EDIT]

In fact it seems to run through fine here. I'm using gcc.exe (4.3.2-tdm-1 for MinGW) 4.3.2.


[EDIT²]

I was wrong. The individual tests run through fine, but it crashes at the final step of the building process :o

(There are negative execution counts, as you said)


well, there's also the case in which x264 isn't compiled with pthread support. can't just assume people are going to build it in.

...and the ./configure script could disable/enable "--threads auto" in the profiling section of the Makefile, depending on whether pthread is enabled or not.

[kemuri-_9]

well, there's also the case in which x264 isn't compiled with pthread support. can't just assume people are going to build it in.

btw, this is getting pretty OT

Edit:
tried with gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 and
gcc-4.2 (GCC) 4.2.4 (Ubuntu 4.2.4-3ubuntu4)
they crashed too.

[Maccara]

Would multi-threading corruption the profiling results? Or would it be even better to take threading into account?


Btw, I did include multi-threading in the PGO when I did my tests in the past with VS2005, so the profiling was not exactly the same as GCC. Can't remember, though, if it made any difference. (I suppose it "might", as then the pthread code would be included in the profiling and maybe some overhead would be reduced - but I have no data how big overhead pthreads cause so this is a bit of a stretch)

[roozhou]

Btw, I did include multi-threading in the PGO when I did my tests in the past with VS2005, so the profiling was not exactly the same as GCC. Can't remember, though, if it made any difference. (I suppose it "might", as then the pthread code would be included in the profiling and maybe some overhead would be reduced - but I have no data how big overhead pthreads cause so this is a bit of a stretch)

You can try xvid's way, replacing pthreads with native win32 api.