Re: [eigen] Transform class performance and inconsistencies

[ Thread Index | Date Index | More Archives ]

On 12/17/2012 02:27 PM, Christoph Hertzberg wrote:
On 17.12.2012 12:24, Jakob Schwendner wrote:
ok, thanks for confirming this. The other strange case, that you can see in my
benchmark is:

For the record, I can't reproduce this using g++-4.7.1 (on 32bit linux). I get the following timings (using Jacob's benchmark):

So, I guess the question is if this is GCC 4.7, or the 32bit system. My benchmarks are run on 64bit linux.

I also did not see any strange copies for the vector variants, the aligned variants all end with sth similar to
    mulps    %xmm2, %xmm0
    addps    %xmm1, %xmm0
    movaps    %xmm0, (%eax)
    ret    $4

However, all variants where the result does not fit into a register lead to a copy of the result (with aligned moves where possible, though), so either RVO is not optimal there, or not possible due to aliasing. And maybe that does not occur on 64bit machines, due to the higher number of registers.
Hm... but shouldn't that make the 64 bit variant faster? It seems that on your machine both AutoAlign and DontAlign cases are consistent, unlike in the results from Gael and Me.

Still, the timings show that e.g. aligned Isometry * X could be optimized to Projective * X in most cases (maybe unless the last line of the Isometry is not stored explicitly)

Yes, getting twice the speed on Iso * Iso Transform for the float case is certainly an improvement. At least in our application this is the second most used operation of the Geometry module (after Iso * vec).

As for the non-compiling vec3 = Projective * vec3 from your first mail, I don't think this should be allowed, since for arbitrary Projective matrices you can't make any assumptions about the last component of the result.
I agree. I think though that the documentation should be updated in this case. Also, a better error message would certainly help as well...


Mail converted by MHonArc 2.6.19+