[HN Gopher] ARM's Cortex A53: Tiny but Important
___________________________________________________________________
ARM's Cortex A53: Tiny but Important
Author : ingve
Score : 233 points
Date : 2023-05-28 09:12 UTC (13 hours ago)
(HTM) web link (chipsandcheese.com)
(TXT) w3m dump (chipsandcheese.com)
| causality0 wrote:
| "Efficient cores for low power tasks and performance cores for
| demanding applications" is a catchphrase I've seen hundreds of
| times but I've never once seen someone actually demonstrate it or
| test it, or even really explain how my phone decides which is
| which. Does WhatsApp run on an efficiency core most of the time
| but swap to a performance core when it's converting a video to
| send?
| jffry wrote:
| I found this [1] which says:
|
| "Generally, when the game is in the foreground, persistent
| threads such as the game thread and render thread should run on
| the high-performance large cores, whereas other process and
| worker threads may be scheduled on smaller cores."
|
| There's also a Wikipedia article [2] which talks a little about
| scheduling. I imagine Android probably has more specific
| context it can use as hints to its scheduler about where a
| thread should be run.
|
| [1] https://developer.android.com/agi/sys-trace/threads-
| scheduli...
|
| [2] https://en.wikipedia.org/wiki/ARM_big.LITTLE#Scheduling
| charcircuit wrote:
| It's mostly the Linux scheduler
|
| https://www.kernel.org/doc/html/latest/scheduler/sched-capac...
|
| Android does set niceness for processes. See the
| THREAD_PRIORITY_* constants
|
| https://developer.android.com/reference/android/os/Process
|
| and it uses cgroups too. Process.THREAD_GROUP_* has some
| Android ones, but different vendors sometimes write their own
| to try and be clever to increase performance.
|
| https://source.android.com/docs/core/perf/cgroups
| pm215 wrote:
| It's also worth bearing in mind that there's been a lot of
| work put into that scheduler over the years so it will make
| better decisions about what to run where when the cores
| aren't all the same.
| masklinn wrote:
| https://eclecticlight.co/ Has multiple articles characterising
| the M1 (and M2) and how the MacOS scheduler uses it.
|
| I'm sure Android's scheduled does things differently but it's
| at least an idea of the sort of things which can happen.
|
| For macs (and I assume iOS) the basics are that background
| processes get scheduled on E cores exclusively, and higher
| priority processes get scheduled on P cores preferentially but
| may be scheduled on E cores if the P cores are at full
| occupancy.
| Yoofie wrote:
| Someone else posted a really compelling video where they test
| the power efficiency of Android and Apple phones.
|
| https://youtu.be/s0ukXDnWlTY
|
| Its really quite informative.
| yukIttEft wrote:
| When looking at die shots like
| https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2023... I
| always wonder how people are able to label things. How does one
| figure out what part does what?
| barelyauser wrote:
| Because they know what to look for? Designers can't hide stuff
| out that much.
| [deleted]
| curiousObject wrote:
| It's easier to understand if you look at an analysis of a much
| older, less dense, die. Ken Shiriff is a superb source of these
|
| There are some visual clues. First, the chip pins are labeled
| in the spec so you can guess they'll be close to relevant
| units, and also try to trace their connections throughout the
| die.
|
| Second, units like memory have an obvious regular structure
| because they are made from many identical micro-units
|
| Third, if you see, for example, 16 identical adjacent units you
| could guess this is something that could be dealing with data
| 16 bits at a time. That narrows it down
|
| There are numerous clues like those.
|
| You could also use tricks like using a thermal camera. What
| part gets hot when you do certain operations?
| nativeit wrote:
| +1 on Ken Shiriff's blog, and his work with @curiousmarc on
| YouTube. Those gentlemen are national treasures whose work on
| restoring, documenting, and appreciating vintage computing
| and Apollo-era technology have been second to none in their
| breadth and depth.
|
| I also personally really value their work--for anyone with
| intermediate to advanced knowledge of electronics engineering
| and computers, they are an invaluable source of educational
| entertainment as traditional mainstream media simply doesn't
| cater to such niche audiences.
| samstave wrote:
| One of my professional regrets was when I worked at Intel in
| 1997, I had 30x42 plots of chip dies hanging on the wall in
| our lab... I wish I had taken some of them and framed them,
| they were beautiful.
| cebert wrote:
| That would be a nice to frame in an office.
| hotpotamus wrote:
| This reminds me that I meant to pick up some of the wafers
| sometime. I've seen failures/surplus/whatever for sale on
| eBay and other places and meant to get one to frame or
| display as they are impressive in their way.
| samstave wrote:
| I had a keychain of a CPU in resin for a long time, Intel
| would sell them in the gift shop because they were failed
| prints.
|
| Also, in SC5? there was a hallway that had a bunch of
| plaques from partner companies... and what was awesome
| was the amount of "Engrish"
|
| Some of the comments were along the same line as "for
| great justice" (if you are aware of that old meme)
| hoc wrote:
| Got on of these keychain chips in the late eighties from
| a friend whose dad worked at IBM. I remember that it came
| with a comparably cheap key ring clip and that the edges
| wore off nicely over time. Funny to be reminded of that.
| Thanks for mentioning.
| rektide wrote:
| Pretty wild to me that the Cortex A53 is a decade old & barely
| modified in it's newer forms. It's so hard to imagine so many
| years & a microarchitecture remaining so unchanging.
|
| By compare Intel's been making small but OK revs to the Atom
| cores. And the new E-core on the new n100 replacement is
| monstrously faster, yet still small. A potential core-m moment
| for Intel, a great small chip that expands.
| snvzz wrote:
| >It's so hard to imagine so many years & a microarchitecture
| remaining so unchanging.
|
| It's a shame, because it was the best design from ARM; they're
| now focusing on Cortex-A7x and Cortex-X, which aren't anywhere
| as power efficient[0].
|
| Meanwhile, their revised Cortex-A57 has been surpassed in
| performance/power/area by several RISC-V microarchitectures,
| such as SiFive's U74[1], used in the VisionFive2 and Star64, or
| even the open source XuanTie C910[2][3].
|
| 0. https://youtu.be/s0ukXDnWlTY?t=790
|
| 1. https://www.sifive.com/cores/u74
|
| 2. https://xrvm.com/cpu-details?id=4056743610438262784
|
| 3. https://github.com/T-head-Semi/openc910
| jpm_sd wrote:
| The A53 is very popular in automotive and embedded applications.
| I'm familiar with the iMX8 and the S32G but I'm sure there are
| others.
| adrian_b wrote:
| It is very popular only because almost all companies that are
| neither Chinese nor smartphone-oriented have failed to
| introduce any products with less obsolete ARM cores, for many,
| many years.
|
| NXP has begun to introduce products with Cortex-A55 only
| recently, but they should always be preferred for any new
| designs over the legacy products with Cortex-A53, because the
| Armv8.2-A ISA implemented by Cortex-A55 corrects some serious
| mistakes of the Cortex-A53 ISA, e.g. the lack of atomic read-
| modify-write memory accesses.
|
| The people who still choose Cortex-A53 for any new projects are
| typically clueless about the software implications of their
| choice.
|
| Unfortunately, there are only 3 companies that offer CPUs for
| automotive and embedded applications with non-obsolete ARM
| cores: NVIDIA, Qualcomm and MediaTek. All 3 demand an arm and a
| leg for their CPUs, so whenever the performance of a Cortex-A55
| is not enough it is much cheaper to use Intel Atom CPUs than to
| use more recent ARM cores, e.g. Cortex-A78.
| jpm_sd wrote:
| This is a little harsh, upgrade cycles in these fields are
| very long. I'm working on a project right now where we are
| upgrading from iMX6 (quad A9) to iMX8 (quad A53).
| realjhol wrote:
| In regard to the A55 and the A510, can anyone explain the design
| goals of these? Do they refine the A53 as a "small" CPU? Or are
| they larger more featureful CPUs?
| Findecanor wrote:
| n my impression, the later ones are all supposed to be
| successors of the previous but within about the same chip area.
| The A55 is basically a refined A53 with support for DynamIQ.
| The point of the A510 was support for ARMv9 with SVE2, but it
| is wider also because people expect faster processors. To
| amortise the cost of the larger back-end it lost 32-bit support
| and there's an option to make a cluster of two share the same
| FP/SIMD/SVE unit and L2 cache.
| realjhol wrote:
| The A53 is a fantastic workhorse for all kinds of embedded
| workloads. I was worried bloat would creep into later models,
| while the tried and true A53 moves toward obsolescence. From
| what you're saying, it seems like they are trying not to get
| carried away with it.
| zokier wrote:
| There is also A34 if A510 gets too big for your tastes
| [deleted]
| adrian_b wrote:
| The main purpose of Cortex-A55 and Cortex-A510 is to implement
| additional instructions over those of Cortex-A53, respectively
| Armv8.2-A and Armv9.0-A.
|
| This is necessary to make them ISA-compatible with the big
| cores and medium-size cores with which they are intended to be
| paired.
|
| Besides the main goal of implementing improved ISA's, they take
| advantage of the fact that since the time of Cortex-A53 the
| cost of transistors has diminished a lot and they implement
| various micro-architectural enhancements that result in a
| decently greater performance at identical clock frequency,
| while keeping similar area and power consumption ratios between
| the small cores like A510 and the medium-size cores like A710,
| like they are since the first Big.little ARM cores (Cortex-A15
| paired with Cortex-A7).
|
| ARM has always avoided to publish any precise numbers for the
| design goals of the little cores, but it seems that they are
| usually designed to use an area of about 25% of the area of the
| medium-size cores and to have a power consumption around 0.5 W
| per core.
| borissk wrote:
| SoCs that have only A53 cores are terribly slow. Recently played
| with a Motorola Moto G22 phone with a Mediatek Helio G37. The
| phone has a nice design, 5 cameras, enough RAM and storage
| (4GB/64GB), but the UI is laggy and slow, installing and lunching
| apps, rendering web pages takes a lot of time.
| the_third_wave wrote:
| I would not call the Redmi Note 5 (SD626) I've been using for
| the last 4 years "terribly slow", instead I call it "perfectly
| useable". This whole "laggy UI" thing people complain about is
| beyond me, the UI is GPU rendered and keeps up with most of
| what I throw at it. I don't expect a low-power device I charge
| every 3d day to perform like a mains-connected system.
| 29083011397778 wrote:
| > I would not call the Redmi Note 5... "terribly slow",
| instead I call it "perfectly useable".
|
| The software you use plays a rather large role in how the
| hardware performs. Some people here like to live on the OEM-
| designed happy path, where things tend to just work. That
| means using Google Apps for everything, an expectation that
| the latest video streaming social platforms will open quickly
| and not stutter, and scrolling the Google Play Store or
| Google Maps will be a fluid experience.
|
| Others may use simpler apps, or expect less of their phones.
| I'm in the latter category, and I suspect you are as well.
| While the BlackBerry KeyOne I use daily was panned by some
| six months after release in 2017 for being too slow, I
| instead killed off nearly everything else that would run in
| the background - including and specifically any Google
| frameworks and apps.
|
| Some software companies have made a point of taking any
| hardware gains for granted. Most people have new phones, with
| fast processors, so some companies will push devs to take
| shortcuts. I'm quietly indignant about that, though that rant
| is rather tangental to your original question about how some
| have such different experiences from yours.
| daviddever23box wrote:
| You may not expect desktop-class performance, though others
| do. Display scrolling on a mobile handset is an indicator of
| quality that separates cheap devices from those that one
| might actually want to use to get work (or play) done.
| wiseowise wrote:
| Those are cheap devices.
| supriyo-biswas wrote:
| Not trying to justify phone manufacturers not putting in the
| effort to optimize their software, but one way around the slow
| UIs is to go into the Developer Settings and turn the UI
| animation speed to 0x. It's a setting I've always enabled on my
| Android phones when I used to use them.
| trustingtrust wrote:
| This core is ideal to be replaced in low power platforms like
| SMB routers that run on MIPS (MT7621). I think Qualcomm and
| Mediatek is extensively using these in router SOCs which
| previously were based on MIPS. These cores are probably less
| 'application' cores and a more designed towards low power
| helping cores. For example QC uses network accelerators along
| with the cores. Anything gigabit and beyond still requires
| bigger ARM cores or Intel but below gigabit these are not bad.
| nfriedly wrote:
| Agreed. I'm perfectly happy to have a couple of A53s in my
| phone for background tasks. Four feels a bit overkill but okay,
| maybe it makes the big.LITTLE design work better.
|
| But I've always been disappointed by devices that are all A53s.
|
| And when I see devices that have _eight_ A53s and nothing else,
| I have to assume that they are just trying to trick people into
| thinking it 's a more powerful device than it actually is.
| dopa42365 wrote:
| >I have to assume that they are just trying to trick people
| into thinking it's a more powerful device than it actually is
|
| Why would you think that people who actually look up and care
| about the hardware at the same time are unable to read the
| first sentence on wikipedia and have no idea what it is? Do
| you really believe that customers of $100 budget phones are
| tricked into powerful performance?
| mardifoufs wrote:
| Oddly enough, a very sizeable portion of customers seem to
| be aware of core numbers and "memory" size (often confused
| with disk size, though). The i3-5-7 naming scheme is also
| pretty widely understood. I used to work at an electronics
| store when I was a teenager (6-7 years ago, so not that
| long ago!) and that kind of made it a struggle to steer
| people who knew just enough to hurt themselves into buying
| an actually good product. I mean, that MediaTek is an 8
| core CPU so why was I trying to sell him a 2/4cores
| Qualcomm? Or they'd buy a laptop with a Celeron and barely
| enough flash to fit Windows, but it was a quad core!
| Obviously better than the 2 core i3 that actually has space
| to install software lol.
|
| I'd guess 25% of customers knew about those at a
| superficial level, and another 10% actually knew what they
| should be looking for.
| pavlov wrote:
| I'd guess there are a lot of people who see "eight-core
| CPU!" and don't research any further. Same way that PC
| buyers used to stare at GHz and ignore the total
| performance of the CPU.
| hochmartinez wrote:
| Nope... I'm using a tiny SBC, a Radxa Zero with a A53 Cpu, with
| Manjaro Linux, as a ultra low power daily driver and it is
| perfectly usable for light browsing, programming or
| productivity.
|
| It boots Linux in 7 seconds and xfce desktop is pretty snappy.
|
| Kernel is 6.1 and RAM is only 4GB.
|
| Opens Lazarus almost instantly and FPC compiles ARM binaries
| super fast.
|
| Amazing little machine...
| neurostimulant wrote:
| Modern Android runtime is probably too heavy for these cores
| alone if not accompanied by some A7X cores.
| worldofmatthew wrote:
| That more Android being more bloated than desktop Linux.
| kennethrc wrote:
| I'll bet that's due to slow storage, and not the CPU(s); I've
| done a few handsets and tablets and write performance was a
| large part of being laggy or not. It's quite obvious when the
| storage is full and the flash controller spends a lot of time
| doing RMW ops and halting writes.
| borissk wrote:
| Don't think so - CPU and GPU are far more important for the
| speed and fluidity of UI than flash write speed.
|
| Yes, if the storage is full it can kill both the performance
| and stability of Android, but devices with slow SoC are slow
| even with plenty of free space.
| ConfuSomu wrote:
| Yep, this was also the case with my old phone. Opening apps
| took a while but after that, everything was more fluid
| afterwards and clearly indicated that storage played a part
| in the device's slowness. Though, the 1.5 GB ram and the
| quad-core Cortex-A7 still made the device pretty slow.
| actionfromafar wrote:
| It's sad that Android doesn't automatically fall back to a
| simpler GUI which takes less time to render. Even Windows XP
| (2000, 98?) got this right (with manual settings).
|
| Even an A53 is a super computer when it comes to graphics
| compared to CPUs of yore.
| userbinator wrote:
| _Android doesn 't automatically fall back to a simpler GUI_
|
| How much simpler can it be, given that everything seems to
| already be flat and borderless? As your last sentence alludes
| to, Windows and other desktop OSs worked perfectly fine with
| far more complex UIs (including _windows_ ) on far less
| powerful hardware. Mobile UIs seem to be quite primitive in
| comparison.
|
| In other words, this is entirely a software problem.
| lxgr wrote:
| A visually simpler GUI (such as Luna vs. "classic" on Windows
| XP) isn't necessarily less resource-intensive. Implementing
| an actual different, less resource-intensive rendering path
| could help, but would double the development effort.
| Hextinium wrote:
| A serious improvement on these budget phones is turning
| animations completely off, it removed most of the stuttering
| and GPU usage doesn't spike just pulling up the keyboard.
| apexalpha wrote:
| Is this not what Android Go is supposed to be?
| joshuaissac wrote:
| They are meant to be used in a big.LITTLE configuration. So the
| A53 cores should be active in the low-power mode, and more
| powerful cores should be active in high-power mode.
| borissk wrote:
| And yet millions of new phones sold in India, Africa, South
| America and Russia have only A53 cores.
| sosodev wrote:
| It's interesting that the author used a photo of the Tegra X1
| here. My understanding is that the Nintendo Switch (most widely
| distributed Tegra X1?) never or very rarely uses its A53 cores.
| [deleted]
| photochemsyn wrote:
| This is an area where RISC-V could be come a major competitor,
| e.g. SiFive has a
|
| https://www.eenewseurope.com/en/sifive-aims-for-arm-with-hig...
|
| > "The Performance P670 and P470 RISC-V cores are designed to
| take on ARM's Cortex A53 and A55 cores, Drew Barbier, senior
| director of product management at SiFive tells eeNews Europe."
|
| A compare-and-contrast article would make for good reading.
| justahuman74 wrote:
| I'd love to see a chart with all the licenseable arm and riscv
| cores compared
| sillywalk wrote:
| I wish that ARM's naming convention was less.. complicated. It's
| like USB.
| user6723 wrote:
| ARM Cortex A53 is one of the few (or only?) modern CPUs without
| spectre problems. Other CPUs do have mitigations but they only
| lessen the problem.
| sylware wrote:
| Hopefully, we get worldwide non-toxic IP cores with enough
| performance from RISC-V to replace those abominations.
| Symmetry wrote:
| There's a lot to be said for open source ISAs like RISC-V. But
| it's a lot harder to create a top of the line open source
| microarchitecture implementing it that's competitive to closed
| source designs. A Linux kernel developer can make changes and
| test them several times a day for a cost in electricity
| measured in cents. An equivalent build/test cycle on a CPU core
| is going to be north of a month and a million dollars.
| Simulation helps but to optimize speed and yield you really
| need to build the chips and due to physical effects that's a
| process with much weaker abstraction barriers than software
| development. So I'm skeptical that we'll ever have cutting edge
| open source microarchitectures.
| sylware wrote:
| I am not talking about open source architecture, but more
| about a worldwide non-toxic ISA: namely anybody can create
| FREELY a RISC-V microarchitecture AT WORLWIDE SCALE, and that
| closed or open, which you cannot with arm or x86.
|
| Ofc, worldwide royalty free is not enough (or just be allowed
| to implement the ISA...), silicium is really about
| performance, and I sincerely hope RISC-V will end up
| providing microarchitectures (open or not) "good enough" to
| do the job.
|
| I am perfectly aware RISC-V will fail if not providing at
| scale really good implementations. Rumors say "really
| performant" implementations are not expected before 2024.
| klelatti wrote:
| > namely anybody can create FREELY a RISC-V
| microarchitecture AT WORLWIDE SCALE
|
| The problem with this argument is that it ignores the cost
| of creating the microarchitecture. It's almost certainly
| cheaper to license an Arm A series core than to create a
| comparable RISC-V core from scratch.
|
| Sure we have a firm like SiFive that licenses RV cores to
| third parties but the existence of firms like Arm and SFive
| shouldn't be taken for granted. If rumour has it SiFive
| were almost taken over by Intel. Thankfully Nvidia were
| stopped from buying Arm.
|
| If you wish for Arm's demise you may get the end of their
| business model and that probably isn't a great outcome.
| sylware wrote:
| risc-v is not limited to sifive, there are several other
| implementations. And yes, arm and x86 made angry ppl with
| enough resources to make happen risc-v, and it has been a
| decade and it is still gaining momentum even if the
| market is over-saturated with arm and x86. That's last
| point is really positive, and it allows us to think
| risc-v could be successful.
|
| But I agree that without _REALLY_ performant
| implementations, risc-v WILL fail and rumors say that
| things won't start to get serious before 2024.
| Nevertheless, in its current state, failure is still a
| more than valid outcome.
| shjake wrote:
| IMHO ARM is one of the best things that ever happened in the
| computer industry.
|
| > non-toxic IP cores with enough performance from RISC-V
|
| Why would anyone also their designs to be used for free or for
| cheaper than ARM does?
| Yujf wrote:
| Competition. Multiple vendors can compete with RISC-V while
| ARM can prevent all competition with licenses, if it really
| will happen is a different case, but I'm optimistic about the
| potential.
| shjake wrote:
| Possibly, but historically it high end semiconductors seem
| to turn into a winner takes all market more often than not.
| If that's the case it's probably preferable to have someone
| like ARM at the top than Intel or Nvidia.
| sylware wrote:
| nope, it is would be better if it was RISC-V.
| shjake wrote:
| Why (besides religious reasons)?
|
| I don't see how can high-end/competitive RISC-V cores
| could be fully open/free and without that how is it
| better than ARM.
| sylware wrote:
| There is nothing religious here.
|
| arm and x86 are _not_ royalty free ISAs, RISC-V _is_ ,
| then RISC-V is mechanically a better choice, until it
| does a good enough job.
| rektide wrote:
| It's winner take all in a competitive scenario, maybe.
| Winner is all is what RISC-V is trying to make happen.
| rektide wrote:
| Most people want to build things not cores, the cores aren't
| the core competency. So the hope is, release what cores you
| have & let others improve it for you. Western Digital's
| swer-v core is seemingly an example of this thinking.
| shjake wrote:
| Would you not expect companies which actually want to make
| to cores to have an advantage?
|
| And the companies that don't want to make it their core
| business but can afford enough resources (e.g. Google,
| Apple, Amazon) would just use them to leverage their core
| products.
|
| I could only see this on the lower end where
| margins/required R&D investment are relatively low.
| mhh__ wrote:
| Article could use a more aggressive editor, slightly bloated.
| speed_spread wrote:
| Someday somebody will say that about someone else's DNA.
| hoc wrote:
| If that could be checked and fixed on a regular basis, I'll
| be fine with that.
| silvestrov wrote:
| It would be interesting with a graph of "performance per watt".
|
| Mobile phones often have background tasks that does not need much
| CPU power. A53 seems very suitable for this, so it would be nice
| with some idea of how much power phones saves by using A53 for
| this instead of a high performance core.
| monocasa wrote:
| It really depends on the workload. Modern thoughts on the
| matter trend towards a design called "race to sleep" where even
| your efficiency cores are still pretty beefy relative to an
| A53. That model is focused on quickly turning the core on,
| running through all of the work, and going back to sleep,
| rather than staying on longer on a much weaker core. Doing this
| effectively requires OS support to coalesce timer deadlines to
| bunch up as much work as possible on each wakeup cycle.
|
| But with software support the model is very effective which is
| why you see most e-cores these days being relatively beefy OoOE
| cores that can leave the A53 in the dust. Whether that's
| Icestorm in the M1, Goldmont on Intel, or A57s on big.LITTLE
| ARM SoCs.
| nfriedly wrote:
| Geekerwan on YouTube tests the performance and effiency of
| different cores at different frequencies. This is one good
| example where the A55 and A510 (successors to the A53) are
| graphed at around 15:40: https://youtu.be/s0ukXDnWlTY
| (honestly, the whole video is pretty informative)
___________________________________________________________________
(page generated 2023-05-28 23:00 UTC)