[sldev] SSE2 / Ouch

[Dzonatas]

 From what I read on the jira issue and in these mails, it sounds like 
the gSysCPU.hasSSE() doesn't return the correct result for AMD processors.

Nicholaz Beresford wrote:
>
> 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
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>

-- 
Power to Change the Void