enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)
On Monday, March 1, 2021, Gabriel Paubert <paubert@iram.es> wrote:
> On Mon, Mar 01, 2021 at 12:22:22PM +0000, Luke Kenneth Casson Leighton wrote:
>> ---
>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>
>> On Mon, Mar 1, 2021 at 8:39 AM Gabriel Paubert <paubert@iram.es> wrote:
>>
>> > Beware that VSX is not Altivec. Altivec was called VMX by IBM and
>> > VSX is a superset of Altivec (IIRC).
>> >
>> > G4 and G5 do not have VSX.
>>
>> apologies i tend to lump these together.
>>
>> > This is going to be hopelessly slow.
>>
>> great! i have absolutely no problem with that, at all. the idea is
>> to give people access to something where due to the ongoing cascading
>> mistaken assumptions "nobody has any hardware except IBM POWER9 and
>> EABI 2.0 says VSX therefore #ifdef POWER9 --> enable VSX".
>>
>> it's a stopgap measure that at least allows... _something_. breathing
>> space whilst the OpenPOWER Foundation puts together a plan.
>>
>> > The point of SIMD is to process quickly vast amounts of data,
>>
>> that was its seductive intent. the reality is very different,
>> poisoning L1 I-Cache through massive bloating of program size, and in
>> some cases actually causing such heavy internal bus contention between
>> instruction and data reads that all processing grinds to a halt.
>>
>> https://www.sigarch.org/simd-instructions-considered-harmful/
>
> This publications claims (and probably rightly) that vector instructions
> are preferable to SIMD, but does not say at all that falling back to
> purely scalar is better.
i appreciate this is a side-track: LibreSOC is introducing a concept of Cray-style "hardware for-loops" around the scalar ISA. with gcc autovectorisation the seemingly-scalar c code becomes as fast as the hardware has available parallel ALUs. hence the performance penalty is not as great.
POWER9 on the other hand, if you've seen the proposed glibc6 patch to add VSX to e.g. strncpy, it's alarming. whilst the above article is hypothetical, the real-world patch is a staggering 250 hand-coded assembly instructions (the equivalent RVV is 13), dramatically reducing L1 cache effectiveness and likely interfering with the use of memory bounds checkers that align memory at the end of pages.
> Also, PPC SIMD has seen fewer variations than x86, which started with
> MMX (64bit), then SSE (128 bit registers, single precision only), SSE2
> (finally able to get rid of the awful x87 stacked registers) and so many
> extensions that I agree that it is impossible to track.
indeed. all that is gone with Cray-style Vectors.
> Hmmm, G5 is BE only. No way to run LE, G4 and older are 32 bit BE (they
> could run LE also, but it's not easy).
>
understood. ok so EABI 2.0 is out of the running, and EABI 1.9 is the 64-bit upgrade of 1.5, which is what debian-ppc64 (be) is based on.
1.5 and 1.9 never had SIMD / VMX / VSX so there shouldn't be a problem (for G5).
which, coming back to the original question, i'm not seeing a reason why disabling altivec should not compile.
unless, of course, there have been assumptions "#ifdef PPC64 equals POWER9 therefore VSX" which are unfortunately creeping in ever since EABI 2.0 came about?
l.
--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Reply to: