On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson wrote:
> On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote:
>> 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

That looks more promising.  Strange that it doesn't show up when searching for sha or sha3.
https://code.dlang.org/search?q=sha3

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

I saw your library before, but it looked like it is ONLY for native D on GPUs.  I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.

On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster wrote:
> On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson wrote:
>> 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.
>
> I saw your library before, but it looked like it is ONLY for native D on GPUs.  I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.

p.s. since you seem to be a green team guy, you might not know that llvm optimization sucks on AMD.  I use -legacy when building my kernels to get the good old compiler.

On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster wrote:
> On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster wrote:
>> On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson wrote:
>>> 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.
>>
>> I saw your library before, but it looked like it is ONLY for native D on GPUs.  I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.

Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work.

> p.s. since you seem to be a green team guy, you might not know that llvm optimization sucks on AMD.  I use -legacy when building my kernels to get the good old compiler.

"green team guy"?

It that with the OpenCL C compiler? DCompute goes through SPIR-V for OpenCL (although it would be nice to support SPIR. Unfortunately the official version SPIR 2.0 is based of is not supported by LDC), I dont know if this makes a difference.
It would be nice to eventually support AMDGCN et. al. at some point but I don't have the time at the moment.

On Thursday, 8 February 2018 at 15:59:28 UTC, Nicholas Wilson wrote:
> On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster wrote:
>> On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster wrote:
>>> On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson wrote:
>>>> 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.
>>>
>>> I saw your library before, but it looked like it is ONLY for native D on GPUs.  I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.
>
> Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work.

OK, maybe I'll take a closer look.

>> p.s. since you seem to be a green team guy, you might not know that llvm optimization sucks on AMD.  I use -legacy when building my kernels to get the good old compiler.
>
> "green team guy"?
>
> It that with the OpenCL C compiler?

nVidia's logo is green, while AMD's logo is often red.
On Linux with AMDGPU-Pro 17 and up, the driver uses llvm/amdgpu.  The driver still has the old gcc-based? compiler.  The old compiler can be selected with clBuildProgram using the option "-legacy".

On Thursday, 8 February 2018 at 17:24:31 UTC, Ralph Doncaster wrote:
> On Thursday, 8 February 2018 at 15:59:28 UTC, Nicholas Wilson wrote:
>> On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster wrote:
>>> On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster wrote:
>>>> On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson wrote:
>>>>> 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.
>>>>
>>>> I saw your library before, but it looked like it is ONLY for native D on GPUs.  I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C.
>>
>> Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work.
>
> OK, maybe I'll take a closer look.
>
>>> p.s. since you seem to be a green team guy, you might not know that llvm optimization sucks on AMD.  I use -legacy when building my kernels to get the good old compiler.
>>
>> "green team guy"?
>>
>> It that with the OpenCL C compiler?
>
> nVidia's logo is green, while AMD's logo is often red.

Ah, I have no affiliation with any of the hardware vendors. The only reason DCompute supports CUDA is LLVM has a backend for it and I thought "it can't be too hard". I test (not nearly as frequently as I should) on a rather old  Intel CPU and very old (CC2.1) Nvidia card, simply due to availability (i.e. I had them before I started). CI Testing is on my list of things to do but I just haven't got around to it yet.

> On Linux with AMDGPU-Pro 17 and up, the driver uses llvm/amdgpu.  The driver still has the old gcc-based? compiler.
>  The old compiler can be selected with clBuildProgram using the option "-legacy".

Unfortunately I can't help much there but I should definitely test (and optimise) with AMD.
Hopefully it catches up with the legacy one because DCompute is currently tied to LDC and hence LLVM. The mainlining of polly, region vectoriser and VPlan should boost perf all round.

On 2/6/2018 1:51 AM, 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.

Warp successfully compiles all of Boost, including their advanced preprocessor metaprogramming library. So it's very, very compatible. If you have something that didn't work, I suspect it is because the user-defined list of predefined macros supplied to Warp wasn't correct.

If that wasn't it, I'd appreciate it if you could boil down what went wrong.