Re: iopipe v0.1.0 - now with Windows support!
On Sunday, 17 June 2018 at 04:52:07 UTC, Martin Nowak wrote: On 06/10/2018 10:10 PM, Steven Schveighoffer wrote: Note that the new io library also supports sockets, which IODev did not have support for, AND has a pluggable driver system, so you could potentially use fiber-based async io without rebuilding. It just makes a lot of sense for D to have a standard low-level io library that everything can use without having to kludge together multiple types of io libraries. Note that the WIP std.io library is fully @nogc @safe, so it's a bit edgy on using latest features. Soon want to move to use DIP10008 instead of preallocated exceptions. This is very encouraging. I’d like to see it working well with Photon (though my time is very limited atm). Any thoughts on what set of syscalls I need to support? Maybe I could just provide my own “native” driver that fits your concept of I/O driver in io library. With that and @nogc in the Driver interface¹ it's still to be seen whether we can adapt this well with vibe.d or need to adjust the low-level design. -Martin ¹: https://martinnowak.github.io/io/std/io/driver/Driver.html
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*)(&s2)) = *(cast(const void16*)(&s1));
_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*)(&s2), loadUnaligned(cast(const
void16*)(&s1)));
_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.
