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
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
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
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
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
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
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.
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:
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
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
On Sunday, 10 June 2018 at 20:10:31 UTC, Steven Schveighoffer
wrote:
-Steve
Does iopipe work with CTFE?
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? :)
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
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:
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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.
they have bugs and features
D only has features
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
https://news.ycombinator.com/item?id=17306761
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.
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
34 matches
Mail list logo
