3 ms·

I think this could actually be somewhat competitive outside of the RISC-V developer and enthusiasts market, if the performance is a advertised: Cortex-A55 30% f

I think this could actually be somewhat competitive outside of the RISC-V developer and enthusiasts market, if the performance is a advertised: Cortex-A55 30% faster, 20% more efficient, that should be similar to the Cortex-A510, and dual-issue RVV 1.0 with VLEN=256 AFAIK there is currently no Cortex-A510 easily available SBC, and this should have 2x the vector performance than it. (A510: dual-issue 128 bit neon vs X60: dual-issue 256 bit RVV) Edit: I had ", not factoring in that RVV is generally a more expressive/feature-rich isa than neon" in the above, which is true, but the Cortex-A510 also supports SVE has a similar feature set (it includes gather/scatter/compress operations). This might be ideal for low power applications that need a decent amount of cores and can take advantage of vector compute.

brucehoult 3y ago
1 MB of L2 cache shared between all 8 cores is a bit light. VisionFive 2 (etc) has 2 MB shared between 4 cores. It works well. LicheePi 4A (etc) has 1 MB shared between 4 cores, which may or may not be one of the reasons it's slower than VF2 in real world use, despite its higher clock speed and OoO µarch. As the Arm world found out a few years ago, a well done dual issue in-order like A55 (or U74) came come very close to OoO (A72) performance, but at much lower energy usage. The distinguishing factor of these modern dual-issue is that they duplicate the ALUs into "early" and "late" ALUs, such that you can issue two dependent instruction together and the 1st one uses the early ALU and the 2nd uses the late ALU. You only get a stall if the dependency chain continues not only into the 3rd instruction (which can execute late), but also the 4th depends on the result of the 3rd. Put an independent instruction anywhere in there and the pressure is off. This is much cheaper in area and energy than doing full on OoO, but gives a very significant performance boost over basic dual-issue e.g. A53. It's interesting that Arm went to triple-issue in-order with the A510, but reverted back to dual-issue in the A520.

brucehoult 3y ago

1 MB of L2 cache shared between all 8 cores is a bit light. VisionFive 2 (etc) has 2 MB shared between 4 cores. It works well. LicheePi 4A (etc) has 1 MB shared between 4 cores, which may or may not be one of the reasons it's slower than VF2 in real world use, despite its higher clock speed and OoO µarch. As the Arm world found out a few years ago, a well done dual issue in-order like A55 (or U74) came come very close to OoO (A72) performance, but at much lower energy usage. The distinguishing factor of these modern dual-issue is that they duplicate the ALUs into "early" and "late" ALUs, such that you can issue two dependent instruction together and the 1st one uses the early ALU and the 2nd uses the late ALU. You only get a stall if the dependency chain continues not only into the 3rd instruction (which can execute late), but also the 4th depends on the result of the 3rd. Put an independent instruction anywhere in there and the pressure is off. This is much cheaper in area and energy than doing full on OoO, but gives a very significant performance boost over basic dual-issue e.g. A53. It's interesting that Arm went to triple-issue in-order with the A510, but reverted back to dual-issue in the A520.