On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
> I had a little fun today kicking the crap out of C's memcpy with a D implementation.
>
> https://github.com/JinShil/memcpyD
>
> Request for help: I don't have a Linux system running on real hardware at this time, nor do I have a wide range of platforms and machines to test with.  If you'd like to help me with this potentially foolish endeavor, please run the program on your hardware and send me the results.
>
> Feedback, advise, and pull requests to improve the implementation are most welcome.
>
> Mike

I get this on Linux 4.16.3-gentoo, AMD FX(tm)-6100 Six-Core Processor, 8GiB ram,

using ldc2 -O3L:
size memcpyC memcpyD
1 5 0
2 0 0
4 0 0
8 0 0
16 1519 0
32 1833 0
64 3816 0
128 7543 0
256 146500 0
512 194818 0
1024 329593 846142
2048 714945 1117132
4096 1596170 1803621
8192 5899818 6110026
16384 12338384 14141850
32768 24971315 26771484
65536 49806637 63260128

size memcpyC memcpyD
1 0 0
1 0 0
1 0 0
2 0 0
2 0 0
4 0 0
4 0 0
8 0 0
8 0 0
4 0 0
8 0 0
core.exception.AssertError@memcpyd.d(9): Assertion failure
----------------
??:? _d_assert [0xcaf056d5]
??:? [0xa015e7fe]
??:? [0xa0158cb0]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0xcaf29daf]
??:? _d_run_main [0xcaf29c7b]
??:? __libc_start_main [0xca160eeb]
??:? [0xa0158b29]

On Wednesday, 13 June 2018 at 12:45:26 UTC, Fra Mecca wrote:
> I get this on Linux 4.16.3-gentoo, AMD FX(tm)-6100 Six-Core Processor, 8GiB ram,
>
> using ldc2 -O3L:
> size memcpyC memcpyD
> 1 5 0
> 2 0 0
> 4 0 0
> 8 0 0
> 16 1519 0
> 32 1833 0
> 64 3816 0
> 128 7543 0
> 256 146500 0
> 512 194818 0
> 1024 329593 846142
> 2048 714945 1117132
> 4096 1596170 1803621
> 8192 5899818 6110026
> 16384 12338384 14141850
> 32768 24971315 26771484
> 65536 49806637 63260128
>
> size memcpyC memcpyD
> 1 0 0
> 1 0 0
> 1 0 0
> 2 0 0
> 2 0 0
> 4 0 0
> 4 0 0
> 8 0 0
> 8 0 0
> 4 0 0
> 8 0 0
> core.exception.AssertError@memcpyd.d(9): Assertion failure
> ----------------
> ??:? _d_assert [0xcaf056d5]
> ??:? [0xa015e7fe]
> ??:? [0xa0158cb0]
> ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0xcaf29daf]
> ??:? _d_run_main [0xcaf29c7b]
> ??:? __libc_start_main [0xca160eeb]
> ??:? [0xa0158b29]

Yes, optimizations are throwing code away.  I'm working on it.

Mike

On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
> I had a little fun today kicking the crap out of C's memcpy with a D implementation.
>
> https://github.com/JinShil/memcpyD
>
> Request for help: I don't have a Linux system running on real hardware at this time, nor do I have a wide range of platforms and machines to test with.  If you'd like to help me with this potentially foolish endeavor, please run the program on your hardware and send me the results.
>
> Feedback, advise, and pull requests to improve the implementation are most welcome.
>
> Mike

I'm glad to see this kind of improvement! I noticed there wasn't any macOS testing though, so heres the results on my machine:

size memcpyC memcpyD
1 38613 5185
2 42475 7259
4 54272 3450
8 29391 3457
16 32947 3626
32 33761 7253
64 44152 14510
128 51985 27711
256 65700 58044
512 95315 119977
1024 150726 387021
2048 265975 667858
4096 521565 1113945
8192 965322 2039064
16384 3923818 3997524
32768 15586237 15669232
65536 33195890 31640205

size memcpyC memcpyD
1 40057 5180
1 36664 5226
1 37625 5280
2 36584 5178
2 36956 5252
4 51086 3448
4 49952 3456
8 29497 3455
8 29710 3987
4 51539 3453
8 29715 3449
16 29747 23535

sys info : Intel Core i5 4258u (28w), 8GB DDR3 1600MHz RAM

Looks very promising. One question though, why not use std.datetime.stopwatch.benchmark? I think it has some protection against optimizing compilers (I may be wrong though). Also, LDC has attributes to control optimizations on a per function basis.see : https://wiki.dlang.org/LDC-specific_language_changes

My linux install got messed up, but I'll post benchmarks as soon as its up

On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
> I had a little fun today kicking the crap out of C's memcpy with a D implementation.
>
> https://github.com/JinShil/memcpyD
>
> Request for help: I don't have a Linux system running on real hardware at this time, nor do I have a wide range of platforms and machines to test with.  If you'd like to help me with this potentially foolish endeavor, please run the program on your hardware and send me the results.
>
> Feedback, advise, and pull requests to improve the implementation are most welcome.
>
> Mike

specs
.........................................

(note: tried DMD v2.078.3) > dmd -O  (and got strange assertion errors).

(used LDC 1.8.0 instead) > ldc2 -O2

Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz
24GB Mem (Speed: 1066 MT/s)

Kubuntu 18.04 LTS - 4.15.0-23-generic
........................................


results
........................................
size memcpyC memcpyD
1 0 0
2 0 0
4 0 0
8 0 0
16 1247 0
32 1889 0
64 3055 0
128 5040 0
256 91407 0
512 158527 0
1024 253191 870780
2048 474243 1170349
4096 932151 1933045
8192 1894059 3284901
16384 4447945 6122015
32768 18572704 20772417
65536 37470068 40211203

size memcpyC memcpyD
1 0 0
1 0 0
1 0 0
2 0 0
2 0 0
4 0 0
4 0 0
8 0 0
8 0 0
4 0 0
8 0 0
16 0 0

..........................

On 6/13/18 2:46 AM, Mike Franklin wrote:
> I had a little fun today kicking the crap out of C's memcpy with a D implementation.
> 
> https://github.com/JinShil/memcpyD
> 
> Request for help: I don't have a Linux system running on real hardware at this time, nor do I have a wide range of platforms and machines to test with.  If you'd like to help me with this potentially foolish endeavor, please run the program on your hardware and send me the results.

Just FYI, Linux results on a VM are still valid -- many people (including myself) only use Linux on a VM, so even though it's not a definitive win against glibc memcpy on Linux, the end result is, it's still faster for those users :)

I won't add much, since I'm using a Mac, and those numbers have already been posted.

But I wanted to say don't discount those findings off-hand.

-Steve

On 06/13/2018 02:07 AM, ToRuSer wrote:

> So well done to the D community, for discriminating against all the Tor
> users out there. You've done yourself proud.

I am part of the D community. I haven't discriminated against anyone. I don't know what a Tor user is.

I've just searched: So Tor is an old idea of mine, implemented. :o)

Ali

On Wednesday, 13 June 2018 at 16:21:53 UTC, Steven Schveighoffer wrote:
> I won't add much, since I'm using a Mac, and those numbers have already been posted.

Reproduction is an important part of the scientific process, please post away ;)

Also: memcpyD commit f5fb0fda0dbacc960ced59d7171ff76a95cc2abf on Archlinux native x86_64 4.16.13-2 with Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz and 7681MB of RAM, with dmd and ldc, no flag and optimized.

DMD:

size memcpyC memcpyD
1 50392 30745
2 50189 33515
4 47493 33456
8 50282 33428
16 36385 36061
32 36212 32142
64 50141 31137
128 52947 52785
256 86422 76346
512 131191 128344
1024 227875 291414
2048 444865 449210
4096 826391 823613
8192 1542429 1545051
16384 3264964 3228990
32768 11644816 11902418
65536 23658237 24026304

size memcpyC memcpyD
1 43209 37462
1 42412 38043
1 42079 38002
2 56503 39923
2 50544 38033
4 47760 37239
4 48910 36976
8 51110 38065
8 53761 36297
4 48201 35548
8 54820 38036
16 39360 35409



DMD -O:

core.exception.AssertError@memcpyd.d(9): Assertion failure
----------------
??:? _d_assertp [0xc4e79cc5]
??:? pure nothrow @nogc void memcpyd.verify!(real).verify(const(real), const(real)) [0xc4e77c2c]
??:? void memcpyd.test!(real).test() [0xc4e76d60]
??:? _Dmain [0xc4e63ecd]

1 42014 26518
2 46086 26486
4 45984 29272
8 48813 26484
16 34866 18126
32 32036 18107
64 46073 20892
128 45964 27993
256 82344 50250
512 133484 94766
1024 216402 270462
2048 436465 443122
4096 815875 801596
8192 1524872 1530453
16384 3721245 3584620
32768 11776185 11739396
65536 23702074 23589480

size memcpyC memcpyD
1 37755 15424
1 40486 15319
1 40505 15352
2 47097 15653
2 46160 15319
4 43180 18110
4 46041 15321
8 46014 15342
8 46066 15341
4 43277 18105
8 45962 15321


LDC:

size memcpyC memcpyD
1 56378 48873
2 59461 49025
4 50481 45299
8 53786 49517
16 46103 39122
32 48100 46139
64 83864 67401
128 83849 90426
256 122471 138309
512 169668 228472
1024 260461 276878
2048 444937 472365
4096 860962 825468
8192 1578929 1567154
16384 3429235 3284611
32768 11941494 11868947
65536 24052536 24112980

size memcpyC memcpyD
1 47853 33403
1 47623 32924
1 48190 33100
2 59752 33146
2 59574 34371
4 53928 35042
4 54131 31991
8 57929 35864
8 57372 32174
4 54901 33253
8 62537 34535
16 52487 38358


LDC -O2:

core.exception.AssertError@memcpyd.d(9): Assertion failure
----------------
??:? _d_assert [0x7fba47d79b35]
??:? void memcpyd.test!(real).test() [0x5638cb483d6e]
??:? _Dmain [0x5638cb47ea30]
size memcpyC memcpyD
1 0 0
2 0 0
4 0 0
8 0 0
16 385 0
32 792 0
64 1542 0
128 2981 0
256 90108 0
512 126316 0
1024 217881 391419
2048 415182 620853
4096 1244805 1240074
8192 2428417 2414095
16384 4863280 4971193
32768 12968909 12966676
65536 26393408 26395410

size memcpyC memcpyD
1 0 0
1 0 0
1 0 0
2 0 0
2 0 0
4 0 0
4 0 0
8 0 0
8 0 0
4 0 0
8 0 0

On Wednesday, 13 June 2018 at 17:04:11 UTC, Ali Çehreli wrote:
>
> I am part of the D community. I haven't discriminated against anyone. I don't know what a Tor user is.
>
> I've just searched: So Tor is an old idea of mine, implemented. :o)
>
> Ali

Tor is our last line of defence against an Orson Wells future, where everyones actions are scrutinized by big brother, so that big brother can use that knowledge to put fear into, control and manipulate, those that don't conform.

assert("bad tor user" != "all tor users are bad");

(actually there are more bad non-tor users)

Unfortunately, it's becoming increasingly, the norm, to discriminate against tor users (no doubt those doing that discrimination are those that are happy to conform, of which there will be many, sadly).

https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf

On Thursday, 14 June 2018 at 02:32:51 UTC, errExit wrote:
> Tor is our last line of defence against an Orson Wells future, where everyones actions are scrutinized by big brother, so that big brother can use that knowledge to put fear into, control and manipulate, those that don't conform.
>
> assert("bad tor user" != "all tor users are bad");
>
> (actually there are more bad non-tor users)
>
> Unfortunately, it's becoming increasingly, the norm, to discriminate against tor users (no doubt those doing that discrimination are those that are happy to conform, of which there will be many, sadly).
>
> https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf

Don't mistake spammer management with discrimination. I share your frustration that TOR isn't more usable than it is today with CloudFlare etc, but coming with political reasons holds no water if the reason why it was blacklisted wasn't political in the first place. It's not false, it just won't work.

Hopefully once that particular user gets discouraged or we find a way to actually avoid user impersonification, then things will be able to come back to normal.

On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
> I had a little fun today kicking the crap out of C's memcpy with a D implementation.
>
> https://github.com/JinShil/memcpyD
>
> Request for help: I don't have a Linux system running on real hardware at this time, nor do I have a wide range of platforms and machines to test with.  If you'd like to help me with this potentially foolish endeavor, please run the program on your hardware and send me the results.
>
> Feedback, advise, and pull requests to improve the implementation are most welcome.
>
> Mike

On 8 core, 16 GB Intel Skull Candy box running Ubuntu 18.04 64 bit.

https://gist.githubusercontent.com/carun/f7c2c200b1be20d0a9489296d6601332/raw/db01bb8bc909c6048288fccc500bd15e5ee491b2/memcpyd-output.log

Hope this helps.