Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/index.php?threads/will-amd-nvidia-or-intel-use-risc-v-in-the-future.16636/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021370
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

Will AMD, Nvidia, or Intel use RISC-V in the future?

Jumper

Member
Will AMD, Nvidia, or Intel use RISC-V instead of x86 to build some products in the future? For example, AMD canceled their ARM project that was started by Jim Keller but it does make sense to me they would heavily invest in RISC-V as it is slowly gaining momentum in the market. Do you know if these companies are considering pouring R&D money into some RISC-V projects?
 
All of these companies are researching it and if it makes sense it will be used. Right now most of the applications for RISC V are embedded devices with low demands, and it will likely be years until RISC V is ready for high performance compute. Until then the priority is and should be x86 (and ARM/x86 partnerships for NVIDIA). In short x86 works and makes some ultra fast chips so there is no reason to switch to an arch that is "inferior" for their use cases.
 
RISC-V is like Linux, nailing down bad ideas from the 1980s by making them cheap.

There's no real future in RISC-V, or any other ISA, it's a really bad way to define processors.

This kind of thing is the future - https://www.ascenium.com/

- but probably not those particular guys.

That said you still have to compile your code, or do you?
 
RISC-V is like Linux, nailing down bad ideas from the 1980s by making them cheap.

There's no real future in RISC-V, or any other ISA, it's a really bad way to define processors.

This kind of thing is the future - https://www.ascenium.com/

- but probably not those particular guys.

That said you still have to compile your code, or do you?
I doubt I'll live long enough to see this future come to widely-deployed fruition. I haven't seen this movie before, but I've seen one of the same genre. VLIW. Give control of CPU parallelism to compilers. Color me a skeptic.
 
I doubt I'll live long enough to see this future come to widely-deployed fruition. I haven't seen this movie before, but I've seen one of the same genre. VLIW. Give control of CPU parallelism to compilers. Color me a skeptic.
VLIW has been revisited often, its two failings are more complexity than the compiler writers can handle (they like RISC), and power consumption, but the power consumption is less of a problem as devices shrink, and AI can be used to do the compilation, so I'd say it's time has arrived. VLIW can kill off X86, ARM and RISC-V if done right. X86 is particularly vulnerable since scaling has slowed a lot and everybody can get on the same (fast) process..
 
RISC-V is like Linux, nailing down bad ideas from the 1980s by making them cheap.

There's no real future in RISC-V, or any other ISA, it's a really bad way to define processors.
Then there's no future for Linux? That would be a bold take. I think when a technology matures quantity becomes the quality - operating systems, semiconductors, and otherwise.

This is how China broke the US/German monopoly on PV cells, to the benefit of anyone who cares about green energy. China is also all-in on RISC, and I don't see why the pattern would change as they advance their semiconductor manufacturing capabilities.
 
VLIW has been revisited often, its two failings are more complexity than the compiler writers can handle (they like RISC), and power consumption, but the power consumption is less of a problem as devices shrink, and AI can be used to do the compilation, so I'd say it's time has arrived. VLIW can kill off X86, ARM and RISC-V if done right. X86 is particularly vulnerable since scaling has slowed a lot and everybody can get on the same (fast) process..
To my knowledge, AI-based compilers are a research field, and one that has yet to bear any fruit at all. Most of the compiler advancement I'm seeing falls into two areas, the proliferation of problem or field-specific languages (Rust, Go, data parallel extensions like DPC++, Scala, etc.), and cross-platform languages that allow the same code to execute on different execution platforms (CPUs, GPUs, FPGA, etc). Do you have any examples of commercial products or even research projects that have produced results of AI-assisted compilation?

As for VLIW, I'm not seeing evidence that VLIW can kill off anything except itself. The only current VLIW product I'm aware of is the Kalray, which is now trying to reposition itself as a DPU, and has a market share that easily rounds to zero. Can you think of any other commercial products?

Given the momentum and investment in ISA-based processors and non-VLIW architectures, I'm still thinking I probably won't live long enough to see the ISA-based products displaced.
 
Last edited:
Then there's no future for Linux? That would be a bold take. I think when a technology matures quantity becomes the quality - operating systems, semiconductors, and otherwise.

This is how China broke the US/German monopoly on PV cells, to the benefit of anyone who cares about green energy. China is also all-in on RISC, and I don't see why the pattern would change as they advance their semiconductor manufacturing capabilities.
Linux doesn't need ISAs, it's open source code, so you can interpret it on any processor. Linux was doing fine without RISC-V it will do equally well without it.
 
To my knowledge, AI-based compilers are a research field, and one that has yet to bear any fruit at all. Most of the compiler advancement I'm seeing falls into two areas, the proliferation of problem or field-specific languages (Rust, Go, data parallel extensions like DPC++, Scala, etc.), and cross-platform languages that allow the same code to execute on different execution platforms (CPUs, GPUs, FPGA, etc). Do you have any examples of commercial products or even research projects that have produced results of AI-assisted compilation?

As for VLIW, I'm not seeing evidence that VLIW can kill off anything except itself. The only current VLIW product I'm aware of is the Kalray, which is now trying to reposition itself as a DPU, and has a market share that easily rounds to zero. Can you think of any other commercial products?

Given the momentum and investment in ISA-based processors and non-VLIW architectures, I'm still thinking I probably won't live long enough to see the ISA-based products displaced.

We'll probably live that long. The problem with the ISA approach is it doesn't handle heterogeneity or adaption well. RISC-V is an extensible ISA, which means you need a runtime system that can adapt, and a runtime system that can adapt, can do a lot more than RISC-V.

The VLIW approach wins because processors deal in cache-line transfers, not 32bit or 64bit words.
 
The VLIW approach wins because processors deal in cache-line transfers, not 32bit or 64bit words.
As I said, the VLIW approach loses because it needs "magic compilers" or hand-tuning in assembler language to approach the best performance of conventional superscalar CPUs. Your prediction of AI-based compiler technology to solve the magic compiler problem is not yet on the horizon, so VLIW under-performs superscalar designs because superscalar instruction-level parallelism is automatic and hidden from the compilers and applications. Though VLIW may very well have the theoretical potential to exceed current superscalar strategies, the lack of required compiler technologies supports the continued massive industry investments in superscalar designs. I believe when choosing technology winners you can always follow the money; you can choose technology winners by the industry R&D dollars being invested, and not theoretical technical superiority. Examples that come to mind of dominant technologies that are in their market position because of massive funding, yet are technologically inferior, arguably include the x86 ISA, PCI Express, Ethernet, SCSI/SATA (now being quickly superseded by NVMe, but they were dominant for a long time while being inferior), and I would argue DDR. VLIW investment is currently trivial by comparison to superscalar R&D. Further evidence for my pessimism is the lack of successful products in the market after decades of people touting the VLIW approach, and that one of the biggest and most expensive failures in computer engineering history, and a multi-company disaster to boot, was a VLIW CPU, the Intel Itanium.

I can only think of two computing technologies, in a few minutes of thinking about it, that rose up from a superior technological base and had lower funding than the incumbent technologies, and achieved dominance. Relational databases (1970s/1980s) and SSDs. Relational databases, and their associated technology, Structured Query Language (SQL), did a clean sweep of the competing database technologies within a short number of years, and still dominate the database industry. Of course, the relational model and SQL were invented by IBM, which at the time was the world's largest computing R&D investor, but they were half-hearted about it because they has a massive revenue stream from their own non-relational database, IMS-DB. I think we all know the SDD versus HDD story. Can you think of any others that violate the R&D investment rule?
 
As I said, the VLIW approach loses because it needs "magic compilers" or hand-tuning in assembler language to approach the best performance of conventional superscalar CPUs. Your prediction of AI-based compiler technology to solve the magic compiler problem is not yet on the horizon, so VLIW under-performs superscalar designs because superscalar instruction-level parallelism is automatic and hidden from the compilers and applications. Though VLIW may very well have the theoretical potential to exceed current superscalar strategies, the lack of required compiler technologies supports the continued massive industry investments in superscalar designs. I believe when choosing technology winners you can always follow the money; you can choose technology winners by the industry R&D dollars being invested, and not theoretical technical superiority. Examples that come to mind of dominant technologies that are in their market position because of massive funding, yet are technologically inferior, arguably include the x86 ISA, PCI Express, Ethernet, SCSI/SATA (now being quickly superseded by NVMe, but they were dominant for a long time while being inferior), and I would argue DDR. VLIW investment is currently trivial by comparison to superscalar R&D. Further evidence for my pessimism is the lack of successful products in the market after decades of people touting the VLIW approach, and that one of the biggest and most expensive failures in computer engineering history, and a multi-company disaster to boot, was a VLIW CPU, the Intel Itanium.

I can only think of two computing technologies, in a few minutes of thinking about it, that rose up from a superior technological base and had lower funding than the incumbent technologies, and achieved dominance. Relational databases (1970s/1980s) and SSDs. Relational databases, and their associated technology, Structured Query Language (SQL), did a clean sweep of the competing database technologies within a short number of years, and still dominate the database industry. Of course, the relational model and SQL were invented by IBM, which at the time was the world's largest computing R&D investor, but they were half-hearted about it because they has a massive revenue stream from their own non-relational database, IMS-DB. I think we all know the SDD versus HDD story. Can you think of any others that violate the R&D investment rule?
Relational databases are a software thing, not really processors, but since you bring it: up in-memory computing will beat other approaches at the end of the day, particularly for databases.
SSDs vs HDDs has been a decades long battle, I'm not sure what investment rule (if any ) was broken, but solid state memory enables new types of computing (like in-memory), which Intel completely failed to realize with Optane (as with VLIW/Itanium).
No amount of spending on single-threaded super-scalar core R&D gets you past the Von-Neumann bottleneck.


I have spent some time with the LLVM crowd, and you are right they probably won't come up with a magic compiler, however they have a lot of interesting pieces that can be used with AI to build a better compiler/runtime system that isn't based on archaic ISAs. To some extent RISC-V forces us down that road by being an extensible ISA, which might be all that's good about it.
 
Relational databases are a software thing, not really processors, but since you bring it: up in-memory computing will beat other approaches at the end of the day, particularly for databases.
SSDs vs HDDs has been a decades long battle, I'm not sure what investment rule (if any ) was broken, but solid state memory enables new types of computing (like in-memory), which Intel completely failed to realize with Optane (as with VLIW/Itanium).
No amount of spending on single-threaded super-scalar core R&D gets you past the Von-Neumann bottleneck.


I have spent some time with the LLVM crowd, and you are right they probably won't come up with a magic compiler, however they have a lot of interesting pieces that can be used with AI to build a better compiler/runtime system that isn't based on archaic ISAs. To some extent RISC-V forces us down that road by being an extensible ISA, which might be all that's good about it.
I'm sorry, I've taken us way off-topic, but relational databases represent a logical data model of two-dimensional tables. The physical representation of the data, in database parlance the "physical schema", is independent of the logical view. In-memory relational databases already exist and are in broad-market production use, such as Volt:


and Oracle:


I've still can't name a new technology that so quickly supplanted a highly funded incumbent as relational databases. I thought about WiFi and cabled Ethernet in homes and offices, but one could hardly call WiFi under-funded compared to cabled client Ethernet. I haven't calculated it, but WiFi R&D probably exceeded client Ethernet R&D, perhaps even including datacenter Ethernet R&D.

I haven't had someone quote the Von Neumann Bottleneck to me in a while, especially since the current interesting superscalar CPUs use Harvard Architecture, multi-threading, and SIMD instructions to increase processing throughput.

SSDs didn't supplant HDDs in clients and servers until about 15 years ago. I remember the HDD industry saying that high RPM, perpendicular recording, and SMR would keep HDDs in the game for large-scale storage, but then many-layer NAND chips, QLC NAND, mimicking HDD block storage behaviors, and using HDD form factors blew HDDs away for the most part. I would argue that includes Optane, though exactly why Micron and Intel backed away from Optane is not public information. Many suspect that Optane density layering, called "decks", were too difficult to implement as compared to NAND layers, and Optane would fall farther behind over time. Optane as a DRAM replacement or extender always looked like a stretch to me, since Optane needed a DRAM write cache. Of course, my mention of SSD technology is a tangent to this discussion, so I'll move on.

You have made a lot of assertions about the superiority of post-ISA CPUs, but you're not persuasive, at least to me. I'll let this topic be.
 
In-memory computing is not quite the same as in-RAM computing where you avoid swapping, you can get that in general with Tidalscale -


For proper in-memory computing you want a ratio of local memory to core of about 2MB (the L2 cache size), and minimal sharing.

Languages like C/C++ with traditional compilers expect a stack-based shared-memory machine, however, there's nothing in C/C++ that limits you to doing that. The bulk of C/C++ is used in static form, and can be re-interpreted as data-flow. RISC-V is interesting in that you can use JiT compilation with the extensions to dynamically recompile critical code for FPGA which the core can offload to. The AI JiT compiler only needs to deal with code patterns that are acceleratable by FPGA, and 100% success is not needed to be useful.

I was working for the IO Turbine team a decade ago, they were selling SSD tech to Facebook, because the TCO for SSDs had become less than HDDs, real-estate and power being an issue for HDDs.

Intel's options for Optane were bad, they treated it like Flash, and got little of its performance advantage, you needed to treat it like slower DRAM, and use in in-memory NUMA architecture, but Intel only does X86/SMP, and their NUMA graphics stuff is on the cheap end of the market. Sticking DRAM in between the core and the Optane completely defeats the purpose.
 
Intel's options for Optane were bad, they treated it like Flash, and got little of its performance advantage, you needed to treat it like slower DRAM, and use in in-memory NUMA architecture, but Intel only does X86/SMP, and their NUMA graphics stuff is on the cheap end of the market. Sticking DRAM in between the core and the Optane completely defeats the purpose.
The DRAM cache is necessary for Optane when used as a DRAM extension because while Optane endurance is better than SLC NAND, it is not unlimited like DRAM.
 
DRAM might be necessary as working memory, but not as cache for Optane, If you are doing things like AI training, where you are reading through a lot of data repeatedly the DRAM caching buys you nothing. HDDs needed DRAM for caching, Flash needs it because of the slow read/write times.

Flash SSDs usually have wear-leveling to handle the failures, Optane's higher cycle life means you can make a drive last for years, Phase change memory is also rad-hard, where Flash doesn't handle ionizing radiation well.

Intel just didn't use it properly, they treated it like Flash, when it isn't anything like Flash.
 
DRAM might be necessary as working memory, but not as cache for Optane, If you are doing things like AI training, where you are reading through a lot of data repeatedly the DRAM caching buys you nothing. HDDs needed DRAM for caching, Flash needs it because of the slow read/write times.

Flash SSDs usually have wear-leveling to handle the failures, Optane's higher cycle life means you can make a drive last for years, Phase change memory is also rad-hard, where Flash doesn't handle ionizing radiation well.

Intel just didn't use it properly, they treated it like Flash, when it isn't anything like Flash.
Not correct. The DRAM caching is used for Optane DIMMs. DRAM write caching hides the longer write latency of Optane versus DRAM, and absorbs many writes before they hit the Optane chips, extending endurance. I said DRAM caching is used when Optane is used for memory extension, which are the DIMM products; I didn't mention Optane SSDs.

I haven't seen Intel discuss Optane DIMMs for AI/ML workloads, but I doubt it would be appropriate.
 
My company is willing to provide a free layout on TSMC 16/12 or GF14/12 including an NRZ serdes, ESD/Pclamp protection, PLLs (the serdes already includes one), CML and LVDS drivers to a US based company with a functional VLIW flow. We would tape it out through IMEC, but you gotta pay for the MPW. We can also lay out the silicon interposer. Simguru, if you have a functional flow that uses VLIW, perhaps we can help you prove your claims.
 
Back
Top