bearophile wrote:
Joseph Wakeling:
I took a little time last night and wrote up a C++ version that
I'll take a look at this, I was away for few days.
Thank you very much!
No rush or even necessity -- I'm just curious if it sheds any light on
D-related issues. :-)
Joseph Wakeling:
I took a little time last night and wrote up a C++ version that
I'll take a look at this, I was away for few days.
Bye,
bearophile
bearophile wrote:
This is the middle parts (the two loops) of Yzlm.objectReputationUpdate
compiled with ldc, this is one of the two main hot spots of the program, the
you can compared this asm with the asm of the same part from the C++ version:
To find why the C++ code is faster you can
Ary Borenszweig wrote:
Don wrote:
Ary Borenszweig wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5
(but you have to import std.math anyway,
bearophile wrote:
You are right, sorry.
No need to apologise! You helped me significantly improve my code,
helped me understand D a lot better and left me feeling generally very
positive about developing further in D. I'd call that a result. :-)
So I think it's probably just compiler
bearophile wrote:
Ary Borenszweig:
My point is, if you are going to pow, you will need std.math, so it'll
always be a burden to import it by hand when using it. ^^
Can the automatic import happen only iff a module uses the ^^fp?
Bye,
bearophile
That's what I'm asking for.
Hi Bearophile,
Thanks ever so much for the amount of effort you put into this -- it is
extremely kind and generous. :-)
I'm not seeing the significant gains that you see with DMD, but for me
too LDC doubles the speed.
My guess for the difference is that you ran less than the full 100
iterations
bearophile wrote:
Robert Clipsham Wrote:
this way if/when
tango is ported to D2 it doesn't have to hack around this to allow it to
allow users to use ^^.
I hope Tango2 will be designed to be installed beside Phobos2, and not in
place of it.
I thought that was the aim ... ? At least
On Wed, 14 Apr 2010 17:19:53 -0400, Joseph Wakeling
joseph.wakel...@webdrake.net wrote:
/
version(Tango) {
import tango.stdc.stdio: printf;
} else {
import std.stdio: printf;
}
void main()
{
double[] x;
Joseph Wakeling:
My guess for the difference is that you ran less than the full 100 iterations
of the main for loop.
You are right, sorry.
So I think it's probably just compiler difference that's to blame for speed
differences
This can be true, but such differences are not magic, they can
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^
This is the middle parts (the two loops) of Yzlm.objectReputationUpdate
compiled with ldc, this is one of the two main hot spots of the program, the
you can compared this asm with the asm of the same part from the C++ version:
To find why the C++ code is faster you can show me the equivalent
Ary Borenszweig wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
That's not a
Don wrote:
Ary Borenszweig wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
Ary Borenszweig:
My point is, if you are going to pow, you will need std.math, so it'll
always be a burden to import it by hand when using it. ^^
Can the automatic import happen only iff a module uses the ^^fp?
Bye,
bearophile
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but you have to
import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^ y will probably always require
import std.math,
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but you
have to import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^ y will probably always require
import
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^ y will
Don:
That's not a bug. It's intentional. x ^^ y will probably always require
import std.math, if y is a floating point number.
What's the rationale behind this decision?
I have filed it as a bug many days ago, because I think it's a wrong intention:
Don:
Thank you for your answer and comments.
Because pow() for floating point, when implemented properly, is a HUGE
function, that ends up dragging almost all of std.math into the
executable. And I think it's deceptive to do that silently.
To make it completely built-in, basically all of
bearophile wrote:
Don:
Thank you for your answer and comments.
Because pow() for floating point, when implemented properly, is a HUGE
function, that ends up dragging almost all of std.math into the
executable. And I think it's deceptive to do that silently.
To make it completely built-in,
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^
Lars T. Kyllingstad wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
That's not a
- the two nested loops in the main are more efficient as ref double,
this is something dmd will need to fix;
A test shows that on ldc the two nested loops are a little faster without the
ref. I'd like the compiler to use a const ref with the foreach iterates on
array items bigger than a word.
On 14/04/10 20:54, Don wrote:
I have a vague recollection that correctly-rounded pow() will require
bigint (can't quite remember, though). I'm also concerned about build
tools -- I don't want them to have to know about the dependency.
As a bare minimum, the error message will need to improve
Don wrote:
The D code compiles directly to a memset and memcpy, which are
intrinsics. There's no way C++ could beat it.
OK. I'm just bemused about why -- having solved the memory leak -- my D
code is running significantly slower than equivalent C++ code.
For now I'm just playing with D by
This is a single module, and on my PC is more than two times faster than the
original code. Now I think there are no naive ways left to speed it up.
Compile it with:
dmd -O -release -inline
The low performance was caused by:
- virtual methods that don't need to be virtual;
- ^^0.5 and pow(x,2)
This compiles for D1. With LDC it runs about two times faster still, about
4.5-5 times faster than the original version. We can compare this to the C++
version of yours.
ldc -O5 -release -inline -enable-unsafe-fp-math -unroll-allow-partial test.d
I have also tried the faster rnd generator
28 matches
Mail list logo
