GLIBC - I would like to contribute some platform optimizations
Gunnar von Boehn
gunnar@greyhound-data.com
Tue Sep 25 11:04:00 GMT 2007
Hello List,
Hello Mike,
Please find attached the source "libfastmemcpy.c".
Its a simple memcpy which achieves 60-80% more throughput than
glibc-memcpy on many CPUs.
The memcpy uses MMX and I've tested it on the following CPUs
AMD Duron, AMD Athlon 64, Intel XEON, AMD Opteron.
To archive optimal memcpy performamce a few things are done:
a) Source data should be prefetched to avoid memory latency bubbles.
The below routine will use "prefetchnta" instruction for this.
b) To improve write speed its adviseable to align the
destination properly. The destination will be aligned
to 32 bit boundary first and for bigger copies, the destrination
will be aligned to 64 byte (AMD cache line) boundary.
c) Using a non cache poluting copy will save the 2nd level
cache for other usage. While in rare cases this might be a small
disadvantage, in general this will be a big overall speed
improvement. The below routine uses "movntq" to avoid cache polution
In addition to the source I have attached the source of a small memcpy
benchmark routine, called "memcpy_bench.c"
The memcpy_bench will compare different memcpy routines and measure
their performance. The shown memory throughput will be printed as
MEMORY-BUS throughput in MB/sec. As a memcpy of 50 MB is reading of 50
MB + writing of 50 MB it will be shown as Bus speed of 100 MB.
These different memcpy routines that will be compared:
a) glibc-memcpy
b) bmove512 memcpy routine used by the MySQL-server to copy
bigger blocks as data
c) simple loop copying the data 8bit wise
d) simple loop copying the data 32bit wise
e) simple loop copying the data 64bit wise (using float commands)
This one is also known as STREAM-copy
f) The fast memcpy
The test will copy blocks of different sizes from 16 MB to 16 Byte.
Each test will always copy 16 MB.
E.G. the 1 MB copy will run 16 times to copy 16 MB.
With each run the copy will be moved to another block of 1 MB.
To the 16 iterations of 1 MB will in fact copy 16 MB of different data.
The purpose of this is to really measure the memory-bus performance as
we shift the copy window during the test and the data cache will have
the same (little) influence on each test independent of the size of the
copied block.
The test will be repeated on different aligned data to show the effects
of the alignment on the copy speed. On some CPUs some routines e.g the
64 bit wise float will run slow on misalignement data.
For full results please compile and run the benchmark yourself.
- The test shows that glibc-memcpy achieves
for medium sized and big blocks : 1405 MB/sec
and for small blocks : 650 MB/sec
- The fast memcpy does achieve
for medium sized and big blocks : 2500 MB/sec + 77 %
and for small blocks : 1308 MB/sec + 100 %
I claim no copyright for any of the sources.
Please fell free to use it for whatever you want.
Would be more than silly to claim copyright for such simple code anyway)
I hope that this source is a help for you.
Please tell me if you need anything else.
Please reply to my email address as well as I'm not in this mailing list.
Cheers
Gunnar
Dump of parts of membench output (Please excuse bad email formatting)
For a more complete test with more tests on various aligments please run
the memcpy_bench
Good aligned:
----------------------------------------------------------------------------------------------------------------
Alignment 0
---------------------------------------------------------------------------------------------------------------
16MB 4MB 1MB 256KB 64KB 16KB 4KB 1KB
512B 256B 128B 64B 32B 16B
----------------------------------------------------------------------------------------------------------------
glibc memcpy 1405 1404 1406 1393 1403 1408 1409 1384
1377 1380 1375 1314 903 649
bmove512 1415 1411 1410 1410 1410 1410 1397 1408 1409
copy 8 1133 1130 1142 1142 1138 1137 1132 1130
1126 1118 1113 1109 1014 907
copy 32 1416 1430 1411 1417 1434 1432 1427 1428
1426 1426 1424 1380 1348 1415
copy 64f 1464 1457 1465 1453 1440 1448 1463 1458
1455 1454 1445 1442 1393 1420
memcpy_mmx 2500 2497 2488 2500 2499 2495 2483 2491
2461 2453 1406 1334 1336 1308
Aligned on odd adress
----------------------------------------------------------------------------------------------------------------
Alignment 1
----------------------------------------------------------------------------------------------------------------
16MB 4MB 1MB 256KB 64KB 16KB 4KB 1KB
512B 256B 128B 64B 32B 16B
----------------------------------------------------------------------------------------------------------------
glibc memcpy 1464 1461 1462 1458 1449 1457 1455 1444
1437 1385 1386 1299 1119 682
bmove512 1411 1417 1411 1414 1414 1394 1409 1409 1406
copy 8 1173 1172 1174 1175 1170 1173 1157 1150
1143 1143 1122 1066 971 863
copy 32 1414 1428 1429 1424 1433 1406 1421 1422
1417 1409 1388 1382 1399 1378
copy 64f 1462 1443 1458 1458 1453 1454 1443 1434
1431 1418 1427 1425 1421 1403
memcpy_mmx 2506 2518 2506 2518 2510 2459 2338 1998
1646 1459 1447 1420 1381 1264
Mike Frysinger wrote:
> On Sunday 02 September 2007, Gunnar von Boehn wrote:
>
>>I would like to contribute some performance optimizations to the GLIBC.
>>I did some work on memory functions as e.g memcpy.
>>My results are very promising and with small changes e.g. memcpy could
>>get up to 50% more throughput on many platforms for transfer > 1KB.
>>(Tested on AMD/K7/K8 and PowerPC 603/750/7447/970)
>>
>>Can you please tell me the procedures to be able to contribute the
>>optimizations to you?
>
>
> (1) post the actual changes to the mailing list
> (2) post data supporting your improvement claims and the methodology for
> collecting said data
> (3) significant changes require FSF copyright assignment
> -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libfastmemcpy.c
Type: text/x-csrc
Size: 5787 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20070925/4e5b6b72/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memcpy_bench.c
Type: text/x-csrc
Size: 28663 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20070925/4e5b6b72/attachment-0001.bin>
More information about the Libc-alpha
mailing list