Erik Engheim writes on Medium about processor design (Apple M1, RISC-V, ARM), the Julia language, and engineering topics like airships and SpaceX.
HN commenters cite his posts to support points about Julia versus Python, and to argue Elon Musk acts as SpaceX's chief engineer.
M1 is still just a tablet SoC in a laptop form factor.
That wouldn't be good enough for production hardware. The developer units had a previous iPad’s A12 SoC in an enclosure for developers to test things on. For example, the A series doesn't support virtualization because that's not required on a phone or tablet. But the M1 supports this and other laptop/desktop features. Even the A14 only has 4 cores compared to the M1's 8 cores. This isn't just a tablet SoC.
We don't know what the efficiency will look like after you add all the I/O you need for a real desktop, we don't know how the memory subsystem will deal with 4 more cores that are just as fast. What's the point of having fast cores if you cannot feed them?
Perhaps you haven't been paying attention, but the Mac mini is a real desktop. And all of the M1 Macs have blazingly fast memory access. Remember, it's an SoC—the memory is on the same die as the CPUs, GPUs and they all have equal access to it. No bus to go across. That's why it's so fast.
People act like Apple changed the game or is light years ahead of everyone but they literally haven't made a proper desktop-class chip yet.
The M1 already has features no "desktop" chip has, such as 8 instruction decoders. This may not sound like a big deal, but none of the Intel or AMD chips--not the threadripper or the Zen3—has more than 4. Why this matters:
"It is because the ability to run fast depends
on how quickly you can fill up the ROB with
micro-ops and…
There are lots of little things that add up. Things like expressing multiline closures in Python is clunky compared to almost any other dynamic language whether Ruby, Lua or Julia.
AsyncIO is quite complex in how it works. You use the same patterns for concurrency in Julia, but it is so much easier to grasp and work with.
Multiple-dispatch as used in Julia e.g. makes API design so much cleaner. You can see that almost anywhere. I make some comparison of making REST calls in Python and Julia here. Julia is much cleaner IMHO: https://erik-engheim.medium.com/explore-rest-apis-with-curl-e58ebaaabf7a
The Python problem is that you cannot reuse the same function name easily for different types. Hence instead of creating one abstraction across many different types you need to invent all these different names which can be hard to guess. In Julia there are often far fewer core concepts to learn which can be re-applied in far more ways.
Python insistence on an object-oriented approach often creates problems. I have some observations on that in machine learning, looking at PyTorch compared to Julia's Flux: https://python.plainenglish.io/python-experience-in-machine-learning-from-julia-perspective-fe24e42eee4a
Out of the box experience is not all that great. The Python REPL is very bare bones. https://erik-engheim.medium.com/python-vs-julia-observations-e61ee667fa95
Things like calling shell programs is done more elegantly in Julia. Same with calling C functions. String…
Oh, I found the apparently quite limited number of Japanese syllables interesting, and indeed:
> The basic units of the Japanese writing system are syllables. Standard Japanese uses 100 distinct syllables. Of these, 5 are single vowels, 62 are consonants combined with a vowel, and 53 are consonants combined with 'y' plus a vowel. [1]
Which suggests a relatively obvious possibility of a simple writing system, where learning to write and read doesn't require memorizing countless (logographic / concept based) kanji. Though kanji seem to be older. So apparently the syllable/character association was not as obvious as it seems.
It's interesting that assigning syllables characters isn't really practical in Germanic/Romance languages, as there are far more than in Japanese. One source cites 15.000 out of 100.000 possible for English [2]. It's actually cool that someone came up with the consonant/vowel distinction, ages ago, which saves tons of characters, and which proved to be a big advantage (mostly over logographic writing) when the printing press took Europe by storm, while it flopped in China and Korea [3].
[1] http://afe.easia.columbia.edu/japan/japanworkbook/language/lsp.htm
[2] https://www.phon.ucl.ac.uk/courses/spsci/iss/week7.php
[3] https://erik-engheim.medium.com/why-didnt-china-become-the-world-superpower-37408d6d0616
RISC ISAs are about an assembly language that is for compilers to write, not humans. That's not to say you can't, but the dance in and out of the registers is tedious.
And RISC-V is more explicitly pure-RISC than ARM, and honestly I think ARM is "friendlier" to write with its conditional instructions and other conveniences. Also for some reason I find the ARM mnemonics easier to read. Maybe it's the 6502 influence, I dunno. FWIW I have never learned x86 assembly; when I went from 68000 to x86, I just started writing C instead.
I'm not saying any of this makes ARM superior. I think RISC-V's choices make more sense for a compiler target. It's not meant to be written by humans. But on a "retro" machine, assembly is kind of part of the deal.
Maybe a fancy macro assembler for RISC-V would be nice, to give a slightly higher level CISC-style set of semantics, but without going the whole hog to a high level language.
https://erik-engheim.medium.com/arm-x86-and-risc-v-microprocessors-compared-92bf0d46fd52 has a nice breakdown.
Well, two main reasons:
1. Innovator's dilemma: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma
ARM in this case is the underdog, attacking the incumbent x86. It is the lesser tech because it started from "below" (lower value niches not taken by the incumbent which prefers higher profit margins).
2. RISC vs CISC has never been settled. Until Apple (and Amazon super recently) produced their super recent architectures based on ARM, x86 was considered superior. Yes, RISC was theoretically better in the 80s and later 90s, but x86 has been reinvented successfully 2 times (micro-ops and x86_64) and scaled from 0.2MHz to 5Ghz. It's also a mix of CISC and RISC, it's not pure CISC now. Same for ARM, they've added various instructions which bring it closer to CISC.
As far as I can see the only real difference these days is the constant length of instructions for ARM: https://erik-engheim.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2
> ... is there something else going on in this case?
There is: the term comes from general CPU design terminology and is not specific to RISC-V, although Google does find some RISC-V-specific materials for me given your query[1–3]. Look for micro- and macro-op fusion in Agner Fog’s manuals[4] or Wikichip[5], for example.
[1]: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fusion-finalV2.pdf
[2]: https://reviews.llvm.org/D73643
[3]: https://erik-engheim.medium.com/the-genius-of-risc-v-microprocessors-b19d735abaa6
[4]: https://www.agner.org/optimize/#manuals
[5]: https://en.wikichip.org/wiki/macro-operation_fusion