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
Don wrote:
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.mat
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.
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 diffe
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, be
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
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).
That'
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 bug.
> 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 equivale
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 ^^
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
On Wed, 14 Apr 2010 17:19:53 -0400, Joseph Wakeling
wrote:
/
version(Tango) {
import tango.stdc.stdio: printf;
} else {
import std.stdio: printf;
}
void main()
{
double[] x;
for(uint i=0;i<100;++i) {
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 ... ?
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
On Wed, 14 Apr 2010 05:58:55 -0400, bearophile
wrote:
>
> Don:
>
> >Raising to a float power is really a niche feature.<
>
> Used it as x^^0.5 to perform the square root is not a niche feature, square
> roots are common enough.
> And sqrt is an intrinsic, it doesn't need all std.math.
I thin
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.
Bye,
bearophile
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 (wit
Lars T. Kyllingstad wrote:
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, becaus
> - 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 wo
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
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 ^^
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, basi
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
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:
http://d.puremagic.com/issues/show_bug.cgi
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 proba
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 s
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, if
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 (R250
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) d
This is a little cleaned up version of the result of the profiling (no inling,
final classes, -O -release):
Func
Time
7586124 std.random __uniform std.random __MersenneTwisterEngine
4040384 main
2408110 performance userReputationUpdate performance Rating
2299561 std.math __nextafte
So far I've just given a light reading of the code. Notes:
- 1.0L in D is a real, not a double, it's 10-12-16 bytes long.
- Mt19937 is a Mersenne twister, keep in mind that it's really good but slow.
If you need less quality, use a faster generator.
- Compile your code with -w, so it says you that
Joseph Wakeling:
> OK. I'm just bemused about why -- having solved the memory leak -- my D
> code is running significantly slower than equivalent C++ code.
I'll try to take a look at your D code. In the meantime you can show the
equivalent C++ code too, so I can compare.
Note that dmd has an old
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 do
35 matches
Mail list logo
