Re: Encouraging preliminary results implementing memcpy in D
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
Re: Encouraging preliminary results implementing memcpy in D
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; 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).
Yes, I'm already aware of that. My plan is to create optimized
implementations for aligned data, and then handled unaligned data
as compositions of the various aligned implementations. For
example a 3 byte copy would be a short copy plus a byte copy.
That may not be appropriate for all cases. I'll have to measure,
and adapt.
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.
Thanks! I think you're right.
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).
Unfortunately the code gen is quite a bit worse:
Exibit A:
https://run.dlang.io/is/jIuHRG
*(cast(void16*)()) = *(cast(const void16*)());
_Dmain:
pushRBP
mov RBP,RSP
sub RSP,020h
lea RAX,-020h[RBP]
xor ECX,ECX
mov [RAX],RCX
mov 8[RAX],RCX
lea RDX,-010h[RBP]
mov [RDX],RCX
mov 8[RDX],RCX
movdqa XMM0,-020h[RBP]
movdqa -010h[RBP],XMM0
xor EAX,EAX
leave
ret
add [RAX],AL
.text._Dmainends
Exhibit B:
https://run.dlang.io/is/PLRfhW
storeUnaligned(cast(void16*)(), loadUnaligned(cast(const
void16*)()));
_Dmain:
pushRBP
mov RBP,RSP
sub RSP,050h
lea RAX,-050h[RBP]
xor ECX,ECX
mov [RAX],RCX
mov 8[RAX],RCX
lea RDX,-040h[RBP]
mov [RDX],RCX
mov 8[RDX],RCX
mov -030h[RBP],RDX
mov -010h[RBP],RAX
movdqu XMM0,[RAX]
movdqa -020h[RBP],XMM0
movdqa XMM1,-020h[RBP]
movdqu [RDX],XMM1
xor EAX,EAX
leave
ret
add [RAX],AL
.text._Dmainends
If the code gen was better, that would definitely be the way to
go; to have unaligned and aligned share the same implementation.
Maybe I can fix the DMD code gen, or implement a `copyUnaligned`
intrinsic.
Also, there doesn't seem to be any equivalent 32-byte
implementations in `core.simd`. Is that just because noone's
bother to implement them yet? And with AVX512, we should
probably have 64-byte implementations as well.
Mike
emeralD - Command-line tool for template files
emeralD is a command-line tool for template files that can be used to generate code files, configurations etc. It's a very useful tool for generating files that you'd normally have to create by hand. The idea for emeralD was not actually by me, but by Moogly (I don't know what he goes by in the forums, if he uses them.) who wanted something to generate files for ex. vibe.d and Diamond. Also additionally thanks to 0xEAB for a few ideas. emeralD is generic and not tied to D files only, but can be used for any type of file within any programming language. For more information see the Github repository and for examples see the read me. Github: https://github.com/DiamondMVC/emeralD Thank you!
Re: detectcycles: A source code dependency cycle checker
I did not mention it in the README, but the tred filter used in https://code.dlang.org/packages/depend complains about cyclic dependencies. I am currently working on a branch, where the transitive reduction and the corresponding warnings are built in. While this tool is for D only, it also allows to visualize and to check dependencies.
Re: Encouraging preliminary results implementing memcpy in D
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
Re: Encouraging preliminary results implementing memcpy in D
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
detectcycles: A source code dependency cycle checker
https://github.com/vnayar/detectcycles I made a small configurable tool to detect software source dependency cycles that is configurable to use for most languages. By default, C++, Java, and D are supported, but add new languages is as simple as adding a few lines to JSON configuation file. I often work on very large software projects in various different languages, and sometimes you walk onto projects that were large long before you got there. Part of my work involves re-architecting and breaking apart monolithic code bases, and knowing which components have been tied together as a block is useful for a quick analysis and helps show me where I need to focus my attention. Hopefully other people find it useful as well.
Re: Beta 2.081.0
On Sunday, 17 June 2018 at 05:20:51 UTC, Manu wrote: The biggest highlight in this release for C++ users like myself is a huge amount of work relating to extern(C++). I think this is the biggest step forward since it was introduced in 2012. Mixed-language class hierarchies are now supported, and a whole raft of long-standing ABI issues have been worked out, making construction and destruction semantics compatible between languages. No more work-arounds for virtual destructors, or factory-style 'create' functions are required. It's still an amazing progress! Thank you!! I was planning to make this change to the release notes before the next release, but I had no idea a release was imminent. Are there announcements ahead of the release branch being tagged? https://dlang.org/changelog/release-schedule.html Anyway, if we could see that those patches are integrated into 2.081, that'd be very excellent. Targeting stable and getting it merged before the final 2.081 release (in two weeks) should be all you need. (The beta release announcement [1] would be updated too, but as it probably will be regenerated over the course of the beta period and will be removed once the beta period is over, it's not that important.) [1] https://github.com/dlang/dlang.org/blob/master/changelog/2.081.0_pre.dd
