[RFC] disable fastmemcpy on x86-64 by default
Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks? Greetings, Reimar Döffinger
Hi On Sun, May 27, 2007 at 06:19:48PM +0200, Reimar D?ffinger wrote:
Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower.
TOOLS/fastmemcpybench.c ? either way its VERY important to not run benchmarks with uninitalized arrays, iam mentioning that as its a very common misstake a array as returned by malloc() will have all its 4k pages pointing to a single zeroed 4k page and will when read have 100% cache hits (depending on CPU) which is likely not what people want to benchmark [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
Hello, On Sun, May 27, 2007 at 07:29:09PM +0200, Michael Niedermayer wrote:
On Sun, May 27, 2007 at 06:19:48PM +0200, Reimar D?ffinger wrote:
since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower.
TOOLS/fastmemcpybench.c ?
That does not help really much, since which one wins depends extremely on sizes, e.g. (values in () are on 32 bit): size 32 bytes: system libc 1525.9MB/s (305.2MB/s) fastmemcpy 381.5MB/s (339.1MB/s) size 1024*768*2: 1015.6MB/s (557.5MB/s) 1201.6MB/s (1199.9MB/s) for even larger sizes the differences don't seem to be statistically relevant. In personally don't find the difference decidedly enough in favour for our fastmemcpy to use it in my own builds but your opinion might differ (using system memcpy reduces binary size and instruction cache load)... Greetings, Reimar Döffinger
Hi On Sun, May 27, 2007 at 08:25:12PM +0200, Reimar Döffinger wrote:
Hello, On Sun, May 27, 2007 at 07:29:09PM +0200, Michael Niedermayer wrote:
On Sun, May 27, 2007 at 06:19:48PM +0200, Reimar D?ffinger wrote:
since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower.
TOOLS/fastmemcpybench.c ?
That does not help really much, since which one wins depends extremely on sizes, e.g. (values in () are on 32 bit):
size 32 bytes: system libc 1525.9MB/s (305.2MB/s) fastmemcpy 381.5MB/s (339.1MB/s)
size 1024*768*2: 1015.6MB/s (557.5MB/s) 1201.6MB/s (1199.9MB/s)
for even larger sizes the differences don't seem to be statistically relevant.
In personally don't find the difference decidedly enough in favour for our fastmemcpy to use it in my own builds but your opinion might differ (using system memcpy reduces binary size and instruction cache load)...
i dont think that a single memcpy() libc or fast can be optimal, the optimal choice depends on size to be copied, if src and dst are in the cache and if dst will be read immedeatly afterwards, on the cache size, and if dst is in main memory or on some pci/agp card we already have a function for mem->agp copies so that case doesnt need to be considered anymore what about a mp_memcpy() / av_memcpy() which takes AV_SRC_IN_CACHE, AV_DST_IN_CACHE, AV_WILL_READ_DST, AV_SIZE_CONST ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates
Hello, On Sun, May 27, 2007 at 09:54:31PM +0200, Michael Niedermayer wrote:
what about a mp_memcpy() / av_memcpy() which takes AV_SRC_IN_CACHE, AV_DST_IN_CACHE, AV_WILL_READ_DST, AV_SIZE_CONST ?
Are there any copies with large, constant size? If not normal memcpy that the compiler can replace with its builtin is probably best. I also do wonder in how many cases where the fast memcpy is beneficial we need to support for unaligned access, this is quite a bit of the fast_memcpy complexity. If even length can be assumed to be a certain multiple the function might even become small enough to inline. But either way the first step would be to cleanup the mess that resulted from that 'just slap a #include "fastmemcpy.h" there', esp. for the gui code I really doubt there is much of a point in it... Greetings, Reimar Döffinger
Hi, On 5/27/07, Reimar D?ffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks?
What would be a good benchmark? A very HD video sample like Apple's? What hardware would exhibit more how fastmemcpy affects speed? I have an AMD64 2.4Ghz /s754 with a Geforce 6200LE AGP, if it matters. Guillaume -- Y'a pas de gonzesse hooligan, Imbécile et meurtrière Y'en a pas même en grande Bretagne A part bien sûr Madame Thatcher -- Renaud (sur "Miss Maggie")
Hello, On Sun, May 27, 2007 at 07:39:20PM +0200, Guillaume POIRIER wrote:
On 5/27/07, Reimar D?ffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks?
What would be a good benchmark? A very HD video sample like Apple's?
Judging by the synthetic benchmarks I had running results might differ quite a bit depending on resolution.
What hardware would exhibit more how fastmemcpy affects speed? I have an AMD64 2.4Ghz /s754 with a Geforce 6200LE AGP, if it matters.
I don't really know, I'm interested to get some statistics... Greetings, Reimar Döffinger
Dnia niedziela, 27 maja 2007, Reimar D?ffinger napisał:
since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks? And what exactly should be "at least not slower". I made simple test "-quiet -benchmark -vo null -nosound" and results are following:
w/o patch: BENCHMARKs: VC: 9.211s VO: 2.236s A: 0.000s Sys: 0.237s = 11.684s BENCHMARK%: VC: 78.8329% VO: 19.1350% A: 0.0000% Sys: 2.0321% = 100.0000% w/ patch: BENCHMARKs: VC: 9.208s VO: 4.087s A: 0.000s Sys: 0.299s = 13.594s BENCHMARK%: VC: 67.7354% VO: 30.0667% A: 0.0000% Sys: 2.1979% = 100.0000% Tests made on AMD64 3000+ (1.8GHz), gcc 4.1.2 and glibc 2.5. -- Piotr Stachura
Hi, On May 27, 2007, at 8:15 , Piotr Stachura wrote:
Dnia niedziela, 27 maja 2007, Reimar D?ffinger napisał:
since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks? And what exactly should be "at least not slower". I made simple test "-quiet -benchmark -vo null -nosound" and results are following:
w/o patch: BENCHMARKs: VC: 9.211s VO: 2.236s A: 0.000s Sys: 0.237s = 11.684s BENCHMARK%: VC: 78.8329% VO: 19.1350% A: 0.0000% Sys: 2.0321% = 100.0000%
w/ patch: BENCHMARKs: VC: 9.208s VO: 4.087s A: 0.000s Sys: 0.299s = 13.594s BENCHMARK%: VC: 67.7354% VO: 30.0667% A: 0.0000% Sys: 2.1979% = 100.0000%
Tests made on AMD64 3000+ (1.8GHz), gcc 4.1.2 and glibc 2.5.
Did you make several runs? Making around 10 runs, providing mean time and smallest time would allow to make sure you're not measuring random noise. Also, telling what kind of sample you're using may be a good idea. All that IMHO. Guillaume
Tests made on AMD64 3000+ (1.8GHz), gcc 4.1.2 and glibc 2.5.
Did you make several runs? Making around 10 runs, providing mean time and smallest time would allow to make sure you're not measuring random noise. Also, telling what kind of sample you're using may be a good idea.
I made another one. A sample is first 100s of Bleach episode 1 encoded by AHQ (h264 640x480). About 7 runs each, best results: w/o patch: BENCHMARKs: VC: 15.057s VO: 1.208s A: 0.000s Sys: 0.197s = 16.462s BENCHMARK%: VC: 91.4647% VO: 7.3400% A: 0.0000% Sys: 1.1953% = 100.0000% w/ patch: BENCHMARKs: VC: 15.285s VO: 1.954s A: 0.000s Sys: 0.223s = 17.462s BENCHMARK%: VC: 87.5324% VO: 11.1913% A: 0.0000% Sys: 1.2763% = 100.0000%
Ouch. Which vo and what resolution?
as I mentioned "-vo null" that is somehow strange according to VO time. Resolution: video 640x480, working 1280x1024 but when null VO then it shouldn't matter. If it matters: CommandLine: '-quiet' '-benchmark' '-vo' 'null' '-nosound' '001. 死神になっちゃった日 (A Shinigami is Born!).mkv' '-endpos' '100' '-v' Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) VO: [null] 640x480 => 640x480 Planar YV12 *** [ass] Exporting mp_image_t, 640x480x12bpp YUV planar, 460800 bytes *** [vo] Allocating mp_image_t, 640x480x12bpp YUV planar, 460800 bytes -- Piotr Stachura
Ouch. Which vo and what resolution?
as I mentioned "-vo null" that is somehow strange according to VO time. Resolution: video 640x480, working 1280x1024 but when null VO then it shouldn't matter.
If it matters:
CommandLine: '-quiet' '-benchmark' '-vo' 'null' '-nosound' '001. 死神になっちゃった日 (A Shinigami is Born!).mkv' '-endpos' '100' '-v' Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) VO: [null] 640x480 => 640x480 Planar YV12 *** [ass] Exporting mp_image_t, 640x480x12bpp YUV planar, 460800 bytes *** [vo] Allocating mp_image_t, 640x480x12bpp YUV planar, 460800 bytes
Now I made also tests on -vo xv: w/o patch: BENCHMARKs: VC: 15.041s VO: 17.028s A: 0.000s Sys: 0.186s = 32.254s BENCHMARK%: VC: 46.6319% VO: 52.7926% A: 0.0000% Sys: 0.5754% = 100.0000% w/ patch: BENCHMARKs: VC: 15.064s VO: 17.061s A: 0.000s Sys: 0.196s = 32.322s BENCHMARK%: VC: 46.6070% VO: 52.7857% A: 0.0000% Sys: 0.6072% = 100.0000% VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12) VO: [xv] 640x480 => 640x480 Planar YV12 Now benchmarks are almost this same. Mayby something is wrong with null output :> -- Piotr Stachura
Hello, On Sun, May 27, 2007 at 08:15:23PM +0200, Piotr Stachura wrote:
Dnia niedziela, 27 maja 2007, Reimar D?ffinger napisa??:
since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks? And what exactly should be "at least not slower". I made simple test "-quiet -benchmark -vo null -nosound" and results are following:
w/o patch: BENCHMARKs: VC: 9.211s VO: 2.236s A: 0.000s Sys: 0.237s = 11.684s BENCHMARK%: VC: 78.8329% VO: 19.1350% A: 0.0000% Sys: 2.0321% = 100.0000%
w/ patch: BENCHMARKs: VC: 9.208s VO: 4.087s A: 0.000s Sys: 0.299s = 13.594s BENCHMARK%: VC: 67.7354% VO: 30.0667% A: 0.0000% Sys: 2.1979% = 100.0000%
Ouch. Which vo and what resolution? Greetings, Reimar Döffinger
On Sun, 27 May 2007 18:19:48 +0200 Reimar D?ffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks?
Here some benchmarks: System: attila@jashugan:~ # uname -a Linux jashugan 2.6.18 #1 Wed Sep 27 17:50:21 CEST 2006 x86_64 GNU/Linux attila@jashugan:~ # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 55 model name : AMD Athlon(tm) 64 Processor 3700+ stepping : 2 cpu MHz : 2202.856 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm bogomips : 4409.53 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp attila@jashugan:~ # dpkg -s libc6|grep Version Version: 2.3.6.ds1-13 attila@jashugan:~ # dpkg -s gcc|grep Version Version: 4:4.1.1-15 attila@jashugan:~ # free -m total used free shared buffers cached Mem: 2012 1952 59 0 4 1125 -/+ buffers/cache: 822 1190 Swap: 7812 0 7812 Graphics card is a Matrox G550, used vo: xmga All benchmarks are best of 3, with one burn in, run from a local sata disk (resp after burn in from RAM) standard parameters: -quiet -nosound -benchmark ------------------------------------------------- Benchmark 1: (frist 2000 frames only) MPlayer dev-SVN-r23390-4.1.2 (C) 2000-2007 MPlayer Team CPU: AMD Athlon(tm) 64 Processor 3700+ (Family: 15, Model: 55, Stepping: 2) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 Playing /tmp/[Ayako]_Seto_no_Hanayome_-_01_(H264)_[951E16B9].mkv. [mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0 [mkv] Track ID 2: audio (A_AAC), -aid 0, -alang und [mkv] Track ID 3: subtitles (S_TEXT/ASS), -sid 0, -slang und [mkv] Track ID 4: subtitles (S_TEXT/UTF8), -sid 1, -slang und [mkv] Will play video track 1. [mkv] No audio track found/wanted. Matroska file format detected. VIDEO: [avc1] 1280x720 24bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== Audio: no sound Starting playback... VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xmga] 1280x720 => 1280x720 Planar YV12 [MGA] Using 3 buffers. w/o patch: BENCHMARKs: VC: 19.974s VO: 44.601s A: 0.000s Sys: 0.093s = 64.668s BENCHMARK%: VC: 30.8864% VO: 68.9698% A: 0.0000% Sys: 0.1437% = 100.0000% w/ patch: BENCHMARKs: VC: 19.889s VO: 44.503s A: 0.000s Sys: 0.091s = 64.484s BENCHMARK%: VC: 30.8437% VO: 69.0146% A: 0.0000% Sys: 0.1416% = 100.0000% ------------------------------------------------- Benchmark 2: MPlayer dev-SVN-r23390-4.1.2 (C) 2000-2007 MPlayer Team CPU: AMD Athlon(tm) 64 Processor 3700+ (Family: 15, Model: 55, Stepping: 2) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 Playing /tmp/Inuyasha Movie Commercial 01 Dvd Rip.avi. AVI file format detected. [aviheader] Video stream found, -vid 0 [aviheader] Audio stream found, -aid 1 VIDEO: [DIVX] 720x480 24bpp 23.976 fps 4038.1 kbps (492.9 kbyte/s) Clip info: Software: Nandub v1.0rc2 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) ========================================================================== Audio: no sound Starting playback... [mpeg4 @ 0xcedc20]looks like this file was encoded with (divx4/(old)xvid/opendivx) -> forcing low_delay flag VDec: vo config request - 720 x 480 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. VO: [xmga] 720x480 => 720x480 Planar YV12 [MGA] Using 3 buffers. w/o patch: BENCHMARKs: VC: 9.980s VO: 0.003s A: 0.000s Sys: 0.046s = 10.029s BENCHMARK%: VC: 99.5084% VO: 0.0336% A: 0.0000% Sys: 0.4580% = 100.0000% w/ patch: BENCHMARKs: VC: 8.833s VO: 0.003s A: 0.000s Sys: 0.047s = 8.883s BENCHMARK%: VC: 99.4307% VO: 0.0367% A: 0.0000% Sys: 0.5326% = 100.0000% ------------------------------------------------- Benchmark 3: MPlayer dev-SVN-r23390-4.1.2 (C) 2000-2007 MPlayer Team CPU: AMD Athlon(tm) 64 Processor 3700+ (Family: 15, Model: 55, Stepping: 2) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 Playing /tmp/[AnY-Spork] Iriya no Sora, UFO no Natsu - 1 [DVD-MP3][46B1F913].avi. AVI file format detected. [aviheader] Video stream found, -vid 0 [aviheader] Audio stream found, -aid 1 VIDEO: [XVID] 640x480 24bpp 23.976 fps 1064.2 kbps (129.9 kbyte/s) Clip info: Software: VirtualDubMod 1.5.10.1 (build 2366/release) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) ========================================================================== Audio: no sound Starting playback... VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [xmga] 640x480 => 640x480 Planar YV12 [MGA] Using 3 buffers. w/o patch: BENCHMARKs: VC: 307.732s VO: 0.126s A: 0.000s Sys: 1.025s = 308.883s BENCHMARK%: VC: 99.6274% VO: 0.0407% A: 0.0000% Sys: 0.3319% = 100.0000% w/ patch: BENCHMARKs: VC: 307.750s VO: 0.112s A: 0.000s Sys: 1.093s = 308.954s BENCHMARK%: VC: 99.6102% VO: 0.0361% A: 0.0000% Sys: 0.3537% = 100.0000% ------------------------------------------------- Benchmark 4: V for Vendetta DVD, coppied to disk, with -ss 4:00 -frames 4000 MPlayer dev-SVN-r23390-4.1.2 (C) 2000-2007 MPlayer Team CPU: AMD Athlon(tm) 64 Processor 3700+ (Family: 15, Model: 55, Stepping: 2) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 Playing dvd://1. libdvdread: Couldn't find device name. There are 2 titles on this DVD. There are 12 chapters in this DVD title. There are 1 angles in this DVD title. audio stream: 0 format: ac3 (stereo) language: unknown aid: 128. number of audio channels on disk: 1. number of subtitles on disk: 0 MPEG-PS file format detected. VIDEO: MPEG2 720x480 (aspect 3) 29.970 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough VDec: vo config request - 720 x 480 (preferred colorspace: Mpeg PES) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. Try appending the scale filter to your filter list, e.g. -vf spp,scale instead of -vf spp. VDecoder init failed :( Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b Selected video codec: [mpeg12] vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2)) ========================================================================== Audio: no sound Starting playback... VDec: vo config request - 720 x 480 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xmga] 720x480 => 854x480 Planar YV12 [MGA] Using 3 buffers. w/o patch: BENCHMARKs: VC: 6.520s VO: 42.695s A: 0.000s Sys: 0.313s = 49.528s BENCHMARK%: VC: 13.1638% VO: 86.2044% A: 0.0000% Sys: 0.6318% = 100.0000% w/ patch: BENCHMARKs: VC: 6.178s VO: 36.899s A: 0.000s Sys: 0.308s = 43.386s BENCHMARK%: VC: 14.2394% VO: 85.0499% A: 0.0000% Sys: 0.7107% = 100.0000% ------------------------------------------------- Benchmark 5: (first 10000 frames only) MPlayer dev-SVN-r23390-4.1.2 (C) 2000-2007 MPlayer Team CPU: AMD Athlon(tm) 64 Processor 3700+ (Family: 15, Model: 55, Stepping: 2) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 Playing /tmp/Hana Bi.avi. AVI file format detected. [aviheader] Video stream found, -vid 0 [aviheader] Audio stream found, -aid 1 VIDEO: [DIVX] 560x320 24bpp 23.976 fps 809.7 kbps (98.8 kbyte/s) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) ========================================================================== Audio: no sound Starting playback... [mpeg4 @ 0xcedc20]looks like this file was encoded with (divx4/(old)xvid/opendivx) -> forcing low_delay flag VDec: vo config request - 560 x 320 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. VO: [xmga] 560x320 => 560x320 Planar YV12 [MGA] Using 3 buffers. w/o patch: BENCHMARKs: VC: 71.232s VO: 0.018s A: 0.000s Sys: 0.199s = 71.449s BENCHMARK%: VC: 99.6961% VO: 0.0257% A: 0.0000% Sys: 0.2781% = 100.0000% w/ patch: BENCHMARKs: VC: 61.344s VO: 0.019s A: 0.000s Sys: 0.174s = 61.537s BENCHMARK%: VC: 99.6857% VO: 0.0316% A: 0.0000% Sys: 0.2827% = 100.0000% ------------------------------------------------- I also sinlge-run tested a few other samples similar to benchmark 1 and 3 (ie animes with divx3, divx4, xvid, h.264) codecs that didn't show any siginificant speed difference (<1%) Interesting are benchmark 2 and 5, which both are faster with the patch. They are also the only ones i came across that were decoded using the low_delay flag. If someone is interested in this, i could search for more samples of this kind, i should have some. Attila Kinali -- Linux ist... wenn man einfache Dinge auch mit einer kryptischen post-fix Sprache loesen kann -- Daniel Hottinger
Hi On Sun, May 27, 2007 at 10:47:55PM +0200, Attila Kinali wrote:
On Sun, 27 May 2007 18:19:48 +0200 Reimar D?ffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks?
Here some benchmarks: [...] I also sinlge-run tested a few other samples similar to benchmark 1 and 3 (ie animes with divx3, divx4, xvid, h.264) codecs that didn't show any siginificant speed difference (<1%)
Interesting are benchmark 2 and 5, which both are faster with the patch.
hmm, theres something odd ... where is this code using any memcpy at all? doesnt mga vo always use mem2agpcpy() ? it seems the patch disabled this and uses plain memcpy() for it and MIN_LEN is 2k and mem2agpcpy is just done per line which is less then 2k so it practically falls back to rep movsb this is in impressive series of bugs ... if my hypothesis is correct then reimar will have some work to do ;) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.
Hi On Sun, May 27, 2007 at 11:11:45PM +0200, Michael Niedermayer wrote:
Hi
On Sun, May 27, 2007 at 10:47:55PM +0200, Attila Kinali wrote:
On Sun, 27 May 2007 18:19:48 +0200 Reimar D?ffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks?
Here some benchmarks: [...] I also sinlge-run tested a few other samples similar to benchmark 1 and 3 (ie animes with divx3, divx4, xvid, h.264) codecs that didn't show any siginificant speed difference (<1%)
Interesting are benchmark 2 and 5, which both are faster with the patch.
hmm, theres something odd ... where is this code using any memcpy at all? doesnt mga vo always use mem2agpcpy() ? it seems the patch disabled this and uses plain memcpy() for it
and MIN_LEN is 2k and mem2agpcpy is just done per line which is less then 2k so it practically falls back to rep movsb
this is in impressive series of bugs ...
if my hypothesis is correct then reimar will have some work to do ;)
hypothesis seems wrong MIN_LEN seems 64 maybe HAVE_MMX1 should rather be called HAVE_ONLY_MMX1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable
On Sun, 27 May 2007 23:11:45 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
Interesting are benchmark 2 and 5, which both are faster with the patch.
I missed here benchmark 4, which is also slightly faster. Interesting to note: benchmark 2 and 5 are faster in the VC(!) bechmark 4 in the VO. Which suggest that benchmark 2 and 5 use dr. (couldn't see anything in the -v log, and i'm to tired to check the code)
hmm, theres something odd ... where is this code using any memcpy at all? doesnt mga vo always use mem2agpcpy() ? it seems the patch disabled this and uses plain memcpy() for it
Yes, from libvo/fast_memcpy.h: ---schnipp--- #ifdef USE_FASTMEMCPY [...] #else /* USE_FASTMEMCPY */ #define mem2agpcpy(a,b,c) memcpy(a,b,c) #endif ---schnapp--- And due to the patch, USE_FASTMEMCPY isn't set anymore.
and MIN_LEN is 2k and mem2agpcpy is just done per line which is less then 2k so it practically falls back to rep movsb
I tried a series of files which had shorter line sizes than the ones liste, none of which showed any speedup. But i didn't check for any use of dr.
this is in impressive series of bugs ...
if my hypothesis is correct then reimar will have some work to do ;)
BTW: is there any reason why fast_memcpy&co are not defined inline? I even think that in the case w/o runtime cpu detection, we could just do a #define fast_memcpy fast_memcpy_XXX (where XXX is one of MMX,SSE...) and get completely rid not only of a call, but of a stack frame too. Attila Kinali -- Linux ist... wenn man einfache Dinge auch mit einer kryptischen post-fix Sprache loesen kann -- Daniel Hottinger
Hi On Sun, May 27, 2007 at 11:38:57PM +0200, Attila Kinali wrote: [...]
this is in impressive series of bugs ...
if my hypothesis is correct then reimar will have some work to do ;)
BTW: is there any reason why fast_memcpy&co are not defined inline?
as fast_memcpy() isnt in a header (currently) that wont change anything with gcc
I even think that in the case w/o runtime cpu detection, we could just do a #define fast_memcpy fast_memcpy_XXX (where XXX is one of MMX,SSE...) and get completely rid not only of a call, but of a stack frame too.
fast_memcpy_XXX() mem2agpcpy_XXX() should be inlined by gcc (in theory) as they are static and used just at one spot [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle
On Sun, May 27, 2007 at 10:47:55PM +0200, Attila Kinali wrote:
On Sun, 27 May 2007 18:19:48 +0200 Reimar D?ffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks?
Here some benchmarks:
System: attila@jashugan:~ # uname -a Linux jashugan 2.6.18 #1 Wed Sep 27 17:50:21 CEST 2006 x86_64 GNU/Linux attila@jashugan:~ # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 55 model name : AMD Athlon(tm) 64 Processor 3700+ stepping : 2 cpu MHz : 2202.856 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm bogomips : 4409.53 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp
attila@jashugan:~ # dpkg -s libc6|grep Version Version: 2.3.6.ds1-13 attila@jashugan:~ # dpkg -s gcc|grep Version Version: 4:4.1.1-15 attila@jashugan:~ # free -m total used free shared buffers cached Mem: 2012 1952 59 0 4 1125 -/+ buffers/cache: 822 1190 Swap: 7812 0 7812
Graphics card is a Matrox G550, used vo: xmga
All benchmarks are best of 3, with one burn in, run from a local sata disk (resp after burn in from RAM)
standard parameters: -quiet -nosound -benchmark [...]
I also sinlge-run tested a few other samples similar to benchmark 1 and 3 (ie animes with divx3, divx4, xvid, h.264) codecs that didn't show any siginificant speed difference (<1%)
Interesting are benchmark 2 and 5, which both are faster with the patch. They are also the only ones i came across that were decoded using the low_delay flag.
hypothesis 2 the width of the with patch faster cases is not a multiple of 64 which forces a few bytes of the mem2agp copy to be copied by small_memcpy() which does NOT use non temporal stores which defeats the whole purpose of mem2agp copy as the dst is read into the cache and reads from agp are shitty slow experiment to test, outcomment the small_memcpy() call fix if it is the problem, put a non temporal memcpy with size <64 there ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
On Sunday 27 May 2007 at 10:19, Reimar D?ffinger wrote:
Hello, since SSE is part of the x86-64 architecture, at least glibc makes use of it for its memcpy and some quick (and imprecise) tests indicate that it's at least not slower. So what do you think about attached patch? Can someone do more concise benchmarks?
Well, as Michael N. stated, it depends on size, that's why the next gcc will decide on that size, how the memcpy 'function call' will be treated. I.e. all below a 1 kbytes can be copied faster with sse2. http://www.greyhound-data.com/gunnar/glibc/index.htm?page=benchmarks So, till this new gcc is available, IMHO a generic memcpy inline function shall make one happy, if size<1024 { .. double pointer stream copy } else old fashion glibc memcpy .. And yes .. it makes a huge difference ;-) Cheers, Sven
Greetings, Reimar Döffinger
-- health & wealth mailto:sgothel@jausoft.com ; www : http://www.jausoft.ca ; pgp: http://www.jausoft.com/gpg/ land : +1 (780) 637 3842 ; cell: +1 (780) 952 4481 Timezone MST: EST-2, UTC-7, CET-8 ; MDT: EDT-2, UTC-6, CEDT-8
participants (8)
-
Attila Kinali -
Guillaume POIRIER -
Guillaume Poirier -
Michael Niedermayer -
Piotr Stachura -
Reimar D?ffinger -
Reimar Döffinger
-
Sven Gothel