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.
>


Just a little remark. Alignment has also an extremely heavy impact on the performance of memcpy(). Does your test include it?

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 ignore that part.

> 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 don't? And don't even try to pretend the companies can't trivially solve the "economic" issues for themselves in an instant by knocking off the behaviour that causes loss of talent.

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 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.
>>
>
>
> Just a little remark. Alignment has also an extremely heavy impact on the performance of memcpy(). Does your test include it?

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.

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 don't? And don't even try to pretend the companies can't trivially solve the "economic" issues for themselves in an instant by knocking off the behaviour that causes loss of talent.

But that would imply that they have a frontal lobe. :)

In all seriousness, it is surprising how frequently companies seem to be incapable of making decisions that would fix a lot of their problems, and they seem to be incredibly prone to thinking about things in a shortsighted manner.

I'm reminded of an article by Joel Spoelskey where he talks about how one of the key things that a source control software solution can do to make it more likely for folks to be willing to try it is to make it easy to get your source code and history back out again and into another source control system. However, companies typically freak out at the idea of making it easy to switch from their product to another product. They're quite willing to make it easy to switch _to_ their product so that they can start making money off of you, but the idea that making it low cost to leave could actually improve the odds of someone trying their product - and thus increase their profits - seems to be beyond them.

Another case which is closer to the exact topic at hand is that many companies seem to forget how much it costs to hire someone when they consider what they should do to make it so that their employees are willing - or even eager - to stay. Spending more money on current employees (be that on salary or something else to make the workplace desirable) or avoiding practices that tick employees off so that they leave can often save money in the long run, but companies frequently ignore that fact. They're usually more interested in saving on the bottom line right now than making decisions that save money over time.

So, while I completely agree that companies can technically make decisions that solve some of their problems with things like retaining talent, it seems like it's frequently the case that they're simply incapable of doing it in practice - though YMMV; some companies are better about it than others.

- Jonathan M Davis

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 `a[] = b[]` so there is no reason to call `memcpy` directly; that is a job for the druntime.  `memcpyD` is intended to be an internal druntime utility.

However, we should still be good D citizens when we write our low level druntime code, so the interface will be `memcpy(T)(T a, T b)` and `memcpy(T)(T[] a, T[] b)` instead of `memcpy(void* a, void* b, size_t size)`.  This will ensure the code, at compile-time, adheres to D's guarantees such as `@safe`, `nothrow`, and `pure`.  And, given that it won't require `TypeInfo` it will be usable in -betterC.

Although rare, I believe it is still possible to have misaligned memory in D.  My understanding is that misaligned copies usually involve copying smaller chunks of the memory until they are aligned, and then copying the aligned memory in larger chunks.  I suspect that will work well with the D implementation.

TL;DR, Unaligned memory will be handled after optimized aligned memory copies are implemented.

Mike

On Thursday, 14 June 2018 at 20:59:06 UTC, Jonathan M Davis wrote:
> 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 don't? And don't even try to pretend the companies can't trivially solve the "economic" issues for themselves in an instant by knocking off the behaviour that causes loss of talent.
>
> But that would imply that they have a frontal lobe. :)
>
> In all seriousness, it is surprising how frequently companies seem to be incapable of making decisions that would fix a lot of their problems, and they seem to be incredibly prone to thinking about things in a shortsighted manner.
>
> I'm reminded of an article by Joel Spoelskey where he talks about how one of the key things that a source control software solution can do to make it more likely for folks to be willing to try it is to make it easy to get your source code and history back out again and into another source control system. However, companies typically freak out at the idea of making it easy to switch from their product to another product. They're quite willing to make it easy to switch _to_ their product so that they can start making money off of you, but the idea that making it low cost to leave could actually improve the odds of someone trying their product - and thus increase their profits - seems to be beyond them.
>
> Another case which is closer to the exact topic at hand is that many companies seem to forget how much it costs to hire someone when they consider what they should do to make it so that their employees are willing - or even eager - to stay. Spending more money on current employees (be that on salary or something else to make the workplace desirable) or avoiding practices that tick employees off so that they leave can often save money in the long run, but companies frequently ignore that fact. They're usually more interested in saving on the bottom line right now than making decisions that save money over time.
>
> So, while I completely agree that companies can technically make decisions that solve some of their problems with things like retaining talent, it seems like it's frequently the case that they're simply incapable of doing it in practice - though YMMV; some companies are better about it than others.

This was an interesting read on that topic, which I've linked on this forum before, where an engineer points out that companies would be better off not chasing "rockstars" with hot keywords on their resumes but improving their training, processes, and culture so that even average programmers can be productive, including mentioning using source control and the Joel test that you just referenced:

https://danluu.com/programmer-moneyball/

Of course, the reason companies mostly don't do it is they're prone to the same cognitive failings as anybody else: it's easier to chase a quick fix than doing the hard work of putting in a system like this.

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 internal druntime utility.
>
> [...]

Ok, thanks for the explanation.

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 the sender (I mean, whoever issues the certificate for S/MIME should ideally check your name, etc.) :-)

Although admittedly that'd work only for the NNTP / mailing list, I don't know how that could be adapted to the web "forum" interface...

On 06/14/2018 05:59 AM, Cym13 wrote:
> 
> 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:
> 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 isn't necessarily true. For example, `ubyte[1024].alignof == 1`, and struct alignment can also be set explicitly using align(N).

On x86, you can get away with this in a lot of cases even though it's undefined behaviour [1], but this is not necessarily the case for SSE/AVX instructions. In fact, that's probably a pretty good guess as to where those weird crashes you mentioned come from.

On other architectures, unaligned accesses might be outright unsupported.

For loading into vector registers, you can use core.simd.loadUnaligned instead (ldc.simd.loadUnaligned for LDC – LDC's druntime has not been updated yet after {load, store}Unaligned were added upstream as well).

 — David



[1] This is applying C rules to D, where creation of unaligned pointers is undefined behaviour. The D specification doesn't mention

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