-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AVX2 memcpy(), memcmp() & Ko #635
Comments
The PoCs for I believe there are more optimization opportunities of the functions. Glibc uses much more complicated algorithms, e.g. https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S;h=cbd0d077cf61718a8f558829bd368fb79505fa26;hb=HEAD Wrk benchmark resultsI used the same setup and workload as described in HTTP Requests Proxying article. proxying of 1KB fileOptimized version (3 runs): 28436 RPS, 28617 RPS, 28515 RPS (perf for Vanilla: 28611 RPS, 28826 RPS, 29064 RPS (perf for memcpy_erms ~ 0.70%) Caching of 1KB fileOptimized: 51479 RPS, 53292 RPS, 53004 RPS (perf: Vanilla: 44149 RPS, 46638 RPS, 51809 RPS (perf: |
More performance data from the hardware testbed. In most of the tests
|
Fix #635: SIMD implementations for memcpy(), memset(), and memcmp()
Linux kernel uses dummy x86 assembly for
memcpy()
,memcmp()
etc. Meantime Tempesta FW and Tempesta DB copy small data using the routines. Example of the data is HTTP headers - usually they small, but some of them (like Cookie) can reach enormous size and we have to copy them to be able to adjust.Actually with #634 in mind we should not copy HTTP headers, but we still need to copy some small data.
The text was updated successfully, but these errors were encountered: