ok, i have a working version (memory is nice, twice the speed as
non parallel) ;
http://dpaste.dzfl.pl/504a652c6c47
real0m14.427s
user1m19.347s
sys 0m0.124s
i've got similar performances, without Allocators, using directly
malloc and free
i had to recursively deallocate ...
thou
version with apr (like in c version)
http://dpaste.dzfl.pl/68c0157225e7
compiled with ldc it's indeed a bit faster on average :
real0m1.999s
user0m9.810s
sys 0m0.148
btw Rust version is even faster than my little bit outdated gcc
(4.9)
latest try with allocators :
http://dpaste.dzf
C++ version :
real0m3.587s
user0m9.211s
sys 0m7.341s
using Apache Portable Runtime(APR) like in the C version :
http://dpaste.dzfl.pl/6ca8b5ffd6dc
works like a charm, 2.061s on my machine !
if file name is binarytrees.d
dmd -w -inline -O -release -I/usr/include/apr-1.0
-L/usr/lib/x86_64-linux-gnu/libapr-1.so -of"binarytrees"
"binarytrees.d"
m
On Monday, 7 December 2015 at 10:55:25 UTC, Alex wrote:
On Sunday, 6 December 2015 at 12:23:52 UTC, visitor wrote:
Hello, interesting exercise for me to learn about allocators
:-)
Nice to know, a novice can inspire someone :)
i managed to parallelize the code reaching similar
performance, in
On Sunday, 6 December 2015 at 12:23:52 UTC, visitor wrote:
Hello, interesting exercise for me to learn about allocators :-)
Nice to know, a novice can inspire someone :)
i managed to parallelize the code reaching similar performance,
in terms of speed, as the non parallel version :
http://dpa
On Sunday, 6 December 2015 at 08:45:10 UTC, Rikki Cattermole
wrote:
Why is TreeNode not final?
This is an interesting hint! Just after adding final the program
takes two seconds less... This is roughly 5%. Do you have another
hints of this kind? ;)
Also yours does not use threads in any way.
On Sunday, 6 December 2015 at 08:35:33 UTC, Alex wrote:
Thanks for commenting to everyone! If anybody has further ideas
- all of them would be appreciated :)
The original site is not interested in any further languages to
be tested, so my experiment ends here for now...
Hello, interesting exer
On 06/12/15 9:35 PM, Alex wrote:
Ok, lets conclude this post for now. Did some comparison runs with the
original C++ code. Missed this at the beginning.
The results so far are as following:
Here is the original code in C++.
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytree
Ok, lets conclude this post for now. Did some comparison runs
with the original C++ code. Missed this at the beginning.
The results so far are as following:
Here is the original code in C++.
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=gpp&id=6
With modificatio
On Friday, 4 December 2015 at 14:06:26 UTC, Alex wrote:
[...]
hoping it would be faster. This was not the case. Why?
[...]
Is there anything else to improve performance significantly?
Profile. Profile profile profile. Callgrind. Find bottlenecks
instead of guessing them.
On 05.12.2015 01:40, Alex wrote:
found and tried out the -vgc option...
Is there a way to deactivate the GC, if it stands in way?
You can call core.memory.GC.disable to disable automatic collections.
.enable to turn them on again.
http://dlang.org/phobos/core_memory.html#.GC
Yes, I thought
On Friday, 4 December 2015 at 23:23:37 UTC, anonymous wrote:
Why the parallel version is slower then the sequential?
If you set
int n = 14 in the main function
the parallel version is MUCH slower then the sequential. At my
machine
7x slower. Shouldn't it be the other way round?
I don't know w
On 04.12.2015 15:06, Alex wrote:
3. The compilation was done by:
dmd -O -release -boundscheck=off [filename.d]
Is there anything else to improve performance significantly?
You forgot -inline.
By the way, I'm not a fan of using -boundscheck=off like a general
optimization flag. It undermines @
On 04.12.2015 21:30, Alex wrote:
Yes, I missed this, sorry. The main part of the question was probably
about the class and struct difference. I thought handling with structs
and pointers would be faster then with classes.
When you use a struct directly, without going through a pointer, that
ca
On Friday, 4 December 2015 at 19:31:22 UTC, anonymous wrote:
Why did you expect the C++ inspired version to be faster? Just
because the original was written in C++?
From a quick skim the two versions seem to be pretty much
identical, aside from names and struct vs class.
Names don't make a d
On 04.12.2015 15:06, Alex wrote:
1. I wrote the C++ inspired version after the C# inspired, hoping it
would be faster. This was not the case. Why?
[...]
Why did you expect the C++ inspired version to be faster? Just because
the original was written in C++?
From a quick skim the two versions
On Friday, 4 December 2015 at 14:06:26 UTC, Alex wrote:
Hi everybody,
this is going to be a learning by doing a benchmark test - post.
clip
3. The compilation was done by:
dmd -O -release -boundscheck=off [filename.d]
Is there anything else to improve performance significantly?
If you have
Hi everybody,
this is going to be a learning by doing a benchmark test - post.
Found this "game" on the web
http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees
and wanted to experiment on my self, I tried to reimplement some
code in D.
This:
http://dpaste.dzfl.pl/4d8e
19 matches
Mail list logo