Check twice where is yours 64 bit tools installed. Paths something diff in Win8, VS2010, VS2012 Express installations.

On 6/21/2013 10:54 PM, Jonathan Dunlap wrote:
> Alright, I installed VC2010 (with x64 libs) and added the -m64 option to the
> compiler. Sadly the compiler dies with the below message. Should I file a bug or
> did I miss something?

Anytime you see a message like "Internal error" it's a compiler bug and should be reported to bugzilla.

To work around, try replacing -gc with -g.

> -----
>
> Building: Easy (Debug)
>
> Performing main compilation...
>
> Current dictionary: C:\Users\dunlap\Documents\GitHub\CodeEval\Dlang\
>
> C:\D\dmd2\windows\bin\dmd.exe -debug -gc "main.d" "SIMDTests.d"
> "-IC:\D\dmd2\src\druntime\src" "-IC:\D\dmd2\src\phobos" "-odobj\Debug"
> "-ofC:\Users\dunlap\Documents\GitHub\CodeEval\Dlang\bin\Debug\SIMDTests.exe" -m64
>
> Internal error: ..\ztc\cgcv.c 2162
>
> Exit code 1
>
> Build complete -- 1 error, 0 warnings

On 22 June 2013 15:54, Jonathan Dunlap <jadit2@gmail.com> wrote:

> Alright, I installed VC2010 (with x64 libs) and added the -m64 option to the compiler. Sadly the compiler dies with the below message. Should I file a bug or did I miss something?
> -----
>
> Building: Easy (Debug)
>
> Performing main compilation...
>
> Current dictionary: C:\Users\dunlap\Documents\**GitHub\CodeEval\Dlang\
>
> C:\D\dmd2\windows\bin\dmd.exe -debug -gc "main.d" "SIMDTests.d"
>  "-IC:\D\dmd2\src\druntime\src" "-IC:\D\dmd2\src\phobos" "-odobj\Debug"
> "-ofC:\Users\dunlap\Documents\**GitHub\CodeEval\Dlang\bin\**Debug\SIMDTests.exe"
> -m64
>
> Internal error: ..\ztc\cgcv.c 2162
>
> Exit code 1
>
> Build complete -- 1 error, 0 warnings
>

You can't use SIMD and symbolic debuginfo. The compiler will crash.

On 6/22/2013 1:10 AM, Manu wrote:
> You can't use SIMD and symbolic debuginfo. The compiler will crash.

I didn't know that. Bugzilla?

Pretty sure it's in there...
Here it is: http://d.puremagic.com/issues/show_bug.cgi?id=10224

On 22 June 2013 18:36, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/22/2013 1:10 AM, Manu wrote:
>
>> You can't use SIMD and symbolic debuginfo. The compiler will crash.
>>
>
> I didn't know that. Bugzilla?
>

Am 22.06.2013 00:43, schrieb Jonathan Dunlap:
> In D 2.063.2 on Windows 7:
> Error: SIMD vector types not supported on this platform
>
> Should I file a bug for this or is this currently on a roadmap? I'm
> SUPER excited to get into SIMD development with D. :D

In its current state you don't want to be using SIMD with dmd because the generated assembly will be significantly slower then if you just use the default FPU math. If you need simd you will need to write inline assembler. This will then also work on 32 bit windows. But you have to use unaligned loads / stores because the compiler will not garantuee alignment (on 32 bit).

More details on the underperforming generated assembly can be found here:
http://d.puremagic.com/issues/show_bug.cgi?id=10226

Kind Regards
Benjamin Thaut

> In its current state you don't want to be using SIMD with dmd because the generated assembly will be significantly slower then if you just use the default FPU math.

That may be true for some kinds of code, but it isn't true int general.
For example, see the comparison of pfft's performance when built with 64 bit DMD using SIMD and without SIMD:

http://i.imgur.com/kYYI9R9.png

This benchmark was run on a core i5 2500K on 64 bit Debian Wheezy.

Am 22.06.2013 15:53, schrieb jerro:
>> In its current state you don't want to be using SIMD with dmd because
>> the generated assembly will be significantly slower then if you just
>> use the default FPU math.
>
> That may be true for some kinds of code, but it isn't true int general.
> For example, see the comparison of pfft's performance when built with 64
> bit DMD using SIMD and without SIMD:
>
> http://i.imgur.com/kYYI9R9.png
>
> This benchmark was run on a core i5 2500K on 64 bit Debian Wheezy.

Well, but judging from the assembly it generates, it could be even faster. What exactly is pfft? Does it use dmd's __simd intrinsics?
Or does it only do primitive operations (* / - +) on simd types?

Kind Regards
Benjamin Thaut

Am 22.06.2013 15:53, schrieb jerro:
>> In its current state you don't want to be using SIMD with dmd because
>> the generated assembly will be significantly slower then if you just
>> use the default FPU math.
>
> That may be true for some kinds of code, but it isn't true int general.
> For example, see the comparison of pfft's performance when built with 64
> bit DMD using SIMD and without SIMD:
>
> http://i.imgur.com/kYYI9R9.png
>
> This benchmark was run on a core i5 2500K on 64 bit Debian Wheezy.

Ok I saw that you did write quite a few cirtical functions in inline assembly. Not really a good argument for dmds codegen with simd intrinsics.

Kind Regards
Benjamin Thaut

On Saturday, 22 June 2013 at 15:41:43 UTC, Benjamin Thaut wrote:
> Am 22.06.2013 15:53, schrieb jerro:
>>> In its current state you don't want to be using SIMD with dmd because
>>> the generated assembly will be significantly slower then if you just
>>> use the default FPU math.
>>
>> That may be true for some kinds of code, but it isn't true int general.
>> For example, see the comparison of pfft's performance when built with 64
>> bit DMD using SIMD and without SIMD:
>>
>> http://i.imgur.com/kYYI9R9.png
>>
>> This benchmark was run on a core i5 2500K on 64 bit Debian Wheezy.
>
> Ok I saw that you did write quite a few cirtical functions in inline assembly. Not really a good argument for dmds codegen with simd intrinsics.
>
> Kind Regards
> Benjamin Thaut

I have actually run that benchmark with the code from this branch:

https://github.com/jerro/pfft/tree/experimental

The only function in sse_float.d on that branch that uses inline assembly is scalar_to_vector. The reason why I used more inline assembly in the master branch is that DMD didn't have intrinsics for some instructions such as shufps at the time.

I'm not really arguing for DMD's codegen with SIMD intrinsics. It's more that, from what I've seen, it doesn't produce very good scalar floating point code either (at least when compared to LDC or GDC). Whether I use scalar floating point or SIMD, pfft is about two times slower if I compile it with DMD than it is if I compile it with GDC.