Thanks a lot for your reply.
When you are comparing LDC and GDC, you should either use
-mcpu=generic for ldc or -march=native for GDC, because their
default targets are different. GDC will produce code that works
on most x86_64 (if you are on a x86_64 system) CPUs by default,
and LDC targets the host CPU. But this does not
Am Wed, 13 Feb 2013 18:10:47 +0100
schrieb Joseph Rushton Wakeling :
> Just to update on times. I was running another large job at the same time as
> doing all these tests, so there was some slowdown. Current results are:
>
> -- with g++ -O3 and using double rather than float: about 4.3 s
>
>
On 02/13/2013 04:41 PM, Joseph Rushton Wakeling wrote:
On 02/13/2013 04:17 PM, FG wrote:
Good point about choosing the right type of floating point numbers.
Conclusion: when there's enough space, always pick double over float.
Tested with GDC in win64. floats: 16.0s / doubles: 14.1s / reals: 11.
Am Wed, 13 Feb 2013 16:17:12 +0100
schrieb FG :
> Good point about choosing the right type of floating point numbers.
> Conclusion: when there's enough space, always pick double over float.
> Tested with GDC in win64. floats: 16.0s / doubles: 14.1s / reals: 11.2s.
> I thought to myself: cool, I al
On 02/13/2013 04:17 PM, FG wrote:
Good point about choosing the right type of floating point numbers.
Conclusion: when there's enough space, always pick double over float.
Tested with GDC in win64. floats: 16.0s / doubles: 14.1s / reals: 11.2s.
I thought to myself: cool, I almost beat the 13.4s I
On 2013-02-13 16:26, Marco Leise wrote:
I'd still bet a dollar that with an array of values floats would
outperform doubles, when cache misses happen. (E.g. more or
less random memory access.)
I'll play it safe and only bet my opDollar. :)
Am Wed, 13 Feb 2013 15:45:13 +0100
schrieb Joseph Rushton Wakeling :
> On 02/13/2013 03:29 PM, Marco Leise wrote:
> > They are actual storage in memory, where every increase in
> > size hurts.
>
> When I replaced with TReal, it sped things up for double.
Oh this gets even better... I only added
Good point about choosing the right type of floating point numbers.
Conclusion: when there's enough space, always pick double over float.
Tested with GDC in win64. floats: 16.0s / doubles: 14.1s / reals: 11.2s.
I thought to myself: cool, I almost beat the 13.4s I got with C++, until I
changed the
Am Wed, 13 Feb 2013 15:45:13 +0100
schrieb Joseph Rushton Wakeling :
> On 02/13/2013 03:29 PM, Marco Leise wrote:
> > They are actual storage in memory, where every increase in
> > size hurts.
>
> When I replaced with TReal, it sped things up for double.
Give me that stuff, your northbridge is o
On 02/13/2013 03:56 PM, Marco Leise wrote:
Ok, I get pretty much the same numbers as before with:
ldmd2 -O -inline -release
It's even a bit faster than my lng command line.
My experience has been that the higher -O values of ldc don't do much, but of
course, that's going to vary dependi
Am Wed, 13 Feb 2013 15:00:21 +0100
schrieb Joseph Rushton Wakeling :
> Compiling with ldmd2 -O -inline -release on 64-bit Ubuntu, latest from-GitHub
> LDC, LLVM 3.2:
>
>D code serial with dimension 32768 ...
> using floats Total time: 4.751 [sec]
> using doubles Total time: 4.362 [
On 02/13/2013 03:29 PM, Marco Leise wrote:
They are actual storage in memory, where every increase in
size hurts.
When I replaced with TReal, it sped things up for double.
Am Wed, 13 Feb 2013 14:48:21 +0100
schrieb Joseph Rushton Wakeling :
> On 02/13/2013 02:26 PM, Marco Leise wrote:
> > You get both, 50% more speed and more precision! It is a
> > win-win situation. Also take a look at Phobos' std.math that
> > returns real everywhere.
>
> I have to say, it's not
Am Wed, 13 Feb 2013 14:44:36 +0100
schrieb FG :
> On 2013-02-13 14:26, Marco Leise wrote:
> > template Julia(TReal)
> > {
> > struct ComplexStruct
> > {
> > float r;
> > float i;
> > ...
>
> Why aren't r and i of type TReal?
They are actual storage in mem
On 02/13/2013 02:26 PM, Marco Leise wrote:
I compiled with LDC2 and these are the results:
D code serial with dimension 32768 ...
using floats Total time: 13.399 [sec]
using doubles Total time: 9.429 [sec]
using reals Total time: 8.909 [sec] // <- !!!
You get both, 50% more speed
On 02/13/2013 02:26 PM, Marco Leise wrote:
You get both, 50% more speed and more precision! It is a
win-win situation. Also take a look at Phobos' std.math that
returns real everywhere.
I have to say, it's not been my experience that using real improves speed.
Exactly what optimizations are yo
On 2013-02-13 14:26, Marco Leise wrote:
template Julia(TReal)
{
struct ComplexStruct
{
float r;
float i;
...
Why aren't r and i of type TReal?
I like optimization challenges. This is an excellent test
program to check the effect of different floating point types
on intermediate values. Remember that when you store values in
a float variable, the FPU actually has to round it down to
that precision, store it in a 32-bit memory location, the
On 02/12/2013 11:17 PM, FG wrote:
Winblows and DMD 32-bit, the rest 64-bit, but still, dmd was quite fast.
Interesting how gdc -O3 gave no extra boost vs. -O2.
... try adding -frelease to the gdc call?
Well technically it was that much faster because it did optimize
away the useless calcOn Tuesday, 12 February 2013 at 23:31:17
UTC, FG wrote:
On 2013-02-13 00:06, Sparsh Mittal wrote:
I had a look, but first had to make juliaValue global,
because g++ had
optimized all the calculations away.
LOL. For a while you thought that C++ could be that much faster
than D? :D
I was stunned and shared it with others who could not find. It
was like a scientist discovering a phenomenon which is against
established laws. Good that I was wrong and a right person
pointed it.
On 2013-02-13 00:06, Sparsh Mittal wrote:
I had a look, but first had to make juliaValue global, because g++ had
optimized all the calculations away.
Brilliant! Yes, that is why the time was coming out to be zero, regardless of
what value of DIM I put. Thank you very very much.
LOL. For a w
I had a look, but first had to make juliaValue global, because
g++ had optimized all the calculations away.
Brilliant! Yes, that is why the time was coming out to be zero,
regardless of what value of DIM I put. Thank you very very much.
On 2013-02-12 21:39, Sparsh Mittal wrote:
I am finding C++ code is much faster than D code.
I had a look, but first had to make juliaValue global, because g++ had optimized
all the calculations away. :) Also changed DIM to 32 * 1024.
13.2s -- g++ -O3
16.0s -- g++ -O2
15.9s -- gdc -O3
15.9s
Thanks for your insights. It was very helpful.
13-Feb-2013 01:09, Sparsh Mittal пишет:
Pardon me, can you please point me to suitable reference or tell just
command here. Searching on google, I could not find anything yet.
Performance is my main concern.
GDC, seems like its mostly "build from source" kind of thing.
Moved to gitbub:
https:
OK. I found it.
On Wed, Feb 13, 2013 at 12:56:01AM +0400, Dmitry Olshansky wrote:
> 13-Feb-2013 00:39, Sparsh Mittal пишет:
> >I am finding C++ code is much faster than D code.
>
> Seems like DMD's floating point issue. The issue being that it
> always works with floats as full-width reals + rounding. Basically
>
Pardon me, can you please point me to suitable reference or tell
just command here. Searching on google, I could not find anything
yet. Performance is my main concern.
13-Feb-2013 00:39, Sparsh Mittal пишет:
I am finding C++ code is much faster than D code.
Seems like DMD's floating point issue. The issue being that it always
works with floats as full-width reals + rounding. Basically if nothing
changed (and I doubt it changed) then DMD with floating point
On Tuesday, 12 February 2013 at 20:39:36 UTC, Sparsh Mittal wrote:
I am finding C++ code is much faster than D code.
dmd (AFAIK) is known to be slower. try LDC or GDC if speed is
your major concern.
I am finding C++ code is much faster than D code.
I am writing Julia sets program in C++ and D; exactly same way as
much as possible. On executing I find large difference in their
execution time. Can you comment what wrong am I doing or is it
expected?
//===C++ code, compiled with -O3 ==
#include
#include
using name
34 matches
Mail list logo
