On Tuesday, 5 July 2016 at 06:38:18 UTC, ketmar wrote:
> On Tuesday, 5 July 2016 at 06:27:17 UTC, Ola Fosheim Grøstad wrote:
>> Sounds like a good project. A non-optimizing backend that retains type information and asserts could be very useful. And keeping it simple is valuable, it makes it easier for others to understand the front-end/back-end connection.
>
> but... but it IS optimizing backend! once i have SSA, i can do alot of optimizations on that -- i just didn't implemented 'em all, but it doesn't matter. and any such optimizations are completely independent of frontend code anyway.

Ohoh, sorry :-) But quite frankly, good SIMD support is more important to me than a good optimizer. So if you extend aliced with good SIMD support and do it well in the backend then it could take off, IMO.

On Tuesday, 5 July 2016 at 06:44:55 UTC, Ola Fosheim Grøstad wrote:
> Ohoh, sorry :-) But quite frankly, good SIMD support is more important to me than a good optimizer. So if you extend aliced with good SIMD support and do it well in the backend then it could take off, IMO.

heh. that is something i completely don't care about. but still, it is doable from within SSA engine too! you actually can write vectorization pass over SSA.

On Tuesday, 5 July 2016 at 06:44:55 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 5 July 2016 at 06:38:18 UTC, ketmar wrote:
>> On Tuesday, 5 July 2016 at 06:27:17 UTC, Ola Fosheim Grøstad wrote:
>>> Sounds like a good project. A non-optimizing backend that retains type information and asserts could be very useful. And keeping it simple is valuable, it makes it easier for others to understand the front-end/back-end connection.
>>
>> but... but it IS optimizing backend! once i have SSA, i can do alot of optimizations on that -- i just didn't implemented 'em all, but it doesn't matter. and any such optimizations are completely independent of frontend code anyway.
>
> Ohoh, sorry :-) But quite frankly, good SIMD support is more important to me than a good optimizer. So if you extend aliced with good SIMD support and do it well in the backend then it could take off, IMO.

https://gist.github.com/9il/a167e56d7923185f6ce253ee14969b7f
https://gist.github.com/9il/58c1b80110de2db5f2eff6999346a928

available today with LDC ;)

See also https://github.com/ldc-developers/ldc/issues/1438

On Tuesday, 5 July 2016 at 09:23:42 UTC, ZombineDev wrote:
> https://gist.github.com/9il/a167e56d7923185f6ce253ee14969b7f
> https://gist.github.com/9il/58c1b80110de2db5f2eff6999346a928
>
> available today with LDC ;)

I meant good manual SIMD support in the language, not vectorization.

On Tuesday, 5 July 2016 at 09:51:01 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 5 July 2016 at 09:23:42 UTC, ZombineDev wrote:
>> https://gist.github.com/9il/a167e56d7923185f6ce253ee14969b7f
>> https://gist.github.com/9il/58c1b80110de2db5f2eff6999346a928
>>
>> available today with LDC ;)
>
> I meant good manual SIMD support in the language, not vectorization.

On that note, I made this to use the Intel intrinsic names:
https://github.com/p0nce/intel-intrinsics

On Tuesday, 5 July 2016 at 09:51:01 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 5 July 2016 at 09:23:42 UTC, ZombineDev wrote:
>> https://gist.github.com/9il/a167e56d7923185f6ce253ee14969b7f
>> https://gist.github.com/9il/58c1b80110de2db5f2eff6999346a928
>>
>> available today with LDC ;)
>
> I meant good manual SIMD support in the language, not vectorization.

Have you put any enhancement request on https://issues.dlang.org or written a DIP? If not, I can guarantee with almost 100% that it will not get worked because no one knows what you need. If you really want good SIMD support in D, you should look at https://dlang.org/spec/simd.html and the list of intrinsics that GDC and LDC  provide and write a list of things that you find missing in terms of language support. Otherwise your claims are vague and non-actionable.

On Tuesday, 5 July 2016 at 11:27:33 UTC, ZombineDev wrote:
> https://dlang.org/spec/simd.html and the list of intrinsics

core.simd is completely unusable on any 32-bit targets except hipsteros.

On Tuesday, 5 July 2016 at 11:27:33 UTC, ZombineDev wrote:
> Have you put any enhancement request on https://issues.dlang.org or written a DIP? If not, I can guarantee with almost 100% that it will not get worked because no one knows what you need.

SIMD support has been discussed and shot down before. I don't need anything and see no point in a DIP SIMD before getting floats fixed.

But it would make the language more attractive.

On Tuesday, 5 July 2016 at 12:59:27 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 5 July 2016 at 11:27:33 UTC, ZombineDev wrote:
>> Have you put any enhancement request on https://issues.dlang.org or written a DIP? If not, I can guarantee with almost 100% that it will not get worked because no one knows what you need.
>
> SIMD support has been discussed and shot down before.

The fact core.simd exists (regardless how well it works) contradicts your statement. I still can't see what *you* find missing in the current implementation. Do you have any particular SIMD enhancement request that was declined?

The floats problem you talk about does not affect SIMD, so to me it seems that your just looking for excuses for not working on a solid proposal.

On Tuesday, 5 July 2016 at 12:40:57 UTC, ketmar wrote:
> On Tuesday, 5 July 2016 at 11:27:33 UTC, ZombineDev wrote:
>> https://dlang.org/spec/simd.html and the list of intrinsics
>
> core.simd is completely unusable on any 32-bit targets except hipsteros.

Why? I only found this issue:
https://issues.dlang.org/show_bug.cgi?id=16092