Re: [eigen] Transform class performance and inconsistencies |
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
On 12/17/2012 02:27 PM, Christoph Hertzberg wrote:
So, I guess the question is if this is GCC 4.7, or the 32bit system. My benchmarks are run on 64bit linux.On 17.12.2012 12:24, Jakob Schwendner wrote:ok, thanks for confirming this. The other strange case, that you can see in mybenchmark 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):
I also did not see any strange copies for the vector variants, the aligned variants all end with sth similar toHm... 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.mulps %xmm2, %xmm0 addps %xmm1, %xmm0 movaps %xmm0, (%eax) ret $4However, 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.
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).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)
I agree. I think though that the documentation should be updated in this case. Also, a better error message would certainly help as well...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.
Jakob
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |