Re: Rquest for timings

2011-11-26 Thread bearophile
Thank you for your suprising timings, Jerry.

 All timings done with gdc 0.30 using dmd 2.055 and gcc 4.6.2.  I built
 with both D and C++ enabled so the back end would be the same.

Is your system a 64 bit one?


 So, the upshot seems like DMD and GDC generate similar code for this test.

This is an uncommon thing, expecially on 32 bit systems.


 And both D compilers generate slightly faster code than the C++
 version, therefore the D front end is doing a slightly better
 optimization job, or your first version is slightly more efficient code.

D1 code is often a bit slower than similar C++ code, but in this case I think 
D2 has allowed to specify more semantics that has produced a faster program. 
The static foreach I have used that D2 code is not just looking more clean 
compared to the those C++0x template tricks, but also the assembly output is 
better.

And the first D2 program is not even the fastest possible: that second D2 
program today is slow, but it contains some more semantics that hopefuly 
someday will allow the second version of the program to be faster than the 
first one, and about as fast as that Fortran version.

This code that currently doesn't compile (no vector ^^, no vector sqrt, no good 
sum function):

immutable double[NPAIR] distance = sqrt(sum(r[] ^^ 2, dim=0));


Is currently implemented like this:

double[NPAIR] distance = void;
foreach (i; Iota!(0, NPAIR))
distance[i] = sqrt(r[i][0] ^^ 2 + r[i][1] ^^ 2 + r[i][2] ^^ 2);


Here those square roots are parallelizable, the compiler is allowed to use a 
SSE2 sqrtpd instruction to performs those 10 sqrt(double) with 5 instructions. 
With the ymm register of AVX the instruction VSQRTPD (intrinsic _mm256_sqrt_pd 
in lesser languages) does 4 double squares at a time. But maybe its starting 
location needs to be aligned to 16 bytes (not currently supported syntax):

align(16) immutable double[NPAIR] distance = sqrt(sum(r[] ^^ 2, dim=0));

Bye,
bearophile


Re: Rquest for timings

2011-11-26 Thread Andrea Fontana
Maybe Jerry could test my edits and check for timing...

About ^^: have you tried to benchmark

1/(x ^^ n) vs x ^^ -n ?  (with n0)

On my setup second version is very very slow.


== Quotato dall`articolo bearophile (bearophileh...@lycos.com)
 Andrea Fontana Wrote:
 Yes, really :-) Timings taken with DMD 2.056+, 32 bit Vista OS.
 Bye,
 bearophile



Re: Rquest for timings

2011-11-26 Thread bearophile
Andrea Fontana:

 About ^^: have you tried to benchmark
 
 1/(x ^^ n) vs x ^^ -n ?  (with n0)
 
 On my setup second version is very very slow.

Take a look at the produced assembly code :-)
Maybe x ^^ n is rewritten with a simple code, while ^^-n calls the pow function.

Bye,
bearophile


Re: auto

2011-11-26 Thread mta`chrono
Did you know that auto is not auto in the way auto behalfs. it's just a
placeholder so the compiler can determine that a variable follows. but
you can use any other keyword for type interfering, too.

void main()
{
const a = FunctionThatReturnsSomething();
static b = 5.0;
scope c = hey;
}


Strong size_t

2011-11-26 Thread Kagamin
Tried to create a stronger version of size_t which will not interoperate with 
int and long
http://codepad.org/47OB3nJi

But for some reason can't compare struct to int using opEquals and opCmp. How 
to fix it? And should it? One can write `v==intp(42)` or `vintp(43)`.


Re: Strong size_t

2011-11-26 Thread Simen Kjærås

On Sat, 26 Nov 2011 17:22:58 +0100, Kagamin s...@here.lot wrote:

Tried to create a stronger version of size_t which will not interoperate  
with int and long

http://codepad.org/47OB3nJi

But for some reason can't compare struct to int using opEquals and  
opCmp. How to fix it? And should it? One can write `v==intp(42)` or  
`vintp(43)`.


Have you tried to overload opEquals and opCmp for ints? That seems to
work just fine for me:

bool opEquals(int v) const { return value == v; }
int opCmp(int v) const
{
return valuev?1:valuev?-1:0;
}

Just add those to the intp struct.


Re: Strong size_t

2011-11-26 Thread Kagamin
Simen Kjærås Wrote:

 On Sat, 26 Nov 2011 17:22:58 +0100, Kagamin s...@here.lot wrote:
 
  Tried to create a stronger version of size_t which will not interoperate  
  with int and long
  http://codepad.org/47OB3nJi
 
  But for some reason can't compare struct to int using opEquals and  
  opCmp. How to fix it? And should it? One can write `v==intp(42)` or  
  `vintp(43)`.
 
 Have you tried to overload opEquals and opCmp for ints? That seems to
 work just fine for me:
 
  bool opEquals(int v) const { return value == v; }
  int opCmp(int v) const
  {
  return valuev?1:valuev?-1:0;
  }
 
 Just add those to the intp struct.

It writes
Error: function strongintp.intp.opEquals type signature should be const 
bool(ref const(intp)) not const bool(ref const const(short) v)

Hmm... may be my compiler version is old and this was fixed...


Re: Strong size_t

2011-11-26 Thread Steven Schveighoffer

On Sat, 26 Nov 2011 11:45:26 -0500, Kagamin s...@here.lot wrote:


Simen Kjærås Wrote:


On Sat, 26 Nov 2011 17:22:58 +0100, Kagamin s...@here.lot wrote:

 Tried to create a stronger version of size_t which will not  
interoperate

 with int and long
 http://codepad.org/47OB3nJi

 But for some reason can't compare struct to int using opEquals and
 opCmp. How to fix it? And should it? One can write `v==intp(42)` or
 `vintp(43)`.

Have you tried to overload opEquals and opCmp for ints? That seems to
work just fine for me:

 bool opEquals(int v) const { return value == v; }
 int opCmp(int v) const
 {
 return valuev?1:valuev?-1:0;
 }

Just add those to the intp struct.


It writes
Error: function strongintp.intp.opEquals type signature should be const  
bool(ref const(intp)) not const bool(ref const const(short) v)


Hmm... may be my compiler version is old and this was fixed...


According to bugzilla, yes.

http://d.puremagic.com/issues/show_bug.cgi?id=3659

-Steve