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 shar

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.