Don wrote:
> A simple rule of thumb: if it's an array, use float or double. If it's not, use real.

I agree. The only reason to use float or double is to save on storage.

Walter Bright:
> I agree. The only reason to use float or double is to save on storage.

A little D1 program, that I compile with LDC:

import tango.stdc.stdio: printf;
import tango.stdc.stdlib: atof;
alias real FP;
void main() {
    FP x = atof("1.5");
    FP y = atof("2.5");
    FP xy = x * y;
    printf("%lf\n", xy);
}


ldc -O3 -release -inline -output-s temp.d

FP = double:

_Dmain:
	subl	$36, %esp
	movl	$.str, (%esp)
	call	atof
	movl	$.str1, (%esp)
	fstpl	24(%esp)
	call	atof
	fstpl	16(%esp)
	movsd	24(%esp), %xmm0
	mulsd	16(%esp), %xmm0
	movsd	%xmm0, 4(%esp)
	movl	$.str2, (%esp)
	call	printf
	xorl	%eax, %eax
	addl	$36, %esp
	ret	$8

-------------------------

FP = real:

_Dmain:
	subl	$28, %esp
	movl	$.str, (%esp)
	call	atof
	fstpt	16(%esp)
	movl	$.str1, (%esp)
	call	atof
	fldt	16(%esp)
	fmulp	%st(1)
	fstpt	4(%esp)
	movl	$.str2, (%esp)
	call	printf
	xorl	%eax, %eax
	addl	$28, %esp
	ret	$8


If you use the real type you are forced to use X86 FPU, that is very inefficient if used by LDC.

Bye,
bearophile

Don:
> A simple rule of thumb: if it's an array, use float or double. If it's not, use real.

The rule of thumb from me is: if you care for performance never use real type.

Bye,
bearophile

Walter Bright Wrote:

> Don wrote:
> > A simple rule of thumb: if it's an array, use float or double. If it's not, use real.
> 
> I agree. The only reason to use float or double is to save on storage.

There is another reason: performance, when combined with vectorized code.  If I use 4 32-bit floats to represent my vectors, points, etc. in my ray tracer, I can stuff them into an SSE register and use intrinsics to really, *really* speed it up.  Especially if I use the sum-of-products / structure-of-arrays form for packetizing the data.  Now, I realize this is not necessarily possible with D2 currently, but it's not inconceivable that some D2 compiler would get that capability in the relatively near future.

If I instead use 8-byte floats, I now have to double my operations and thus much of my processing time (due to only being able to put 2 items into each SSE register).  If I use reals, well, I get the x86 FPU, which seriously hampers performance.  And when it comes to rendering, performance is a very, very big deal (even in production/offline rendering).

-Mike

Mike Farnsworth wrote:
> There is another reason: performance, when combined with vectorized code.  If
> I use 4 32-bit floats to represent my vectors, points, etc. in my ray tracer,
> I can stuff them into an SSE register and use intrinsics to really, *really*
> speed it up.  Especially if I use the sum-of-products / structure-of-arrays
> form for packetizing the data.  Now, I realize this is not necessarily
> possible with D2 currently, but it's not inconceivable that some D2 compiler
> would get that capability in the relatively near future.
> 
> If I instead use 8-byte floats, I now have to double my operations and thus
> much of my processing time (due to only being able to put 2 items into each
> SSE register).  If I use reals, well, I get the x86 FPU, which seriously
> hampers performance.  And when it comes to rendering, performance is a very,
> very big deal (even in production/offline rendering).

I agree that rendering is different, and likely is a quite different thing than numerical analysis.

Walter Bright Wrote:

> Don wrote:
> > A simple rule of thumb: if it's an array, use float or double. If it's not, use real.
> 
> I agree. The only reason to use float or double is to save on storage.

Portability will become more important as evo algos get used more.
Especially in combination with threshold functions.
The computer will generate/optimize all input/intermediate values itself and executing the program on higher precision machines might give totally different outputs.

strtr wrote:
> Portability will become more important as evo algos get used more. Especially
> in combination with threshold functions. The computer will generate/optimize
> all input/intermediate values itself and executing the program on higher
> precision machines might give totally different outputs.


You've got a bad algorithm if increasing the precision breaks it.

Hello bearophile,

> Don:
> 
>> A simple rule of thumb: if it's an array, use float or double. If
>> it's not, use real.
>> 
> The rule of thumb from me is: if you care for performance never use
> real type.

Has anyone actually teased to show that the vector ops are actually faster than the FPU for cases where there is nothing to vectorize?

-- 
... <IXOYE><

Walter Bright Wrote:

> strtr wrote:
> > Portability will become more important as evo algos get used more. Especially in combination with threshold functions. The computer will generate/optimize all input/intermediate values itself and executing the program on higher precision machines might give totally different outputs.
> 
> 
> You've got a bad algorithm if increasing the precision breaks it.

No, I don't.
All algorithms using threshold functions which have been generated using evolutionary algorithms will break by changing the precision. That is, you will need to retrain them.
The point of most of these algorithms(eg. neural networks) is that you don't know what is happening in it.

Hello Strtr,

> Walter Bright Wrote:
> 
>> You've got a bad algorithm if increasing the precision breaks it.
>> 
> No, I don't.
> 
> All algorithms using threshold functions which have been generated
> using evolutionary algorithms will break by changing the precision.
> That is, you will need to retrain them.
> 
> The point of most of these algorithms(eg. neural networks) is that you
> don't know what is happening in it.

If you don't know what the algorithms is doing then the types used are part of the algorithm.

OTOH, some would argue that Walter is still right by saying that if you don't know what is happening, then you've got a bad algorithm.

However you cut it, these cases are by far the minority. 

-- 
... <IXOYE>