64-bit RISC-V core claims 10x better CoreMarks/Watt compared to other 3-5GHz CPU
linuxgizmos.com
linuxgizmos.com
A big red flag is the Cortex-A9 comparison that is used, being described as the faster arm processor for CoreMark, if you go to to EEMBC's CoreMark score database (https://www.eembc.org/coremark/scores.php), search 'arm' a Cortex A9 part does indeed take top score. Note this are just user sumbitted scores without any real curation, searching 'arm' isn't guaranteed to give you all arm cores in the database, plus results could have errors in.
Given the age of the core (it was introduced in 2007) I'd be rather surprised if the A9 was the best performing arm core on CoreMark. Though From a quick google I can't find CoreMark numbers for other arm A-class cores.
Is the focus on efficiency covering up that it can't scale up to be actually as fast as the m1?
It all seems a bit too good to be true, what's the catch?
Take a look at their press release here: http://www.micromagic.com/news/CoreMark_PressRelease.pdf
They claim 11'000 CoreMarks at 4.25 GHz in what is presumably their more efficient running mode (0.8v, consuming 200 mW). That gives you 2.58 CoreMark/MHz which is quite poor even comparing against high-performance embedded, let alone the likes of the M1 (The arm M4 can achieve 3.42 CoreMark/MHz for instance). That indicates a microarchitecture that will choke on more complex workloads.
I think what they've done is produce a super simple 64-bit RISC-V core they've focused on clocking as fast as possible and pushing the power down as much as possible. Does a good job on CoreMark/Watt numbers (assuming they're even correct!) but useless for any real application.
Either you want a desktop/server style workload in which case their IPC, and hence total performance and efficiency, will drop through the floor, or you have something more CoreMark style in which case you don't need it running at anything like 5 GHz and you're far better off with one of the many embedded cores on the market.
It seems that their measurements are based on what the current reading said on the screen of a $60 noname ("Hanmatek") power supply. [1]
I don't now much about CPU loads, maybe it's constant and the reading is reasonably accurate, but I'd at least hope for some better measuring equipment.
[1] https://www.amazon.com/Adjustable-HANMATEK-HM305-Variable-Sw...
A modern AMD/intel uses very few gates to implement the arithmetic. we are talking ~1% of the gates actually do the work. The rest is taken up by Cashes, Schedulers, Branch predictors, Decoders, and a load of other stuff that is designed to speed up the CPU to get good single core performance. all this extra hardware takes up a lot of power.
Here is an interesting thought experiment:
On a large die you could (theoretically) today fit say one million Motorola 68000 Processors. If you clocked that at 5Ghz it would in theory be about 1000 times faster then a Ryzen 7 using the same power. But it would still mean that each core would be hundreds of times slower then a Ryzen core. It would be almost impossible to write programs that would utilize all one million cores effectively enough to make a program run faster on this hardware than it does on a Ryzen CPU.
Right now RISC-V is very simple this means it draws very little power. The problem is that it doesn't scale. The RISC-V instruction set is not one that makes it easy to add all the optimizations that one wants to add for a high performance CPU.
Its a bit like saying that an ant is more efficient than a bulldozer, yes, that's technically true, but trying to coordinating a million ants to build a road is a lot less efficient then just using a bulldozer.
The CPU you describe would be great for embarrassingly parallel simulation, machine learning, and similar tasks. I wish there was such a thing.
Another thought that I’ve had for a while is that Intel’s Itanium was maybe a good idea badly executed or before it’s time. If you really could offload a lot of that to the compiler you could in theory maintain a lot of single thread performance while having far more cores.
GPUs are essentially, very many simpler cores on a big die, and the reason it works is that the programing model is inherently parallel. (You almost always want to compute many pixels)
GPU "cores" are different because they have graphics specific instructions like texture lookups.
They are also different because you want to run the exact same program on many cores at once. So you have have one instruction decoder/dispatcher that control more then one core. This leads to some weird behavior, like if you have a branch in shader code, all cores may compute both branches, but then each core may mask away the result of what ever branch the specific core shouldn't have taken.
Your "there are cores inside my cores" explanation is what's causing the confusion.
As imtringued suggests, that's not quite right. In SIMD terms, all lanes of the core will be 'along for the ride' in case of control-flow diverging. The core must run the instructions for both branches, effectively disabling and re-enabling its various lanes as necessary. When disabled, a lane does no work.
What SIMD calls a lane, SIMT calls a work-item or (perhaps more confusingly) a thread. The term 'core' refers to the level at which there is independent control-flow, much like in CPUs.
See https://en.wikipedia.org/wiki/Single_instruction,_multiple_t...
it's a russian company, heavily backed by russian government/army/3letteragencies
it's hard to tell how successful they are, but there are some benchmarks https://github.com/EntityFX/anybench/blob/master/results/e2k...
Right. Then, you have to consider how to supply power to all these transistors switching at once, which would well be in the ~10-100A range and beyond. So you have to figure out how not to have it melt (dark silicon, chiplets to have a lower power/area ratio, etc).
And once you have it not melt, you have to figure out a way of making it useful: keeping the processors fed with data.
Because even the algorithms that crunch just a few variables need to be supplied with those, as well as instructions, etc. This ends up sucking a lot of energy, when you have to clock long lines at 5GHz times the number of CPUs times bus width (you can trade hertz for bus width). To avoid this, we use caches. Good luck keeping your CPU count at 1M with the area SRAM needs. AMD GPUs have been memory bandwidth-starved for a few years now, their latest generation features a whooping 128MB cache.
Adiabatic/reversible computing is another way to get around that, but we're not there yet, and isn't a silver bullet either.
Von neumann architectures is the thing that doesn't scale. In my opinion, we are going to go back to specialized computing, especially since Moore's Law left us in the cold a few years ago. And RISC-V is quite extensible, which makes it relatively suitable for specialized architectures.
I hope it at least illustrates that Perfomance / per watt is nice, but unless the perfomance is good enough to be ballpark where you need it, it doesnt matter too much.
If there was a dual core CPU where each core ran twice as fast as the fastest Intel/AMD core at the same Watt as an 8 Core Intel/AMD CPU, It would sell like hot cakes, even if it was half the Performance per Watt.
Not even in this case, the performance and energy numbers they got for CoreMark on the M1 are off by an order of magnitude
I'm actually curious why we have not seen many-core devices. Typical desktop CPUs still only have 4-8 cores, as do mobile devices. (disregarding the many small hardware-management cores like SSD controllers, GPU management, modems, ...)
Why not have many more cores with different performance profiles, that then are dedicated to various tasks. Like a bunch of low power, in-order cores for background OS management or background apps like Slack that just check for new messages and send notifications, ...
Naively I would assume:
* the increased hardware complexity (wiring, caches, ...) makes this both cost and power budget prohibitive
* current operating systems are not really built for that world
* the benefits compared to current big/little designs with two hands full of cores are not worth the effort
Maybe someone knowledgable can offer more insight?
Alot of DSP and networking tasks are handled by the modem itself.
Software and Compiler toolchains are often quick to optimize for any improvements that a processor provides but the bottleneck generally is cost and complexity which don’t scale linearly.
Single core performance is critical and core count has rapidly diminishing returns for the majority of everyday tasks (Amdahl's law and all that).
When you have independent tasks that need to run massively parallel you are better off using a different architecture because you can get better value from simpler compute units.
Why would you need a lot of actual CPU power after all that?
Of course it is easier to program for a homogenous architecture, be it CPU or GPGPU.
I can see the battery life advantages of using a lot of low-power cores for background tasks like networking and I/O and reserving a few very fast cores for foreground apps. If a background music player can get one or two slow background cores while you're using your device for some heavy workload you'll see fewer context switches and better optimized L1 cache for your main task.
My computer has 12 cores but runs 118 processes even when idle. Phones probably run maybe half that, but even still a high core count for even sub-gigahertz cores could bring a noticeable benefit if the OS's scheduling algorithm would be able to optimize for them.
I don't think lack of general-purpose cores has been a problem for mobile for a long time. I see much more value in heterogeneous SoC's that integrate multiple application-specific blocks that can only do a few things but do them very, very efficiently. This is pretty much what the industry has been moving towards for the past few years anyway, the Apple M1 being a good example of that.
M0+ is 0.009mm^2 at 40nm. You can probably add another zero with two full node shrinks. M4 is just 0.04mm^2 at 40nm. M7 is probably 2-3x the size and M55 with SIMD (zero architecture relation to A55), but without tensor cores is probably 2-3x that size.
Accounting for die shrink and core growth, we basically get back where we started with M55 being around 0.04mm^2 and A53 being around 1mm^2 at 20nm. Even if I were off a further order of magnitude (not likely given that it's still just a 4-stage, in-order core), it would still be only 2/5 the size. I'd note that A55 is bigger than A53 by some amount (I don't think ARM has released that data).
If I'm right, you can fit 25 M55 cores in the space of one A53. Even if I'm very off, you could still fit 2.5x as many cores.
Dedicated cores for system processes has a few desirable effects. They are on simpler designs less likely to be exploitable with the latest order and timing attacks. They don't need to be interrupted often. This decreases context switching latency (which can exceed actual processing time). Less data moves around the chip decreasing power consumption. Prefetching can be more accurate with a smaller transistor budget and even cache sizes can decreases per core due to single purpose use. Since it's single use, you can also clock gate it completely when not in use.
I'd rather like to see a phone chip design with a hundred tiny cores each anchored to one process in place of 4 A55 cores.
This one is more marketing than a technical post worthy of HN.
Sigh. So much for the openness.
[1] https://www.eetimes.com/micro-magic-risc-v-core-claims-to-be...
[1] https://www.zdnet.com/article/risc-v-the-linux-of-the-chip-w...