Yup, there was a long wait for it since people were excited for an SBC SoC with something other than A72 on it. Took way too long to get to market, hence my comment about the O6 and RK3688.
Yup, there was a long wait for it since people were excited for an SBC SoC with something other than A72 on it. Took way too long to get to market, hence my comment about the O6 and RK3688.RK3588 was announced long before it actually went to fabs I think.
The specs they originally announced were different to what they later made.
For some a vector can only look like CDC and Cray vector implementations. Anyway the point is moot: the article under discussion clearly classifies both R-V vector and Arm SVE as vector extensions:A bit of reading seems to imply by SIMD's basic definition that is a vector, depending on what you classify to be a vector:
Row and column vectors - Wikipedia
en.wikipedia.org
Vector instructions such as RISC-V vector extension [9] and ARMSVE [18] have recently been introduced in general-purpose CPUs [1,17]. A vector instruction processes multiple data elements in atime-division manner, achieving high performance with lower hardware cost.
Ye, the Amlogic 'competitor' S928X took even longer to get to market and on a larger node to boot.Yup, there was a long wait for it since people were excited for an SBC SoC with something other than A72 on it. Took way too long to get to market, hence my comment about the O6 and RK3688.
Wait, there isn't v9.3 CPU core?IIRC the GPU spec changed from one more contemporary to the A76 to the G610.
I might be misremembering things though.
RockChip have an annoying tendency to be ambiguous with specs of future SoCs sometimes, like the RK3688 mentions a v9.3-A CPU core, but according to latest rumours of X930 and Ax30 they are v9.4-A ISA instead 😒
Not sure at this point.Wait, there isn't v9.3 CPU core?
IIRC v9.3 contains almost nothing of interest. In particular SME2 can be implemented with v9.2.Wait, there isn't v9.3 CPU core?
A bit of reading seems to imply by SIMD's basic definition that is a vector, depending on what you classify to be a vector:
Row and column vectors - Wikipedia
en.wikipedia.org
Here is a link to hotchips slides for SXAurora Vector Engine Proccessor https://old.hotchips.org/hc30/2conf/2.14_NEC_vector_NEC_SXAurora_TSUBASA_HotChips30_finalb.pdf, Anandtech did a live blog on it here https://www.anandtech.com/show/13259/hot-chips-2018-nec-vector-processor-live-blog. The blog post mentions OoO, while the slides are using OoO scheduling. You can also find SX-ACE slides here https://old.hotchips.org/wp-content...e-epub/HC26.11.110-SX-ACE-MOMOSE-NEC-v004.pdf
From high level point of view they seem similar, SX-ACE hotchips slides don't mention OoO explicitly as far as I can tell. But still Aurora seems like an evolution of ACE so they thought that adding OoO scheduling is important.
But maybe Intel EPIC would have eventually also develop into hardware-OOO machinery......
Intel experimented with it. The final gen, Poulson, was also dynamically scheduled and could have been extended to full OoO relatively easily.
For EPIC it was only potential way to go forward.
Too many vectors.....Vector cpu vectors are loops of independent scalar operations which can take different paths. Direct not abstracted SIMD hardware uses packed vectors -without shuffle instructions hardware is identical to scalar but operate with packed vectors instead of scalar operations. OOO is so identical for SIMD hardware as scalar hardware - one op per vector. Vector ISA code instead have hundreds of possible ops per vector.
I invite you to show us some RISC-V vector code that demonstrates that it fits that "definition" which I don't understand.Vector ISA code instead have hundreds of possible ops per vector.
I can only assume that they mean instead of SIMD's "every problem must fit 4 hammers at once" take that 'vector ISA' code can do a lot more than 4 operations per instruction, or possibly any number of operations from 2 to whatever the limit is.I invite you to show us some RISC-V vector code that demonstrates that it fits that "definition" which I don't understand.
I can only assume that they mean instead of SIMD's "every problem must fit 4 hammers at once" take that 'vector ISA' code can do a lot more than 4 operations per instruction, or possibly any number of operations from 2 to whatever the limit is.
I invite you to show us some RISC-V vector code that demonstrates that it fits that "definition" which I don't understand.
It really wasn't.
So can you exhibit R-V code that demonstrates that it is more of a vector ISA than SVE?Vector cpus vectors are independent scalar ops. Vector cpu''s can usually chain those ops between execution units and if data addresses are known there's no need for hardware out-of-ordering. OOO will be needed when addressing is calculated dynamically on the fly and when doing so there's as many tracked ops as there's scalar ops in vectors as they are independent ops and not packed to solid packed vectors. With low-width SIMD hardware it's still possible to do hardware data tracking and ordering but as those NEC engineers noted, it's pretty impractical to track and rearrange wide alu count vector machine ops, like those 256 per cycle on that Nec design. Hardware limitation makes it possible to do either wide in-order execution units or much narrower OOO units.
So can you exhibit R-V code that demonstrates that it is more of a vector ISA than SVE?
Hardware can easily detect data patterns from runtime execution which cannot predict in compile time. When it detects those and those are critical for code timing it's only logical to add out-of-order hardware to execute those in advance. Intel hardware designers did know what to do
but such a complex ISA implementation made hardware implementations too complex to be any competitive against simpler designs.
Welcome back, Sarah KerriganOn the contrary, IPF cores were fairly small; Itanium silicon was dominated by SRAM (and the small cores compared to, say, Power meant that IPF was able to bring LLC on-die almost a decade prior to IBM.) Additionally, Itanium was competitive against comparable RISC and x86 server processors as long as Intel and HP were continuing to seriously invest in it. Even after the Montecito fiasco, where a late-breaking erratum in novel power management features caused Montecito to be delayed by a year and to lose 15% of its projected clock speed, the resulting part was essentially performance-competitive at release. Itanium silicon only became uncompetitive when RISC/UNIX as a whole had started to decline. By that stage, there were non-technical considerations in play - I have an informed suspicion that Poulson, a massive improvement, was deliberately held back by at least a year so that the hilariously bad Tukwila could have a full sales lifecycle.
I think we already went through this. I'd really like to see code VL agnostic and make comparisons of SVE vs R-V vector extension.I don't understand why? RVV is vector isa, pure and clean. SVE instead is scalable packed SIMD - which doesn't actually work beyond academic use cases. In vector isa underlying hardware is totally abstracted, code just works in any hardware if ISA and hardware are bug free. SVE instead is relying software support for different width SIMD hardware -that ain't newer worked and probably newer will. I really don't know why ARM wants to push that braindead solution which both software and hardware vendors don't want to use.
Welcome back, Sarah Kerrigan