Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Mar 1, 2021 at 8:39 AM Gabriel Paubert <email@example.com> 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.
> the overhead of every single emulated
> instructions is counted in hundreds of cycles.
> IMHO, the only solution is to:
> a) only use SIMD in library code
> b) compile 2 or 3 versions of libraries: no SIMD, VMX and/or VSX
this requires going backwards to EABI 1.5. EABI 2.0 as currently
defined *makes SIMD mandatory*.
given that debian PPC64 is BE EABI 1.5 but PPC64LE is LE EABI 2.0 i
don't see how that's workable.
unless you create a new triplet PPC64-LE-using-EABI-1.5
also: multilib and it is being ripped out from distros.
> c) put each library in a different directory
> d) at run time, select the path to load the libraries from CPU
this is multiarch i believe. it requires, as i recall, a
syscall-level understanding of the two ABIs. with ppc64 being BE and
ppc64le being LE this would require word-order swapping at the syscall