<div dir="ltr">Benjamin,<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
And please do not get me wrong. I do not want to stop your efforts to improve<br>
the performance of OSG; far from it!</blockquote><div><br>Not necessarily my efforts - I'm just being the messenger...!<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But putting assembler code into the<br>
project decrease the readability and serviceability of the code.</blockquote><div><br>Absolutely.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Furthermore<br>
it might be that it does not improve the speed at all.</blockquote><div><br>I agree, and this is an oft quoted issue. Here, I think, only testing (and experience) will help. For example, is it worth performing a single Vec3f cross product in SSE? Probably not. But as a counter example, over on osg-submissions (EDIT - and now here), one user (James) is getting large performance gains from having SSE'd the invert_4x4 function.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I just want to suggest<br>
that you try to exhaust the possibility of modern compilers as much as<br>
possible. If you see any bottlenecks after that, it might make sense to<br>
include manual performance tuning.</blockquote><div><br>I agree. This call-for-ideas was motivated by an understanding that several people are pushing in the same direction, and it would be perhaps beneficial to make use of this push.<br>
<br>David<br></div></div></div>