[HN Gopher] A primer on x86 by Casey Muratori and The Primeagen ...
___________________________________________________________________
A primer on x86 by Casey Muratori and The Primeagen [video]
Author : kamikaz1k
Score : 53 points
Date : 2024-04-14 19:27 UTC (3 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| grzeshru wrote:
| The video title is "x86 needs to die" so the HN re-word is highly
| editorialized.
| tredre3 wrote:
| Which is good because the HN title tells me exactly what it is
| whereas the original title tells me nothing.
| aCoreyJ wrote:
| The video title is the title of the article they are reacting
| to and mostly not agreeing with
| klodolph wrote:
| I got tired of the video because they never got to the point.
| Here's the article:
|
| https://hackaday.com/2024/03/21/why-x86-needs-to-die/
|
| The article is, uh, well it's bad. I'm a little hesitant to
| respond point-by-point to an article like this because it just
| sucks up so much time, and there's just so much wrong with the
| article on so many levels. Here's the response article:
|
| https://chipsandcheese.com/2024/03/27/why-x86-doesnt-need-to...
|
| The video appears to go into detail about things like how
| pipelines but it's a long video that just doesn't get to the
| point fast enough. I think the video is somewhat tearing into the
| article and ripping it apart, but I hear some comments in the
| video which I think are not that great, like at 1:01:25:
|
| > RISC is reduced instruction set computer, just means not very
| many instructions
|
| RISC is better understood not in terms of the acronym itself, but
| as a label for the way CPUs were designed post 1980 or so.
| lloydatkinson wrote:
| It seems there's a cult following of pseudo-intellectuals/dev
| celebrities who all seem to have only worked at "faang" like
| companies. Everything about it is a bit weird.
|
| In this case, the one named like prime number, seems to spend
| extraordinary amounts of time waffling on about nothing in
| particular on twitch streams with a relentless torrent of
| energy, and then this feeds the echo chamber of their fans.
|
| Nothing of substance is touched on more than briefly. I am not
| really sure what the point was of this whole article and guest
| appearance.
| wudangmonk wrote:
| TLDR but I'm responding to let you know that I'm grumpy, got
| that? I am grumpy, carry on.
| MaximilianEmel wrote:
| This would have been much better if it was just Casey.
| Zhyl wrote:
| The Primeagen feels like he's bringing Linux, neovim,
| programming et al to a new audience, in the same way that Low
| Level Learning [0] brings rust, assembly and reverse
| engineering to a younger audience.
|
| I don't think his style is for me personally, but I definitely
| feel the world is a better place with his voice in it.
|
| [0] https://www.youtube.com/channel/UC6biysICWOJ-C3P4Tyeggzg
| znpy wrote:
| I followed the primagen briefly, and then unsubscribed. The
| primagen occasionally does super interesting content like
| this one video but otherwise his content is useless garbage
| on average.
|
| Some examples: reaction to other videos rating programming
| languages, reading out articles (like one guy shutting down
| some cloud services and instantly realising half a million
| bucks savings for the company) while commenting out loud but
| adding little to nothing useful, and some neovim videos where
| he basically copy-pastes some code here and there and sone
| functionality appears (without any actual explanation about
| how the code he pasted actually works).
|
| I like the guy, but i've realised that:
|
| 1. His content is not a good use of my time (wrt my interests
| and my skill level)
|
| 2. When he makes actually good content (like this one in this
| case) it'll reach me anyway, somehow.
|
| Hence I unsubscribed.
| anonnon wrote:
| I completely agree. The host needs to lay off the Adderall, or
| at least reduce his dosage.
| anonnon wrote:
| I get that most of HN is abusing stimulants, and so that
| comment understandably touched a nerve, but the host of the
| video is literally an admitted former meth addict who worked
| at a FAANG company (Netflix):
| https://www.youtube.com/watch?v=JjHFubUPLV0
|
| Given his demeanor and past, it would be shocking if he
| weren't at least abusing Adderall or Vyvanse.
| lloydatkinson wrote:
| Without a doubt. The other one is absolutely exhausting to
| listen to.
| soupbowl wrote:
| I like Primeagen, he brings entertainment to boring topics, I
| understand others might not like his style. I think we can
| leave it at that and not accuse him of drug abuse, lol.
| petermcneeley wrote:
| The mill computing project is basically a criticism of x64 I
| wonder what article Ivan Godard would have written.
| jiggawatts wrote:
| I've been follow the Mill project for many years now and it's a
| bit disappointing that they've made more YouTube videos than
| chips.
| camel-cdr wrote:
| I think there are a few other legitimate problems with x86 than
| decode complexity:
|
| * x86_64 traditionally only has 16 registers and destructive
| instructions. This is apparently also a problem for Intel, hence,
| they introduced APX which goes to 32 GPR and adds three-operand
| instructions. But who will use APX in the next 10 years outside
| specialized server software and gentoo users? Consider that most
| applications still target x86-64-v1, and runtime dispatch isn't
| really practical for this.
|
| * Piling on ever larger SIMD extensions. This is not so much a
| burden on the implementation, but on the software landscape. The
| way intel and AMD traditionally seem to implement SIMD
| instructions, is to have execution units that can do an operation
| of the largest SIMD width, and use those to also execute the
| smaller SIMD widths. That seems reasonable, and probably is a
| good tradeoff given the decode complexity, but it also means that
| not using the latest SIMD extension wastes a lot of compute
| power. If decode was easier, you could've stuck with one SIMD
| width, and just add more execution ports, which means that older
| software also gets a speedup on newer generations. This is kinda
| what AMD did for Zen 4, where they implemented AVX512 on top of
| AVX2, instead of the other way around. Or how ARM implementations
| that only support 128-bit wide NEON can keep up with AVX2
| (256-bit) and sometimes AVX512 (512-bit).
|
| * All the legacy things may not cost much in terms of die space,
| because they are implemented in microcode, but I'd imagine they
| have significant development and verification costs.
|
| Edit:
|
| Another aspect regarding decode complexity is that the latest ARM
| cores started removing the uop cache, this would be pretty much
| impossible for a fast x86 implementation. I wonder how ARM decode
| width - uop cache and x86 decode width + uop cache scale for
| wider and wider cores.
| dan-robertson wrote:
| I read that the hardware required to decode an x86 instruction
| isn't actually that bad (potentially less than certain other
| fixed width encodings). The problem is that it is hard to
| decode several instructions from the stream at once
| jiggawatts wrote:
| > But who will use APX in the next 10 years?
|
| There is a decent change that the bytecode runtimes will enable
| this instruction set in their JIT output. This would include
| .NET, JVM and V8.
| zer00eyz wrote:
| >> Consider that most applications still target x86-64-v1, and
| runtime dispatch isn't really practical for this.
|
| https://developers.redhat.com/articles/2024/01/02/exploring-...
|
| Redhat 9 went v2 and they are pushing for v3 now...
|
| I think the drums are beating for this to change in a lot of
| places. Debian will end up being the hold out and (as a Debian
| consumer) I dont know how I feel about this...
| dralley wrote:
| Since Red Hat has a 10 year lifecycle, it can be a little bit
| more aggressive than Debian, since the last version is still
| going to have 7+ years of support for whatever hardware is
| phased out in the new version.
|
| The target platforms are also a bit narrower.
___________________________________________________________________
(page generated 2024-04-14 23:00 UTC)