Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

If you have 256-1024+ multicore CPUs they will probably have a fake unified memory space that's really a lot more like NUMA underneath. Not too different from how GPU compute works under the hood. And it would let you write seamless parallel code by just using Rust.

Check out the Azure HBv5 servers.

High bandwidth memory on-package with 352 AMD Zen 4 cores!

With 7 TB/s memory bandwidth, it’s basically an x86 GPU.

This is the future of high performance computing. It used to be available only for supercomputers but it’s trickling down to cloud VMs you can rent for reasonable money. Eventually it’ll be standard for workstations under your desk.

Forth can.

Modern CPUs don't actually execute the legacy instructions, they execute core-native instructions and have a piece of silicon dedicated to translating the legacy instructions into them. That piece of silicon isn't that big. Modern CPUs use more transistors because transistors are a lot cheaper now, e.g. the i486 had 8KiB of cache, the Ryzen 9700X has >40MiB. The extra transistors don't make it linearly faster but they make it faster enough to be worth it when transistors are cheap.

Modern CPUs also have a lot of things integrated into the "CPU" that used to be separate chips. The i486 didn't have on-die memory or PCI controllers etc., and those things were themselves less complicated then (e.g. a single memory channel and a shared peripheral bus for all devices). The i486SX didn't even have a floating point unit. The Ryzen 9000 series die contains an entire GPU.

that's exactly why Intel proposed x86S

that's basically x86 without 16 and 32 bit support, no real mode etc.

CPU starts initialized in 64bit without all that legacy crap.

that's IMO great idea. I think every few decades we need to stop and think again about what works best and take fresh start or drop some legacy unused features.

risc v have only mandatory basic set of instructions, as little as possible to be Turing complete and everything else is extension that can be (theoretically) removed in the future.

this also could be used to remove legacy parts without disrupting architecture

> If a Ryzen takes 1,250 times the transistor for one core, does one core run 1,250 times (even taking hyperthreading in to account) faster than an i80486 at the same clock? 500 times? 100 times?

Would be interesting to see a benchmark on this.

If we restricted it to 486 instructions only, I'd expect the Ryzen to be 10-15x faster. The modern CPU will perform out-of-order execution with some instructions even run in parallel, even in single-core and single-threaded execution, not to mention superior branch prediction and more cache.

If you allowed modern instructions like AVX-512, then the speedup could easily be 30x or more.

> Would we get to 1,250 times faster for 1,250 times the number of transistors? No. Would we get a lot more performance than we get out of a contemporary x86 CPU? Absolutely.

I doubt you'd get significantly more performance, though you'd likely gain power efficiency.

Half of what you described in your hypothetical instruction set are already implemented in ARM.

In terms of FLOPS, Ryzen is ~1,000,000 times faster than a 486.

For serial branchy code, it isn't a million times faster, but that has almost nothing to do with legacy and everything to do with the nature of serial code and that you can't linearly improve serial execution with architecture and transistor counts (you can sublinearly improve it), but rather with Denard scaling.

It is worth noting, though, that purely via Denard scaling, Ryzen is already >100x faster, though! And via architecture (those transistors) it is several multiples beyond that.

In general compute, if you could clock it down at 33 or 66MHz, a Ryzen would be much faster than a 486, due to using those transistors for ILP (instruction-level parallelism) and TLP (thread-level parallelism). But you won't see any TLP in a single serial program that a 486 would have been running, and you won't get any of the SIMD benefits either, so you won't get anywhere near that in practice on 486 code.

The key to contemporary high performance computing is having more independent work to do, and organizing the data/work to expose the independence to the software/hardware.

> Didn't need to deal with Spectre and Meltdown issues? If we made out-of-order work in ways where much more could be in flight and the compilers / assemblers would know how to avoid stalls based on dependencies, or how to schedule dependencies? What if we took expensive operations, like semaphores / locks, and built solutions in to the chip?

I'm pretty sure that these goals will conflict with one another at some point. For example, the way one solves Spectre/Meltdown issues in a principled way is by changing the hardware and system architecture to have some notion of "privacy-sensitive" data that shouldn't be speculated on. But this will unavoidably limit the scope of OOO and the amount of instructions that can be "in-flight" at any given time.

For that matter, with modern chips, semaphores/locks are already implemented with hardware builtin operations, so you can't do that much better. Transactional memory is an interesting possibility but requires changes on the software side to work properly.

Would be interesting to compare transistor count without L3 (and perhaps L2) cache.

16-core Zen 5 CPU achieves more than 2 TFLOPS FP64. So number crunching performance scaled very well.

It is weird, that the best consumer GPU can 4 TFLOPS. Some years ago GPUs were an order of magnitude and more faster than CPUs. Today GPUs are likely to be artificially limited.

But history showed exactly the opposite, if you don't have an already existing software ecosystem you are dead, the transistors for implementing x86 peculiarities are very much worth it if people in the market want x86.

Aren't 99,99999% of these transistors used in cache?

correct me if i am wrong but isn't that what was tried with the Intel Itanium processors line, only the smarter compilers and assemblers never quiet got there.

what makes it more likely to work this time?

> and the difference in number of transistors is 1,250 times

I should've written per core.

> and now you're spending millions of transistors

and spending millions on patent lawsuits ...

If you look at a Zen5 die shots half of the space is taken by L3 cache.

And from each individual core:

- 25% per core L1/L2 cache

- 25% vector stuff (SSE, AVX, ...)

- from the remaining 50% only about 20% is doing instruction decoding

https://www.techpowerup.com/img/AFnVIoGFWSCE6YXO.jpg

GPUs scaled wide with a similar number of transistors to a 486 and just lots more cores, thousands to tens of thousands of cores averaging out to maybe 5 million transistors per core.

CPUs scaled tall with specialized instruction to make the single thread go faster, no the amount done per transistor does not scale anywhere near linearly, very many of the transistors are dark on any given cycle compared to a much simpler core that will have much higher utilization.

Intel restructures into patent troll, hiring reverse engineers and investing in chip sanding and epoxy acids.

A GPU is a very different beast that relies much more heavily on having a gigantic team of software developers supporting it. A CPU is (comparatively) straightforward. You fab and validate a world class design, make sure compiler support is good enough, upstream some drivers and kernel support, and make sure the standard documentation/debugging/optimization tools are all functional. This is incredibly difficult, but achievable because these are all standardized and well understood interface points.

With GPUs you have all these challenges while also building a massively complicated set of custom compilers and interfaces on the software side, while at the same time trying to keep broken user software written against some other company's interface not only functional, but performant.

I hope to see dedicated GPU coprocessors disappear sooner rather than later, just like arithmetic coprocessors did.

> RISC-V is newer but my understanding is it's still based around ARM, just without royalties (and thus isn't bringing many new ideas to the table per say)

RISC-V is the fifth version of a series of academic chip designs at Berkeley (hence it's name).

In terms of design philosophy, it's probably closest to MIPS of the major architectures; I'll point out that some of its early whitepapers are explicitly calling out ARM and x86 as the kind of architectural weirdos to avoid emulating.

I'm far from an expert here, but these days, it's better to view the instruction set as a frontend to the actual implementation. You can see this with Intel's E/P cores; the instructions are the same, but the chips are optimized differently.

There actually have been changes for "today's needs," and they're usually things like AES acceleration. ARM tried to run Java natively with Jazelle, but it's still best to think of it as a frontend, and the fact that Android is mostly Java and ARM, but this feature got dropped says a lot.

The fact that there haven't been that many changes shows they got the fundamental operations and architecture styles right. What's lacking today is where GPUs step in: massively wide SIMD.

>I've always wondered if there could be a new instruction set, better suited to today's needs.

AArach64 is pretty much a completely new ISA built from ground up.

https://www.realworldtech.com/arm64/5/

I think the ideal would be something like a Xilinx offering, tailoring the CPU- regarding cache, parallelism and in hardware execution of hotloop components, depending on the task.

Your CPU changes with every app, tab and program you open. Changing from one core, to n-core plus AI-GPU and back. This idea, that you have to write it all in stone, always seemed wild to me.

There are not really any newer instruction sets as we are locked into the von Neumann architecture and, until we move away from it, we will continue to move data between memory and CPU registers, or registers ↭ registers etc, which means that we will continue to add, shift, test conditions of arithmetic operations – same instructions across pretty much any CPU architecture relevant today.

So we have:

  CISC – which is still used outside the x86 bubble;

  RISC – which is widely used;

  Hybrid RISC/CISC designs – x86 excluding, that would be the IBM z/Architecture (i.e. mainframes);

  EPIC/VLIW – which has been largely unsuccessful outside DSP's and a few niches.

They all deal with registers, movements and testing the conditions, though, and one can't say that an ISA 123 that effectively does the same thing as an ISA 456 is older or newer. SIMD instructions have been the latest addition, and they also follow the same well known mental and compute models.

Radically different designs, such as Intel APX 432, Smalltalk, Java CPU's, have not received any meaningful acceptance, and it seems that the idea of a CPU architecture that is tied to a higher level compute model has been eschewed in perpetuity. Java CPU's were the last massively hyped up attempt to change it, and that was 30 years ago.

What other viable alternatives outside the von Neumann architecture are available to us? I am not sure.

> As someone who knows almost nothing about CPU architecture, I've always wondered if there could be a new instruction set, better suited to today's needs.

It exists, and was specifically designed to go wide since clock speeds have limits, bit ILP can be scaled almost infinitely if you are willing to put enough transistors into it. aarch64

Together Compute

SFCompute

And so on … definitely not out of trend

That creates a split between those who get to work on skunk works and those stuck on legacy. It’s very possible to end up with a google like situation where no-one wants to keep the lights on for old projects as doing so would be career suicide. There have been some attempts at other companies at requiring people to have a stake in multiple projects in different stages of the lifecycle but I’ve never seen a stable version of this, as individuals benefit from bending the rules.

Or fund a lot of CPU startups that were tied back to Intel for manufacturing/foundry work. Sure, they could be funding their next big CPU competitor, but they'd still be able to capture the revenue from actually producing the chips.

Most of the work that goes into chip design isn't related to the ISA per se. So, it's entirely plausible that some talented chip engineers could design something that implements RISC-V in a way that is quite powerful, much like how Apple did with ARM.

The biggest roadblock would be lack of support on the software side.

If RISC-V started with supercomputing and worked down that would be a change from how an architecture disruption usually works in the industry.

Only two forks left before they'd need to start with half a person.

> The traitorous eight was a group of eight employees who left Shockley Semiconductor Laboratory in 1957 to found Fairchild Semiconductor.

https://en.wikipedia.org/wiki/Traitorous_eight

>Hoping for an open system (which I think RISC-V is) and nothing even close to Intel ME or AMT.

The architecture is independent of additional silicon with separate functions. The "only" thing which makes RISC-V open are that the specifications are freely available and freely usable.

Intel ME is, by design, separate from the actual CPU. Whether the CPU uses x86 or RISC-V is essentially irrelevant.

The article is written for a different audience than you might be used to. oregonlive is the website for the newspaper The Oregonian, which is the largest newspaper in the state of Oregon. Intel has many of its largest fabs in Oregon and is a big employer there. The local news is writing about a hip new startup for a non-technical audience who know what Intel is and why it's important, but need to be reminded what a CPU actually is.

It reads like they're trying to drum up investment. This is why the focus is on the pedigree of the founders, since they don't have a product to speak of yet.