Re: D only has Advantages
On Thursday, 14 June 2018 at 04:11:37 UTC, Anton Fediushin wrote: they have bugs and features D only has features that's because in D, bugs are actually features.
Re: D only has Advantages
they have bugs and features D only has features
Re: Encouraging preliminary results implementing memcpy in D
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.
Re: Arrogant - HTML5 dom with CSS selectors
On 06/13/2018 02:25 PM, Andrea Fontana wrote: On Wednesday, 13 June 2018 at 18:06:02 UTC, Nick Sabalausky (Abscissa) wrote: Does this mean that it requires the raw HTML input to already be fully conformant HTML5 or simply that it supports and outputs valid HTML5? The second one. If you parse invalid html it tries to fix it and output valid html5. And that it can parse correctly any valid html5 syntax. Or at least it should! Awesome. I'll have to check it out.
Re: Encouraging preliminary results implementing memcpy in D
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
D only has Advantages
https://news.ycombinator.com/item?id=17306761
Re: Encouraging preliminary results implementing memcpy in D
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
Re: Arrogant - HTML5 dom with CSS selectors
On Wednesday, 13 June 2018 at 18:06:02 UTC, Nick Sabalausky (Abscissa) wrote: Does this mean that it requires the raw HTML input to already be fully conformant HTML5 or simply that it supports and outputs valid HTML5? The second one. If you parse invalid html it tries to fix it and output valid html5. And that it can parse correctly any valid html5 syntax. Or at least it should! Andrea
Re: Arrogant - HTML5 dom with CSS selectors
On 06/13/2018 09:23 AM, Andrea Fontana wrote: > On behalf of the company I work for [1] today I released a new library: > arrogant. > Nice! It is a fully conformant HTML5 dom library with CSS selectors. Does this mean that it requires the raw HTML input to already be fully conformant HTML5 or simply that it supports and outputs valid HTML5?
Re: Encouraging preliminary results implementing memcpy in D
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
Re: Encouraging preliminary results implementing memcpy in D
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
Re: iopipe v0.1.0 - now with Windows support!
On 6/13/18 12:03 PM, Steven Schveighoffer wrote: I'm going to push this (I'll do some tests for the other widths to make sure it works for all UTF), but if you have any more things you want to work at CTFE, submit some issues on the github project. v0.1.2 released -Steve
Re: iopipe v0.1.0 - now with Windows support!
On 6/13/18 8:35 AM, bauss wrote:
Does iopipe work with CTFE?
It may work in some cases. Some of the things it does are not conducive
to CTFE working well -- like using a buffer. But generally at compile
time, you don't want to use a buffer.
But I would expect, for instance, using algorithms and iopipes on a
string would probably work.
hm... just thought I'd try it:
import std.range : walkLength;
static
assert("hello\nworld\nthis\nis\na\ntest".byLineRange.walkLength == 6);
It didn't work at first, as I'm using memchr for searching for the
newlines, but with a nice little if(__ctfe) override, it works just great!
I'm going to push this (I'll do some tests for the other widths to make
sure it works for all UTF), but if you have any more things you want to
work at CTFE, submit some issues on the github project.
I don't expect a lot of the array casting stuff to work, but maybe there
are ways. I actually never thought much about making it work at
compile-time. I suppose though, it would be cool to import a file at
compile time, and generate the JSON or XML DOM at compile time too :)
I think zip and unzip are never going to work since the underlying C
calls are not CTFE-able.
-Steve
Re: Encouraging preliminary results implementing memcpy in D
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 ..
Re: Encouraging preliminary results implementing memcpy in D
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
Arrogant - HTML5 dom with CSS selectors
On behalf of the company I work for [1] today I released a new library: arrogant. It is a fully conformant HTML5 dom library with CSS selectors. It wraps Modest library [2] by Alexander Borisov that is a quite bigger library/framework. As pointed out promptly by rikkimax [3] it doesn't rely on dynamic loading of modest but it links it during building. So you need to compile modest (not a big effort, is a plain C library without external dependencies) as prerequisite (check readme on github). It is in its early days so any help / pull request / opened issue / benchmark / suggestion are welcome. Developed and tested on Linux. Should work fine on OSX. Never tried on windows. GitHub: https://github.com/2night/arrogant/ Documentation: https://arrogant.dpldocs.info/index.html Dub: https://arrogant.dub.pm [1] http://lab.2night.it [2] https://github.com/lexborisov/Modest [3] https://github.com/2night/arrogant/issues/1 Andrea Fontana
Re: Encouraging preliminary results implementing memcpy in D
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
Re: Encouraging preliminary results implementing memcpy in D
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]
Re: Aalborg D meetup
On Wednesday, 13 June 2018 at 12:12:11 UTC, bauss wrote: I'll be there since I live there and would be nice to see monthly meetups! :) I forgot to ask. Is it free entry? :)
Re: iopipe v0.1.0 - now with Windows support!
On Sunday, 10 June 2018 at 20:10:31 UTC, Steven Schveighoffer wrote: -Steve Does iopipe work with CTFE?
Re: Aalborg D meetup
On Wednesday, 13 June 2018 at 11:17:15 UTC, biocyberman wrote: Reminded by Mike with Seoul D meetup (https://forum.dlang.org/thread/fvswwfcbuuqkaqpmp...@forum.dlang.org) I will unleash my excitement to tell you that we are going to have first D meetup at Aalborg, Denmark 21st June: https://www.meetup.com/AalborgD-Programming-Language/events/251102967/ Ali Cehreli is going to give a lecture about "Introduction to D programming language". It is a excellent opportunity for someone new to D. We plan to make monthly meetup. The meetups intention is to exchange knowledge, and teach each other so that members have better understanding of D and programming, thereby be more productive, more fun to work with D and your tasks. With that in mind, the meetups will be more of a 'tutorial' style than 'show-off' style. So we will be helpful to each other. We invite all D enthusiasts, experts and professionals to join us to teach and learn. I'll be there since I live there and would be nice to see monthly meetups! :)
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 08:55:40 UTC, drug wrote: Ubuntu 18.04 Linux 4.15.0-23-generic AMD® Fx(tm)-8350 eight-core processor × 8 size memcpyC memcpyD 1 51089 36921 2 45896 35733 4 46079 36200 8 48443 37509 16 48669 24925 32 52917 27787 64 55631 44928 128 84282 47795 256 107350 66009 512 159310 126795 1024 247683 452560 2048 440687 673211 4096 1129135 1304085 8192 4740910 4095254 16384 8389579 8874273 32768 16630336 17370310 65536 33032013 42904705 size memcpyC memcpyD 1 52354 28365 1 48407 28445 1 50264 30273 2 51312 27708 2 46138 28973 4 52753 28535 4 52150 27418 8 52220 27276 8 49625 27804 4 49356 33510 8 48529 27668 16 52662 135357 Interesting! I have an AMD 8370 running Windows 8, and I get more favorable results in Windows: size memcpyC memcpyD 1 45361 43626 2 55091 43791 4 70507 43714 8 50910 42854 16 63328 28831 32 72817 30790 64 76307 45823 128 97180 55368 256 164935 68362 512 230508 132100 1024 502189 490590 2048 892968 823070 4096 1896480 1456353 8192 4530645 4516681 16384 10886602 9921215 32768 21717080 19116839 65536 59787610 43549445 size memcpyC memcpyD 1 48770 30084 1 49169 30921 1 43370 30144 2 51404 27571 2 56002 29729 4 69588 29804 4 63743 29510 8 55492 29002 8 46752 31793 4 72673 28858 8 48989 27547 10 55527 121628 In your results, I see that for sizes 1024 and higher (that's when is dispatches to the REP MOVSB algorithm), the performance begins to degrade for Linux. I'm going to install Linux soon and see if I can fix that. Thanks for the data, Mike
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 10:17:10 UTC, Mike Franklin wrote: Well, actually, I probably should divide that time by 10,000,000 to make a more accurate representation. For rigorous benchmarking, check out the first part of Andrei's Writing Fast Code: https://www.youtube.com/watch?v=vrfYLlR8X8k One takeaway is that taking the average of many runtimes is not the best use of your dataset.
Aalborg D meetup
Reminded by Mike with Seoul D meetup (https://forum.dlang.org/thread/fvswwfcbuuqkaqpmp...@forum.dlang.org) I will unleash my excitement to tell you that we are going to have first D meetup at Aalborg, Denmark 21st June: https://www.meetup.com/AalborgD-Programming-Language/events/251102967/ Ali Cehreli is going to give a lecture about "Introduction to D programming language". It is a excellent opportunity for someone new to D. We plan to make monthly meetup. The meetups intention is to exchange knowledge, and teach each other so that members have better understanding of D and programming, thereby be more productive, more fun to work with D and your tasks. With that in mind, the meetups will be more of a 'tutorial' style than 'show-off' style. So we will be helpful to each other. We invite all D enthusiasts, experts and professionals to join us to teach and learn.
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 09:07:21 UTC, ToRuSer wrote: 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 All Tor users now apparently have their posts subjected to 'moderation'. (i.e. someone, will, perhaps, at some point, get around to reviewing their posts, and then, perhaps, it might reach the forum, or not.) So... maybe..you'll get those posts...or maybe not...and when.. is anyones guess. So well done to the D community, for discriminating against all the Tor users out there. You've done yourself proud. The problem is likely more that someone has used Tor to troll here and then the enpoint used was blacklisted.
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 10:13:13 UTC, Dukc wrote: On Wednesday, 13 June 2018 at 09:59:52 UTC, Mike Franklin wrote: The benchmark doesn't allocate any data; it's just copying data. Mike Ah of course. I was thinking other stuff while writing. Well, actually, I probably should divide that time by 10,000,000 to make a more accurate representation. Thanks for the feedback, Mike
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 09:59:52 UTC, Mike Franklin wrote: The benchmark doesn't allocate any data; it's just copying data. Mike Ah of course. I was thinking other stuff while writing.
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 09:40:05 UTC, Dukc wrote: If I read your benchmark graphs right, they claimed that allocating 16 kilobytes takes over 10^^6 usecs, with both mallocs. Doesn't that mean over a second, 16 kilobytes? Can't be! Are you confusing usecs with nsecs? The benchmark doesn't allocate any data; it's just copying data. Each benchmark is run 10,000,000 times to smooth out some of the entropy in the results: https://github.com/JinShil/memcpyD/blob/2e0d3c33ea876a25a04358a3ae505b2eba9f99cb/memcpyd.d#L78 The usecs in the graph is the time it takes to run the benchmark 10,000,000 times. Mike
Re: Encouraging preliminary results implementing memcpy in D
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. If I read your benchmark graphs right, they claimed that allocating 16 kilobytes takes over 10^^6 usecs, with both mallocs. Doesn't that mean over a second, 16 kilobytes? Can't be! Are you confusing usecs with nsecs?
Re: Encouraging preliminary results implementing memcpy in D
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 All Tor users now apparently have their posts subjected to 'moderation'. (i.e. someone, will, perhaps, at some point, get around to reviewing their posts, and then, perhaps, it might reach the forum, or not.) So... maybe..you'll get those posts...or maybe not...and when.. is anyones guess. So well done to the D community, for discriminating against all the Tor users out there. You've done yourself proud.
Re: Encouraging preliminary results implementing memcpy in D
Ubuntu 18.04 Linux 4.15.0-23-generic AMD® Fx(tm)-8350 eight-core processor × 8 size memcpyC memcpyD 1 51089 36921 2 45896 35733 4 46079 36200 8 48443 37509 16 48669 24925 32 52917 27787 64 55631 44928 128 84282 47795 256 107350 66009 512 159310 126795 1024 247683 452560 2048 440687 673211 4096 1129135 1304085 8192 4740910 4095254 16384 8389579 8874273 32768 16630336 17370310 65536 33032013 42904705 size memcpyC memcpyD 1 52354 28365 1 48407 28445 1 50264 30273 2 51312 27708 2 46138 28973 4 52753 28535 4 52150 27418 8 52220 27276 8 49625 27804 4 49356 33510 8 48529 27668 16 52662 135357 second run size memcpyC memcpyD 1 47248 36964 2 45624 35627 4 45535 35596 8 47920 37012 16 47960 25107 32 52798 27394 64 55444 44282 128 76819 41055 256 105852 66429 512 157629 126243 1024 253841 448974 2048 438973 667101 4096 1144280 1337549 8192 3647558 4141162 16384 8301059 8722185 32768 16413116 17506957 65536 32958933 40381270 size memcpyC memcpyD 1 48513 26288 1 46080 26842 1 48526 26989 2 48634 26419 2 43522 27150 4 48229 25737 4 52841 28117 8 49632 25913 8 46325 25487 4 40267 32343 8 45990 25220 16 46509 124042
Re: Encouraging preliminary results implementing memcpy in D
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. Hi Mike, These are my results running your program under archlinux x86_64 with the zen-kernel 4.17.1, the hardware is powered by an ancient "Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz" with 4GB of ram: size memcpyC memcpyD 1 67607 56810 2 68105 57638 4 66760 58949 8 66943 61262 16 71937 43821 32 70955 48392 64 111473 54226 128 144784 77165 256 183504 113597 512 289039 180930 1024 450526 1314835 2048 782029 1890236 4096 1627622 3165319 8192 2751701 5614202 16384 6361074 11484517 32768 30931212 42805529 65536 61878379 86000892 size memcpyC memcpyD 1 66796 44745 1 66773 44343 1 66780 44157 2 66769 44370 2 66792 44529 4 66776 44298 4 66775 44412 8 66766 44409 8 70945 44359 4 66804 44367 8 71007 44432 16 75210 50656
Re: iopipe v0.1.0 - now with Windows support!
On Tuesday, 12 June 2018 at 14:00:32 UTC, Steven Schveighoffer wrote: File.byLine is fast, but only because of the underlying non-range tricks it uses to achieve performance. And iopipe still is 2x faster. I wish iopipe was around a little bit earlier so I could use it in my small project. It doesn't use IO much, just reads large file (60GB+) and computes some hashes. Now I'd like to rewrite it using iopipe just to compare the performance.
Encouraging preliminary results implementing memcpy in D
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
