After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769259 - orc_memcpy() slower than memcpy()
orc_memcpy() slower than memcpy()
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: orc
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-28 09:20 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 10:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
memcpy_speed.diff (1.27 KB, patch)
2016-07-28 09:20 UTC, Sebastian Dröge (slomo) 		none Details | Review
raw data (3.60 KB, text/plain)
2016-07-28 09:20 UTC, Sebastian Dröge (slomo) 		  Details
orc-libc-memcpy.png (61.35 KB, image/png)
2016-07-28 09:21 UTC, Sebastian Dröge (slomo) 		  Details

Description Sebastian Dröge (slomo) 2016-07-28 09:20:21 UTC 
Created attachment 332264 [details] [review]
memcpy_speed.diff

With attached patch for making the memcpy performance test in orc output something meaningful (actual size | time for one iteration with orc | with libc), orc_memcpy() is e.g. about 35% slower than memcpy() on 5MB.

This is on Linux with a "Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz" and glibc 2.22. Similar reports on Windows though.

When putting the output to a file ("data") you can plot this with gnuplot:
> plot "data" using 1:2 t "orc" with lines, "data" using 1:3 t "libc" with lines

See also attached plot from me
Comment 1 Sebastian Dröge (slomo) 2016-07-28 09:20:41 UTC 
Created attachment 332265 [details]
raw data
Comment 2 Sebastian Dröge (slomo) 2016-07-28 09:21:01 UTC 
Created attachment 332266 [details]
orc-libc-memcpy.png
Comment 3 Sebastian Dröge (slomo) 2016-07-28 09:40:10 UTC 
Might be because we use movdqa here, probably unrolled a bit. We could use vmovdqa on CPUs that support AVX, but for supporting AVX we would need a completely separate backend (mixing SSE and AVX instructions makes everything slower).
Comment 4 Sebastian Dröge (slomo) 2016-07-28 09:41:32 UTC 
Bug #769261 for AVX support.
Comment 5 GStreamer system administrator 2018-11-03 10:48:24 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/orc/issues/12.