On 2018-02-06 10:51, Atila Neves wrote:

> I tried Warp on a non-trivial C codebase. It didn't work (by which I mean the code wouldn't compile with it). I don't know how clang managed to build a (for all practical purposes I can see) bug-compatible preprocessor from scratch to gcc, but it did and in large projects it makes a difference.

"gcc" on macOS is an alias to "clang". The idea was to replace GCC with Clang without having to do any changes what so every, code changes, configuration, linking, even the name of the compiler.

-- 
/Jacob Carlborg

On Tue, Feb 06, 2018 at 09:44:16PM +0000, Ralph Doncaster via Digitalmars-d wrote: [...]
> Although I'm new to D, I do know crypto quite well, and especially sha3/keccak.  One reason I considered porting was to see if dmd outputs better code than gcc.  On x86_64 with the xmm registers there is enough room for 1600 bits of the keccak state to be stored in registers, but gcc 5.4 will still use RAM for the state.  It stays in L1, but storing all the state in registers should be much faster as it would avoid a lot of mov instructions loading parts of the state into registers.

Don't have high expectations of dmd's codegen. If you're looking for highly-optimized codegen, you want to be using ldc or gdc instead. In my own projects, I routinely find that executables produced by dmd are about 30-50% slower than executables produced by gdc or ldc.

What dmd is very good at is lightning fast compilation, and also having the latest and greatest D features, being the reference compiler and all that.  However, it's optimizer leaves much to be desired.  For performance-sensitive code, my recommendation is, don't even bother with dmd.  That's not to say that dmd codegen is bad; it's pretty decent for your average non-performance-sensitive GUI app. But it doesn't hold a candle to gdc/ldc, especially when it comes to loop optimizations.


T

-- 
Дерево держится корнями, а человек - друзьями.

On Tuesday, 6 February 2018 at 21:44:16 UTC, Ralph Doncaster wrote:

> Is there an automatic way to make D wrappers for all the C function calls?

https://github.com/jacob-carlborg/dstep

On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote:
> Oh, and look what I just found:
> https://github.com/rust-lang/rust/issues/26179

Oh, look:

https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587

 — David

On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger wrote:
> On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote:
>> Oh, and look what I just found:
>> https://github.com/rust-lang/rust/issues/26179
>
> Oh, look:
>
> https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587

Ahahah, noyce! :o)

On Tuesday, 6 February 2018 at 21:44:16 UTC, Ralph Doncaster wrote:
> Is there an automatic way to make D wrappers for all the C function calls?

Yeah, I hear the dstep https://github.com/jacob-carlborg/dstep
 works well, though I haven't personally used it - I just bring in C functions by hand and that's fairly easy (certainly a lot easier than actually porting the whole thing!) and a one time thing, then it can keep up with impl updates with upstream easily - the interface rarely changes, so you just update it like anything else.

>  One reason I considered porting was to see if dmd outputs better code than gcc.

If you want D to outperform C, it usually means doing architecture changes, and mature C libraries are usually already pretty heavily optimized and hard to beat. D and C have about the same performance potential; when fully optimized by hand and by machine, both will top out about the same.

D's big advantage over C is that is is easier to realize that potential; it takes less programmer effort to write the faster code in the first place. But again, if the C library already has the work done to it, D is unlikely to actually beat it, especially with a direct port where it is likely to generate basically the same machine code (or worse - dmd's optimizer is generally worse than gcc's, and gdc's optimizer is exactly the same as gcc's).

On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger wrote:
>
> Oh, look:
>
> https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587
>
>  — David

Not gcc, no platforms, BEBEBEBEBEBE.
On the serious note: nice, good to see.

On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger wrote:
>

Apparently, GDC folks do not populate builtin module, so there's no easy way to look check it, besides actually trying to compile:
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/builtins.d#L24
A bit of a shame it's so implicit, but it will probably actually work.

On Wednesday, 7 February 2018 at 06:29:01 UTC, Boris-Barboris wrote:
> On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger wrote:
>>
>
> Apparently, GDC folks do not populate builtin module, so there's no easy way to look check it, besides actually trying to compile:
> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/builtins.d#L24
> A bit of a shame it's so implicit, but it will probably actually work.

Read the docs, not the source code. ;-)

If all types have a D equivalent, and it isn't a generic macro style built-in. Then it will be generated and pushed to the module.

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
https://gcc.gnu.org/onlinedocs/gcc/Target-Builtins.html#Target-Builtins

But indeed you do have the generate interface file trick to emit a .di of the module which will be populated with all available functions.

On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote:
> Thanks for the detailed post.  I'm an old C/C++ guy (got started with C++ back in the cfront days), and have been kicking the tires on D recently.  The poor state of libraries is something that may push me away from D as well.  In my case, need opencl and crypto libs.  The opencl package in dub is a crude wrapper around the original C API.  I couldn't find any sha lib, so I've started porting a reference sha3 implementation from C.
>
> I, like you, may end up jumping off the ship though.  I've done a bit of work with golang before, so maybe I'll take another look at it.  The opencl bindings aren't much better, but there are ready-made sha3 libs I can use instead of porting from C.

For crypto there is also Botan: http://code.dlang.org/packages/botan
https://github.com/etcimon/botan

For OpenCL I develop and maintain DCompute:
http://code.dlang.org/packages/dcompute
https://github.com/libmir/dcompute

It has a much beautified interface to OpenCL (and is mostly consistent with its CUDA interface). You can also write kernels directly in D, however this requires that LDC is built against my fork of LLVM: https://github.com/thewilsonator/llvm

It's still in dev but should be usable. Please let me know if you have issues using it.