Hello, did you propose your pfft library as a replacement in
std.numeric ?
I have thought about it, but haven't gotten around to doing it
yet. I'd like to finish support for multidimensional transforms
first.
On Saturday, 22 June 2013 at 16:04:26 UTC, jerro wrote:
I have actually run that benchmark with the code from this
branch:
https://github.com/jerro/pfft/tree/experimental
Hello, did you propose your pfft library as a replacement in
std.numeric ?
Jonathan Dunlap:
Thanks Jerro, I went ahead and used a pointer reference to
ensure it's being saved back into the array
(http://dpaste.dzfl.pl/52710926). Two things:
1) still showing zero time delta
2) On windows 7 x74, using a SAMPLE_AT size of 3 or higher
will cause the program to
Thanks Manu, I think I understand. Quick questions, so I've
updated my test to allow for loop unrolling
http://dpaste.dzfl.pl/12933bc8 as the calculation is done over an
array of elements and does not depend on the last operation. My
problem is that the program reports using 0 time. However,
On Monday, 1 July 2013 at 17:19:02 UTC, Jonathan Dunlap wrote:
Thanks Manu, I think I understand. Quick questions, so I've
updated my test to allow for loop unrolling
http://dpaste.dzfl.pl/12933bc8
The loop body in testSimd doesn't do anything. This line:
auto di = d[i];
copies the vector,
Thanks Jerro, I went ahead and used a pointer reference to ensure
it's being saved back into the array
(http://dpaste.dzfl.pl/52710926). Two things:
1) still showing zero time delta
2) On windows 7 x74, using a SAMPLE_AT size of 3 or higher
will cause the program to immediately quit with
Maybe make the arrays public? it's conceivable the optimiser could
eliminate all that code, since it can prove the results are never
referenced...
I doubt that's the problem though, just a first guess.
On 2 July 2013 09:14, Jonathan Dunlap jad...@gmail.com wrote:
Thanks Jerro, I went ahead and
Alright, I'm now officially building for Windows x64 (amd64).
I've created this early benchmark http://dpaste.dzfl.pl/eae0233e
to explore SIMD performance. As you can see below, on my machine
there is almost zero difference. Am I missing something?
//===SIMD===
0 1.#INF 5 1.#INF -- vector
On Saturday, 29 June 2013 at 14:39:44 UTC, Jonathan Dunlap wrote:
Alright, I'm now officially building for Windows x64 (amd64).
I've created this early benchmark
http://dpaste.dzfl.pl/eae0233e to explore SIMD performance. As
you can see below, on my machine there is almost zero
difference. Am
See Manu's talk and google how to use it. If you don't know what
you're doing you are unlikely to see performance improvements.
I'm not even sure if you're benchmarking SIMD performance or
function call overhead there.
I've updated the project with your suggestions at
http://dpaste.dzfl.pl/fce2d93b but still get the same
performance. Vectors defined in the benchmark function body, no
function calling overhead, etc. See some of my comments below btw:
First of all, calcSIMD and calcScalar are virtual
On 29 June 2013 18:57, Jonathan Dunlap jad...@gmail.com wrote:
I've updated the project with your suggestions at
http://dpaste.dzfl.pl/fce2d93b but still get the same performance. Vectors
defined in the benchmark function body, no function calling overhead, etc.
See some of my comments below
On Saturday, 29 June 2013 at 17:57:20 UTC, Jonathan Dunlap wrote:
I've updated the project with your suggestions at
http://dpaste.dzfl.pl/fce2d93b but still get the same
performance. Vectors defined in the benchmark function body, no
function calling overhead, etc. See some of my comments
For the dlang docs: Member functions which are private or
package are never virtual, and hence cannot be overridden.
The call to calcScalar compiles to this:
movrax,QWORD PTR [r12]
rex.W call QWORD PTR [rax+0x40]
so I think the implementation doesn't conform to the spec in this
case.
modern x86-64 processors can execute them in parallel. Because
of that, the speed of your program is limited by instruction
latency and not throughput.
It seems like auto-vectorization to SIMD code may be an ideal
strategy (e.g. Java) since it seems that the conditions to get
any performance
It seems like auto-vectorization to SIMD code may be an ideal
strategy (e.g. Java) since it seems that the conditions to get
any performance improvement have to be very particular and
situational... which is something the compiler may be best
suited to handle. Thoughts?
The things is that
I did watch Manu's a few days ago which inspired me to start this
project. With the updates in http://dpaste.dzfl.pl/fce2d93b, I'm
still a bit clueless as to why there is almost zero performance
difference... considering that is seems like an ideal setup to
benefit from SIMD. I feel that if I
versioning on Win32/Win64 no longer works.
Why? or What exactly? Details please)
You should probably watch my talk again ;)
Most of the points I make towards the end when I make the claim almost
everyone who tries to use SIMD will see the same or slower performance, and
the reason is they have simply revealed other bottlenecks.
And I also made the point only by strictly
On 23.06.2013 15:33, Rainer Schuetze wrote:
BTW: I also found some bugs in the Win64 along the way, I'll create pull
requests for these.
https://github.com/D-Programming-Language/dmd/pull/2253
https://github.com/D-Programming-Language/dmd/pull/2254
On 23.06.2013 20:24, Jacob Carlborg wrote:
On 2013-06-23 15:33, Rainer Schuetze wrote:
COFF32 files are generated when -m32ms is used on the command line.
So, you have implemented support for COFF 32bit? How long have you been
hiding this :) Although I'm not a Windows user I consider it
On 23.06.2013 21:55, Michael wrote:
Cool)))
Any chances to see it [coff32] in official build?
Let's see if Walter approves.
There is one maybe disruptive change: with two different C runtimes
available for Win32, versioning on Win32/Win64 no longer works. I added
versions
On 22.06.2013 02:07, Manu wrote:
It would certainly be nice in Win32, but I tend to think Win32 COFF
should be much higher priority.
I have removed the dust from these patches and pushed them successfully
through the test suite and unittests:
https://github.com/rainers/dmd/tree/coff32
I've said it before, but this man is a genius! :)
On 23 June 2013 23:33, Rainer Schuetze r.sagita...@gmx.de wrote:
On 22.06.2013 02:07, Manu wrote:
It would certainly be nice in Win32, but I tend to think Win32 COFF
should be much higher priority.
I have removed the dust from these
On 2013-06-23 15:33, Rainer Schuetze wrote:
I have removed the dust from these patches and pushed them successfully
through the test suite and unittests:
https://github.com/rainers/dmd/tree/coff32
https://github.com/rainers/druntime/tree/coff32
https://github.com/rainers/phobos/tree/coff32
Cool)))
Any chances to see it [coff32] in official build?
Also tried VC2012 Express (with x64 libs)... received the same
compiler error.
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
On 22 June 2013 15:54, Jonathan Dunlap jad...@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
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 newshou...@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.
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
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
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
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
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
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?
It's a FFT implementation. It does most of the work using + - and
*. There's one
part off the
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
Btw, is it possible to check for SIMD support as a compilation
condition? Ideally I'm looking to 'polyfill' SIMD if it's not
supported on the platform.
On 6/21/2013 3:43 PM, Jonathan Dunlap wrote:
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
It's not a bug, and there are currently
On 22 June 2013 09:04, Walter Bright newshou...@digitalmars.com wrote:
On 6/21/2013 3:43 PM, Jonathan Dunlap wrote:
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
Walter Bright:
It's not a bug, and there are currently no plans to support
SIMD on Win32. However, it is supported for Win64 compilations.
LDC2 supports SIMD on Win32.
Bye,
bearophile
On Friday, 21 June 2013 at 23:04:10 UTC, Walter Bright wrote:
On 6/21/2013 3:43 PM, Jonathan Dunlap wrote:
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
On Saturday, 22 June 2013 at 04:28:57 UTC, Jonathan Dunlap wrote:
On Friday, 21 June 2013 at 23:04:10 UTC, Walter Bright wrote:
On 6/21/2013 3:43 PM, Jonathan Dunlap wrote:
In D 2.063.2 on Windows 7:
Error: SIMD vector types not supported on this platform
Should I file a bug
wrote:
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
It's not a bug, and there are currently no plans to support
SIMD on Win32. However
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:
47 matches
Mail list logo
