> 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-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 while you thought that C++ could be that much faster than D?  :D

> 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.

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.
>>
>> 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 while you thought that C++ could be that much faster than D?  :D

Well technically it's not that C++ is faster than D or visa-versa, it's that the two compilers did different optimizations, and in this case one of the optimizations that g++ did (removing redundancies) had a large effect on the outcome. It's entirely possible that DMD can still beat g++ under different circumstances.

--rt

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?

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, then load it back in and expand it - you _asked_ for that.

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 and more precision! It is a win-win situation. Also take a look at Phobos' std.math that returns real everywhere.

Modified code:
---8<-------------------------------

module main;

import std.datetime;
import std.metastrings;
import std.stdio;
import std.typetuple;


enum DIM = 32 * 1024;

int juliaValue;

template Julia(TReal)
{
	struct ComplexStruct
	{
		float r;
		float i;

		TReal squarePlusMag(const ComplexStruct another)
		{
			TReal r1 = r*r - i*i + another.r;
			TReal i1 = 2.0*i*r + another.i;

			r = r1;
			i = i1;

			return (r1*r1 + i1*i1);
		}
	}

	int juliaFunction( int x, int y )
	{
		auto c = ComplexStruct(0.8, 0.156);
		auto a = ComplexStruct(x, y);

		foreach (i; 0 .. 200)
			if (a.squarePlusMag(c) > 1000)
				return 0;
		return 1;
	}

	void kernel()
	{
		foreach (x; 0 .. DIM) {
			foreach (y; 0 .. DIM) {
				juliaValue = juliaFunction( x, y );
			}
		}
	}
}

void main()
{
	writeln("D code serial with dimension " ~ toStringNow!DIM ~ " ...");
	StopWatch sw;
	foreach (Math; TypeTuple!(float, double, real))
	{
		sw.start();
		Julia!(Math).kernel();
		sw.stop();
		writefln("  using %ss Total time: %s [sec]",
		         Math.stringof, (sw.peek().msecs * 0.001));
		sw.reset();
	}
}

------------------------------->8---

-- 
Marco

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?

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 you using when compiling?

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 and more precision!

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 [sec]
    using reals Total time: 5.95 [sec]

Using double is indeed marginally faster than float, but real is slower than both.

What's disturbing is that when compiled instead with gdmd -O -inline -release the code is dramatically slower:

  D code serial with dimension 32768 ...
    using floats Total time: 22.108 [sec]
    using doubles Total time: 21.203 [sec]
    using reals Total time: 23.717 [sec]

It's the first time I've encountered such a dramatic difference between GDC and LDC, and I'm wondering whether it's down to a bug or some change between D releases 2.060 and 2.061.

Am Wed, 13 Feb 2013 14:44:36 +0100
schrieb FG <home@fgda.pl>:

> 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 memory, where every increase in
size hurts. And they cannot be optimized away,
like temporary reals, which can be kept on the FPU stack.

-- 
Marco