7 ms·
Modern Microprocessors – A 90-Minute Guide (2001-2016)
- walski 5y agoGreat post, last updated 2016. Might be helpful context on discussed architectures and processors.
- unnouinceput 5y agomost info is from 2001. about only 20% (some graphs and tables / descriptions) are updated in 2016.
- alblue 5y agoI gave a presentation last year on this for QConLondon (before the lock down) and afterwards for the LJC virtually, if people prefer to listen/watch videos. https://speakerdeck.com/alblue/understanding-cpu-microarchitecture-for-performance-ljc https://speakerdeck.com/alblue/understanding-cpu-microarchit...
- deleted 5y ago[deleted]
- klelatti 5y agoThank you for this - really engaging presentation.
- tambourine_man 5y agoCouldn’t find the video on the link above but I guess the previous one is this: https://youtu.be/rglmJ6Xyj1c https://youtu.be/rglmJ6Xyj1c
- alblue 5y agoIt’s at the bottom of the description: The presentation was recorded at the London Java Community meeting in April 2020, and a recording is available here: https://youtu.be/C4HEoBYL0yk https://youtu.be/C4HEoBYL0yk
- Thorentis 5y agoI would love a Bartosz Ciechanowski interactive article on microprocessors. It may be outside his domain though, since the visualisations and demo's would be less 3D model design, and more, perhaps, mini simulations of data channels or state machines that you can play through. Registers that can have initial values set, and then you can step through each clock cycle. Add a new component each few paragraphs and see how it all builds up. I did all this at university, but would love a refreshers that is as well made as his other blog posts.
- mhh__ 5y agoI have been toying with making a game which is factorio-ish but literally for processors so potentially watch out for that (got a job now, though...)
- pantulis 5y agoIsn't the material a little bit old? I remember reading about all this stuff in the University circa 1996. Edit: originally said "outdated".
- artemonster 5y agoahem, what HAS changed since then? besides new models & more updated "MHz" values and some tables with performances, nothing that is of interest to a compressed introduction to the topic. So, personally, what would you have added to the article?
- pantulis 5y agoWell, I wouldn't know, that's why I clicked on the article :P I said "outdated" in a wrong way, because this means is not valid today, which is obviously not the case.
- kens 5y agoI wouldn't say outdated, but these ideas have a long history. Superscalar processors go back to Cray's CDC 6600 in 1966. Cache memory was used in the IBM System/360 Model 85 in 1969. Pipelining was used in the ILLIAC II (1962) and probably earlier. Branch prediction was used in the IBM Stretch (1961). Out-of-order execution and register renaming was implemented in the IBM System/360 Model 91 (1966). It's interesting to see how many CPU architecture ideas that we consider modern were first developed in the 1960s, and how they took a long time to move into microprocessor.
- FullyFunctional 5y agoThat's of course true, but it's might be misleading. OoO didn't take off until HPS came up with the reorder buffer (and enabled precise exceptions), with Pentium Pro being the first (and highly successful) implementation. Also, branch prediction has dramatically improved since stretch, McFarly's two-level was a breakthrough and the current state of the art is Seznec's TAGE-SC. My point is that there's still a lot of advancement made.
- 5y ago
- 7373737373 5y agoThese kinds of optimizations always make me wonder whether they are worth it. Might it be more efficient to use these transistors for more, simple cores instead? Perhaps the property that most problems are so sequential makes timing/clock rate optimizations inevitable.
- posobin 5y agoPrevious discussions: 2018, 87 comments: https://news.ycombinator.com/item?id=18230383 https://news.ycombinator.com/item?id=18230383 2016, 12 comments: https://news.ycombinator.com/item?id=11116211 https://news.ycombinator.com/item?id=11116211 2014, 37 comments: https://news.ycombinator.com/item?id=7174513 https://news.ycombinator.com/item?id=7174513 2011, 30 comments: https://news.ycombinator.com/item?id=2428403 https://news.ycombinator.com/item?id=2428403 This link has also appeared in 9 comments on HN, featuring threads on "Computer Architecture for Network Engineers", "X86 versus other architectures" by Linus Torvalds, and "I don't know how CPUs work so I simulated one in code", also recommending a udacity course on how modern processors work (https://www.udacity.com/course/high-performance-computer-architecture--ud007 https://www.udacity.com/course/high-performance-computer-arc...): https://ampie.app/url-context?url=lighterra.com/papers/modernmicroprocessors https://ampie.app/url-context?url=lighterra.com/papers/moder... Jason also has a couple of other interesting articles on his website, like intro to instruction scheduling and software pipelining (http://www.lighterra.com/papers/basicinstructionscheduling/ http://www.lighterra.com/papers/basicinstructionscheduling/) and the one I liked a lot and agree with called "exception handling considered harmful" (http://www.lighterra.com/papers/exceptionsharmful/ http://www.lighterra.com/papers/exceptionsharmful/).
- peter_d_sherman 5y ago>"One of the most interesting members of the RISC-style x86 group was the Transmeta Crusoe processor, which translated x86 instructions into an internal VLIW form, rather than internal superscalar, and used software to do the translation at runtime, much like a Java virtual machine. This approach allowed the processor itself to be a simple VLIW, without the complex x86 decoding and register-renaming hardware of decoupled x86 designs, and without any superscalar dispatch or OOO logic either." PDS: Why do I bet that the Transmeta Crusoe didn't suffer from Spectre -- or any other other x86 cache-based or microcode-based security vulnerabilities that are so prevalent today? Observation: Intentional hardware backdoors -- would have been difficult to place in Transmeta VLIW processors -- at least in the software-based x86 translation portions of it... Now, are there intentional hardware backdoors in its lower-level VLIW instructions? I don't know and can't speculate on that... Nor do I know if the Transmeta Crusoes contained secret deeply embedded "security" cores/processors -- or not... But secret deeply embedded "security" cores/processors and backdoored VLIW instructions aside -- it would sure be hard as heck for the usual "powers-that-be" -- to be able to create secret/undocumented x86 instructions with side effects/covert communication to lower/secret levels -- and run that code from the Transmeta Crusoe's x86 software interpreter/translator -- especially if the code for the x86 software interpreter/translator -- is open source and throughly reviewed... In other words, from a pro-security perspective -- there's a lot to be said about architecturally simpler CPU's -- regardless of how slow they might be compared to some of today's super-complex (and, ahem, less secure...) CPU's...
- detaro 5y agoAFAIK Transmeta's core was doing a lot of speculative execution stuff, so if it evolved until today I wouldn't bet on it also gaining issues like Spectre.
- peter_d_sherman 5y agoIt would be an interesting test, wouldn't it? See if Transmeta Crusoe is vulnerable to Spectre? But, even if it is... keep in mind that when running x86 instructions, you still have the x86 translation software proxy layer... that means that could could grab any given offending / problem-causing x86 instruction -- when you encountered it, and recode the VLIW output from it to output a different set of native VLIW instructions -- that you knew were safe... In other words, with a Transmeta Crusoe -- if the x86 translation layer is open source and you possess it (and can code / understand things) -- then you'll have some options there. Which is unlike a regular x86 CPU -- where the way it decodes and executes instructions -- cannot be changed in any way by the user...
- ruslan 5y agoGood read. It must be noted this article discusses von Neumann architecture and alike (Harvard).
- bogomipz 5y agoI had a question about the following passage: >"The key question is how the processor should make the guess. Two alternatives spring to mind. First, the compiler might be able to mark the branch to tell the processor which way to go. This is called static branch prediction. It would be ideal if there was a bit in the instruction format in which to encode the prediction, but for older architectures this is not an option, so a convention can be used instead, such as backward branches are predicted to be taken while forward branches are predicted not-taken. Could someone say what the definition of "backward" vs a "forward" is? Is backward the loop continues and forward a jump or return from a loop? Also are there any examples of "static branch prediction" CPU architectures?
- bogomipz 5y agoI was curious about the following comment on SMT in the post: >"From a hardware point of view, implementing SMT requires duplicating all of the parts of the processor which store the "execution state" of each thread – things like the program counter, the architecturally-visible registers (but not the rename registers), the memory mappings held in the TLB, and so on. Luckily, these parts only constitute a tiny fraction of the overall processor's hardware." Is each "SMT core" then just one additional PC and TLB then? I'm not sure if "SMT core" is the correct term or just "SMT" is but it seems like generally with Hyper Threading there is generally 1 hyper thread available for each core effectively doubling the total core count. It seems like it's been that way for a very long time. Is there not much benefit beyond offering single hyper thread/SMT for each core? Or is just prohibitively expensive?
- ajdlinux 5y agoIBM POWER8 has 8-way SMT, and POWER9 has 4-way and 8-way models.
- cosmotic 5y agoHow old does something have to be before it can no longer be called modern? I think 5 years is a stretch.
- ocrow 5y agoI would love for an update that covers recent developments in SOC integrations, for example the onboarding of RAM and neural processing in the M1 chip.