The claims here do seem a little suspicious, for one CoreMark is not the be all and end all of benchmarks, especially if you're trying to compare yourself against the M1 and other CPUs in a similar class. You need a far broader base of benchmarks for a decent comparison (for one thing CoreMark won't give the memory system much of a workout).
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.
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.
Their math is incorrect.
The M1 scores about 300K in Coremarks and has 8 cores => 37.500 per core. M1 consumes about 12W => 1.5 W/core and thus: 37.500 ÷ 1.5 W/core = 25 K Coremarks per Watt.
But this company (or Andy Huang) is claiming M1 has 100 Coremarks per Watt!
Why don’t people check their math if it sounds far off?
I saw multiple people (outside of HN) come up with similar numbers for the M1. The numbers are impressive (2x-3x more efficient than M1) but the extreme dishonesty makes the design look like snakeoil. If you're ahead why lie? Probably because the design isn't actually as good as the press release implies.
The photo from the press release doesn't inspire much confidence.
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.
It's pretty normal for lower complexity cores to be more power efficient than higher complexity cores. Many structures in a processor scale as N^2 with width in terms of both transistors and power usage.
“For a typical 5W device, we can implement 25 cores. Who can do 25 cores in the mobile phone industry?”
I think he forgot to ask himself the really important question : who want 25 cores in a smartphone!
I think you're forgetting to ask yourself if you can do 25 cores with 5w, you can have 5 cores with 1w, which would be pretty damn good in a mobile phone if it's for real!
You run into diminishing returns with screen and radio power on a cell phone pretty quickly. If your phone is sitting in your pocket in airplane mode those aren't a problem, of course, but your processor will be sleeping then anyways.
We've already got 12 (4 fast + 8 slow) cores in mobile phones, why not more?
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.
Just a few low-activity OS & mostly sleeping application threads will barely fill one or two of these typical 'slow' cores you see in big.LITTLE SoC's, so what's the point of adding more of 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.
Those "slow" cores are very big and complex in comparison to an actually small core. A53 in 20nm Exynos 5443 is 1mm^2 without cache (0.55mm^2 for 256k cache) and that's the smallest variant I could find numbers for without die shrinks.
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.
> Who can do 25 cores in the mobile phone industry?
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?
The tradeoff is to keep design complexity as low as possible while carving out sections of the chip for specialized tasks. Apple’s new M1 chip has a ‘neural processor’ that works with Tensorflow to provide a speedup. They thought it was worth the added complexity. They also have 4 low power cores for background tasks.
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.
What do you mean ? You can get the same core design in 4 core and 64 core part with ryzen for example - the difference is price and power.
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.
How are those “many small hardware-management cores like SSD controllers, GPU management, modems, ...” not “many more cores with different performance profiles, that then are dedicated to various tasks”?
ARM phones tend to have specialized cores. You have big.LITTLE, added DSP, ML chips, modem DSP and cpu, hardware media decoders and encoders. And of course GPU w/ GPGPU capability. Maybe tensor cores next.
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.
Well a simple CPU is much more efficient then a complex one.
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.
Aren't GPUs a bit like your example but not quite as extreme?
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.
That's a really weird explanation of SIMD. There are big fat cores in GPUs but each core can process the same instruction stream 32 or 64 times but with different data. If there is only one core but two branches have to be taken it is obvious that the core has to process one branch after the other.
Your "there are cores inside my cores" explanation is what's causing the confusion.
> if you have a branch in shader code, all cores may compute both branches
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.
> 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.
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.
You are right, I'm simplifying a lot. I'm ignoring all kinds of issues like how all one million cores would communicate with memory or each other.
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.
> Unlike Arm, the RISC-V Consortium does not compel disclosure of use. In 2021 we are likely to see many new RISC-V chips spring to life fully formed out of secret R&D labs.
35 comments
[ 50.8 ms ] story [ 1556 ms ] threadA 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?
[0] https://news.ycombinator.com/item?id=25263011
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...
[1] https://www.zdnet.com/article/risc-v-the-linux-of-the-chip-w...
[1] https://www.eetimes.com/micro-magic-risc-v-core-claims-to-be...
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.
I'd much prefer more RAM so the os can keep the apps I'm running paged in for longer.
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.
This one is more marketing than a technical post worthy of HN.
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
Sigh. So much for the openness.