5 ms·

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 di

by hugi 6y ago

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.

bhouston 6y ago
I thought the m1 has dedicated js instructions.
- ssutch3 6y ago
  It's just part of the ARM instruction set.
  - Reason077 6y ago
    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? ;)
- rsynnott 6y ago
  Where'd you get that from? The m1 _does_ have one weird non-ARM extension; it can adopt an x86 memory model on demand.
- count 6y ago
  It's got better/more floating point capacity, which makes it faster at JS because all the numbers in JS are floating point number.
- ducktective 6y ago
  What are js instructions and what does javascript(?) have to do with ISA?
  - Gaelan 6y ago
    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.
  - flohofwoe 6y ago
    See here: https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FJCVTZS https://developer.arm.com/documentation/dui0801/g/A64-Floati... Not Apple Silicon specific though
- wezen 6y ago
  Which are part of arm ISA
- GeekyBear 6y ago
  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-deep-dive/2 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-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
  - Reason077 6y ago
    > "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-instruction-set-reference/a64-floating-point-instructions/fjcvtzs https://developer.arm.com/documentation/100076/0100/a64-inst...
    - GeekyBear 6y ago
      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/1049202132522479616 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 https://twitter.com/andreif7/status/1307420010177007625
- Decabytes 6y ago
  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?
  - kazinator 6y ago
    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.
kzrdude 6y ago
Linux is up and running? Maybe one should get a Macbook air then
djsumdog 6y ago
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.
- kube-system 6y ago
  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.
  - djsumdog 6y ago
    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.
    - kube-system 6y ago
      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.
ksk 6y ago
>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 :)
rualca 6y ago
> 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 https://en.wikipedia.org/wiki/Universal_binary

by hugi 6y ago

bhouston 6y ago

I thought the m1 has dedicated js instructions.

ssutch3 6y ago
It's just part of the ARM instruction set.
- Reason077 6y ago
  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? ;)
rsynnott 6y ago
Where'd you get that from? The m1 _does_ have one weird non-ARM extension; it can adopt an x86 memory model on demand.
count 6y ago
It's got better/more floating point capacity, which makes it faster at JS because all the numbers in JS are floating point number.
ducktective 6y ago
What are js instructions and what does javascript(?) have to do with ISA?
- Gaelan 6y ago
  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.
- flohofwoe 6y ago
  See here: https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FJCVTZS https://developer.arm.com/documentation/dui0801/g/A64-Floati... Not Apple Silicon specific though
wezen 6y ago
Which are part of arm ISA
GeekyBear 6y ago
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-deep-dive/2 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-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
- Reason077 6y ago
  > "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-instruction-set-reference/a64-floating-point-instructions/fjcvtzs https://developer.arm.com/documentation/100076/0100/a64-inst...
  - GeekyBear 6y ago
    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/1049202132522479616 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 https://twitter.com/andreif7/status/1307420010177007625
Decabytes 6y ago
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?
- kazinator 6y ago
  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.

kzrdude 6y ago

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

djsumdog 6y ago

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.

kube-system 6y ago
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.
- djsumdog 6y ago
  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.
  - kube-system 6y ago
    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.

ksk 6y ago

>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 :)

rualca 6y ago

> 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 https://en.wikipedia.org/wiki/Universal_binary