On Tuesday, 5 July 2016 at 14:52:33 UTC, ZombineDev wrote:
> 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?

'cause even documentation says so: "The vector extensions are currently implemented for the OS X 32 bit target, and all 64 bit targets.". and this time documentation is correct.

On Tuesday, 5 July 2016 at 14:38:07 UTC, ZombineDev wrote:
> The fact core.simd exists (regardless how well it works) contradicts your statement.

Of course not. "core.simd" has been an excuse for not doing better.

> The floats problem you talk about does not affect SIMD, so to

Of course it does. You need to take same approach to floats on both scalars and vectors.

I think you are mixing up SIMD with machine language.

On Sunday, 3 July 2016 at 07:16:17 UTC, Bauss wrote:
> On Sunday, 3 July 2016 at 04:37:02 UTC, D is crap wrote:
>> [...]
>
> Say what? I have used it for multiple big projects of my own ranging from 40000-100000 lines of code?
>
> [...]

>> [...]

That's adorable. You think that's a big project :D

On 7/5/2016 9:11 AM, ketmar wrote:
> 'cause even documentation says so: "The vector extensions are currently
> implemented for the OS X 32 bit target, and all 64 bit targets.". and this time
> documentation is correct.

This is because:

1. so D can run on earlier 32 bit processors without SIMD

2. SIMD support requires the stack be aligned everywhere to 128 bits. This can be a bit burdensome for 32 bit targets.

3. (1) and (2) are not issues on OSX 32, because their memory model requires it

4. people wanting high performance are going to be using 64 bits anyway

On Tuesday, 5 July 2016 at 20:27:58 UTC, Walter Bright wrote:
> 1. so D can run on earlier 32 bit processors without SIMD

this is something programmer should check in runtime if he is using SIMD.

> 2. SIMD support requires the stack be aligned everywhere to 128 bits. This can be a bit burdensome for 32 bit targets.

but...

> 3. (1) and (2) are not issues on OSX 32, because their memory model requires it

so the code is already there, but only for osx. fun.

anyway, fixing long-standing bug with `align()` being ignored on stack variables will allow to use SIMD on x86.

> 4. people wanting high performance are going to be using 64 bits anyway

so i'm not in a set of "people". ok.

On Tuesday, 5 July 2016 at 21:44:17 UTC, ketmar wrote:
> On Tuesday, 5 July 2016 at 20:27:58 UTC, Walter Bright wrote:
>> 4. people wanting high performance are going to be using 64 bits anyway
>
> so i'm not in a set of "people". ok.

It might be a good time to think about your hardware. Btw there is a recent announcement that Ubuntu and others will drop 32-bit support quite soon.
http://slashdot.org/story/313313

Here is a copy - the same arguments apply also for performance features.

> Major Linux distributions are in agreement: it's time to stop developing new versions for 32-bit processors. Simply: it's a waste of time, both to create the 32-bit port, and to keep 32-bit hardware around to test it on. At the end of June, Ubuntu developer Dimitri Ledkov chipped into the debate with this mailing list post, saying bluntly that 32-bit ports are a waste of resources. "Building i386 images is not 'for free', it comes at the cost of utilising our build farm, QA and validation time. Whilst we have scalable build-farms, i386 still requires all packages, autopackage tests, and ISOs to be revalidated across our infrastructure." His proposal is that Ubuntu version 18.10 would be 64-bit-only, and if users desperately need to run 32-bit legacy applications, the'll have to do so in containers or virtual machines. [...] In a forum thread, the OpenSUSE Chairman account says 32-bit support "doubles our testing burden (actually, more so, do you know how hard it is to find 32-bit hardware these days?). It also doubles our build load on OBS".

On Tuesday, 5 July 2016 at 22:38:29 UTC, Seb wrote:
> On Tuesday, 5 July 2016 at 21:44:17 UTC, ketmar wrote:
>> On Tuesday, 5 July 2016 at 20:27:58 UTC, Walter Bright wrote:
>>> 4. people wanting high performance are going to be using 64 bits anyway
>>
>> so i'm not in a set of "people". ok.
>
> It might be a good time to think about your hardware. Btw there is a recent announcement that Ubuntu and others will drop 32-bit support quite soon.
> http://slashdot.org/story/313313
>
> Here is a copy - the same arguments apply also for performance features.
>
>> Major Linux distributions are in agreement: it's time to stop developing new versions for 32-bit processors. Simply: it's a waste of time, both to create the 32-bit port, and to keep 32-bit hardware around to test it on. At the end of June, Ubuntu developer Dimitri Ledkov chipped into the debate with this mailing list post, saying bluntly that 32-bit ports are a waste of resources. "Building i386 images is not 'for free', it comes at the cost of utilising our build farm, QA and validation time. Whilst we have scalable build-farms, i386 still requires all packages, autopackage tests, and ISOs to be revalidated across our infrastructure." His proposal is that Ubuntu version 18.10 would be 64-bit-only, and if users desperately need to run 32-bit legacy applications, the'll have to do so in containers or virtual machines. [...] In a forum thread, the OpenSUSE Chairman account says 32-bit support "doubles our testing burden (actually, more so, do you know how hard it is to find 32-bit hardware these days?). It also doubles our build load on OBS".

I bet it's not a hardware thing but rather an OS thing. People on windows mostly use DMD 32 bit because the 64 bit version requires MS VS environment.

Are you windows Ketmar ?

On 7/5/2016 2:44 PM, ketmar wrote:
> anyway, fixing long-standing bug with `align()` being ignored on stack variables
> will allow to use SIMD on x86.

Not really. The alignment requirement has to be done by all functions, whether they use SIMD or not.


>> 4. people wanting high performance are going to be using 64 bits anyway
> so i'm not in a set of "people". ok.

I'm curious about why you require 32 bits.

On Tuesday, 5 July 2016 at 23:56:48 UTC, Walter Bright wrote:
> On 7/5/2016 2:44 PM, ketmar wrote:
>> anyway, fixing long-standing bug with `align()` being ignored on stack variables
>> will allow to use SIMD on x86.
>
> Not really. The alignment requirement has to be done by all functions, whether they use SIMD or not.
>

The intel performance optimization manual have some nice trick to mix code with different stack alignment.

You may want to check that out. Sadly, I can't find the article right now, but mostly it boils down to :
 - as the stack grow down, you can mask the stack pointer at function entry to get it aligned.
 - If both caller and callee both need alignment, callee can call/jump over the masking instructions directly into the meat of the callee.

On Tuesday, 5 July 2016 at 23:50:35 UTC, Basile B. wrote:
>>> Major Linux distributions...
...
> Are you windows Ketmar ?

no. GNU/Linux here. and i don't care what shitheads from "major linux distributions" may think.