[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal
luke.leighton at gmail.com
Fri Aug 9 11:11:04 BST 2019
Andrew, Bruce: I'm sorry, I'm having real difficulty understanding the need
for a "quantitative" analysis, here. It makes absolutely no sense.
Now, for the case where, for example.... let's say... an xBitManip "ROR"
instruction, that's easy to do. Crypto uses it, therefore crypto
performance is adversely impacted, therefore it's easy to justify.
Or, let's say... an opcode that can be used for big-integer math "carry".
You get some algorithms, you look at what the performance is before and
after, and it's easy to justify.
However with 3D and OpenMP, it's a whole different ballgame (not so with
Machine Learning, which can use the same APIs, just with different accuracy
Not only is the market *already pre-justified*, by massive billion-dollar
Corporations such as NVIDIA, AMD, Intel etc., there's pre-defined hardware
APIs in the form of the Khronos OpenCL opcode specification:
that these companies collaborated to create such a specification, that *IS*
the "justification". attempting to do a "quantitative analysis" of
*already proven opcodes* - repeating decades-long Industry-proven
customer-backed ongoing acceptance is both staggeringly time-consuming and
completely pointless, at the same time.
Machine Learning augmentations on the other hand are a different story, as
the field is so new that not even the billion-dollar GPU companies have
proven up-to-date useful hardware.
The justification for these opcodes is thus effectively one word:
"Vulkan". If it's in the Vulkan spec, that *is* the justification, because
failure to include opcodes that SPIR-V supports *automatically* penalises
any such hardware.
The other justification is - again - not quantitative, it's collaborative.
The whole point of RISC-V is that it provides a central focal point for
different stake-holders to utilise it and reduce their NREs and their
customer costs and time to market. Having these trigonometric opcodes -
and compliance with the Vulkan API that goes with that - *is* a
justification in and of itself.
So i'm really sorry, but a "quantitative" analysis of a near-exact replica
of the Kronos OpenCL opcodes is misleading, pointless, and a hopeless waste
of everybody's time.
Does that make sense?
More information about the libre-riscv-dev