|Re: [eigen] Transform class performance and inconsistencies|
[ Thread 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 my
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 to
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.
mulps %xmm2, %xmm0
addps %xmm1, %xmm0
movaps %xmm0, (%eax)
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.
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.