Hiho,
as I used the ldmd wrapper for ldc2 I was able to use the same
arguments given via the cmdfile. These were: -release
-noboundscheck -O and -inline.
Robin
On Thursday, 20 February 2014 at 21:32:10 UTC, Robin wrote:
Hiho,
here are the results of both compilers (DMD and LDC2) on my
system:
LDC:
=
allocationTest ...
Time required: 5 secs, 424 msecs
multiplicationTest ...
Time required: 1
Hiho,
here are the results of both compilers (DMD and LDC2) on my
system:
LDC:
=
allocationTest ...
Time required: 5 secs, 424 msecs
multiplicationTest ...
Time required: 1 secs, 744 msecs
toStringTest ...
Time required: 0 secs,
Robin:
All in all I must say that I am more pleased with the DMD
results as I am kind of worried about the LDC allocation test
performance ...
I am not sure of the causes of this, but the D GG was improved a
little, in the last two compiler versions.
I also had to rewrite parts of the
On Tuesday, 18 February 2014 at 07:50:23 UTC, bearophile wrote:
Stanislav Blinov:
http://dpaste.dzfl.pl/9d7feeab59f6
Few small things should still be improved, but it's an
improvement. Perhaps it needs to use a reference counting from
Phobos.
COW for matrices? Aw, come on... :)
LDC
On Tuesday, 18 February 2014 at 07:45:18 UTC, bearophile wrote:
Stanislav Blinov:
that explicit ctor
for Dimension is completely unnecessary too.
I like a constructor(s) like that because it catches bugs like:
auto d = Dimension(5);
Hmmm... yeah, ok, not completely unnecessary :)
Stanislav Blinov:
allocationTest ...
Time required: 1 sec, 112 ms, 827 μs, and 3 hnsecs
multiplicationTest ...
Time required: 1 sec, 234 ms, 417 μs, and 8 hnsecs
Physics teaches us that those experimental measures are expressed
with a excessive precision. For such benchmarks
Stanislav Blinov:
LDC yields roughly the same times.
This is surprising.
To me as well. I haven't yet tried to dig deep though.
I have compiled your code with (a single module, 32 bit Windows):
dmd -wi -vcolumns -O -release -inline -noboundscheck matrix3.d
ldmd2 -wi -O -release -inline
On Tuesday, 18 February 2014 at 08:50:23 UTC, bearophile wrote:
Stanislav Blinov:
LDC yields roughly the same times.
This is surprising.
To me as well. I haven't yet tried to dig deep though.
I have compiled your code with (a single module, 32 bit
Windows):
dmd -wi -vcolumns -O
...And if I define opEquals as it was made by Robin, i.e. like
this:
bool opEquals(ref const Matrix other) const pure nothrow {
version (all) {
if (dim != other.dim) return false;
foreach(immutable i, const ref e; data)
if (e != other.data[i])
On Tuesday, 18 February 2014 at 09:05:33 UTC, Stanislav Blinov
wrote:
allocationTest ...
Time required: 2 hnsecs (o_O)
identityMatrixTest ...
Time required: 4 hnsecs (o_O)
LDC is probably detecting that you're never actually using the
results of the operation and that none of
Hiho,
I am happy to see that I could encourage so many people to
discuss about this topic to not only give me interesting answer
to my questions but also to analyse and evaluate features and
performance of D.
I have fixed the allocation performance problem via a custom
destructor method
Robin:
the existance of move semantics in C++ and is one of the
coolest features since C++11 which increased and simplified
codes in many cases enormously for value types just as structs
in D.
I guess Andrei doesn't agree with you (and move semantics in
C++11 is quite hard to understand).
On Tuesday, 18 February 2014 at 23:36:12 UTC, Robin wrote:
Another thing which is hopefully a bug in the current language
implementation of D is the strange behaviour of the transpose
method with the only line of code:
return Matrix(this).transposeAssign();
Matrix(this) not compiling when
Hiho,
I currently haven't got enough time to respond to all what have
been said since my last post.
However, here is the simple code:
http://dpaste.dzfl.pl/3df8694eb47d
Thanks in advance!
I am really looking forward to your editing! =)
Robin
On Monday, 17 February 2014 at 09:48:49 UTC, Robin wrote:
Hiho,
I currently haven't got enough time to respond to all what have
been said since my last post.
However, here is the simple code:
http://dpaste.dzfl.pl/3df8694eb47d
Thanks in advance!
I am really looking forward to your editing!
Robin:
http://dpaste.dzfl.pl/3df8694eb47d
I think it's better to improve your code iteratively. First
starting with small simple things:
this(size_t rows, size_t cols) nothrow pure {
=
this(in size_t rows, in size_t cols) nothrow pure {
this(ref const(Dimension) that)
Hiho,
thank you for your code improvements and suggestions.
I really like the foreach loop in D as well as the slight (but
existing) performance boost over conventional for loops. =)
Another success of the changes I have made is that I have
achieved to further improve the matrix
Robin:
The key to victory was pointer arithmetics as I notices that I
have used them in the C++ implementation, too. xD
Perhaps with LDC2 it's not necessary.
I will just post the whole code again so that you can see what
I have changed.
The code looks better.
There's no need to put
On 2/16/2014 6:47 PM, Robin wrote:
@Nick Sabalausky:
Don't be shocked at the bad performance of a beginner D programmer. At
least I am not shocked yet that my D implementation isn't performing as
well as the highly optimized C++11 implementation or the JIT-optimized
Java implementation. In
On 2/17/2014 4:56 PM, Robin wrote:
And here is the complete and improved code:
http://dpaste.dzfl.pl/7f8610efa82b
You should get rid of the .dup's in the constructors and postblits. You
don't want big arrays ever getting accidentally allocated and copied
behind your back when you're only
On Monday, 17 February 2014 at 11:34:43 UTC, bearophile wrote:
foreach (ref T element; this.data) {
element *= scalar;
}
Try to use:
data[] *= scalar;
for (auto i = 0; i this.dim.size; ++i) {
this.data[i] += other.data[i];
}
Try to
Kapps:
I remember array operations (such as data[] -= other.data[])
being significantly slower than doing it yourself. I don't know
if this has been fixed.
They are not being fixed. But for arrays as large as the ones
here, they are fast enough.
-
I have tested the
On Friday, 14 February 2014 at 16:00:09 UTC, Robin wrote:
this(size_t rows, size_t cols) {
this.dim = Dimension(rows, cols);
this.data = new T[this.dim.size];
enum nil = to!T(0);
foreach(ref T element; this.data) element = nil;
}
Your foreach here is
On Tuesday, 18 February 2014 at 03:32:48 UTC, Stanislav Blinov
wrote:
3) Ditch extra constructors, they're completely unnecessary.
For matrix you only need your non-trivial ctor, postblit and
lvalue assignment operator.
Actually rvalue opAssign would be even better :)
Also, I forgot to
Stanislav Blinov:
that explicit ctor
for Dimension is completely unnecessary too.
I like a constructor(s) like that because it catches bugs like:
auto d = Dimension(5);
Bye,
bearophile
Stanislav Blinov:
http://dpaste.dzfl.pl/9d7feeab59f6
Few small things should still be improved, but it's an
improvement. Perhaps it needs to use a reference counting from
Phobos.
LDC yields roughly the same times.
This is surprising.
Bye,
bearophile
On Sunday, 16 February 2014 at 01:25:13 UTC, bearophile wrote:
Many of the things you say and write are still wrong or
confused. Usually the hard optimization of code is one the last
things you learn about a language
Well, actually, sometimes squeezing as much performance as you
can from a
francesco cattoglio:
Well, actually, sometimes squeezing as much performance as you
can from a test case can be a way to find out if a given
language checks all the boxes and can be used to solve your
problems.
Unless you know a language well, you will fail squeezing that.
This is true
On Sunday, 16 February 2014 at 09:53:08 UTC, bearophile wrote:
Be instead amazed of the sometimes near-C++ performance levels
they have pushed Java to :-)
Sorry, but I fail to be amazed by what huge piles of money thrown
to a project for 10+ years can achieve. Those kind of
achievements are
Hiho,
thanks again for your answers!
I don't know where to start ...
@Stanislav Blinov:
I am not currently aware of the move semantics in D or what it
is called there. However, I am not quite sure if D does an
equally good job as C++ in determining if a value can be moved or
not. I have
On Sunday, 16 February 2014 at 23:47:08 UTC, Robin wrote:
I am not currently aware of the move semantics in D or what
it is called there. However, I am not quite sure if D does an
equally good job as C++ in determining if a value can be moved
or not. I have made some simple tests which showed
Robin:
I always thought that D would be much easier to learn than C++
as all the people always say that C++ is the most complex
language. After what I have learned so far D seems to be much
more complex which isn't bad in general, but the learning curve
doesn't feel so well atm as I am
Hiho,
wow, first of all: this community is awesome - so many kind and
interesting answers. =)
With your help I was able to achieve a performance boost for
several different operations.
Some benchmarks:
Allocation of 5 10.000 x 10.000 matrices in a row:
Before: ~8,2 seconds
After: ~2,3
On Saturday, 15 February 2014 at 23:06:27 UTC, Robin wrote:
Matrix is still a class but I changed it to a final class
preventing matrix methods to be virtual. Dimension is now a
final struct (don't know if 'final' is affecting structs in any
way tough ...).
It doesn't. It may even be
In the meantime also take a look at the matrix mul code I've
written here:
http://rosettacode.org/wiki/Matrix_multiplication#D
In the first entry you see no whole transposition up front.
Storing the whole matrix in a 1D array is probably more efficient.
Bye,
bearophile
Robin:
Thanks again for all your helpful comments and thanks in
advance - I am eagerly looking forward for your future
comments! =)
Many of the things you say and write are still wrong or confused.
Usually the hard optimization of code is one the last things you
learn about a language,
Hiho,
I am fairly new to the D programming and still reading throught
the awesome online book at http://ddili.org/ders/d.en/index.html.
However, I think it is missing some things or I am missing
glasses and overlooked these parts in the book.^^
Currently I am trying to write a very simple
On Friday, 14 February 2014 at 16:00:09 UTC, Robin wrote:
this(size_t rows, size_t cols) {
this.dim = Dimension(rows, cols);
this.data = new T[this.dim.size];
enum nil = to!T(0);
foreach(ref T element; this.data) element = nil;
}
I am no expert at optimizing D
On Friday, 14 February 2014 at 16:40:31 UTC, Craig Dillabaugh
wrote:
On Friday, 14 February 2014 at 16:00:09 UTC, Robin wrote:
this(size_t rows, size_t cols) {
this.dim = Dimension(rows, cols);
this.data = new T[this.dim.size];
enum nil = to!T(0);
foreach(ref T
Robin:
class Matrix(T = double) {
private T[] data;
private Dimension dim;
}
Also try final class or struct in your benchmark. And try to
use ldc2 compiler for performance benchmarks.
Perhaps dim is better const, unless you want to change the shape
of the matrix.
Craig Dillabaugh:
this.data = new T[this.dim.size];
with:
this.data.length = this.dim.size
It's the same thing.
Bye,
bearophile
On Friday, 14 February 2014 at 16:47:32 UTC, John Colvin wrote:
On Friday, 14 February 2014 at 16:40:31 UTC, Craig Dillabaugh
wrote:
On Friday, 14 February 2014 at 16:00:09 UTC, Robin wrote:
this(size_t rows, size_t cols) {
this.dim = Dimension(rows, cols);
this.data = new
On Friday, 14 February 2014 at 16:00:09 UTC, Robin wrote:
This is my class with its templated data as a one dimensional
array (as I don't like jagged-arrays) and a dimension (which is
a struct). The dimension object has some util functionality
such as getting the total size or mapping (row,
Chris Cain:
http://dlang.org/phobos/std_array.html#.uninitializedArray
minimallyInitializedArray should be used, because it's safer.
Bye,
bearophile
On Friday, 14 February 2014 at 16:00:09 UTC, Robin wrote:
class Matrix(T = double) {
T opIndex(size_t row, size_t col) const {
First of all make sure you it's not virtual, otherwise each
element access will cost you enough to make it 10x slower than
Java.
On Friday, 14 February 2014 at 16:56:29 UTC, bearophile wrote:
Craig Dillabaugh:
this.data = new T[this.dim.size];
with:
this.data.length = this.dim.size
It's the same thing.
Bye,
bearophile
Not quite. Setting length will copy over the existing contents of
the array. Using new
On Friday, 14 February 2014 at 16:00:09 UTC, Robin wrote:
As I am very new to D I instantly ran into certain optimizing
issues. E.g. the simple matrix multiplication based in my java
implementation requires about 1.5 secs for multiplying two
1000x1000 matrices, however my D implementation
On 2/14/2014 11:00 AM, Robin wrote:
class Matrix(T = double) {
private T[] data;
private Dimension dim;
}
A matrix is just plain-old-data, so use a struct, you don't need a class.
A struct will be much more lightweight: A struct doesn't normally
involve memory allocations like a
Nick Sabalausky:
T opIndex(size_t row, size_t col) const {
immutable size_t i = this.dim.offset(row, col);
if (i = this.dim.size) {
// TODO - have to learn exception handling in D first.
:P
}
return this.data[i];
}
No need for the bounds check. D already does bounds
50 matches
Mail list logo
