Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
17th December 2008, 18:08 | #41 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
So you want to implement your own wrapper for the Windows API to get a pthread-style interface.
What is the benefit over using the pthreads library, which basically does the same, is already working stable, saves you a lot of work and keeps your code clean & simple?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 17th December 2008 at 18:12. |
17th December 2008, 18:22 | #42 | Link | |
Registered User
Join Date: Dec 2004
Location: Melbourne, AU
Posts: 1,963
|
Quote:
(*Sleep() is not a synchronization primitive.) |
|
17th December 2008, 19:12 | #43 | Link | |
Registered User
Join Date: Apr 2008
Posts: 1,181
|
Quote:
|
|
17th December 2008, 19:15 | #44 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
They were very significantly faster than native threads. I doubt that Windows threads sped up that much in the 2 intervening years... |
|
17th December 2008, 19:28 | #46 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
Whenever an operation can be handled in a library, which is running in user mode, an expensive syscall to the os kernel (switch context from user mode to kernel mode and back to user mode) can be avoided. For the same reason pthreads on Linux now uses Futexes in order to avoid expensive syscalls whenever possible.... (BTW: In fact the Win32 API is a "high level" API (implemented by kernel32.dll and friends). There also is the "native" API (implemented in ntdll.dll), which usually is never called directly by an application. Only indirectly through Win32 API calls. The calls to the "native" API finally trap into kernel mode and execute the corresponding kernel function. So much for Win32 API is fast ^^)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 17th December 2008 at 20:02. |
|
17th December 2008, 19:50 | #47 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
MSVC 2008 build with pthreads: x264win64_r1057_msvc2008.rar
I have problems to compile with pthreads in MinGW. Would try it little more and then post patch in mailing list. |
17th December 2008, 22:08 | #48 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
Here is MinGW build with pthreads: x264win64_r1057_mingw.rar
Now you can test speed between MSVC / MinGW and between 32bit / 64bit (32bit build: http://mirror01.x264.nl/x264/revision1057/x264.exe) P.S. 64bit is not profiled (because I use cross-compiler on 32bit system) |
17th December 2008, 23:53 | #50 | Link | |
Registered User
Join Date: Jul 2007
Posts: 552
|
Quote:
|
|
18th December 2008, 01:26 | #51 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
confirmed as working (and thanks for fixing pthreads64 as well)
here's a build to match the current similar megui build Code:
Platform: X86_64 System: MINGW asm: yes avis input: yes mp4 output: yes pthread: yes debug: no gprof: no PIC: no shared: no visualize: no fprofiled: yes mods: x264_win64_support.01.r1057.diff x264_mingw_has_strtok_r.diff x264_mingw_aligned_04.diff x264_hrd_pulldown.09_interlace.diff getting a 5-10% speedup on my own quick tests compared to x86 Edit: now with mp4 output support Last edited by kemuri-_9; 18th December 2008 at 02:44. Reason: mp4 output |
18th December 2008, 02:36 | #53 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
got gpac to compile in mingw64...
whoever decided that char *'s should be compared by using != in zlib should be shot. Edit: it's broken for being used to test string non-equivalency... Last edited by kemuri-_9; 18th December 2008 at 04:27. Reason: edit to not make a new post on OT topic |
18th December 2008, 05:15 | #55 | Link | |
Registered User
Join Date: May 2005
Posts: 1,462
|
Quote:
And is the 'Ugly fades' issue, mentioned here: http://forum.doom9.org/showthread.php?t=143444 also resolved in this version? Otherwise there's no point in having the extra threads for my multi-core environment. Thanks
__________________
Gorgeous, delicious, deculture! |
|
18th December 2008, 06:06 | #57 | Link | |
Registered User
Join Date: Dec 2004
Location: Melbourne, AU
Posts: 1,963
|
Quote:
Yeah that's pretty dumb, almost as much as using strcmp for checking security signatures (thanks nintendo!). |
|
18th December 2008, 07:00 | #58 | Link | |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
Quote:
I thought it was an issue regarding one of the filters I was using, avisynth, or staxrip |
|
18th December 2008, 12:41 | #59 | Link | |
Registered User
Join Date: May 2005
Posts: 1,462
|
Quote:
__________________
Gorgeous, delicious, deculture! |
|
19th December 2008, 14:32 | #60 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
Ah ok! For the couple of times it has happened to me, and its not just with the latest versions, I'm not sure how far back it would go (hasn't always done it), its always at the end of the encode! Its not a major issue since the encoded file is still fine, but it would be good if it didn't happen - I'm guessing that it would be a very difficult problem to find, and it may not even be x264 which is causing it. It could be avisynth... Are you using Avisynth v2.5.8 RC4?
|
Thread Tools | Search this Thread |
Display Modes | |
|
|