4 ms·
From the top of my head (before reading the article): caches, pipelining, branch prediction, memory protections, SIMD, floating point at all, hyper threading,
by Aardwolf 5y ago
From 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
- jandrewrogers 5y agoThe MTA architecture developed by Tera Computing came several years earlier (later acquired by Cray). It was arguably a purer expression of the concept. And barrel processing concurrency mechanics can be found on much older architectures.
- yvdriess 5y agoOther way around: Tera acquired Cray and changed to its name.
- 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.