7,529 karma · joined October 4, 2013
The speed is about the same. The big colmak win for me was that my hands/arms didn't ache after long typing sessions. Ergonomics and not getting repetitive motion injuries matter to me more than compatibility (though I can still type in qwerty even if it's slower these days).
The academic argument Linus himself made is alone reason enough that big-endian SHOULD be included in the ISA. When you are trying to grasp the fundamentals in class, adding little endian's "partially backward, but partially forward" increases complexity and mistakes without meaningfully increasing knowledge of the course fundamentals.
No zbb support is also a valid use. Very small implementations may want to avoid adding zbb, but still maximize performance. These implementations almost certainly won't be large enough to run Linux and wouldn't be Linus' problem anyway.
While I've found myself almost always agreeing with Linus (even on most of his notably controversial rants), he's simply not correct about this one and has no reason to go past the polite, but firm "Linux has no plans to support a second endianness on RISC-V".
Saying "you can have big-endian in your ISA, but we won't be supporting it" is very different from railing on about the ISA having big-endian at all.
Most importantly, big-endian numbers have overwhelmingly won the human factor. If I write 4567, you don't interpret it as 7 thousand 6 hundred and fifty-four. Even an "inverted big-endian" (writing the entire sequence backward rather than partially forward and partially backward like little endian) makes more sense and would be much more at home with right-to-left readers more than little endian too.
Did he make the same rant about ARMv8 which can (if implemented) even switch endianness on the fly? What about POWER, SPARC, MIPS, Alpha, etc which all support big-endian?
Once you leave x86-land, the ISA including optional big-endian is the rule rather than the exception.
More real-world is that I know tons of friends/relatives in the South and I don't know of even ONE that liked the redesign.
It was one of the biggest features of A715 going by ARM’s slides.
The original intent of uops in x86 was to break more complex instructions down into more simple instructions so the main pipeline wasn't super-variable.
If you look at new designs like M-series (or even x86 designs), they try very hard to ensure each instruction/uop retires in a uniform number of cycles (I've read[0] that even some division is done in just two cycles) to keep the pipeline busy and reduce the amount of timings that have to be tracked through the system. There are certainly instructions that take multiple cycles, but those are going to take the longer secondary pipelines and if there is a hard dependency, they will cause bubbles and stalls.
https://www.semiconductor-digest.com/moores-law-indeed-stopp...
M1 core is 2.28mm2 and Zen3 core is 4.05mm2 if you count all the core-specific stuff (and 3.09mm2 even if you exclude the power regulation and the L2 cache that only this core can use). That is 27-45% larger for generally worse performance (and all-around worse performance if per-core power is constrained to something realistic). I'd also note that Oryon and C1-Ultra seem to be much more area efficient than more recent Apple cores.
We're at a point where Apple's E-cores are getting close to Zen or Cove cores in IPC while using just 0.6w at 2.6GHz.
If you count EVERYTHING outside of the core (power, matrix co-processor, last-level-cache, share logic, etc), and average out, we get 15.555mm2 / 4 = 3.89mm2 for M1.
If we do the same for Zen3 (excluding tests and infinity fabric), we have 67.85mm2 / 8 = 8.49mm2.
M1 has 12mb of last-level cache (coherent) or 3mb per core while Zen3 has 4mb of coherent L1 and 32mb of victim cache (used to buffer IO/RAM read/write and to hold cache misses in hopes that they can be used eventually). You can analyze this how you would like, but M1's cache design is more efficient and gives a higher hit rate despite being smaller. Chips and Cheese has an interesting writeup of this as applied to Golden Cove.
https://semianalysis.com/2022/06/10/apple-m2-die-shot-and-ar...
https://x.com/Locuza_/status/1538696558920736769
https://semianalysis.com/2022/06/17/amd-to-infinity-and-beyo...
https://chipsandcheese.com/p/going-armchair-quarterback-on-g...
ARM shed 75% of their decoder size when removing support for the 32-bit ISA in their A-series cores and it’s nowhere near as bad as x86.
A Haskell analysis showed that integer workloads (the most common in normal computing) saw some 4.8w out of 22.1w dedicated to the decoder. That’s 22% of total power. Even if you say that’s the high-water mark and it’s usually half of that, it’s still a massive consideration.
If the decoder power and size weren’t an issue, they’d have moved past 4-wide decode years ago. Instead, golden cove only recently went 6 wide and power consumption went through the roof. Meanwhile, AMD went with a ludicrously complex double 4-wide decoder setup that limits throughput under some circumstances and creates all kinds of headaches and hazards that must be dealt with.
Nobody would do this unless the cost of scaling x86 decided was immense. Instead, they’d just slap on another decoder like ARM or RISC-V does.
No matter how you slice up their handset and mobile divisions profits, the current cost is billions just to license an ISA.
Qualcomm could likely pay for most of their chip design costs with the amount of money they’re giving ARM. When contract renewal comes up, Qualcomm will be even more incentivized to move to RISC-V.
Apple has apparently been moving on chip soft cores to RISC-V. At some point (probably around renewal time), they’re likely to want to save money by switching to RISC-V too.
There are even rumors of ARM working on RISC-V cores (I’d guess smaller cores to compete with SiFive).
There’s an economic incentive to change and the only blocker is ARM inertia, but making ARM emulate quickly on RISC-V is almost certainly easier than making x86 and all its weirdness/edge cases run on ARM.
Once the software is in place (getting close) and a competitive RISC-V phone chip exists, I suspect the conversion will be very fast.
The translation layers cost time and money to build which could be spent making the rest of the chip faster. They stuck up extra die area and use power.
ARM’s total income in 2024 was half of AMDs R&D budget, but the core they finished that year can get x86 desktop levels of performance in a phone.
The idea that there’s no cost to x86 just doesn’t seem to hold up under even mild scrutiny.
ARM’s entire gross profits are about half of AMD’s R&D budget, but ARM cores have soundly beat x86 in IPC for years now (since around A78) and the most recent generations seem to be beating them in total performance, perf/watt, and core size.
We now have all three of the big ARM-based cores (Apple, ARM, and Qualcomm) beating x86. Apple you could maybe write off as unlimited money, but all three isn’t just coincidence.
If that weren’t enough, ARM designers are releasing new cores every year instead of every other year meaning they are doing around twice as many layout and validations despite the massively lower budget.
Before I get the “ARM only makes cores” excuses, I’d note that ARM announced that they’ve been working on their own server chips and that work is obviously having to fit within their same (comparatively tiny) budget.
It seems fairly obvious. Spring legacy garbage drives up complexity and cost (eg, ARM reduced A-series decoder size by 75% when they dropped 32-bit mode which was still way less complex than x86). This complexity drives up development time and cost. It also drives up validation cost and time.
There’s also a physical cost. Large, high frequency uop caches and cache controllers are better than just decoders on x86, but worse than not needing them at all is better still. Likewise, you hear crazy stuff like the x86 overly-strict memory model not mattering because you can speculate it away. That speculation means more complexity, more power, and more area.
Once you’re done with enough of these work-around, you get a chip that is technically as fast, but it cost more to design, costs more to validate, costs more to fab, costs more to buy, costs more to operate, and carries an opportunity cost from taking so much longer to get to market.
ARMv9 still has very few instruction modes with far less complexity when you compare it with x86 or some other classic CISC ISA.
> memory access performance hasn't increased to the same extent as compute performance, thus putting a relatively bigger emphasis on code density.
The problem isn't RAM. The problem is that (generally speaking) cache is either big or fast. x86 was stuck at 32kb for a decade or so. Only recently have we seen larger 64kb caches included. Higher code density means more cache hits. This is the big reason to care about code density in modern CPUs.
RISC-V shows that you can remain RISC and still have great code density. Despite arguably making some bad/terrible decisions about the C instructions, RISC-V still generally beats x86 in code density by a significant margin (and growing as they add new instructions for some common cases).
How is it that you can say these words without confusion?
Language is context sensitive and you understand the word based on the context around it. Likewise, you understand homographs based on the context. Because of this, spelling isn't as important as it might appear.
https://www.thenationalliteracyinstitute.com/2024-2025-liter...
> It's annoying enough for me when some books use French words.
From around 1060 to 1360, French was the official language of England. It wasn't normal French though as William the Conqueror spoke Norman French. Both French dialects mixed in what can only be considered English style. For example Norman French said Warder while other French speakers said Guarder. English adopted both Warden and Guard, but gave them two different meanings. Overall, some 30% of our words are French though over 800 of the most common 1000 words are English in origin.
> would adding half a dozen letters to the alphabet really help with increasing literacy?
ITA (International Teaching Alphabet) shows the benefits and problems.
ITA students rocketed ahead the first couple of years and could read way more words than their traditional counterparts. The problem was the transition. Learning both systems seems to have evened things up or maybe even caused a net negative for ITA students. I believe this was because they had to learn two sets of spelling for everything. If you would like to see the difficulty in learning a new way to read/write and have a bit of fun, try learning Shavian script.
In an ideal world, they would have phonetic spelling only. I believe under those conditions that their advantage would continue to grow all the way through school. The problem is that this study is unethical to conduct because even if it is correct, the students would graduate and be unable to read traditional English which would permanently harm them.
This leaves the tricky problem of bridging the gap. This can't be done too quickly or the older generations get left behind. There's also an issue of transcribing everything into the new spelling. Technology has made that easier than ever, but it would still be a very hard proposition.
The first and easiest step is cleaning up the spellings using the letters we currently have. Stuff like all those -ough endings get rewritten in sane letters as an accepted alternative spelling. Silent letters start going away. We start moving toward consistent vowel and consonant digraphs. This will take time for older people to adapt to, but more consistent rules will mean they will have an easier time sounding them out.
After this, we start adding back letters. Maybe eth and thorn come back for the two "th" sounds. We certainly need a new letter for the S in "treaSure" and maybe bring back the elongated S to use for SH. At some point, we then start working on slowly adding new characters to stand in for the vowel digraphs.
I don't think you could convince adults to do more than a couple of steps at a time each generation. Such a plan would likely take decades to maybe even a century or two. Until the creation of the printing press, such slow changes were considered normal. Only in recent times have we attempted to gate-keep what "real English" is. If we allow the language to grow more organically, I think it could be guided into something far better than we have today.
There are certainly differences, but if you place current English spelling next to something like Shavian (or some other language with near-pure phonetic spelling), I'd say that Modern English learning patterns are closer to Kanji than the pure phonetic alphabets.
We pretend phonics exists, but it's just a lie we tell little kids to kickstart their learning. In reality, English spelling is more like learning Kanji. The original meanings of the words is warped beyond belief and we tell the specific pronunciation of specific letter sequences based on the surrounding letter sequences (much like telling which Kanji reading to use based on the surrounding Kanji). Words aren't so much sounded out as memorized and because English has such a massive vocabulary, the memorization work needed to be proficient is very extensive.
The classic example of this is "ough" which has NINE different pronunciations for the same letters and no real rules to indicate which one should be used. Spelling reform would make such situations completely unnecessary.
Languages with more phonetic alphabets tend to have much higher literacy rates for the same education quality and literacy can be achieved much faster. This works because once you memorize the sounds the letters make, you can sound out any word or write any word (provided you pronounce it correctly). The memorization process slowly kicks in where common words are still sight-read, but that process can happen much sooner and the individual can start independent reading much earlier with a focus on comprehension rather than memorizing weird rules and exceptions.
English departments have done massive damage in this regard. English started finalizing how words would be spelled around the same time the great vowel shift happened and completely screwed up everything. We then mass-adopted words with foreign spellings that used completely different phonetic systems. Despite the issues, English departments insist that these bugs are actually features despite the great harm they cause students and not only codify them, but denigrate all attempts to fix the problems.
English departments aren't the only ones. Even 150 years ago when Webster was trying small spelling reforms (some stuck around and some did not), people complained that the writing was childish. When Teddy Roosevelt tried a further spelling reform of getting rid of unneeded letters, he was turned into a laughing stock for the same reason (again with a handful sticking around). Modern "text speak" is yet another unofficial attempt to simplify spelling so it is more consistent, but once again, better, shorter alternatives are derided as making someone look unintelligent.
This still doesn't deal with the more fundamental phoneme/alphabet mismatch though. English has 44 common phonemes and a bunch of less common and regional sounds (for example, the χ sound in "cloCK"). Our adopted Latin alphabet has 26 letters of which at least 3 are unneeded (C as K or S, Q as KW, and X as KS). This leads to a horrible situation where a lot of sounds no longer have letters (Futhorc didn't get all the sounds, but still did better with 33 letters of which something like 11 were vowels). Some English sounds like the S in "treaSure" seem to have no real, unique spelling at all. Others like th and th have no indicator if it is supposed to be voiced like "THen" or unvoiced like "THink" (we used to have thorn and eth for this). We have 18 unique consonants and 24 common consonant sounds.
The vowel situation is even more dire. We have just 5 vowels and around 20 common vowels leaving each vowel desperately overloaded with all kinds of weird phonics "rules" and almost all of them having either multiple rules or different pronunciations for the same word (eg, "reed" vs "red" in "I read the book"). There needs to be massive vowel reform (either a ton of stable digraphs, diacritics, or more letters) so that sounds can be differentiated properly.
Spelling reform could all but eliminate our illiteracy problems and open a whole new world of possibilities to more than half of all Americans. In a world dominated by ever-increasing volumes of information, these people would have much better lives if we lowered the bar of learning to read to something more attainable.
The long and the short is that x86 is WAY behind in every way. The chips are larger, hotter, and slower too. If the rumored A19 Pro in a $500 laptop happens, it's going to absolutely crush the wintel market.
The stuff about Graviton is missing a key element too. Look at the X3 scores below. They are around 30% slower than the x86 competitors. This is what Graviton 4 is using (Neoverse V2 is based on X3). Neoverse V3 was announced almost 2 years ago now and is based on X4 which is a pretty big jump. I'd expect Neoverse V4 in Feb 2026 to be based on either X925 or C1 Ultra. When these newer, faster cores hit the market, they will be beating x86 in cost (the cores are smaller) and power consumption if not peak performance too.
CPU Spec2017int Spec2017fp GB6 1T GB6 nT
a19 Pro 12.11 17.37 4019 11,054
A18 Pro 10.63 15.93 3605 9,376
A17 Pro 9.39 12.92 2975 7,273[10]
A16 8.52 12.01 2679 7.026[11]
9400 (x925) 8.73 13.67 3010 9,317
9500 (C1 Ultra) ~9.50 ~16.50 3709 10,716
O1 (x925) 9.19 14.46 3125 9.671
SD8Gen2 (X3) 6.52 10.49 2080 5,640[7]
SD8+ (X2) 5.71 9.68 1656 3,716[6]
SD8Gen3 (X4) 7.10 10.95 2366 7,552[9]
8 Elite 8.91 14.18 3237 10,242
8 Elite Gen 5 ~9.75 ~16.50 3946 12,546
U7 258v 8.28 11.57 2864 11,263[3]
HX370 8.02 12.81 3059 14,525[4]
[1] https://www.youtube.com/watch?v=YJaHi-gZESo
[2] https://www.youtube.com/watch?v=cB510ZeFe8w
[3] https://browser.geekbench.com/v6/cpu/14113967
[4] https://browser.geekbench.com/v6/cpu/14136651
[5] https://www.notebookcheck.net/AMD-Zen-5-Strix-Point-CPU-anal...
[6] https://browser.geekbench.com/v6/cpu/14141425
[7] https://browser.geekbench.com/v6/cpu/14173239
[8] https://web.archive.org/web/20240308050136/https://www.anand...
[9] https://browser.geekbench.com/v6/cpu/14169554
15% and increasing quickly. That’s nearly 1 in 5.
Pushing this point further, x86 chips are also slower when the entire task fits in cache.
The real observation is how this isn’t some Apple black magic. All three of the big ARM core designers (Apple, ARM, and Qualcomm) are now beating x86 in raw performance and stomping them in performance per watt (and in performance per watt per area).
It’s not just apples deep pockets either. AMD spent more in R&D than ARM’s entire gross profit margin last I checked. Either AMD sucks or x86 has more technical roadblocks than some people like to believe.
Intel first publicly mentioned Poulson all the way back in 2005 just FOUR years after the original chip was launched. Poulson was basically a traditional out-of-order CPU core that even had hyperthreading[0]. They knew really early on that the designs just weren't that good. This shouldn't have been a surprise to Intel as they'd already made a VLIW CPU in the 90s (i860) that failed spectacularly.
Web development moves faster than any software in history. A lot of this is on the back of JS being ergonomic/fast to code and having very good performance and a lot of what makes it good at this is also what coders familiar with other languages dislike.
What other language has that right combination of really fast development and good performance?
You would probably have to go outside the mainstream to something like Scheme or StandardML to get the ergonomics and performance, but that would upset a whole other group of people.
After that is an even bigger problem. If everyone adopts different languages, different frameworks for those languages, and different user-facing APIs for the WASM APIs, then finding devs for your frontend team who can be productive quickly suddenly becomes impossibly hard.
ES6 wouldn’t have been needed. CSS-in-JS would have become standard decades ago. HTML would have almost disappeared too because parsing s-expressions would have been native. JSON would never been invented either due to S-expr.
In short, everything about the modern web would have appeared decades sooner and been more consistent.
function MyForm() {
const [isHidden, setIsHidden] = useState(false)
return (
<>
<button onClick={()=>setIsHidden(!isHidden)}>{isHidden ? ‘Show’ : ‘Hide’}</button>
{!isHidden &&<form>your same stuff</form>}
</>
)
}
At it’s core, React isn’t very complex and you can build a lot of stuff without much complexity.
The problem I often see is developers overengineering stuff. It’s not react specific and you’ll find this issue everywhere, but the form it takes in react land is adding massive solutions to little problems. I’ve worked on apps with giant routing solutions for a handful of routes or complicated stores with almost nothing in them.
I suspect tech influencers and those of us writing actually large apps have an outsized voice if only because those devs keeping simple react projects simple just don’t have that much to write about.
Yes, all transpilers are compilers, but not all compilers are transpilers.