Optimize my code =)

[bearophile]

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 Dimension in another module. In D modules
contain related stuff, unlike Java.

Also feel free to use some free-standing functions. With UFCS
they get used in the same way, and they help making
classes/structs simpler.

Some of your imports could be moved to more local scopes, instead
of being all at module-level.


>                result ~= to!string(this[r, c]);

=>

                  result ~= this[r, c].text;


> writeln("\tTime required: " ~ to!string(secs) ~ " secs, " ~ 
> to!string(msecs) ~ " msecs");

=>

writeln("\tTime required: ", secs, " secs, ", msecs, " msecs");


>    ref Matrix opOpAssign(string s)(in T scalar) pure nothrow if 
> (s == "*") {

=>

      ref Matrix opOpAssign(string op)(in T scalar) pure nothrow if
(op == "*") {


Also you have two functions with code like:

this.data[] op= scalar;

You can define a single template (untested):


      /**
       * Adds or subtracts all entries of this matrix by the given
other matrix.
       */
      ref Matrix opOpAssign(string op)(const ref Matrix other) pure
nothrow
      if (op == "+" || op == "-")
      in
      {
          assert(this.dim == other.dim);
      }
      body
      {
          mixin("this.data[] " ~ op ~ "= other.data[];");
          return this;
      }



>    Matrix opBinary(string s)(const ref Matrix other) const pure 
> if (s == "*")

Given that on a 32 bit system a Matrix is just 16 bytes, it could
be better to not accept the argument by ref, and avoid one more
level of indirection:

      Matrix opBinary(string s)(in Matrix other) const pure if (s
== "*")


> However, there were some strange things of which I am very 
> confused ...
>
> void allocationTest() {
> 	writeln("allocationTest ...");
> 	sw.start();
> 	auto m1 = Matrix!double(10000, 10000);
> 	{ auto m2 = Matrix!double(10000, 10000); }
> 	{ auto m2 = Matrix!double(10000, 10000); }
> 	{ auto m2 = Matrix!double(10000, 10000); }
> 	//{ auto m2 = Matrix!double(10000, 10000); }
> 	sw.stop();
> 	printBenchmarks();
> }
>
> This is the most confusing code snippet. I have just changed 
> the whole allocation for all m1 and m2 from new Matrix!double 
> (on heap) to Matrix!double (on stack)

The matrix data is always on the heap. What ends on the stack is
a very limited amount of stuff.


> This is extremely confusion as I allocate these matrices on the 
> stack and since I have allocated them within their own 
> scoped-block they should instantly release their memory

You are mistaken. minimallyInitializedArray allocates memory on
the GC heap (and there's not enough space on the stack to
allocate 10000^2 doubles). In both D and Java the deallocation of
memory managed by the GC is not deterministic, so it's not
immediately released at scope exit. Also unlike the Java GC, the
D GC is less refined, and by design it is currently not precise.
With such large arrays often there are _inbound_ pointers that
keep the memory alive, especially on 32 bit systems. So perhaps
your problems are caused by the GC.

You can have deterministic memory management in your struct-based
matrices, but you have to allocate the memory manually (from the
GC or probably better from the C heap) and free it in the struct
destructor usign RAII.


> Another strange things was that the new opEquals implementation:
>
> 	bool opEquals(const ref Matrix other) const pure nothrow {
> 		if (this.dim != other.dim) {
> 			return false;
> 		}
> 		foreach (immutable i; 0 .. this.dim.size) {
> 			if (this.data[i] != other.data[i]) return false;
> 		}
> 		return true;
> 	}
>
> is actually about 20% faster than the one you have suggested. 
> With the single line of "return (this.dim == other.dim && 
> this.data[] == other.data[]).

I think this small performance bug is fixed in dmd 2.065 that is
currently in beta3.


> The last thing I haven't quite understood is that I tried to 
> replace
>
> auto t = Matrix(other).transposeAssign();
>
> in the matrix multiplication algorithm with its shorter and 
> clearer form
>
> auto t = other.transpose(); // sorry for the nasty '()', but I 
> like them! :/
>
> This however gave me wonderful segmentation faults on runtime 
> while using the matrix multiplication ...

This looks like a null-related bug.

I'll benchmark your code a little, but I think I don't have as
much RAM as you.

Bye,
bearophile