[sldev] SSE2 / Ouch

[Nicholaz Beresford]

Robin Cornelius wrote:
> architectures. What worries me here is unless the split is very clean
> it may be uncertain where the code is jumping to and you could easily
> end up in a situation where you are hitting a mix of the SSE and non
> SSE functions due to simple mistakes or omissions.

Yes, "worry" was exactly the word to describe my feelings when I first
saw the code to auto-sample, store the results in a persistent config,
having three files with essentially the same code ... and that was even
before I noticed the intricacies of the VWR-1610 problem.

Don't get me wrong, I'm not trying to be smart here.  I would have run
into exactly the same error as VWR-1610, I would not have thought of
the implications.  And since, as it seems, nobody at LL noticed it
either, and Dzon also didn't notice it, it's clear for me that this
type of solution is far outside the scope of a manageable solution.

Again, I'm not pointing fingers, nor saying that people should have
noticed.  I would have run headlong into this crash (and I know C++
inside out), except for the fact that I would not have tried this,
because have a gut feeling about where my limits are and what kinds
of constructs are calling for trouble (especially with a user base
as big as Linden Lab's).

I have already seen a few samples of code in the viewer already, where
pushing the limits of OO has resulted in problems of the whole variety
(from inconsequential to disastrous).


What worries me most is that a change like this is rolled out without
mention in the changes, not with a note like "well, we're trying
something daring which might cause speed benefit long term, but also
trouble, but you can roll back and please let us know about any
problems".

Either nobody was aware that it might cause trouble, or it slipped
into 1.17.3 accidentally or it was just performed as a silent
experient ... and I'm not sure which of those alternatives is worse.



Nick