(The fact that arm has a reciprocal square root instruction gives away my opinion a little bit...)

Dark silicon and power limits changed the equation a lot, as you observe.

it was important at the time of the original RISC as anything that could not be handled by the single-cycle execution stage would significantly increase the complexity of the pipeline.

Today pipelines are orders of magnitude more complex than the original RISC, so it doesn't really matter.

You are massively understating this. Tenstorrent has ~280 people. They are working on 2-3 CPU designs, 2-3 AI accelerators, all the IO stuff, etc. A decent percentage of these people will have to be dedicated to testing, marketing, HR, finances, legal, etc. Jim Keller projects their 8-wide Ascalon to be competitive with the upcoming Zen5 core.

I'll guarantee you that the Zen 5 core has way more than 280 people working on it. Even if Ascalon were just 70% of the performance of Zen 5, that would put it around Zen 2 performance and that core also required hundreds to thousands of people.

This is an R&D economic disparity that cannot be sustained.

This isn't limited to Tenstorrent either, Nuvia had around 300 people when it was acquired and the Qualcomm Oryon also seems to be competitive with x86 for a fraction of the R&D cost.

edit:

> They are working on 2-3 CPU designs, 2-3 AI accelerators, all the IO stuff, etc

also do we actually know how much they're designing wholecloth and not buying off the shelf?

edit2: i think Tenstorrent is great and i'll probably buy a devkit soon (as well as maybe apply lol...)

It's kind of like comparing Photopea with Photoshop, the former being developed by a single person, and then claiming this huge productivity difference is caused by Photopea using Javascript (vs. C++ for Photoshop).

AMD already has enormous scale that it can spread development costs over. Tenstorrent won’t ‘win’ vs AMD solely because it needs fewer engineers and that reduces development costs (it might win for other reasons but that’s a separate argument).

Even if it does make a cheaper product then you have to take into account the fact that you’re asking hundreds of millions of users to switch ISAs with the corresponding economic costs in return for a small reduction in the purchase price.

AMD shipped 8M chips in Q4 of 2023 and Intel shipped 50M (not what the tech press would have you believe given how they rave about Zen). Even if we assume they shipped that many every quarter (Q4 is the high water mark), that's 32M chips for AMD and another 200M for Intel.

Apple sold 235M smartphones in 2023 and total smartphone sales were around 1.2B. Apple alone outsold Intel and AMD combined and Apple is shipping their high-end cores in every one of those devices. Put simply, AMD and Intel aren't the big boys anymore. Everything you say about AMD/Intel's economies of scale apply even more to the rest of the industry.

Why would a company make a risky expansion into the race-to-the-bottom Wintel market when the phone and server/AI markets are easier to penetrate and offer a great combination of massive economies of scale and super-high margins?

Qualcomm is only trying to enter the PC market because they are dominating the phone market and are looking to expand their business. RISC-V won't be entering until ARM has done the hard part of forcing more ISA flexibility onto devs.

And I'll postulate that however many people AMD has working on a new CPU, Intel probably has at least 2X that many. Part of this is just due to the inertia at Intel, part of it is likely due to Keller being successful at streamlining the AMD design process while he had to give up on that at Intel due to that institutional inertia.

Would Intel be any more efficient if they were designing a RISC-V processor or would they still suffer from the same institutional inertia? I suspect the latter.

If so, then Tenstorrent should have chosen x86. They could support all the way through SSE3 without patent negotiations and maintain backward compatibility rather than risking it on a new ISA. Why didn't they?

The same reason that software devs don't want to implement a bad API that's been continually updated for years. A new API allows you a chance to do things better even if both APIs technically do the same exact things. You can move quickly and confidently spending that mental energy and time on things like performance instead of contemplating weird edge cases and writing endless tests for each of them.

The same applies to Tenstorrent and RISC-V. The cleaner ISA means you don't have to sit around thinking about how an instruction can be potentially executed for a weird side effect and how that will propagate through the pipeline. Instead, you can focus that mental energy on performance enhancing changes.

In any case though, Intel sells 6-7x more chips than AMD, so even with 2x the people, their economies of scale are still better.

That said, I believe a cleanroom RISC-V design by Intel would still progress faster at Intel than x86 does and it would probably require fewer people allowing them to put the rest on other projects and the overall reduction in team size might even further increase the design rate (as you've stated).

> that said, I believe a cleanroom RISC-V design by Intel would still progress faster at Intel than x86

Possibly. But it would still take a lot longer than Tenstorrent or even AMD (should they decide to do this). There's a lot of tasks that Intel tends to throw bodies at that an AMD or Tenstorrent have automated.

So, one might say point 1 was so fully true, that it became internalized on chip, and is why we have L1 caches.

RISC-V achieves better code density than x86, so the same C-code when compiled takes less icache. IIRC it's not a lot smaller, just a little.

Average x86 instruction length is 4.25 bytes. ARM64 is 32-bits. RISC-V compressed was a little under 3 bytes around 10 years ago when introduced.

So if RISC-V instruction length is 30% shorter than x86, why wasn't RISC-V density get a similar boost? x86 has some relatively common instructions that RISC-V didn't have even just a year or two ago. There are still some things that take 4-6 instructions in RISC-V, but just 1-2 instructions in x86 or ARM64.

Over time, the code density of RISC-V will increase. Meanwhile, stuff like APX seems to require very long instructions, so compilers will be playing an interesting game where more registers and 3-register instructions decrease MOVs, but the length of the instructions also shoots up a lot.

Why given the push back against adding new instructions tang would achieve this?

The only issue is adding bad extensions that bleed microarchitectural details to the consumer.

Maybe, but one of the original arguments for RISC, again, was that code density will no longer matter. Apparently, it still does.

There was a brief time in the 80s when that was true, but clearly hasn't been for a while. (Why else would caches be necessary?)

chip area used for complex instructions can be used for something better, like caches — is it really that true today

Some of Intel's CPUs can turn off sections of their caches to save power.

Complex instructions can be easily and more performantly simulated by combining several simpler ones

That now happens with RISCs too, e.g. there are ARM instructions which get split into multiple uops, and of course the larger amount of simpler instructions is essentially what uops are. Patterson wrote the paper at a time when the Pentium's uop-decoding approach didn't exist and "traditional" CISCs were all sequentially microcoded.

Apples-to-apples comparisons here are not quite easy

Pun intended? I believe there was plenty of discussion on that when they came out with the M1, and some have attributed that to process advantage instead of uarch or ISA.

What does "speed" mean here? Latency? Bandwidth?

At the core is a quantitative approach to computer design and analysis that uses empirical observations of programs, experimentation, and simulation as its tools.

So they (rightly) do not judge what is the best solution for all time, they just claim that in 1988 RISC outperformed CISC.

As an aside, I was at a memorable CHIPS(?) conference and Dave House VP at Intel followed speakers from MIPS, SPARC, etc (RISC guys) and opened by looking at his watch and saying "it's now 11am and Intel made more CPUs this morning than all the RISC guys ever made in their entire history" ... so process / scale cannot be ignored.

Reordering RISC-like instructions is also lot easier than reordering complex ones. A larger set of architectural registers also makes that easier.

Look at 6502: making an implementation for it with the zero page backed by register file instead of RAM is entirely possible.

[1] https://shakti.org.in