Jim was involved in the early versions of Zen & M1, I believe he knows.
Apples M series looks very impressive because typically, at launch, they are node ahead of the competition, so early access deals with TSMC is the secret weapon this buys them about 6 months. They also are primarily laptop chips, AMD has competitive technology but always launches the low power chips after the desktop & server parts.
> so early access deals with TSMC is the secret weapon this buys them about 6 months
Aren't Apple typically 2 years ahead? M1 came out 2020, other CPUs from the same node level (5 nm TSMC) came out 2022. If you mean apple launches their 6 months ahead of the rest of the industry gets on the previous node, sure, but not the current node.
What you are thinking about is maybe that AMD 7nm is comparable to Apple 5nm, but really what you should compare is todays AMD cpus with the Apple cpu from 2022, since they are on the same architecture.
But yeah, all the impressive bits about Apple performance disapears once you take architecture into account.
I've used ChatGPT on Azure. It sucks on so many levels, everything about it was clearly enforced by some bean counters who see X dollars for Y flops with zero regard for developers. So choosing AMD here would be about par for the course. There is a reason why everyone at the top is racing to buy Nvidia cards and pay the premium.
There are only like 3 AI building companies who have the tech capability and resources to afford that and 2 of them don't even offer their chips to others or have gone back to Nvidia. The rest is manufacturers desperately trying to get a piece of the pie.
Any sensor that captures a ton of data that needs realtime processing to 'compress' the data before the data can be forwarded to data accumulator. Think MRI or CT scanners but industrially there are thousands of applications.
If you need a lot of realtime processing to drive motors (think industrial robots of all kinds), FPGAs are preferred of micro-controllers.
All kinds of industrial sorting systems are driven by fpgas because the moment of measurement (typically with a camera) & the sorting decision are less than a milisecond apart.
There are many more, it's a very 'industrial' product nowadays, but sometimes an FPGA will pop up in a high-end smartphone or TV because they allow to add certain features late in the design cycle.
If you're looking for fair comparisons don't ask nVidias marketing department, those guys are worse than Intel.
What AMD did was a true comparison, while nvidia is applying their transformer engine which modifies & optimizes some of the computation to FP8 & they claim no measurable change in output. So yes, nvidia has some software tricks left up on their sleeve and that makes comparisons hard, but the fact remains that their best hardware can't match the mi300x in raw power. Given some time, AMD can apply the same software optimizations, or one of their partners will.
I think AMD will likely hold the hardware advantage for a while, nVidia doesn't have any product that uses chiplets while AMD has been developing this technology for years. If the trend continues to have these huge AI chips, AMD has a better hand to economically scale their AI chips.
Not my area, but isn't a lot of NVIDIA's edge over AMD precisely software? NVIDIA seem to employ a lot of software dev (for a hardware company) & made CUDA into the de facto standard for much ML work. Do you know if AMD are closing that gap?
They have improved their software significantly in the last year, but there is a movement that's broader than AMD that wants to get rid of CUDA.
The entire industry is motivated to break the nvidia monopoly. The cloud providers, various startups & established players like intel are building their own AI solutions. Simultaneously, CUDA is rarely used directly, typically a higher level (Python) API that can target any low-level API like cuda, PTX or rocm.
What AMD is lacking right now is decent support for rocm on their customer cards on all platforms. Right now if you don't have one of these MI cards or a rx7900 & you're not running linux you're not going to have a nice time. I believe the reason for this is that they have 2 different architectures, CDNA (the MI cards) and RDNA (the customer hardware).
That's what I have (RX 7900XT on Arch), and ROCm with pytorch has been reasonably stable so far. Certainly more than good enough for my experimentation. Pytorch itself has official support and things are pretty much plug & play.
> Given some time, AMD can apply the same software optimizations, or one of their partners will.
Except they have been given time, lots of it, and yet AMD is not anywhere close to parity with CUDA. It's almost like you can't just snap your figures and willy-nilly replicate the billions of dollars and decades investment that went into CUDA.
That was a year ago. AMD is changing their software ecosystem at a rapid pace with AI software as a #1 priority. Experienced engineers have been reassigned from legacy projects to focus on AI software. They've bought a number of software startups that were already developing software in this space. It also looks like they replaced the previous AMD top level management with directors from Xilinx to reenergize the team.
To get a picture of the current state which has changed a lot, this MS Ignite presentation from three weeks ago may be of interest. The slides show the drop in compatibility they have for higher levels of the stack and the tools for translation at the lower levels. Finally there's a live demo at the end.
I have a comment elsewhere in this thread imagining a headless VS Code with a remote UI in the browser. Would get you something close to Theia with the full VS Code ecosystem.
Vscode's architecture is not fit for that, as it runs additional node processes (e.g. the extension host process) that are chatting with the renderer process on a very fine-grained level.
Interesting. This is possibly too late to get a response, but can you give me any more detail? What constitutes chatty? What IPC mechanism? Is it just that the API for extensions is so wide open?
And still, do those things prevent something else from synchronizing UI state? Completely let VS Code run normally, even with a fake X server if I need... and then another extension that just syncs the current state of each UI panel to an emulated one in browser?
Anyway, sounds like you've thought this through or see obvious holes... I'd really like to understand more of why it's unworkable, or how it could be doable with other compromises. Thanks in advance.
Theia is using monaco. But there's other reasons for Theia too like the governance of the project, vscode is controlled by Microsoft and they may have conflicts when lets say some feature would compete with their visual studio offering.
There's two versions of VS Code, the "official" one and "Visual Studio Code - Open Source", and the former contains proprietary bits that are kept that way so other people don't use it to compete with VS.
Project Rider from JetBrains accidentally ended up including one of these bits unaware it was part of a proprietary license and had to remove the functionality that depended on it (CoreCLR debugging), later writing a new implementation to put the feature back in.
Although it's not a core component of VS Code (although, one time it was bundled, probably) rather it's something provided through proprietary C# plugin and additional download.
This is a very old (I think > 15 years ago) competition, the results say nothing about the situation today, both language have changed a lot.
It was a PR stunt by the Synopsys guys who a that time wanted to kill VHDL. The VHDL guys had to work with slow & broken VHDL simulators. The the problem was devised by verilog enthusiasts. All VHDL engineers who showed up (in much smaller numbers than verilog engineers) felt like they they didn't have a fair chance.
Let me guess, you were downcasting everything to std_logic_vector? If you have to cast things all the time in VHDL you're not using it correctly.
But please enjoy (System)Verilog with it's random often undefined coercion, implicit wire declarations, non-deterministic simulation and lack of any meaningful compile-time checks. Honestly, as a huge Haskell fan, I can't believe you're a Haskell fan.
