
I love ARM - 20i
https://www.20i.com/blog/i-love-arm/
======
varbhat
This is my consideration.

1)ARM is good for phones/tablets/portable small devices which runs on battery
because it saves much more power.

2)I think that x64 hardware of similar specs outperforms arm64 in
performance.[Personal observance]

3) I love how I can boot Different linux distros/BSDs/HaikuOS/Windows/other
x64-generic-OS.In my arm64 phone,I can't(OS must be especially crafted for
that specific processor ,then it must be tweaked carefully for that device in
order to boot).Also,there is very much diversity in arm64 space.This implies
that some arm64 hardware can't boot/run some OSs which hasn't been crafted for
that device.

For my use-case,(3) is very important.I am damn sure that,some manufacturers
might manufacture hardware that can't boot other OS(say situation where most
(arm) laptops can't run linux and only runs windows). I don't want that to
happen.Also , booting up OS in arm64 is not standardized(there is lot of
diversity in boot process in arm64 unlike x64).Also ,some components might not
be upstreamed in Linux kernel(So,I need to patch my kernel everytime/My kernel
will never get updated to new major version like many android phones).

Speaking of other architectures,I also don't think RISC-V will become major
architecture anytime soon/will suffer the same disadvantages of arm64 I
mentioned above.Maybe,pp64(openpower) might be good architecture but I haven't
got a chance to deal with that hardware.

~~~
rocqua
The thing about x64 is that it's really complex instruction decoding system is
unavoidable overhead. Especially since every processor translates the x64
instructions into processor-specific micro-instructions. And then those are
run by the processor.

It seems to me that a simpler instruction set that occurs much less overhead
than the above will simply have a higher performance ceiling. The only
advantage I see in x64 is that the complex instructions are a form of
'compression' for the micro-instructions. Maaaaybe the resultant bandwidth
reduction in reading isntructions is worth the performance overhead of x64
instruction decoding.

~~~
Symmetry
Decode complexity is a real cost to x86-64 but it's not a huge one. Well, for
medium devices in the Pentium range it can be pretty significant but for
modern large cores it'll only end up costing 5% or so of the total power
budget on x86. And there are some design effects where ARM cores will tend to
make the decode unit big enough that it's never the limiting factor whereas
x86 cores tend to balance the size of the decoder against the other stages
more.

More significant than that, I think, is that modern 64 bit ARM is actually
tend to produce denser code than modern 64 bit x86 - which is really weird
when you consider that ARM-64 is fixed width and x86-64 is variable width but
backwards compatibility can do that.

And more important than that, however, is that x86-64 has a very strict memory
model and ARM a more relaxed one which can cause problems for programmers who
aren't careful but has huge implications for the design of the memory backend.

~~~
monocasa
> More significant than that, I think, is that modern 64 bit ARM is actually
> tend to produce denser code than modern 64 bit x86

Do you have a citation for that? Everything I've seen says the opposite,
including
[http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document...](http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf)

The strongest wording I've seen is that aarch64 is 'competitive with' x86_64.

~~~
Symmetry
You know I think you're correct and I was mis-remembering. I think what I
might have actually been confused by is instructions per task rather than
bytes of instruction per task but given that my memory has already failed me
once here who knows.

------
Abishek_Muthian
I love ARM too, that's why I'm sad to hear that SoftBank has put it on the
block for sale and especially that Nvidia is eyeing it.

People say, it wouldn't get pass regulators; I doubt it, Qualcomm - Broadcom
was blocked as US feared the latter might stall Qualcomm's telecom research
giving advantage to China. But, it's the other way around for ARM Holdings -
Nvidia deal; Why wouldn't US allow its company grabbing a future-proof
computer architecture?

Sidenote/rant- Look what have you done WeWork, burning VC money with a
nonsense company has led to a point that the future of computing democracy is
now under threat. Well, SoftBank wasn't a good place for ARM Holdings in the
first place but at least I thought they were in it for a long haul; I was
wrong.

I feel RISC-V is the true future for open-source computing.

------
richardwhiuk
> I think Apple moving towards entirely ARM compatible Macs and Macbooks will
> drive the ARM SBC market forward for developers (it’s difficult to develop
> on architecture X for architecture Y).

I'd be very surprised if this was the case.

~~~
amelius
I'm surprised that Apple didn't buy ARM yet.

~~~
kalium-xyz
Apple is one of the parties which founded ARM

~~~
jannes
Source? As far as I can see they only made a joint venture:
[https://www.latimes.com/archives/la-
xpm-1990-11-28-fi-4993-s...](https://www.latimes.com/archives/la-
xpm-1990-11-28-fi-4993-story.html)

~~~
simonh
According to that article the joint venture they co-founded was actually ARM.

~~~
jannes
True, however the joint venture was founded to “further develop” the
technology. That means the ARM architecture itself seems to have originated at
Acorn, without Apple.

~~~
Followerer
The point is, originally, Apple were co-owners of Arm (together with Acorn and
VLSI).

------
ed25519FUUU
Every article I read about ARM64 doesn’t really have any technical, concrete
reason to love it. I think we’re simply experiencing a sort of euphoria that
comes with knowing there’s competition in the space and big players are mixing
things up. There’s joy in anticipation.

~~~
_ph_
The one big reason is, that ARM64 is a reasonably clean 64bit RISC CPU. That
doesn't have so much historical baggage to carry as the x86-based CPUs. Which
were never loved, at no time in their life cycle. But due to how history went,
managed to kill all the nice RISC designs that once were around. SPARC, Alpha,
MIPS, just to name some.

------
floatboth
Servers next? Servers first! AWS released a _second generation_ of the
Graviton before Apple announced the Mac transition. Also great stuff is coming
from Ampere and Marvell (ex-Cavium).

~~~
Abishek_Muthian
I've been running one of my production applications[1] on Marvell (ex-Cavium)
based ARM server on Scaleway which has had it for several years now;
unfortunately they decided to pull the plug off their entire ARM line up
suddenly citing stability issues which not many have faced[2].

[1][https://needgap.com](https://needgap.com)

[2][https://news.ycombinator.com/item?id=22865925](https://news.ycombinator.com/item?id=22865925)

~~~
floatboth
Back in the pre-Graviton days I managed to boot FreeBSD on their ThunderX VM
offering, wrote a guide on the forums, even received an email about that from
staff… and a few months later they broke local boot completely and then, yeah,
closed the whole offering for some reason. What a disaster. As much as I
dislike the whole Bezos Empire thing, I'm glad AWS picked up the ARM VM world
and pushed it to great heights.

~~~
Abishek_Muthian
I think main cause of issue with Scaleway's ARM offering could be their own
custom Bios and not the actual hardware. I hope they had come clean with the
actual technical details of the stability issues instead of just mentioning it
in one line on their migration guide to x86 from ARM servers.

~~~
floatboth
huh, they might be bringing ARM back:

[https://amperecomputing.com/ampere-altra-family-of-cloud-
nat...](https://amperecomputing.com/ampere-altra-family-of-cloud-native-
processors-expands-to-128-cores-with-altra-max/)

------
dhosek
My reckless prediction: When Apple releases their first Apple Silicon Macs at
the end of the year, one of them will be a rack-mount server.

~~~
simonebrunozzi
Happy to bet against this.

~~~
kylec
The Mac Pro is rack mountable, and I would expect it to transition to ARM at
some point

~~~
tyingq
Lacking things like dual power supplies and out of band management, that
probably isn't the context the GP meant.

~~~
easton
This probably isn't a game changer for you, but Apple mentioned at WWDC that
Lights Out Management is coming to Mac Pros in the next release of macOS. You
need a Mac Mini somewhere on the network to manage commands from the MDM to
the turned off Mac Pro, so I don't know what happens if that Mac Mini is
turned off, but it's a move in the right direction I guess. (I suppose it's
because they don't want network to be up before the firmware on the target
Macs is validated, but I'm not sure).

[https://developer.apple.com/documentation/devicemanagement/l...](https://developer.apple.com/documentation/devicemanagement/lightsoutmanagementlom)

~~~
tyingq
If the Mac mini is capable of managing several servers, that's not a bad idea.

------
als0
I personally hope to see more 64-bit only processors without the burden of
AArch32 support.

~~~
repiret
You see that in, say, Cortex-A76, which only supports AArch32 at EL0.
Supporting AArch32 at EL0 is quite cheap compared to also supporting it at the
higher exception levels - EL0 can be done entirely in the instruction decoder.

------
jiripospisil
What's the reason behind companies adopting ARM instead of the open standard
RISC-V? E.g. Apple designs its own chips, wouldn't it make more sense to use
RISC-V instead of paying fees to ARM?

~~~
simonh
Apple helped found ARM back in 1990 and is a major shareholder, they have a
massive investment in the architecture, including enormous experience with it.
They can't just drop the massive experience, knowledge, investment and
hardware and software ecosystem they have built up around ARM and switch to a
completely different architecture.

Also Apple already hold a perpetual license for the ARM architecture, the
major costs of their investment in it were spent years or even decades ago.

The obvious counter is the sunk cost fallacy, but what does RISC-V actually
have to offer that Apple doesn't already have with ARM? Those sunk costs have
bought Apple actual tangible benefits on ARM that RISC-V doesn't have, such as
architectural features like the secure enclave, better device integration,
better GPU options, more mature device driver support, a stronger development
and testing tools ecosystem.

The opportunity for RISC-V is new use cases not already strongly addressed by
ARM, or where ARMs more mature ecosystem offers weaker benefits, for companies
not already strongly invested in ARM.

~~~
mumblemumble
In this case, I think that the "sunk cost fallacy" counter is as specious as
it is obvious. It completely misplaces the burden of evidence.

Apple has a platform with hundreds of millions of active users, perhaps over a
billion actual devices in use. In a situation like that, conservatism is
warranted. The guiding principle is simple: If it ain't broke, don't fix it.
Meaning that the argument doesn't start with any sort of discussion about
technical advantages that RISC-V might have over ARM, or challenging reasons
to stay on ARM as if, having dismissed them, the obvious default plan of
migrating to RISC-V would kick into action. It starts with trying to
demonstrate that something about ARM is broken. Because, if it ain't broke,
don't fix it. So. . . is it hindering Apple's strategic or operational
priorities in any way?

------
supernova87a
For the layperson, what is so special about ARM chip designs? Are they much
more efficient in compute achieved per clock cycle or something?

Or as the author alludes to, have less power consuming non-useful overhead
processes running in the background? Is it the equivalent of pipeline length
that Apple pointed out when making the Intel transition back in the 2000s?
(the "megahertz myth"?)

~~~
BoardsOfCanada
Basically the only advantage is simplified instruction decoding, which it has
in common with other RISCs. It has some other nice properties too, I think it
really shows that it has taken lessons learned from other RISC architectures
and struck a good balance. But the reason for the switch isn't how nice ARM
is, the reason is that Intel is struggling with its manufacturing process and
Apple wants to be in control of its own destiny.

~~~
manmal
Apple also want to add their own narrow-purpose chips (like media encoders and
what have you).

------
ChrisMarshallNY
_> Hopefully that will be in a way that will lead to there being
releases/hybrids/OS projects of Apple’s collections of OSes finding themselves
running on boards like the RockPro64 (inside the Pinebook Pro)._

I am looking forward to seeing what they do with ARM. Probably the most
interesting thing will be what kinds of custom SoCs will appear.

But don't get your hopes up for any "hackintoshes." At least, not commercial
ones. You will probably be able to scare up homebrew devices (like they have
nowadays, with Intel), but Apple has always been rather... _punitive_ towards
corporations that produce Apple clones.

~~~
entropicdrifter
I find it unlikely that even the homebrew community will be able to install
Mac OS 11 on any non-apple hardware without emulation for a good long while
because Apple is likely going to lock down their software to only run on their
hardware, much like how iOS can't be run on an Android device without an
emulator.

~~~
ChrisMarshallNY
I agree. I think the T2 (T3?) chip is going to end up being embedded in the
Apple Silicon SoC.

~~~
coreblocks
Definitely, they will consolidate their T2 functionality and also
functionality traditionally left to the chipset into one SoC.

------
1996
I will be the dissenting voice and say I prefer MIPS.

Like the Wintel (Windows/Intel) monoculture, ARM brings the GoogleArm
monoculture. The Apple/Arm monoculture that some people seem to hope for would
be no different: heavily restricted, with fewer possibilities for free
software.

MIPS64 offer us a good royaltie-free alternative, to be independent of the
western companies (UK/US based)

If Nvidia gets ARM, I fully expect the same shenanigans Intel pulled on X86.

So I hope a third party alternative (MIPS, Sparc, anything) will be there,
hopefully with a major fab like Samsung behind it.

~~~
sigjuice
MIPS64 is no longer royalty-free.

 _Wave Computing Closes Its MIPS Open Initiative with Immediate Effect, Zero
Warning_

[https://www.hackster.io/news/wave-computing-closes-its-
mips-...](https://www.hackster.io/news/wave-computing-closes-its-mips-open-
initiative-with-immediate-effect-zero-warning-e88b0df9acd0)

~~~
iagovar
So we're only left with RISCV? Sparc seams a dead end, and power too.

~~~
floatboth
IBM is actively investing in POWER though

~~~
aww_dang
Would be nice if they brought that back into the laptop realm.

~~~
erk__
There is a project to make a power pc laptop [https://www.powerpc-
notebook.org/en/](https://www.powerpc-notebook.org/en/) Though it does not use
a IBM CPU.

~~~
duskwuff
They claim to be using a NXP T2080 CPU as the core of their laptop. This is
doomed to failure.

The T2080 is a high-speed communications processor. It is not designed for
energy efficiency. It can draw up to 20W at full power, and does not support
the sorts of power-saving features that would be required for a mobile part.
The datasheet doesn't even _specify_ the processor's idle power consumption!
Some of the tables can be read to imply that it might be able to idle down to
roughly 7W, but that's still completely unsuitable for a laptop.

~~~
sigjuice
Are there other Power processors that might be better suited for a laptop?

~~~
duskwuff
Somewhat not by much. NXP has a couple of other QorIQ parts which might fit a
laptop application a little better; for instance, the T1040 series (4 cores,
1.5 GHz, 7W TDP) seems like a better fit. IBM's POWER parts are aimed squarely
at supercomputing and are completely unsuitable for this use case.

But, quite frankly, none of these parts are really intended for mobile use.
There hasn't been any real interest in mobile Power hardware since Apple got
out of the business nearly 15 years ago -- ARM cores have utterly dominated
that market.

------
S_A_P
I like that there is a real option to break away from x86/x64 now. It may not
be the best for all use cases, but 10-15 years ago there was no viable
personal computing option. I'm not wishing for Intel's downfall either, they
seem to do better once there is real competition around. While AMD has made
huge strides here, the real problem is there needs to be a high performance
processor that doesn't consume power like x86/x64.

------
Koshkin
Aren’t we in fact just talking about the CPU architecture (a.k.a. the
instruction set, ISA)? On the inside, all CPUs are (or can be made) the same
regardless of the architecture - the differences dictated only by technical
requirements such as desired performance, price, power consumption, etc.

------
zwieback
It's done wonders for embedded systems. I still have a Netwinder in my drawer,
that was when I switched from various oddball micros to ARM - never looked
back. Is ARM the best? Probably not, but that doesn't matter. The only one I
kinda miss is the MSP430 - but not enough to keep working with it.

------
dangoljames
I too am feeling somewhat optimistic about this direction in technology, and
for approximately similar reasons, though I don't think I feel so strongly
about it as to craft a blog post on the topic.

------
prvc
I read the whole article expecting something programming-related to come (it
didn't).

