News AMD to Make Hybrid CPUs, Using AI for Chip Design: CTO Papermaster at ITF World

Page 3 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
AMD's stock price is about the same as it was, back when the deal closed. Their market cap is $173.8B and the deal was estimated at about $50B. So, what are you basing it on, when you say they "gave up a large part of their shares"?
So 50 bil out of 173 is not a large part?! It's almost 1/3.
Most of Xilinx' business is not AI. Even in the datacenter, FPGAs have other uses than that. AI might've partially motivated it, but one thing AMD got was a stable revenue stream and a greater presence in the embedded market.
Still, to get the AI into these chips they had to "merge" with xilinx.
They do get other things out of it of course, nobody said otherwise.
 

abufrejoval

Reputable
Jun 19, 2020
323
224
5,060
In a ideal world, VM's would work with all apps w/o issue.

But it isn't an ideal world, so I prefer to use "Bare Metal" for everything to avoid those weird app incompatibilities, bugs, & issues.

Current software is buggy enough, I don't need the VM to cause more issues on top of that.
It helps that I'm getting paid to get VMs and containers work and came to VMware in 1999 after a bit of VM370 envy.

The other motivator is that it's so extremely easy to just spin up a couple of VMs and then make them jump through hoops, and then try this and that if they keep falling flat on their faces.

Rebuilding a physical machine after a software installation has gone wrong can just be hours intead of seconds of reverting to the last snapshot, especially on big machines that take minutes to just reboot.

There is charm in little boxes, but increasingly I find there is charm in little boxes that can run a couple of VMs without breaking a sweat: there is a ton of capabilities in an Alder/Raptor-Lake or Ryzen 5800U/H based NUC today with NVMe storage: it's quite simply the equivalent of what big vSphere hosts used to have 15 years ago.

Actually, the VM abstractions make it a lot easier to setup most types of systems, unless you're tied to some odd piece of hardware say for industrial control. And then it makes them nicely mobile, even switching between AMD and Intel isn't an issue most of the time, unless you're trying to do live-migrations.

Even performance is rarely an issue, network and storage are either ok or you can do pass-through (that takes a bit of skill, but not more than learning about a new piece of hardware). Even GPUs have become easy, unless you're trying to game on them. For the CUDA stuff I'm doing, it's become a matter of ticking options.

VMs were invented in 1967 to solve 360/370 backward compatibility issues and to transport ancient software without changes onto newer hardware. They still perform that function just as credibly as the consolidation in my experience and I'm very glad Diane Green and Mendel Rosenblum found a way around Intel's VM boykott and used the 486SL's system management mode and some emulation tricks to bring true virtual machines to x86! I wasn't happy to own the better VAX in an 80386 because that was still a "mini", I wanted a mainframe and they delivered.

Of course Intel immediately retaliated and invalidated the majority of their patent portfolio by offereing VM hardware support and sponsoring Xen, but that's just because Intel is Intel.
 
May 19, 2023
16
12
15
When it comes to the latest XDNA AI Engine (not specifically generative AI), the Ryzen AI co-processor might boost boost AI capabilities even on Ryzen consumer CPUs. But one major hurdle/red flag is the cost and overall value proposition of the chip, and using AI in consumer space makes little sense.

The major barrier to implementing Ryzen AI is the cost & that there has to be a good enough and actual reason to put Ryzen AI within budget chips & even desktop SKUs.

But adding Ryzen AI to a Threadripper chip with high core counts might be a good idea, even then, while it might be used for training purposes, it may not necessarily use it.

I think the main driving force that can overcome the value & cost barrier will be the "software". As software evolves and makes use of AI better and adds more value, then there definitely becomes a good reason to have dedicated AI hardware blocks on your chips. Otherwise not.
Well, software is always behind hardware. If the new accelerators aren’t implemented in hardware, and exposed with a decent API, software will never use it. I’m hoping AMD (sooner than later) brings it across the stack (at least in 5/7/9 client parts) so it’ll proliferate software-wise.

Also: always nice to meet a fellow metalhead. \\,,//
 
May 19, 2023
16
12
15
ARM to RISC-V is actually a smaller jump as they are both RISC based and share some basic instructions in their ISA. CISC to RISC is a much bigger jump technically.

Modern RISC CPUs (even RISC V) have very CISC-like instructions (vector for example), so that “differentiation” really doesn’t apply so much anymore. Also, modern CISC CPUs have very RISC-like internal micro-ops. They’ve largely converged.

These days it’s about how fast and accurate your branch predictor is, how close instructions/data can be kept to the core with low latency, and whether you optimize for performance, area efficiency, or power efficiency.

Pick 2, but you can’t have all 3 lol.
 
Last edited:

Kamen Rider Blade

Distinguished
Dec 2, 2013
1,280
810
20,060
It helps that I'm getting paid to get VMs and containers work and came to VMware in 1999 after a bit of VM370 envy.

The other motivator is that it's so extremely easy to just spin up a couple of VMs and then make them jump through hoops, and then try this and that if they keep falling flat on their faces.

Rebuilding a physical machine after a software installation has gone wrong can just be hours intead of seconds of reverting to the last snapshot, especially on big machines that take minutes to just reboot.

There is charm in little boxes, but increasingly I find there is charm in little boxes that can run a couple of VMs without breaking a sweat: there is a ton of capabilities in an Alder/Raptor-Lake or Ryzen 5800U/H based NUC today with NVMe storage: it's quite simply the equivalent of what big vSphere hosts used to have 15 years ago.

Actually, the VM abstractions make it a lot easier to setup most types of systems, unless you're tied to some odd piece of hardware say for industrial control. And then it makes them nicely mobile, even switching between AMD and Intel isn't an issue most of the time, unless you're trying to do live-migrations.

Even performance is rarely an issue, network and storage are either ok or you can do pass-through (that takes a bit of skill, but not more than learning about a new piece of hardware). Even GPUs have become easy, unless you're trying to game on them. For the CUDA stuff I'm doing, it's become a matter of ticking options.

VMs were invented in 1967 to solve 360/370 backward compatibility issues and to transport ancient software without changes onto newer hardware. They still perform that function just as credibly as the consolidation in my experience and I'm very glad Diane Green and Mendel Rosenblum found a way around Intel's VM boykott and used the 486SL's system management mode and some emulation tricks to bring true virtual machines to x86! I wasn't happy to own the better VAX in an 80386 because that was still a "mini", I wanted a mainframe and they delivered.

Of course Intel immediately retaliated and invalidated the majority of their patent portfolio by offereing VM hardware support and sponsoring Xen, but that's just because Intel is Intel.
I perfectly understand how awesome VM's can be, but the thing is, I don't have that much free time in my personal life to deal with that kind of stuff.

I already lack enough free time as is, I don't have time to trouble-shoot esoteric bugs to get a VM to work with the stuff I want to do. So I just go Bare Metal.
 
  • Like
Reactions: abufrejoval

JamesJones44

Reputable
Jan 22, 2021
620
560
5,760
Still, to get the AI into these chips they had to "merge" with xilinx.
They do get other things out of it of course, nobody said otherwise.

It wasn't a merger in the traditional sense. AMD bought Xilinx and is where most of AMD's embedded segment revenue/profits come from, it just so happened that Xlinx had a nice AI platform already in the works which made it so they really got two things they were after in one acquisition.
 
  • Like
Reactions: bit_user
It wasn't a merger in the traditional sense. AMD bought Xilinx and is where most of AMD's embedded segment revenue/profits come from, it just so happened that Xlinx had a nice AI platform already in the works which made it so they really got two things they were after in one acquisition.
Yes, that's why I put merge in quotes and why I was talking about a cost in the first place.
 
  • Like
Reactions: JamesJones44

JamesJones44

Reputable
Jan 22, 2021
620
560
5,760
This would be true if it were the early 90s. Over the last 20-30 years CISC has become more RISC and RISC has become more CISC. In the end both RISC and CISC are basically hybrids of each type now and more like each other now than they were in the 90s.
x86 has well over 1000 different instructions, ARM has less than 300 and RISC-V's standard instruction set is less than 100. There is a massive difference in ISA size between x86-x64 (CISC) and ARM/RISC-V (RISC).

While aspects of CISC and RISC have been adopted each other there is still a very significant difference in instruction operation.
 
  • Like
Reactions: bit_user

JamesJones44

Reputable
Jan 22, 2021
620
560
5,760
Modern RISC CPUs (even RISC V) have very CISC-like instructions (vector for example), so that “differentiation” really doesn’t apply so much anymore. Also, modern CISC CPUs have very RISC-like internal micro-ops. They’ve largely converged.

While they have adopted method of each other and RISC added slightly more complex instructions there are sill way more instructions in CISC than RISC. For example x86_x64 has over 1000 different instructions. ARM on the other hand has less than 300 while RISC-V standard is less than 100. Instructions in different designs float up and down, but in most cases they are still 50% less instructions for RISC based designs (ARM/RISC-V) than CISC designs (x86/x64).
 
  • Like
Reactions: bit_user
x86 has well over 1000 different instructions, ARM has less than 300 and RISC-V's standard instruction set is less than 100. There is a massive difference in ISA size between x86-x64 (CISC) and ARM/RISC-V (RISC).

While aspects of CISC and RISC have been adopted each other there is still a very significant difference in instruction operation.

While they have adopted method of each other and RISC added slightly more complex instructions there are sill way more instructions in CISC than RISC. For example x86_x64 has over 1000 different instructions. ARM on the other hand has less than 300 while RISC-V standard is less than 100. Instructions in different designs float up and down, but in most cases they are still 50% less instructions for RISC based designs (ARM/RISC-V) than CISC designs (x86/x64).
Instruction set count has nothing to do with if something's considered RISC or CISC. Motorola's 6800/68K, MOS 6502, and Zilog Z80 are all considered CISC processors, but have fewer instructions than ARM or RISC-V. The only reason why modern x86-64 has so many instructions is because it has a 50 year legacy to uphold, including about a half dozen operating modes.

The only thing that differentiates CISC from RISC these days is if the ISA primarily uses load-store for memory operations. You might hear that fixed instruction lengths are also used, but that's not a requirement. Modern MIPS uses a variable length instruction (16/32/48-bit sizes) and is considered a RISC ISA.
 
May 19, 2023
16
12
15
While they have adopted method of each other and RISC added slightly more complex instructions there are sill way more instructions in CISC than RISC. For example x86_x64 has over 1000 different instructions. ARM on the other hand has less than 300 while RISC-V standard is less than 100. Instructions in different designs float up and down, but in most cases they are still 50% less instructions for RISC based designs (ARM/RISC-V) than CISC designs (x86/x64).
Yeah, x86 definitely still has way more instructions, and many instructions that do a lot of steps, which really aids in code density. But x86 also has friggin’ decades of extensions upon extensions.

I hope someday either Intel or AMD can do another ISA cleanup like x86-64 did.