On Monday, 18 June 2018 at 02:31:25 UTC, Mike Franklin wrote:
Unfortunately the code gen is quite a bit worse:
Scratch that. If compiling with -O it seems to do the right
thing.
Mike
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote:
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
https://github.com/JinShil/memcpyD
[…]
Feedback, advise, and pull requests to improve the
implementation are most welcome.
The memcpyD implementation is buggy;
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote:
core.simd.loadUnaligned instead
Ah, well… https://issues.dlang.org/show_bug.cgi?id=19001
— David
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
https://github.com/JinShil/memcpyD
[…]
Feedback, advise, and pull requests to improve the
implementation are most welcome.
The memcpyD implementation is buggy; it assumes that all
arguments are aligned to their size. This
Well, e-mail was never meant to be reliable or secure... BTW, there are
already solutions to prevent impersonation: sign the messages with
either PGP or S/MIME... the former is more decentralised, and the later
usually comes together with stronger verifications, like personal
identification of
On Friday, 15 June 2018 at 00:15:35 UTC, Mike Franklin wrote:
On Thursday, 14 June 2018 at 20:35:23 UTC, baz wrote:
[...]
Correct! D already has features like `a[] = b[]` so there is no
reason to call `memcpy` directly; that is a job for the
druntime.
`memcpyD` is intended to be an
On Thursday, 14 June 2018 at 20:35:23 UTC, baz wrote:
I asked on IRC yesterday and actually tHose memcpy are not the
memcpy we use to copy wide chunks, apparently it's rather for
an internal druntime thing, i.e cpy type to type so likely
always aligned.
Correct! D already has features like
On Thursday, June 14, 2018 16:04:32 Nick Sabalausky via Digitalmars-d-
announce wrote:
> On 06/14/2018 05:01 AM, AnotherTorUser wrote:
> > If all such people stopped working for such companies, what do you think
> > the economic impact would be?
>
> What do you think is the social impact if they
On Thursday, 14 June 2018 at 17:27:27 UTC, Patrick Schluter 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
On 06/14/2018 05:01 AM, AnotherTorUser wrote:
sorry. but what world do you live in?
Note this part of what I said:
>> If I worked in such an organization that tracked its employees
>> activities *outside the workplace*
That part is KEY, but it sounds like you an errExit have chosen 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 Thursday, 14 June 2018 at 13:42:14 UTC, Steven Schveighoffer
wrote:
Well, for me, it wasn't attacks. There have been quite a few
people in this community who were rude, insulting, and IMO,
that is not worth moderation. In fact some of them have even
came around and become quite good D
On Thursday, 14 June 2018 at 07:54:20 UTC, Jonathan M Davis wrote:
On Wednesday, June 13, 2018 14:34:28 Uknown via
Digitalmars-d-announce wrote:
Looks very promising. One question though, why not use
std.datetime.stopwatch.benchmark? I think it has some
protection against optimizing compilers
On 6/14/18 9:31 AM, rikki cattermole wrote:
On 15/06/2018 1:22 AM, Steven Schveighoffer wrote:
It's really the impersonation that is the problem, not the anonymity.
If you just would stick to one persona, and especially not impersonate
people who actually post on this forum, you would not have
On 15/06/2018 1:22 AM, Steven Schveighoffer wrote:
It's really the impersonation that is the problem, not the anonymity. If
you just would stick to one persona, and especially not impersonate
people who actually post on this forum, you would not have to use Tor at
all, and the forum moderators
On 6/13/18 10:32 PM, errExit wrote:
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
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 Thursday, 14 June 2018 at 07:19:31 UTC, Nick Sabalausky
(Abscissa) wrote:
I'm with you on a lot of that, however, this part troubles me:
"This becomes problematic for those of us who work in 'certain
organisations', that insist on tracking it's employees online
activities (even outside of
On Thursday, 14 June 2018 at 07:19:31 UTC, Nick Sabalausky
(Abscissa) wrote:
I'm with you on a lot of that, however, this part troubles me:
"This becomes problematic for those of us who work in 'certain
organisations', that insist on tracking it's employees online
activities (even outside of
On Thursday, 14 June 2018 at 07:45:15 UTC, Joakim wrote:
Tor is merely one tool used to route around those building
centralized systems on top of the internet. The real solution
is that as more and more decentralized tech does well, like git
or cryptocurrencies, to get rid of these obsolete
On Wednesday, June 13, 2018 14:34:28 Uknown via Digitalmars-d-announce
wrote:
> 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
On Thursday, 14 June 2018 at 02:32:51 UTC, errExit wrote:
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.
On 06/14/2018 02:34 AM, errExit wrote:
The D Foundation now subjects all users having an ip originating from a
tor exit node, to having their posts moderated (but by whom, when, how,
criteria ?? etc).
Literally millions of people could, and probably would, be using that
exit node.
So
On Thursday, 14 June 2018 at 03:59:47 UTC, Cym13 wrote:
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
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 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.
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
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
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 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 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.
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 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 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 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 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 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 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 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.
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 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
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
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
45 matches
Mail list logo
