Cortex-A72 compared to Pi 3B+

[ejolson]

My understudying is that the Cortex-A72 features out-of-order execution and other optimisations that make it faster, more power hungry and susceptible to Spectre-type side-channel security problems than the A53 used in the Pi 3B and 3B+. Has anyone here made any first-hand comparisons of the relative performance between these two types of ARM cores running at similar clock speeds using standard benchmark programs such as HPL Linpack? I think both 64-bit mode and 32-bit mode results would be interesting.

[W. H. Heydt]

Take a look at the chart here: https://en.wikipedia.org/wiki/Compariso ... v8-A_cores

The last column (DMIPS/MHz) gives relative instruction rates.A53 is 2.24. A72 is 4.72. So something over twice the IPC rating.

[jamesh]

You also need to take in to account the process node used. The Pi3 SoC is on 40nm, whilst most A72 designed S0C's are on 28 or lower, and that makes a difference to the power requirements.

[jahboater]

You also need to take in to account the process node used. The Pi3 SoC is on 40nm, whilst most A72 designed S0C's are on 28 or lower, and that makes a difference to the power requirements.

Wow, I see the A76 is 7nm!

[DavidS]

It seems to be little more than an intelectual exersize at this point in time. Even a single A53 core used in the RPi 3B/3B+ is more than enough to render a fairly complex raytraced scene in under 0.05 seconds at a usable resolution (320x200 pixels), using only CPU soft rendering, without any trouble.

Processing power has got to the point of insane, the super computers of the 1990's could not hold a torch to even the first generation RPi, or the lowest end smart phone on the market for the last 8 years.

We can not even put the processing power we have to good use yet. Why do we want more processing power?

Yes we are good at finding ways of making things look slow, especially in the modern n*x systems, Windows, and Darwin systems. Though most of that slow is do to mass storage device access, either for swapped memory or unneeded read writes to verious files during operation, stuff that should be done in main memory. There is still the issue that memory does not keep up with the CPU also, even with the caching schemes that are now common place.

[jamesh]

Whilst I agree there is a lot of software out there that is so badly written it drags performance right down, there are some use cases there you do need LOADS of cycles.

Image processing from camera is certainly one, codecs is another. Trying to decode 1080p H265, even on a decent CPU set, will use most of your cycles (and a lot of SDRAM bandwidth) . Voice recognition, AI are other tasks that require a lot of oomph.

But word processing, webpages etc? If they are slow on a modern CPU then someone is writing some pretty awful software somewhere.

[DavidS]

Whilst I agree there is a lot of software out there that is so badly written it drags performance right down, there are some use cases there you do need LOADS of cycles.

For very short periods of time, yes. Of course it is proportional to the size of data being worked on, a multi megapixel image may take a few seconds to do a transform on.

Image processing from camera is certainly one, codecs is another. Trying to decode 1080p H265, even on a decent CPU set, will use most of your cycles (and a lot of SDRAM bandwidth) . Voice recognition, AI are other tasks that require a lot of oomph.

Agreed, still not enough to need a more powerfull system (unless you really can not wait a couple of seconds for the entire operation).

But word processing, webpages etc? If they are slow on a modern CPU then someone is writing some pretty awful software somewhere.

LOL, and yes. Unfortunately too often the case nowadays. Some of these programs I think could probably be written to run faster in ARM BASIC fully interpreted on an early RISC PC than they do on modern systems.

[W. H. Heydt]

We can not even put the processing power we have to good use yet. Why do we want more processing power?

The quip was directed at two particular companies, but it could be generalized...

Microsoft can burn up every processor cycle Intel can manufacture.

[ejolson]

Take a look at the chart here: https://en.wikipedia.org/wiki/Compariso ... v8-A_cores

The last column (DMIPS/MHz) gives relative instruction rates.A53 is 2.24. A72 is 4.72. So something over twice the IPC rating.

That's an interesting start. The Drystone appears well-suited to the-out-of-order optimizations in the A72. Since the DMIPS score contains no information on floating-point performance, I'm still wondering how HPL would perform.

It is possible that a benchmark which uses a well-tuned basic linear algebra subroutine library such as OpenBLAS will avoid stalls on the floating-point unit to the extent that the A53 and A72 perform much the same, assuming of course that the floating point units themselves are similar. From a practical point of view, the use cases I am considering are floating-point intensive scientific and statistical computations which range from fluid dynamics to deep learning.

[bensimmo]

We can not even put the processing power we have to good use yet. Why do we want more processing power?

The quip was directed at two particular companies, but it could be generalized...

Microsoft can burn up every processor cycle Intel can manufacture.

Only once Chrome has used most of it up first.
We need more 'power' because.. just look at games and the visuals. It's not long before the current big things come to a crawl and people (media and shareholders) demand more from a game.
Does it make them better... not really the point.

For most people turning an LED or similar switch on and monitoring some temperatures, then no you don't need anymore, in fact, a Pi Zero is even overkill.
Programming in a nice GUI way to do that need the power of the Pi for the average person and the Pi3 at that.

I assume most the Pi Engineers need more power than the Pi and few actually use it to do any work on?

I could do with more power than the Pi3 and my desktop to slice some 3D object, it's not the rate limiting step there though.

[DavidS]

We can not even put the processing power we have to good use yet. Why do we want more processing power?

The quip was directed at two particular companies, but it could be generalized...

Microsoft can burn up every processor cycle Intel can manufacture.

Only once Chrome has used most of it up first.
We need more 'power' because.. just look at games and the visuals. It's not long before the current big things come to a crawl and people (media and shareholders) demand more from a game.
Does it make them better... not really the point.

For most people turning an LED or similar switch on and monitoring some temperatures, then no you don't need anymore, in fact, a Pi Zero is even overkill.
Programming in a nice GUI way to do that need the power of the Pi for the average person and the Pi3 at that.

I assume most the Pi Engineers need more power than the Pi and few actually use it to do any work on?

I could do with more power than the Pi3 and my desktop to slice some 3D object, it's not the rate limiting step there though.

Slicing does take a few, that is the nature of it. I just do my slicing in the background, and let it take however long it is going to, I am usually waiting for my 3D printer to finnish the previous print anyway, the Raspberry Pi can slice a many many times faster than current FDM 3D printers can print, so if I can pre slice 100 models in the time it takes to print 1 what is the hurry.

[DavidS]

I must correct myself:

Slicing takes almost no time, what takes a while is everything else that is (mostly) done after slicing; comparing layers to find overhangs and bridges, bounds checks, generating the infill, path tracing, generating the g-code, etc.

[Heater]

W. H. Heydt,

Microsoft can burn up every processor cycle Intel can manufacture.

Just now I have to say that MS is not the worst offender.

On this machine I'm typing on now I have Chrome using 668MB of my 8GB RAM. I can perhaps forgive that, I have 20 odd tabs open.

Worse still in the IntelJ IDE, that is using 910MB with only a couple of little source files open. And it eats CPU cycles when doing nothing!

Of course InteliJ is written in Java, and that shows up separately as another 600MB of RAM consumption.

That's almost 2 gigs to edit a few little files!

Meanwhile, Microsoft's Visual Studio Code is also in use on this machine. A mere 300MB with 10 source file tabs open.

MS is doing quite well here. Oracle (Java) is causing Global Warming!

[ejolson]

Worse still in the IntelJ IDE, that is using 910MB with only a couple of little source files open. And it eats CPU cycles when doing nothing!

Maybe it's actually mining bitcoins instead of doing nothing.

Even the vim editor is a memory hog compared to the original vi, but one gets used to multi-level undo pretty quickly. Fortunately syntax highlighting can be turned off. Does IntelliJ IDEA include some sort of artificial intelligence or deep neural network to help people write better programs? Can it be turned off?

Still wondering about A72 versus Pi 3B+ performance.

[DavidS]

Still wondering about A72 versus Pi 3B+ performance.

Well that is a tough one indeed, if the A72 is a 64 bit only implementation then comparison becomes difficult. The reasoning being that many things will perform better in a 32 bit environment giving everything being equal, and most of what is run on the Raspberry Pi is 32 bit. Remember that with 64 bit you are having to transfer more data to and from memory for many operations, there are other considerations as well that I will not get into here.

The newer core is likely to be about twice as fast per clock as the RPi 3B/3B+ running a purely 64 bit OS, while there is no direct comparison for the newer core running a 32 bit OS.

So there is really no way to answer the question, we can not even directly test the answer if we had both and the ability to run EXACTLY THE SAME OS and Software on each of the two to test, simply because only half of the equasion can ever be tested.

[jahboater]

Still wondering about A72 versus Pi 3B+ performance.

Well that is a tough one indeed, if the A72 is a 64 bit only implementation then comparison becomes difficult.

We are OK there, its only the recent A76 and friends that are 64-bit only.
The A72 is quite old in this context, announced 2015.

[Heater]

ejolson,

Fortunately syntax highlighting can be turned off. Does IntelliJ IDEA include some sort of artificial intelligence or deep neural network to help people write better programs? Can it be turned off?

Like you I used to be old skool and considered IDE's and syntax highlighting as pointless fluff. A useless gimmick that sucks memory and CPU. A crutch for bad programmers. If you know your language syntax, know the libraries and API's you are using and think about what you are writing why would you need syntax highlighting?

But recently I discovered that these syntax high lighting, inteli-sensing IDE's can be very useful....

I have been getting into writing HDL to configure FPGA's with. Normally people would use Verilog or VHDL to do that but those languages are horrible. So I'm creating my logic designs in SpinalHDL http://spinalhdl.github.io/SpinalDoc/. Now Spinal is actually just a library for the Scala language that generates Verilog from your hardware description in Scala. This presents some problems: One, I knew nothing about Scala. Two, I was new to this HDL business. Three, I had to learn the Scala and Spinal API. As such the syntax highlighting and inteli-sensing of Scala in the Intelij IDE has been very useful.

The syntax highlighting helps me learn the Scala syntax.

The Inteli-sense highlights common errors like misspelled variable names, unused variables etc.

Auto-completion helps discover what is in the Scala and Spinal library APIs.

As a bonus it keep my source nicely formatted.

In short, my progress would have been a lot slower without all these crutches.

The downside of course is that Intelij, like other IDE's is a huge, slow, complex, clumsy thing. The fact that it is written in Java and depends on the JVM certainly contributes to much of that.

I doubt there is artificial intelligence or neural networks in these IDE's. But the do clearly have parsers for the languages they deal with that are constantly processing your source as you type. They are constantly building symbol tables and so on. Pretty much recompiling your code continuously.

[bensimmo]

Not to compare against the P3, but to compare the architecture, look for a Big/Little (or something similar).
You'll find an A53/A72 setup in the Huawei P9's (and Huawei various other brandings) basically their Kirin 950 or 955 (under the brand HiSilicon, but it's HuaWei.)
It's smaller at 16nm, and you'll need to slow the A72 down in frequency. (the A53 there runs at 1.8GHz, A72 up to 2.5GHz)

or the Snapdragon 650/652.

That's of course if you can separate the cores to only use one set or the other.
One thing is, should you slow the A72 core down given that part of the advantage is it is capable of running at a higher frequency.

edit to add, this may be of some insight/ might not be. https://www.anandtech.com/show/9878/the ... 8-review/3

[ejolson]

Not to compare against the P3, but to compare the architecture, look for a Big/Little (or something similar).

I've never used a big.LITTLE architecture system. I wonder how the scheduler decides which type of core for each process. I think you are right that one would need to disable the A53 cores in order to test the A72.

[6by9]

I've never used a big.LITTLE architecture system. I wonder how the scheduler decides which type of core for each process.

With a lot of complexity!
There were also two alternative modes of operation for big.LITTLE - either have a matched number of big and little cores and migrate all processes to the corresponding core, or just spin up the big cores on demand (ie the overall load hits a certain threshold) and migrate the heavyweight operations onto a big core.
It took a fair amount of reworking on the scheduler to try to manage the switchover, with hysteresis to avoid bouncing up and down, and yet I still recall having fun on Android phones when the platform team messed it up.

https://en.wikipedia.org/wiki/Heterogen ... processing for a reasonable description of the principles.
big.Little has benefits where you are really needing to power save (eg mobile devices). The Pi isn't really aiming at that market, so I'm not sure there is a significant gain from the added complexity.

[bensimmo]

Not when half the power is supped up by the ethernet chip

This was just to compare the 72 to 53 with all other parts being (assumed) equal. though A73 replaced it in most chipsets.

Can they switch to using the A53's then ramp up to include the A73 for optimised pathways so a full octa-core usage (e.g. background usage and control on A53 and the video and website on the A72s)
I guess I would need to read that link and it's probably more how the manufacturer set them up and programmers can use them.

We'd want a straight 8x A76's and for $35

[W. H. Heydt]

I've never used a big.LITTLE architecture system. I wonder how the scheduler decides which type of core for each process.

With a lot of complexity!
There were also two alternative modes of operation for big.LITTLE - either have a matched number of big and little cores and migrate all processes to the corresponding core, or just spin up the big cores on demand (ie the overall load hits a certain threshold) and migrate the heavyweight operations onto a big core.
It took a fair amount of reworking on the scheduler to try to manage the switchover, with hysteresis to avoid bouncing up and down, and yet I still recall having fun on Android phones when the platform team messed it up.

https://en.wikipedia.org/wiki/Heterogen ... processing for a reasonable description of the principles.
big.Little has benefits where you are really needing to power save (eg mobile devices). The Pi isn't really aiming at that market, so I'm not sure there is a significant gain from the added complexity.

You need people with longer memories. CDC was doing something remarkably like this with the CDC 6600...over 50 years ago. Granted, it only had one "big" processor (the CP), and 8 "little" processors (PPs). The scheme was that the OS ran on PP0 and PP1 through PP7 were for handling I/O. User programs ran on the CP. The CP was a 60-bit machine while the PPs were 18-bit machines.

So...why not run the Linux kernel on a "little" core and use other "little" cores to handle things like USB and other interfaces and run the applications on the "big" cores?

[ejolson]

So...why not run the Linux kernel on a "little" core and use other "little" cores to handle things like USB and other interfaces and run the applications on the "big" cores?

It looks like schedtool can be used to set processor affinity and force an application to run on any subset of cores you want. Maybe there is also a way to force specific Linux kernel worker threads onto specific cores. I expect for performance reasons you generally want to stay on the same core when switching rings into a system call. I wonder if anyone with A72 hardware will agree to run some performance tests.

[Imperf3kt]

Not entirely sure if this is related but hey, I found this interesting processor that claims it can use A53 or A72 cores
https://en.wikichip.org/wiki/mediatek/helio/mt6797