Hacker News Reader

What utter nonsense. Different ARM chips aren't "somewhat compatible" anymore than Intel/AMD x86 chips. It's a standard instruction set. And even if we'd get different instruction sets, we have much better toolchains/compilers to work with multiple architectures now than we did in "the home computing landscape of the 80s / early 90s" (GCC and LLVM aren't really comparable to Sinclair Basic).

The M1 has been out for a month and we already have hundreds/thousands of natively compiled binaries—and Windows and Linux are up and running.

Choice is not a problem and competition is good.

I thought the m1 has dedicated js instructions.

It's just part of the ARM instruction set.

Yeah, but any guesses as to which ARM architecture licensee submitted these instructions to the ISA? It was probably the one who was first, by several years, to implement them, right? ;)

Where'd you get that from?

The m1 _does_ have one weird non-ARM extension; it can adopt an x86 memory model on demand.

It's got better/more floating point capacity, which makes it faster at JS because all the numbers in JS are floating point number.

What are js instructions and what does javascript(?) have to do with ISA?

IIRC, the standard ARM instruction set does include some instructions with "javascript" in the end. I think they're floating point instructions that handle some edge case (NaNs?) in the same way that x86, and therefore the JS spec, do.

See here:

https://developer.arm.com/documentation/dui0801/g/A64-Floati...

Not Apple Silicon specific though

Which are part of arm ISA

There are several theories as to why the M1 does so well on on JavaScript benchmarks.

>Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles).

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

>Apple has confirmed that it’s a massive 192KB instruction cache. That’s absolutely enormous and is 3x larger than the competing Arm designs, and 6x larger than current x86 designs, which yet again might explain why Apple does extremely well in very high instruction pressure workloads, such as the popular JavaScript benchmarks.

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

> "There are several theories as to why the M1 does so well on on JavaScript benchmarks."

A major reason it does so well is the native Javascript support added in ARMv8.3-A.

Specifically, FJCVTZS (Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero)[1] which is a Javascript-specific variant of FCVTZS implementing the overflow and exception handling behaviour that Javascript wants.

Javascript needs to do these conversions a lot, since it doesn't have integer types, and it's much faster to have it implemented in silicon rather than using the old instructions and having to handle the overflow/error checking.

[1] https://developer.arm.com/documentation/100076/0100/a64-inst...

People who were looking for a root cause of the iOS JavaScript performance advantage have been pointing to that instruction as "the" reason before it was even used by Safari.

https://mobile.twitter.com/saambarati/status/104920213252247...

I'm sure it doesn't hurt, but the performance advantage predates the instruction's use.

Here's another theory.

>Finally doing perf counters on a dedicated test bench... 9900K having 60% worse branch misprediction than Apple's A12.

https://twitter.com/andreif7/status/1307420010177007625

the second theory seems better in my experience. I pulled a few js benchmarks and ran on native Safari on m1 vs rosetta2 node and the rosetta2+node is significantly faster, suggested the instruction set is not the key.

As far as I understand that instruction is needed to get x86 FP semantics on ARM. I.e it doesn't make JS faster but just not as slow as it would otherwise be.

Also apparently most JS engines do not actually use the FP unit but can do most computations on the integer units (unless is really FP math) which normally have much lower latency (but also lower bandwidth).

I've been thinking about the instruction cache of the M1 lately.

Another difference between x86 and ARM is that, for historical reasons, on x86 there is no need to invalidate the instruction cache explicitly when writing instructions to memory. That is, on x86, when a core writes to memory, the corresponding line in the instruction cache has to be invalidated. Since the instruction cache is usually VIPT for performance reasons, it has to be indexed only by bits which don't change in the virtual to physical mapping, otherwise there's a risk of cache aliases. For an instruction cache, an alias should not be a problem (it just wastes space with duplicated data), except that all aliases have to be flushed when invalidating by physical address.

IIRC, in 64-bit ARM user space (EL0) the only available instruction to invalidate the instruction cache is an "invalidate by virtual address" instruction. Since calling that instruction (after calling an instruction to flush the data cache to the point of unification) is required on ARM, there's no need to be able to invalidate all aliases of a physical address, like would be required on x86. That means it would be easier on ARM to have much larger instruction caches than on x86.

This raises so many questions for me that are predicated on this being the case, but this is way out of my league so I could be off the mark. Incoming geeking about Universal Programming Languages.

1. If you can increase the performance of a language by adding language specific instruction sets to the processor, how much of a boost would we see on average?

2. Instead of building in instructions for say Python, C#, Java, etc, what if you built it in a language designed to create other languages I.E Racket? (I like Racket but another language that specialized in this would be fine). Since languages built on Racket ultimately compile to valid Racket code, you'll still get the speed up, and can program with the features and syntax you want (within reason obv constrained by the limitations of the base language).

3. I wasn't around for this, but isn't this what made Lisp faster on Lisp Machines? Since they had dedicated hardware for interpreting Lisp instructions?

You can certainly speed up a dynamic language by building VM which is a more or less ideal translation target for that language, and then implementing that VM in real hardware.

Hardware can parallelize type checks. For instance, you can have an add instruction which proceeds on the assumption that the two arguments are numbers. In parallel, a type checking unit in the hardware can abort that instruction and cause a branch to some handler if the operand types are wrong.

Function calls in dynamic languages can be expensive partly due to the dynamic checking that there are not too few or too many arguments. This affects code that doesn't otherwise require type checking (like logic that is doing nothing more than just passing arguments through several layers of functions and capturing return values). Hardware can help here also.

The industry moved toward general-purpose hardware. The Lisp people figured out ways to compile Lisp well to general-purpose hardware.

The thing about hardware is that it also needs optimization: a machine designed for ideal execution of Lisp is going to be expected to produce new revisions that are faster and faster, keeping up with advances in general-purpose machines. If it fails to do so, its performance will be overtaken by Lisp that is compiled to the general-purpose machines.

Linux is up and running? Maybe one should get a Macbook air then

A PC = x86_64 + UEFI. They are have a lot of standard components. You can take any Linux boot USB and boot almost any PC with it and at least get a console if nothing else.

A PlayStation 4 is x86_64 but is NOT a PC. Watch the Fail0ver video on their PS4 kernel port to understand how different it is.

ARM is a god damn clusterfuck of random pins soldered to random shit and every Android kernel patched to hell in non-upstreamable ways. Look at all the work PostmarketOS has to do in order to get mainline Linux to work on all the random ARM e-waste out there.

DeviceTree is a joke. Microsoft at least forces ARM+UEFI, but they have locked bootloaders and even though people have found exploits to unlock them, there's virtually no reversed engineered drivers. All those hundreds of thousands of Lumina phones? Now they're e-waste. Worthless.

Linux grew because IBM created the PC. Compaq reversed engineered the BIOS and everyone started making compatibles. Over time, BIOS and later UEFI became solid standards.

ARM may be fast, but the non-standard Basic Input/Output and device detection makes it nothing but potential e-waste.

Devil's advocate: anything that says Compaq on it is probably e-waste anyway, standards notwithstanding. Being standards-compliant isn't enough to save a machine from the landfill by itself; if those machines can't keep up with users' expectations, they too will end up discarded. Most devices that people throw away are "serviceable" machines. The people who rescue old hardware with linux and put it back into service are extreme outliers.

I used Compaq in my example because they were the first company to reverse engineer and IBM bios through some legal slight of hand (one group reverse engineered the entire BIOS and wrote a spec, an entirely different group re-implemented that spec, and the first PC compatible was born). I wasn't commenting on the quality of the brand at all.

I know why you picked it, and I wasn’t commenting on the quality either. (I loved Compaqs when I was young) I’m just saying that dumpsters are already full of old computers that could run Linux, but people aren’t doing it. They’re tossing the old Windows Vista laptop in the trash and buying whatever is on sale at Best Buy this week.

Hardly any of this matters in userspace or device-independent kernel modules, which is what 99% of developers work in.

>Different ARM chips aren't "somewhat compatible" anymore than Intel/AMD x86 chips. It's a standard instruction set.

Can you create a single build for all ARM chips for the same OS? If not, its all the same. At work we're using binaries built for XP that work without modification on W10. No doubt, its a testament to the massive backwards compat. effort by MS, but also from Intel. This is a massive, massive benefit to actual customers who just want to keep running software that they purchased/developed/commissioned on the replacement hardware when their current hardware fails. ARM/M1 brings a lot of benefits too, but as always, each person has to decide what they're willing to give up.

>The M1 has been out for a month and we already have hundreds/thousands of natively compiled binaries—and Windows and Linux are up and running.

Assuming the vendor is still in business, you have to rely on the good faith of the vendor to gift you the new version for free.

The OP raises very valid points, I don't know what is 'utter nonsense' about it. It's only tech, not a tribal war :)

> And even if we'd get different instruction sets, we have much better toolchains/compilers to work with multiple architectures now than we did in "the home computing landscape of the 80s / early 90s" (GCC and LLVM aren't really comparable to Sinclair Basic).

I would add that mac osx does have universal binaries for some years.

https://en.wikipedia.org/wiki/Universal_binary

>There will be N somewhat compatible ARM chips, that is to say they are somewhat incompatible.

This isn't how ARM's architecture license works. All ARM implementations are required to pass the same standard test suite.

>Architectural licensees get a set of specs and a testing suite that they have to pass, the rest is up to them. If they want to make a processor that is faster, slower, more efficient, smaller, or anything else than the one ARM supplies, this is what they have to do.

https://semiaccurate.com/2013/08/07/a-long-look-at-how-arm-l...

Sure, for the instruction set all the CPUs are required to be compatible. However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem. I assume that if Google and Amazon were to build their own chips, they'd do the same. Those accelerators will not be intercompatible, and we'll have a dozen different vendored drivers, like how GPUs work.

> However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem.

I think this is overstated. There are quite a few differences between Intel and AMD extensions these days and they don’t create much of a problem. Apple’s architecture isn’t reliant on accelerators or special instructions to get good performance on general purpose code.

But it could exist right? For instance, what if MS created an ARM variant with special instructions to accelerate C# garbage collection? You could imagine a world where vertical integration throughout the entire stack leads to software which kind of works everywhere, but only really gives a good experience on 1st party hardware.

I'm no expert but put too many extensions in there and you're looking less like RISC and more like CISC. It would make more sense on x86 platforms.

>Sure, for the instruction set all the CPUs are required to be compatible.

Isn't that the only thing we care about?

Anything else is a lot like saying that Intel based PCs aren't really compatible with each other because they can use different implementations of things like graphics chips, sound chips, and NICs.

> However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem

I mean, so have Intel and AMD, for decades.

> Sure, for the instruction set all the CPUs are required to be compatible. However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem.

There is little evidence that Apple has built anything truly non-standard in the M1 so far, the closest thing they have is the TSO mode, and that's not an optimisation since it provides stronger guarantees (and thus lower performances) than normal. That cost happens to be recouped tenfolds when emulating a TSO architecture (aka x86) rather than having to do it in software, but that's got nothing to do with ARM workloads.

Not specializing in this area, I'm somewhat at a loss to understand what is so unique about the M1 that competitors could not implement similar in other ARM based systems or instead on Intel/AMD? Maybe another way to ask is what of the M1 performance is due to ARM and what from the Apple implementation?

I'm not a specialist either but my understanding is that Apple has thrown a lot of resources (and hardware) at the problem (and have been doing so for a while, the M1 is simply the apotheosis), and it has paid off: https://news.ycombinator.com/item?id=25257932

Nothing stops other ARM manufacturers from doing that, but it's expensive, and most manufacturers don't really have a reason to work this hard at it, they have a fairly low-margin biz and their clients aren't going to pay big bucks. For Apple however, these chips are completely structural, they already underlie huge amounts of their business and with the switch of Macs to ARM are slated to do so even more.

It may not be possible for x86 though, because of the architecture's complexity limits e.g. how wide you can decode, and more generally how much hardware you can keep fed concurrently.

Being willing to be inefficient in terms of performance per square millimetre of silicon to be more efficient in terms of performance per watt was how it started. Having less cruft in the ISA that let them be more creative in other areas might be the more important factor now.

Their specialized audio/ video/ image/ machine learning cores aren't helping with general purpose tasks like building code.

It's also not much different from the PC world where you have video cards and Nvidia's CUDA.

> Amazon, Google, Microsoft start building their own chips for their own clouds.

At least Amazon (Graviton) and Google (TPUs) already are. Google is also reportedly looking into its own ARM CPUs for its own mobile devices (Pixel line); if it does, I can’t imagine Cloud would be far behind.

> At least Microsoft is likely to sell their chips to third parties (they used to sell their software).

I would expect MS would keep its chips for its hardware, rather than selling them. But, sure, either they or Google might sell to partners, to help out the ecosystem for their OS's.

> If you want to develop for AWS you’ll be safer to have a laptop with an Amazon chip, if you want to develop for Google Cloud a Google Chip, for Azure a Microsoft chip.

In either case, cloud-as-dev environment is being actively pushed by all players, and negates that issue. It doesn’t matter what chip (or OS, or much of anything else) I have on my laptop if my dev environment is in the same cloud that I’m deploying to.

> 1. Amazon, Google, Microsoft start building their own chips for their own clouds.

https://aws.amazon.com/ec2/graviton/

> 5. If you want to develop for AWS you'll be safer to have a laptop with an Amazon chip,

Since I mostly work on Java that runs at Amazon, I develop locally using Amazon Corretto (https://aws.amazon.com/corretto/), less for performance than for greater confidence I won't run issues between JVM differences when deploying at AWS.

> Or we'll end up with 5 different laptops (unlikely) or one that connects to a remote desktop running in the appropriate cloud with the correct chip.

We're already there when deploying Python with dependencies that need to be compiled from a different OS. The options that I've used so far are 1. Only using pure Python dependencies, which mostly works, and 2. Running a container locally. Thinking about the CPU you're going to be running on might make sense if you're working on native code, but it probably won't be a big deal.

N somewhat compatible ARM chips, that is to say they are somewhat incompatible. Remember the home computing landscape of the 80s / early 90s but also the diversity in server architectures and OSes

I'm not so sure. Or at least, I don't think a balkanized landscape like that would last very long before the market converges on some type of de-facto standard, much like things ultimately did in the 80's/90's, and late alternative ::ahem, Itanium:: failed to gain traction in the market.

Also, instead of a variety of (often vendor-specific) OS's, we're really only dealing with two major candidates: Windows & Linux. Linux with its multiple distributions is more complicated, although AFAIK the main server distros there are Ubuntu, Red Hat, Debian, and CentOS. So the chips that best support these OS's would likely be the one the industry converges on, assuming it's available as a commodity component. (i.e., not just in a propriety cloud) And it would be smart to make sure desktops/laptops can run the flavor of chips running in clouds because that's where much development/coding happens.

You’ll just be developing remotely. Amazon has had graviton for a while. Google has had TPUs you can use online but can’t buy locally.

What makes you think you’d have to have a local laptop? In fact, it’s in every behemoth’s interest to keep the good hardware managed and let the plebs work remotely using inferior technology.

Amazon already has Graviton 2, and considering the rapid pace they are switching over their infrastructure suggest to me they are going All In.

Microsoft and Oracle is partnering with Ampere. And Google is all over the map as usual, OpenPOWER, ARM, RISC-V. And I would not be surprised if they roll their own just like AWS. Marvell has ARM offering as well. ( They really should consider buying Ampere ) So it does seems like Server ARM CPU are consolidating to a few players anyway. And Despite what they claim, Ampere and Graviton 2 are pretty much customised from ARM's Server SoC reference design.

Apple will have a super large M1 like design for future Mac Pro. What I am interested in is if Apple would use this, assuming rack mountable Mac Pro for their own DataCenter usage? ( i.e Installing Linux ) Or Bring back Xserve?

What do you mean by somewhat compatible? Why fragmentation when Arm sets the ISA standard?

The base ISA is set by ARM, but every vendor has their own set of features turned on or off, and their own extensions, and potentially their own way of laying out memory mapped IO and identifying peripherals.

Every vendor does not have their own set of extensions. Different x86 chips have different extensions (from a pre-defined set) - I don't see panic about x86 fragmentation.

Is there any difference between AMD and Intel these days in terms of instructions other than AVX512?

Not aware of any but there are significant extension variations even within Intel e.g. lack of AVX on Atom.

It's not panic but this is really annoying like with AVX-512. The side effect is that people are making choice for the target architecture.

All of the predictions / claims except for (1) seem very incorrect to me

At the big corps that I've worked, my laptop is just a client to the machine that hosts the code & does the builds (that machine has been a giant Linux desktop & an ec2 instance)

We already see Apple chips in ec2. Today it's ostensibly "rent a machine to run your test suite" (although iiuc there's a 24h minimum rental), but I don't see any reason why it won't eventually be "just run your server on an apple cloud instance on ec2" (or develop locally in a container and deploy to that)

Software is actually reducing the friction of deploying to a different machine than you develop on, and the proliferation of high end custom chips isn't going to change that

Nuvia is a startup aiming to make server chip in a more Apple style. They have some serious heaveyweight designers including people who worked on Apple's chips and have gotten a lot of investment.

https://nuviainc.com/blog

I don't think the most important thing here is the ISA. A64 is a pretty nice and I don't see any reason you would want to be incompatible with it, especially since getting an ARM architecture license requires you to be compatible with other ARM chips. But Amazon isn't going with Apple's very wide and deep pipeline strategy and there's nothing to say that other ARM chips would either.

There is no incentive for AWS to add restrictions like Apple with XCode. Indeed, I think that this would just reduce the amount of the customers they can reach.

I don’t think that other computers manufacturers are going to follow Apple’s lead. Maybe Microsoft will do it if they decide to get serious with their Surface line.

The one company I see benefiting the most from this is Qualcomm. They have the customers and the money to invest in R&D.

Amazon already makes their own chips on the Graviton line. I wonder how long before you can get a graviton pc? maybe never?

I just had a vision: Amazon Basics Laptops

I would assume that they would go under the Fire branding, like FireBook.

They had a FirePhone but they seemed to not push it to hard and dropped it.

They couldn't convince developers to publish applications to the Amazon Store, which meant that the device was substantially less useful than a Google Android phone.

That's very interesting. A CR-48 looking, basic laptop with workable keyboard and trackpad. Chrome/Chromium OS (similar to CloudReady) since all the schools are on Google. If they could get it to $249 with reasonable performance, they could crush it.

Would they really want to use Google's OS? I would expect a FireTop, right?

Since we’re fantasising, I’d say a bare metal Linux distro — or a fork of Chromium OS — running as web client for AWS Workspaces. The downside is that you need an Internet connection at all times, and possibly a subscription.

To continue the fantasy: Amazon uses their experience with Stadia to deliver high-quality virtual desktops to thin client laptops.

You own nothing but the locked-down terminal that connects you to the AWS virtual desktop cloud.

That's not a vision, that's a nightmare.

Wait till you hear the best part. Like the Kindle, they will ship it with ads as screensaver. Additionally, you will receive promoted notifications once in a while.

You pay 529.99$ upfront, or a monthly subscription, in order to remove the ads and enjoy your O.S. powered by AWS Workspaces.

We're already living in Cyberpunk 2077...

And like their Halo Band, it'll listen in on your conversations to constantly assess your tone + upload semi-nude pics of you to AWS?

x86 line of processors is fragmented with tons of extensions.

There is more to a cloud than the chips. Having the cloud chip in your dev laptop wont mean you have the same memory/power/cooling/storage services. Code optimized on your laptop, despite having the same chip, wont necessarily run perfectly in the cloud.

Also it’s the architecture that matters, not the specific chip. And we got virtualization and containers for that.

I don't think any of the major cloud providers would be interested in #5. Better to have a wide open list of hardware that can develop for your platform. You can still run Windows VMs in AWS, Oracle DBs in Azure, etc.

re: 6: eh, it's less than that, as long as you're in the same architecture. Linux applications virtualized on M1, running on a Pi 4, and Graviton2 are going to be binary-compatible with each other, and although you'll get the extra atomic performance out of the M1, they won't be massively different other than just scaling up. Cross compiling after some testing to ensure the right atomic order was used should be fine cross-arch.

If one were to add more ARM extensions and actually push them for third-party usage, that might change though.

IMHO even if fragmentation happens (quite likely as RISC-V gains traction), this will force developers to actually take cross platform compatibility AND performance seriously.

It has nothing to do with their architecture. Here are the facts:

The M1 is a 5nm chip, while the i9 is a 14nm chip! The M1 has about 16b transistor, the i9 has only about half of that amount.

No surprise the M1 is faster. Most credit should go to TSMC for being able to manufacture 5nm chips.

The surprising fact is that M1 in a 999$ MBA can beat a 3000$+ MBP 16”, or get near the performance of a desktop CPU that cost ~400$.

This... isn't a fact. It's the opposite from what I've read - the architecture is just as important as the smaller nm process.

This post is good reading on the matter: https://news.ycombinator.com/item?id=25257932

I really doubt the M1 would perform nearly as good if it was a 14nm chip with 8b transistors.

The nanometer process is not an actual standard. So it's apples and oranges to compare two fabs

You are right, there different ways to measure transistors, but if I recall it correctly this should not account for more than 20 or 30% difference.

of course, but no matter the standards, TSMC 5nm is significantly smaller (and efficienter) than Intel 14nm.

> It has nothing to do with their architecture.

That it has zero to do with the architecture is a bold assertion (and seems unlikely).

In any event Apple would not have been able to manufacture / buy an x86 on 5nm so the architecture has quite a lot of influence on the performance of the latest Apple laptops.

I made the following thought experiment. If we downscale the M1 to a 8b transistor chip and make it use 14nm technology, would it still be faster than an i9 chip? I don't think so.

I think so. 3900X has 9.89b transistors and it is still faster than the i9.

Problem is your thought experiment doesn't work because you've ignored:

- The TDP of the M1 and the i9

- How each has utilised die area (e.g how much is devoted to CPU / GPU and accelerators)

When we see the version of the M1 for the larger MacBook Pros then the gap will become even bigger.

maybe you will be able to compile everything in the cloud and then it doesn't matter what type of computer you have

That would be the end of interesting software. Censorship at the compiler level.

> Back to mainframe / time sharing?

Back to the entirely proprietary mainframe of 1970 with dumb remote terminals.

But this time the mainframe performs pervasive surveillance.

Just use the gap in performance among smartphones. M1 utilises the same high performance cores A14 has. And A14 is ahead of competing Arm by roughly 2 years. Here's your answer, hardware-wise.

But in the world of software things are far more complicated.

The clouds should start building their own bytes so they can get cheaper bandwidth.