7 ms·
What's new in CPUs since the 80s? (2015)
- hulitu 5y ago"My first computer was a 286. On that machine, a memory access might take a few cycles. A few years back, I used a Pentium 4 system where a memory access took more than 400 cycles. Processors have sped up a lot more than memory" I remember seeing an add for Power which advertised memory speed at half the processor speed. I think only consumer CPUs have slow memories.
- musicale 5y agoWhat about wide/multiple issue/superscalar, deep pipelining, speculation, multicore (only mentioned briefly), load/store (RISC) architectures (including internal implementations of x86), heterogeneous designs, SoC designs, and various types of accelerators in addition to GPUs (media accelerators, ML accelerators, smart NICs...) Though probably few of those things are technically new since the 1980s.
- ant6n 5y ago2015? I think there’s a date missing on the page.
- MBCook 5y agoNear the end in one section the the author provides an update and refers to it being 2016, a year since they wrote the article.
- Aardwolf 5y agoFrom the top of my head (before reading the article): caches, pipelining, branch prediction, memory protections, SIMD, floating point at all, hyper threading, multi-core, needing cooling fins or let alone active cooling I wonder how much I've forgotten
- deleted 5y ago[deleted]
- varjag 5y agoMost of that (possibly all) existed by 1980s. The Z80 in my Spectrum had no heatsink ;)
- hulitu 5y agoThe last processor designed by hand was Alpha.
- yvdriess 5y agoAll of those already existed by the 80s.
- ithkuil 5y agoUS patent for the technology behind hyper-threading was granted to Kenneth Okin at Sun Microsystems in November 1994
- formerly_proven 5y agoCDC 6600 ran ten threads on one processor in a way that seems a lot like the Niagara T1 on paper.
- anamax 5y agoAnd between the two was HEP, by Burton Smith.
- ithkuil 5y agoI think the main difference is that the CDC 6600 the PP state barrel would rotate in a regular way constantly multiplexing the execution of the 10 virtual PPs in the same hardware. Hyper threading is the idea where the multiplexing of multiple threads happens dynamically based on data dependencies / stalls.
- yvdriess 5y agoFundamentally they are the same SMT concept though: multiple hardware threads that have separate register (and other) state but share an execution unit. HT as an implementation tries to give long sequential execution windows to a hardware thread, it's designed to hide occasional long latencies (IO typically), but pays by having a higher switching cost. A barrel processor trades off individual instruction latency for a higher degree of parallelism and improved latency hiding.
- code_biologist 5y agoI don't want to dismiss hyper-threading as trite — it's not, especially in implementation, but it is pretty obvious. Prior to 1994 the CPU-memory speed delta wasn't so bad that you needed to cover for stalled execution units constantly. Looking at the core clock vs FSB of 1994 Intel chips is a great throwback! [1] Then CPU speed exploded relative to memory, as was probably anticipated by forward looking CPU architects in 1994. With slow memory there are a few obvious changes you make to the degree you need to cover for load stalls: 1) OoO execution 2) data prefetching 3) find other computation (that likely has its own memory stalls) to interleave. On the thread level is a pretty obvious grain to interleave work, if deeply non-trivial to actually implement. Performance oriented programmers have always had to think about memory access patterns. Not new since the 80s to need to be friendly to your architecture there. [1] https://en.wikipedia.org/wiki/Pentium#Pentium https://en.wikipedia.org/wiki/Pentium#Pentium
- amelius 5y agoThe riddance of segmented memory.
- infogulch 5y agoHave you heard of this newfangled device called a Graphics Processing Unit and "VRAM"?
- amelius 5y agoYeah, but that's GPU, not CPU. Hopefully we will see similar progress there in the next 40 years.
- dragontamer 5y agoThat's not "segmented memory". Segmented memory was a 16-bit processor trying to access a 32-bit space (good grief, I forgot the details). You'd have "segment registers", such as "ds" or "es". Reading/writing to memory was by default to the "ds" segment (a 64kB region). If you wanted to read/write to a different segment, you needed to make sure that es, or fs, or one of the other segment registers were available. If you look at old Win32 code, you might see "far pointer" and "near pointers". "far pointers" were 32-bit pointers that would load the appropriate segment register, while "near pointers" were 16-bit pointers that only made sense within certain contexts. It was a nightmare. "Flat Mode" eventually became the norm when processors had enough space to just store full sized 32-bit pointers (and later, 64-bit pointers). "Flat mode" made everything easier and now we can forget that those dark ages ever existed...
- vardump 5y agoThe alternative wasn't that great either. Having just 16 address bits allowed you 64 kB of data memory and code memory that were stuck into same RAM area is a lot worse alternative (for example 8051 was like that). Or 65816 style banks, ugh. If you had to have just 16 address bits, having code (CS), stack (SS), data (DS), extra (ES), etc. segments was actually pretty nice. Memory copying and scanning operations were natural without needing to swap bank in the innermost loop. Of course if you could afford 32-bit addressing, there's no comparison. Flat memory space is the best option, but I don't think it came for free.
- mhh__ 5y agohttps://en.wikipedia.org/wiki/Tomasulo_algorithm https://en.wikipedia.org/wiki/Tomasulo_algorithm was invented in the 1960s, although it did take a while for OOO to make it into the consumer market.
- gchadwick 5y agoInteresting point about L1 cache sizes and the relationship between page size > Also, first-level caches are usually limited by the page size times the associativity of the cache. If the cache is smaller than that, the bits used to index into the cache are the same regardless if whether you're looking at the virtual address or the physical address, so you don't have to do a virtual to physical translation before indexing into the cache. If the cache is larger than that, you have to first do a TLB lookup to index into the cache (which will cost at least one extra cycle), or build a virtually indexed cache (which is possible, but adds complexity and coupling to software). You can see this limit in modern chips. Haswell has an 8-way associative cache and 4kB pages. Its l1 data cache is 8 * 4kB = 32kB. Having helped build the virtually indexed cache of the arm A55 I can confirm it's a complete nightmare and I can see why Intel and AMD have kept to the L1 data cache limit required to avoid it. Interestingly Apple may have gone down the virtually indexed route (or possibly some other cunning design corner) for the M1 with their 128 kB data cache. However I believe they standardized on 16k pages which would allow still allow physical indexing with an 8 way associative cache. So what do they do when they're running x86 code with 4k pages? Does they drop 75% of their L1 cache to maintain physical indexing? Do they aggressively try and merge the x86 4k pages into 16k pages with some slow back-up when they can't do that? Maybe they've gone with some special purpose hardware support for emulating x86 4k pages on their 16k page architecture. Have they just indeed implemented a virtually indexed cache?
- zozbot234 5y ago> Do they aggressively try and merge the x86 4k pages into 16k pages with some slow back-up when they can't do that? This does not seem feasible because the 16k pages on ARM are not "huge" pages; it's a completely different arrangement of the virtual address space and page tables. The two are not interoperable.
- ddingus 5y agoPerhaps that explains the odd cache sizes. Map x86 onto it's own cache when necessary.
- heavyset_go 5y ago
- jeffbee 5y ago2015. A good exercise would be "What's new in CPUs since 2015?" A few I can think of: branch target alignment has returned as a key to achieving peak optimization, after a brief period of irrelevance on x86; x86 user-space monitor/wait/pause have exposed for the first time explicit power controls to user programs. One thing I would have added to "since the 80s" is the x86 timestamp counter. It really changed the way we get timing information.
- titzer 5y agoSpectre. It was a vulnerability before 2015, but not known publicly until early 2018. It's hugely disruptive to microarchitecture, particularly with crossing kernel/user space boundaries, separating state between hyperthreads, etc.
- code_biologist 5y ago100%. Feasible timing attacks mean we must look at all speculative execution with suspicion. But dang that's a lot of performance to give up.
- jcranmer 5y agoIntel PT is another thing that's worth calling out since 2015 (see the other article on the front page right now, https://news.ycombinator.com/item?id=31121319 https://news.ycombinator.com/item?id=31121319, for something that benefits from it). It does look like Hardware Lock Elision/Transactional Memory is something that seems like it will be consigned to the dustbins of history (again).
- jeffbee 5y agoIntel did not ship even one working implementation of TSX, so it's not like anyone will be inconvenienced that they cancelled it.
- bcrl 5y agoA number of companies invested in doing the software development to take advantage of TSX (as the performance improvements helped databases by companies like Oracle), so Intel certainly lost a lot of credibility. And Intel is jerking software developers around again with the latest vector instructions that keep getting turned off in desktop / laptop SKUs and only being available on servers. Intel has done quite poorly over the past 5+ years on this front.
- jcadam 5y agoMy Ryzen 9 is just a bit more performant than the MOS6502 my Apple ][ was rocking back in the 80s. Ok... it also has things like a built-in FPU, multiple cores, cache, pipelining, branch prediction, more address space, more registers, and manufactured with a significantly better (and smaller) process.
- hulitu 5y agoYes, but look at how fast it runs the antivirus /s
- VyseofArcadia 5y ago> Even though incl is a single instruction, it's not guaranteed to be atomic. Internally, incl is implemented as a load followed by an add followed by an store. I've heard the joke that RISC won because modern CISC processors are just complex interfaces on top of RISC cores, but there really is some truth to that, isn't there?
- terafo 5y ago> but there really is some truth to that, isn't there? There was an Arm version of AMD's Zen, it was called K12, but it never made it to the market since AMD had to choose their bets very carefully back then.
- 7speter 5y agoIsn’t amd still hamstrung by their size relative to their competitors? At least in different ways than 5 years ago. The latest examples of amd having to choose carefully include them having to choose what products to focus on with their agreed upon capacity at tsmc last year (more zen chips to make gains ops intel, more gpus to make market share gains vs nvidia and or dedicating as much capacity to console apus for Sony and Microsoft. Also seems to be the case when they tried to make a budget gpu and had to settle with strapping laptop gpus to desktop pci cards and suffering heavy derision from gamers because, as I understand from people familiar with the way chips are designed, a design for a new die can cost tens of millions of dollars and amd, unlike intel and nvidia, are still too small to just crank out new costly designs at will.
- dralley 5y agoChip design cycles are long enough that you could argue they're hamstrung by their size 3 years ago.
- monocasa 5y agoEh, it's overstated. Classic CISC tended towards microcode because it allowed complex operations in way that didn't consume main data memory bandwidth. RISC in a lot of ways was the recognition that when you can assume ubiquitous instruction caches for your ISA you can let your ASM writers just write what was microcode previously. Hot loops will be cached and out of the way of data bandwidth, but now there's no arbitrary limits to microcode program size. So RISC was a revolution over CISC, but CISC arguably always had 'a RISC core' inside, even before RISC was a thing.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- phendrenad2 5y agoNice article. Kind of low-hanging fruit though. A comparison between CPUs in 2022 vs CPUs in 2002 would be much more interesting. ;)
- xmprt 5y agoNot really low hanging fruit if the last time you studied CPU design was in a university course. I personally found a lot of the information pretty interesting.
- gotaquestion 5y agoThe section on power really understates the complexity. Throttling didn't appear until the mid-90's as a coarse clock gating chipwide. Voltage/frequency scaling appeared a few years later (gradual P-state transitions). Then power control units monitored key activity signals and could not only scale the voltage, but estimate power and target specific blocks (e.g., turning off L1 D$). There are some more details in there but that's the main gist. The power control unit is its own operating system!
- susrev 5y agoThe vast expanses of text with no formatting rules always makes it hard for me to follow along. Added some simple rules that make it much easier to read. p { maxwidth: 1000px, text-align: center, margin-left: auto, margin-right: auto } body { text-align: center } MUCH easier (code snippets = toast)
- jimjambw 5y agoWhat about reader mode?
- kccqzy 5y ago> With substantial hardware effort, Google was able to avoid interference, but additional isolation features could allow this to be done at higher efficiency with less effort. This is surprising to me. Running any workload that's not your own will trash the CPU caches and will make your workload slower. Consider for example your performance sensitive code has nothing to do for the next 500 microseconds. If the core runs some other best effort work, it will trash the CPU caches, so that after that 500 microseconds, even when that other work is immediately preempted by the kernel, your performance sensitive code is now dealing with a cold cache.
- jeffbee 5y agoGoogle's Borg traces contain both cycles per instruction and last-level cache misses for every process in the traced cluster, so if you are interested you can go dive into that. https://github.com/google/cluster-data https://github.com/google/cluster-data
- luhn 5y agoOne thing I've always wondered: How do pre-compiled binaries take advantage of new instructions, if they do at all? Since the compiler needs to create a binary that will work on any modern-ish machine, is there a way to use new instructions without breaking compatibility for older CPUs?
- jeabays 5y agoUnfortunately, the answer is usually just to recompile.
- runnerup 5y agoYou’d need to recompile the binary to take advantage of new instructions. The compiler alone, but also the code, can create branches where the binary checks if certain instructions are available and if they are not, use a less optimal operation. Backwards compatibility for modern binaries basically. But not forward ability to see the future instructions that haven’t been invented yet. Not all binaries are fully backwards compatible. If you’re missing AVX, a surprising number of games won’t run. Sometimes only because the launcher won’t run, even though the game plays without AVX.
- HideousKojima 5y agoI've actually sometimes seen this as an argument in favor of JITed languages like C# and Java, that you can take advantage of newer CPU features and instructions etc. without having to recompile. In practice languages that compile to native binaries still win at performance, but it was interesting to see it turned into a talking point.
- wvenable 5y agoJIT languages still have a bit of a trade off. But for a pure pre-compiled example there is Apple Bitcode which is meant to be compiled to the destination architecture before run (as opposed to JIT code which is compiled when run). It's mandatory for Apple watchOS apps and when they released watch with a 64bit CPU they just recompiled all the apps.
- nimbius 5y agomy favourite addition since the 80s has been the unrelenting, unquestioned, ubiquitous and permanent inclusion of numerous iterations of poorly planned and executed management engine frameworks designed to completely ablate the user from the experience of general computing in the service of perpetual and mandatory DRM and security theatricality. the best aspect of this new feature is that not only is your processor effectively indifferent from a rented pressure washer, but on a long enough timeline the indelible omniscient slavemaster to which your IO is subservient can and will always find itself hacked. One of the biggest features missing from 80s processors was the ability to watch a C level cog from a multinational conglomerate squirm in an overstarched tom ford three piece as tech journalists methodically connect the dots between a corpulent scumbag and a hastily constructed excuse to hobble user freedoms at the behest of the next minions movie to arrive finally at a conclusion that takes said chipmakers stock to the barber. oh and chips come with light up fans and crap now but theres no open standard on how to control the light color so everyone just leaves it in Liberace disco mode so its like a wonderful little rainbow coloured pride parade is marching through my case.
- hulitu 5y agoYou are preaching to the choir. People don't care about security. They just want to see their Netflix 320x240 px movie marketed as HD.
- hengheng 5y agoAre you alright
- B1FF_PSUVM 5y agoHe's pining for the freedoms. For a while it seemed that senator-level freedom would be available to the great unwashed, but it was but a mirage. Carry on.
- Kuinox 5y agoIs that a GPT3 generated text ? It must be.
- TaylorPhebillo 5y agoI'm going through Understanding Software Dynamics by Richard Sites now, and it's the first book I've read that covers the practical performance implications of some of these new features, even if briefly.
- drpixie 5y agoThe short answer to David Albert's original question is much simpler than the article ... very little is actually new. We have lots of features that have migrated from "big" computers into PCs and SoCs, but very little that a big-machine programmer from 40-50 years ago wouldn't recognize. Multi-level caches, TLBs, out-of-order execution, NUMA memory, SIMD, multi-threading - were all normal features of big machines (Crays, Cybers, etc) and are now normal on single chip machines. We have various optimizations and special case handling (eg branch prediction) but these are not normally directly visible to programmers. GPUs (very large specialized coprocessors) were not a feature of older computers; and their capacity routinely dwarves the "main" CPU. At a lower level, the routine use of high speed serial comms is new-ish, or at least a reinvention. It was used in very early computers, but use of serial comms for PCIe devices and SD cards is now routine. Perhaps it's just an optimization, but it was not usual a few decades ago. One thing that I don't recall seeing on older computers is the multitude of fine-grained performance counters now available - useful for fine-tuning, and for peeking at what's going on outside your own process!!
- jart 5y agoI clicked on this link without really reading the title. Then about halfway through I started getting this really exciting feeling, like wow, who is the person who's writing this technical poetry? Then I looked up at the omnibar and, of course, it's Dan Luu.
- lowbloodsugar 5y agoMost CPUs aren’t based on 8086? From phones and chromebooks, to cloud and up to the biggest super computers: ARM is there.
- hulitu 5y ago8086 is the USA of computers.
- pkrumins 5y agoI hope they invent the CSS instruction in the next gen CPU so that Dan can start using it in his blog.