On Friday, 6 November 2015 at 01:17:20 UTC, TheFlyingFiddle wrote:
> On Friday, 6 November 2015 at 00:43:49 UTC, rsw0x wrote:
>> On Thursday, 5 November 2015 at 23:37:45 UTC, TheFlyingFiddle wrote:
>>> On Thursday, 5 November 2015 at 21:24:03 UTC, TheFlyingFiddle wrote:
>>>> [...]
>>>
>>> I reduced it further:
>>>
>>> [...]
>>
>> these run at the exact same speed for me and produce identical assembly output from a quick glance
>> dmd 2.069, -O -release -inline
>
> Are you running on windows?
>
> I tested on windows x64 and there I also get the exact same speed for both functions.

linux x86-64

Ok, benchA and benchB have the same assembler code generated. However, I _can_ reproduce the slowdown albeit on average only 20%-40%, not a factor of 10.

It turns out that it's always the first tested function that's slower. You can test this by switching benchA and benchB in the call to benchmark(). I suspect the reason is that the OS is paging in the code the first time, and we're actually seeing the cost of the page fault. If you a second round of benchmarks after the first one, that one shows more or less the same performance for both functions.

On Friday, 6 November 2015 at 11:37:22 UTC, Marc Schütz wrote:
> Ok, benchA and benchB have the same assembler code generated. However, I _can_ reproduce the slowdown albeit on average only 20%-40%, not a factor of 10.

Forgot to add that this is on Linux x86_64, so that probably explains the difference.

>
> It turns out that it's always the first tested function that's slower. You can test this by switching benchA and benchB in the call to benchmark(). I suspect the reason is that the OS is paging in the code the first time, and we're actually seeing the cost of the page fault. If you a second round of benchmarks after the first one, that one shows more or less the same performance for both functions.

On Friday, 6 November 2015 at 11:38:29 UTC, Marc Schütz wrote:
> On Friday, 6 November 2015 at 11:37:22 UTC, Marc Schütz wrote:
>> Ok, benchA and benchB have the same assembler code generated. However, I _can_ reproduce the slowdown albeit on average only 20%-40%, not a factor of 10.
>
> Forgot to add that this is on Linux x86_64, so that probably explains the difference.
>
>>
>> It turns out that it's always the first tested function that's slower. You can test this by switching benchA and benchB in the call to benchmark(). I suspect the reason is that the OS is paging in the code the first time, and we're actually seeing the cost of the page fault. If you a second round of benchmarks after the first one, that one shows more or less the same performance for both functions.

I tested swapping around the functions on windows x86 and I still get the same slowdown with the default initializer. Still basically the same running speed of both functions on windows x64. Interestingly enough the slowdown disappear if I add another float variable to the structs. This causes the assembly to change to using different instructions so I guess that is why. Also it only seems to affect small structs with floats in them. If I change the memebers to int both versions run at the same speed on x86 aswell.

I did some testing on Linux and Windows.
I ran the code with ten times the iterations, and found the results consistent with what has previously been observed in this thread.
The code seems to run just fine on Linux, but is slowed down 10x on Windows x86.


Windows (32-bit)

rdmd bug.d -inline -boundscheck=off -release
Default:  TickDuration(14398890)
Explicit: TickDuration(168888)


Linux (64-bit)

rdmd bug.d -m64 -inline -boundscheck=off
Default:  TickDuration(59090876)
Explicit: TickDuration(49529493)


Linux (32-bit)

rdmd bug.d -inline -boundscheck=off
Default:  TickDuration(58882306)
Explicit: TickDuration(49231968)

On Friday, 6 November 2015 at 17:55:47 UTC, arGus wrote:
> I did some testing on Linux and Windows.
> I ran the code with ten times the iterations, and found the results consistent with what has previously been observed in this thread.
> The code seems to run just fine on Linux, but is slowed down 10x on Windows x86.
>
>
> Windows (32-bit)
>
> rdmd bug.d -inline -boundscheck=off -release
> Default:  TickDuration(14398890)
> Explicit: TickDuration(168888)
>
>
> Linux (64-bit)
>
> rdmd bug.d -m64 -inline -boundscheck=off
> Default:  TickDuration(59090876)
> Explicit: TickDuration(49529493)
>
>
> Linux (32-bit)
>
> rdmd bug.d -inline -boundscheck=off
> Default:  TickDuration(58882306)
> Explicit: TickDuration(49231968)

File a bug report, this probably needs Walter to look at it.

On Friday, 6 November 2015 at 01:17:20 UTC, TheFlyingFiddle wrote:
> On Friday, 6 November 2015 at 00:43:49 UTC, rsw0x wrote:
>> On Thursday, 5 November 2015 at 23:37:45 UTC, TheFlyingFiddle wrote:
>>> On Thursday, 5 November 2015 at 21:24:03 UTC, TheFlyingFiddle wrote:
>>>> [...]
>>>
>>> I reduced it further:
>>>
>>> [...]
>>
>> these run at the exact same speed for me and produce identical assembly output from a quick glance
>> dmd 2.069, -O -release -inline
>
> Are you running on windows?
>
> I tested on windows x64 and there I also get the exact same speed for both functions.

I am still disappointed that DMD is not native 64 bit in windows yet.  Please show exactly how you are getting 64 bit to work in windows 10. I have never gotten this to work.  for any version of DMD.   All of my new $400.00 systems are 4 gig 64 bit windows 10...    and the processor instruction sets are very nice.  I dabble in assembler.   I have always wondered why D does not take advantage of newer instructions...... and 64 bit. I see a 64 Bit droid Compiler for D.  :):):)

On Saturday, 7 November 2015 at 03:18:59 UTC, steven kladitis wrote:
> [...]
> I am still disappointed that DMD is not native 64 bit in windows yet.
> [...]

It's because they can't make a nice distribution. DMD win32 is a nice package that works out of the box (compiler, standard C lib, standard D lib, linker, etc) without any further configuration or derquirement.

DMD win64 requires MSVS for the standard C lib and the linker.