[gentoo-user] Re: CFLAGs for kernel compilation

[James]

Volker Armin Hemmann <volkerarmin <at> googlemail.com> writes:


> >>>>>> http://www.agner.org/optimize/calling_conventions.pdf
> >>>>>
> >>>>> Not sure what you're trying to say.
> >>>>>
> >>>>
> >>>> that simd is not save in kernel if not carefully guarded.
> >>>>
> >>>> Really people, just don't fuck around with the cflags.
> >>>
> >>> I still fail to see the relevance. Unless you mean using a different
> >>> -O level. In that case, yes. You shouldn't. But I was talking about
> >>> -march.
> >>>
> >>
> >> you said this
> >>
> >>>
> >>> (note that SIMD is not FP and is perfectly fine in the kernel.)
> >>
> >> and I have shown you that you are wrong.
> >
> > Not sure why you think that. The kernel crypto routines are full of
> > SIMD code (like SSE and AVX.) Automatic vectorization wouldn't work.
> > But -march is not going to introduce that
>
> and never used in interrupt context and carefully guarded. You act like
> 'oh, you can use simd instructions without any consideration' and that
> is just not true.


Volker,
Historically, you are correct. Looking forward, GCC-5.x will (can?) change
this as the simd and other hardware, including (DDR_5) memory all become
available  for (compiler) usage. For the longest time, we the FOSS
communities, have at best been given access to low lever APIs for access to
some of these hardware resources. All processor architectures are at war.
Intel (the bastards) have had FPGA and tools to reconfigure the amount and
types of hardwware in some of their  processors for quite some time. 

The Arm64 cores have simd (GPU if you like) centric cores on the same SOC as
the arm64 bit licensed CPU cores. The new gpu has already been integrated
into the processor cores (same substrate) just the the i387 FPU was some
decades ago. So Arm is providing 'bare metal' access to various customers
and compilers Since there are thousands of vendors building up customer
arm64 SOCs there is no way for Arm to constrict, like Intel, Nvidia and AMD
have historically done. Game_set_match.  

Even though those GPU cores available via arm64 are very weak compared to
Nvidia and AMD; bare metal access to those (gpu) resources if far superior
to what Intel (dragging their feet), Nvidia or AMD are offering. Just look
at how AMD's Mantle has stalled for the FOSS communities. Amd, via
competition from  a myriad of arm SOC vendors, is being forced to roll out
Arm64 bit server chips, just to stay relevant. Both of you guys are looking
at this issue, from historically color-coded sunglasses. Change is here; get
onboard with helping the masses help themselves to the feeding (coding) freenzy.


What a pair of really smart guys like you (2) should be doing is setting up
a gentoo wiki listing and demonstrating for others how to "profile" low
level codes: both kernel and system level, so these other gentoo folks *can
learn* about what you are saying  by example; running tools such as
kernelshark, and other performance/profiling types of analysis. Providing
seemless  and generic access to the gpu resources will go a long way towards
revitalizing FOSS cryptographic dominance; and that is a very good thing. ymmv.


For the record,  most simd hardware really sucks for dense_matrix
requirements. Most simd hardware only really works for sparse matrix
apps, like x.264 because the overlying (embedded) algorithms used are poorly
documented by intention from the hardware vendors. I do not have direct
proof; but I strongly suspect this is the case because the simd pipelined
memory  that these low level APIs give to FOSS community, are memory
constricted by design.


peace,
James