Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Gabriel Paubert <paubert@iram.es>]

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.

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. 

At least for PPC until now, it has been 128 bit registers, always.
> 
> 
> > 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.

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).


> 
> unless you create a new triplet PPC64-LE-using-EABI-1.5
> 

I don't think so, stay with BE.

> 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
> >    capabilities
> 
> 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
> level.

You have to be BE anyway (kernel and userspace) to support the oldest 64
bit processors. The switch to LE occured during Power7, but I believe
that real official distro support only happened with Power8.  

Locating libraries at program startup is done by ld.so, not by the kernel.


	Gabriel