Jensen Huang’s vision for data center dominance may destroy the Arm ecosystem(semianalysis.com)
semianalysis.com
Jensen Huang’s vision for data center dominance may destroy the Arm ecosystem
https://semianalysis.com/jensen-huangs-vision-for-data-center-dominance-will-destroy-the-arm-ecosystem/
119 comments
Have you used Infiniband? 40Gbps cards are $30 on ebay, right now for tech that is what 3 generations back. Currently shipping gear is 200Gbps. Everything flows from, in, out or to the network. Cores don't matter. All future workloads will be done by GPUs.
I have in HPC and backup scenarios.
I also ran datacenter services on Sun and IBM hardware that smoked anything offered by Intel platforms. But at the end of the day, commodity beats premium for 80%+ of the market. We run Linux on POWER exclusively as a cost-savings mechanism to reduce the Oracle bill.
I also ran datacenter services on Sun and IBM hardware that smoked anything offered by Intel platforms. But at the end of the day, commodity beats premium for 80%+ of the market. We run Linux on POWER exclusively as a cost-savings mechanism to reduce the Oracle bill.
Sorry for the snark, but what if my workload contains branches?
GPUs have excellent support for branches. Pascal has divergent thread execution, Volta added forward progress guarantees, Ampere improves on this further.
There is a lot of research about doing databases on GPUs, and Apache Spark runs on GPUs today, with much higher performance than on CPUs.
There is a lot of research about doing databases on GPUs, and Apache Spark runs on GPUs today, with much higher performance than on CPUs.
GPU databases are limited primarily by memory constraints on the card (e.g. ~32GB maximum per card for GV100 or whatever) and interconnect latency/bandwidth, not by raw parallel scan speed. If scan speed was all that mattered, we'd have had GPU-like parallel database hardware decades ago. You can crunch rows, but only as long as it fits in memory. Once your working set exceeds the provided RAM and has to page out data to the CPU over PCIe or some other link, the numbers and utilization begin looking much worse. "Every benchmark looks amazing when your working set fits entirely in cache."
But even more than that, for the price of a single high end Tesla (approx. 10k USD), you can build a high-end COTS x86 machine with a shitload of RAM, NVMe, and then install ClickHouse on it. That machine will scale to trillions of rows with ease and millisecond response times, whether or not everything fits in memory. It will cost less money and also cost less energy and it will scale out easier, and have better utilization of the hardware.
I'd wager that unless you have infinite money to dump on Nvidia or exceedingly specific requirements, any GPU database will get soaked by a comparable columnar OLAP store in every dimension.
But even more than that, for the price of a single high end Tesla (approx. 10k USD), you can build a high-end COTS x86 machine with a shitload of RAM, NVMe, and then install ClickHouse on it. That machine will scale to trillions of rows with ease and millisecond response times, whether or not everything fits in memory. It will cost less money and also cost less energy and it will scale out easier, and have better utilization of the hardware.
I'd wager that unless you have infinite money to dump on Nvidia or exceedingly specific requirements, any GPU database will get soaked by a comparable columnar OLAP store in every dimension.
> GPU-like parallel database hardware decades ago
https://en.wikipedia.org/wiki/Netezza#Technology
Furthermore, that line of reasoning is fallacious. The non-existence of a thing doesn't prove that the idea is bad.
https://en.wikipedia.org/wiki/Netezza#Technology
Furthermore, that line of reasoning is fallacious. The non-existence of a thing doesn't prove that the idea is bad.
I have been prototyping all of my new applications in context of commodity x86 with 10GbE links and NVMe storage.
I personally feel like distributed (coherent) shared memory is a bit overkill. I would much rather the kind of grain that a solid 10gbps link works well with. I.e. anything that is sensitive to latencies measured in microseconds or lower just lives on the same node where it needs to be sampled.
I can't think of too many applications that couldn't be designed to work just as well using 10GbE vs Infiniband/RDMA/shared memory. Even most real-time simulations could be designed to run in a practically syncrhonous fashion across a number of distributed hosts using stuff you can buy at Newegg or Amazon.
I personally feel like distributed (coherent) shared memory is a bit overkill. I would much rather the kind of grain that a solid 10gbps link works well with. I.e. anything that is sensitive to latencies measured in microseconds or lower just lives on the same node where it needs to be sampled.
I can't think of too many applications that couldn't be designed to work just as well using 10GbE vs Infiniband/RDMA/shared memory. Even most real-time simulations could be designed to run in a practically syncrhonous fashion across a number of distributed hosts using stuff you can buy at Newegg or Amazon.
In exactly the same way, "treat your servers as cattle, not pets" is massive overkill for your average wordpress site, but Amazon pulled an entire industry out of that hat.
> You could pave a road with the gravestones of technology vendors who pursued industry dominance with faster, more expensive chips. If IBM, Sun, Unisys, HP, Digital, SGI and a dozen others failed, why would a company with almost zero datacenter presence succeed?
I have very much the same opinion, and I think that Huang is at least aware of that.
> Nvidia would probably pursue a similar strategy -- sell chips with lots and lots of cores and lease capacity on demand.
But this will be pretty much the same IBM thing. Some banks, and Oracle/SAP buyer types may buy in, but that will be it. It does not change anything to how the companies in the above list of "big iron" vendors attempted to do it before.
I want to remind that Huang is also, a very big "investment relations" player, and he likes to make an impression of "grandiose" plans to impressionable investor guys.
I have very much the same opinion, and I think that Huang is at least aware of that.
> Nvidia would probably pursue a similar strategy -- sell chips with lots and lots of cores and lease capacity on demand.
But this will be pretty much the same IBM thing. Some banks, and Oracle/SAP buyer types may buy in, but that will be it. It does not change anything to how the companies in the above list of "big iron" vendors attempted to do it before.
I want to remind that Huang is also, a very big "investment relations" player, and he likes to make an impression of "grandiose" plans to impressionable investor guys.
> impressionable investor guys.
Impressionable investor guys tend not to be investor guys for very long. Big-vision bluster can can work with media and some end users but it turns off real market analysts.
Impressionable investor guys tend not to be investor guys for very long. Big-vision bluster can can work with media and some end users but it turns off real market analysts.
Seems to be working fine for Elon, Miyoshi Son & gang.
[deleted]
Elon seems to have delivered as opposed to Son, no?
Huh? Mellanox (now part of Nvidia) has a massive data center presence, and it's growing their NICs are leaps and bounds above Intel's.
>The datacenter is a 3 legged stool, and the remaining missing piece is a CPU. AMD, Intel, and various hyperscalers are also working to build out their own 3-legged stool.
Intel/AMD is allowed to build a moat in data center but Nvidia can't(?)
>Nvidia’s endgame isn’t more revenue from licensing costs. Their endgame is a fully vertically integrated data center provider. They will want to make and control every part of the three legged stool. This means they slowly destroy the idea of Neoverse. Whether through making that IP extremely costly, or having their own in house designs be a generation ahead, Nvidia will build a moat around Arm server CPUs. Over time, Jensen Huang will muscle out other Arm vendors
Intel doesn't even licensed out x86. AMD is grandfathered in. So Intel is allowed to control x86 but Nvidia can't. this is like Oracle bought MySQL along with Sun and Michael Widenius cry about it. You know what you are doing when you sold MySql to Sun. another company can come along to buy it. this is what closed ecosystem/software does. MySql is saved by dual licenses so maybe its time to ditch this idea of building an ecosystem on closed hardware/software.
Intel/AMD is allowed to build a moat in data center but Nvidia can't(?)
>Nvidia’s endgame isn’t more revenue from licensing costs. Their endgame is a fully vertically integrated data center provider. They will want to make and control every part of the three legged stool. This means they slowly destroy the idea of Neoverse. Whether through making that IP extremely costly, or having their own in house designs be a generation ahead, Nvidia will build a moat around Arm server CPUs. Over time, Jensen Huang will muscle out other Arm vendors
Intel doesn't even licensed out x86. AMD is grandfathered in. So Intel is allowed to control x86 but Nvidia can't. this is like Oracle bought MySQL along with Sun and Michael Widenius cry about it. You know what you are doing when you sold MySql to Sun. another company can come along to buy it. this is what closed ecosystem/software does. MySql is saved by dual licenses so maybe its time to ditch this idea of building an ecosystem on closed hardware/software.
x86 has been (effectively) a duopoly for over 20 years but breaking the ARM ecosystem would be a new thing. Building a moat is one thing but privatizing an existing ecosystem is different.
Nvidia already has the ability to build world beating data-center products using the three 'legs' of GPU (where it already dominates), the Mellanox technology it's acquired and Arm CPUs (where of course with an architecture license its free to improve on existing Arm designs). It already has a potential moat by virtue of its unique access to these three technologies together.
So why would it pay $30bn+ to own Arm? Because it would have the ability to directly hinder the businesses (and customers) of its current and potential competitors who have invested in the development of Arm based products. Not just in the data center but in mobile and in products that are used by billions of people around the world. That can't be right.
So why would it pay $30bn+ to own Arm? Because it would have the ability to directly hinder the businesses (and customers) of its current and potential competitors who have invested in the development of Arm based products. Not just in the data center but in mobile and in products that are used by billions of people around the world. That can't be right.
> it would have the ability to directly hinder the businesses
They have extensive contracts in place. It's not like ARM instruction set is provided to nVidia and then they can just revoke it because they don't like nVidia.
They have extensive contracts in place. It's not like ARM instruction set is provided to nVidia and then they can just revoke it because they don't like nVidia.
I think the parent is saying that the only value add for Nvidia to purchase ARM itself rather than just purchasing an architectural licence is to use ARM in an anticompetitive way.
That's not much of a value gain it would just push the industry further away from ARM. x86 has a lot of legacy power and it enjoyed being the only relevant platform for a long time in a lot of markets so there's a lot of cost in making stuff that was architecture specific cross platform. ARM doesn't really have that, people that deal with ARM already have to worry about infrastructure set portability (all of them also have x86 support) once you add ARM the way is open for other ISA
> That's not much of a value gain it would just push the industry further away from ARM.
I think that's the big irony here. It's taken ARM decades to break out of embedded/mobile and get to the point where they're seriously considered for workstation or server use. If Nvidia were to acquire ARM it would likely antagonize everyone to the point where they'd rush back to x86 and Nvidia would gain nothing.
I think that's the big irony here. It's taken ARM decades to break out of embedded/mobile and get to the point where they're seriously considered for workstation or server use. If Nvidia were to acquire ARM it would likely antagonize everyone to the point where they'd rush back to x86 and Nvidia would gain nothing.
That ship sailed already, Apple selling laptops with ARM processors is a sign of the times here.
Apple is still a very small part of the market when it comes to laptops and desktops. Their ARM-based computers will be a tiny drop in the bucket when stacked against mobile ARM chipsets. Sure, I expect PC vendors to jump on the ARM train as well, but if the sale to Nvidia happens, that could stop before it gets into full swing, or not happen at all. I'm sure PC makers who are thinking about ARM are watching this deal very carefully, and are avoiding jumping too soon.
Arm is the last instruction set that mattered. X86 and Arm are dead. It is always the third choice that wins.
> That's not much of a value gain it would just push the industry further away from ARM
It's enough for a short term gains, which is enough for a nifty bonus to a CEO.
It's enough for a short term gains, which is enough for a nifty bonus to a CEO.
He founded the company and has been CEO for 27 years, so that he could extract short-term gains?
> to use ARM in an anticompetitive way
If so Nvidia will surely buy ARM.
If so Nvidia will surely buy ARM.
Right, but they can neglect it, or even just signal the intention to neglect it, and everyone smaller than, say, Apple will have to skate to where that puck will lead.
[deleted]
I'm not so sure that would be the play. Wouldn't it make more sense to bundle their GPU/Cuda IP with new processors like how Qualcomm bundles their SoCs with their modems or Intel chipsets with their CPUs? I think the end goal here is to build a bigger moat with CUDA.
They can already do that without having to buy ARM.
I think they would be expending the money to grow their CPU team. The ARM engineers would be working on making Nvidia CPUs better, neglecting “public” ARM cores.
This would hurt small fish, but Apple, Amazon, Google, Tesla, Facebook, etc already have their own in house ARM teams.
I think they would be expending the money to grow their CPU team. The ARM engineers would be working on making Nvidia CPUs better, neglecting “public” ARM cores.
This would hurt small fish, but Apple, Amazon, Google, Tesla, Facebook, etc already have their own in house ARM teams.
> The rational for purchasing Arm seems ridiculous to many, but Jensen’s vision is for the datacenter being a computer and Nvidia being the one to build it.
The thing is, there are 3 companies that control the future of datacenter growth. Amazon, Microsoft and Google. They can move the industry to RISC-V if NVidia doesn't play ball, or convince Intel to manufacture on TSMC's process.
Nvidia won't be in a particularly strong negotiating position. My understanding is that lots of ARM licenses are perpetual, or very broad. The existing players can just keep making ARM chips, what can NVidia do to extract more money from them, new instructions?
The thing is, there are 3 companies that control the future of datacenter growth. Amazon, Microsoft and Google. They can move the industry to RISC-V if NVidia doesn't play ball, or convince Intel to manufacture on TSMC's process.
Nvidia won't be in a particularly strong negotiating position. My understanding is that lots of ARM licenses are perpetual, or very broad. The existing players can just keep making ARM chips, what can NVidia do to extract more money from them, new instructions?
> what can NVidia do to extract more money from them, new instructions?
I don't know what those perpetual licenses look like, but, if there are any strings attached at all, perhaps Nvidia can tug on them in order to apply a little good old-fashioned embrace-extend-extinguish to ARM? Extend ARM with new instructions that offer performance improvements when you've bought 100% into Nvidia hardware, maybe, and then stifle competition by making them implement these features in order to claim ARM compatibility, thereby making it more difficult/expensive for anyone else to pair ARM CPUs with other companies' GPUs?
I don't know what those perpetual licenses look like, but, if there are any strings attached at all, perhaps Nvidia can tug on them in order to apply a little good old-fashioned embrace-extend-extinguish to ARM? Extend ARM with new instructions that offer performance improvements when you've bought 100% into Nvidia hardware, maybe, and then stifle competition by making them implement these features in order to claim ARM compatibility, thereby making it more difficult/expensive for anyone else to pair ARM CPUs with other companies' GPUs?
In a string-tugging fight between AWS and ARM, you'd bet on ARM?
I don't see a fight between AWS and ARM as a realistic scenario. In The Great British Bake-Off, Mary Berry and Paul Hollywood were competing against neither the contestants nor the baking challenges. Their involvement was defining the scoring rubric and selecting the winners.
Similarly, AWS is in competition with nobody in this context. AWS just influences the competitive landscape and chooses who wins by awarding contracts.
Similarly, AWS is in competition with nobody in this context. AWS just influences the competitive landscape and chooses who wins by awarding contracts.
It took Arm 20 years to achieve current success with substantial inroads into networking, mobile, automotive, servers (AWS & others) and desktops (Apple Silicon imminent). This is not the time to give up and start over. There are society-wide opportunity costs.
China is having issues with Arm and has a strategic view to develop its domestic industry. This alone means that a significant challenger to Arm will rise.
China is heavily investing in RISC-V. I'd bet dollars to doughnuts that their challenger will use a RISC-V ISA.
Interesting point, I don't believe I've heard about Chinese ARM processor, but I do know that China has MIPS based processors, and they're using VIAs license to build x86 chips.
Well, China has Rockchip and HiSillicon, although HiSillicon lost the right to manufacture in TSMC sometimes ago. Not only VIA, both Intel and AMD has joint venture in China to produce homegrown Chinese x86 chips.
There was a drama at ARM China recently. The fired, but de-jure still acting CEO was caught self dealing with his own obscure fund company, some times with clients' assistance.
IMHO, it simply looked like he was was quietly moving out cash from the company.
IMHO, it simply looked like he was was quietly moving out cash from the company.
> The thing is, there are 3 companies that control the future of datacenter growth. Amazon, Microsoft and Google.
The are big players in Internet business, but they are not big enough consumers to benefit economically from owning chips. Even if they will be all combined, they will not be even a double digit of top tier Xeon buyers.
And this is partly the reason why AMD was so keen on playing ball with them. AMD among other things was making a proprietary CPU for Amazon, which the later discarded. It was later rebranded Seattle, and thrown on the open market.
The are big players in Internet business, but they are not big enough consumers to benefit economically from owning chips. Even if they will be all combined, they will not be even a double digit of top tier Xeon buyers.
And this is partly the reason why AMD was so keen on playing ball with them. AMD among other things was making a proprietary CPU for Amazon, which the later discarded. It was later rebranded Seattle, and thrown on the open market.
> but they are not big enough consumers to benefit economically from owning chips.
AWS Graviton 2 (Arm) would like a word about that with you. https://aws.amazon.com/ec2/graviton/
AWS Graviton 2 (Arm) would like a word about that with you. https://aws.amazon.com/ec2/graviton/
I bet they will eventually wrap it up, as they can't keep up with AMD, and Intel RnD, and given the restarting of competition in X86, and thus falling prices.
Pretty much the only way they could've done that economically, in relative terms, was at the time of obscenely high prices on high core count xeons.
Pretty much the only way they could've done that economically, in relative terms, was at the time of obscenely high prices on high core count xeons.
ARM's got a lot of development effort as a whole, and they're getting very competitive performance-wise. They're also not hindered in having to be compatible with the 8088.
Won't keep up in what way? Graviton2 is already better for some use cases. https://www.honeycomb.io/blog/observations-on-arm64-awss-ama...
My take on this is that the Graviton stuff exists to solve the Catch-22 problem: AWS wants you running ARM stuff, so they need to provide an ARM platform for you to do it on. Current suppliers may not be providing anything cloudy enough from the enterprise management side of things, so AWS might have to roll their own for now.
Once the ball is rolling, they can get 3rd party ARM chips or full servers in and stop with their own development on that side if they want to.
Once the ball is rolling, they can get 3rd party ARM chips or full servers in and stop with their own development on that side if they want to.
Amazon has been putting their own chips into systems for years, after they bought Annapurna Labs - they have hardware virtualisation support in their network and storage chips, and now their own CPU. This does not seem to be a short-term tactic.
Part of being in the top half of the s curve that is Moore's law is that CPU cores, even high performance ones, become a commodity. Historically, designing high perf cores required a huge capital investment on a short time frame in order to take advantage of each node. As the difference in nodes slows, that gives more breathing room for other companies and even open source to create competitive cores for a given gate count.
Also, the x86_64 patents don't last forever.
Also, the x86_64 patents don't last forever.
>Also, the x86_64 patents don't last forever.
No, but Intel and AMD have a decent reason to work together to create new key feature additions to x86 that can be newly patented. FMA is under patent for 6 more years. AVX2 is 12 more years. AVX512 another 15.
No, but Intel and AMD have a decent reason to work together to create new key feature additions to x86 that can be newly patented. FMA is under patent for 6 more years. AVX2 is 12 more years. AVX512 another 15.
You think Amazon, Microsoft, and Google taken together are not a major customer of Intel? That's preposterous. I bet they are #1, #2, and #3 buyers of Xeon CPUs taken individually.
They might not be #1, #2 and #3, but they're certainly in the top 7 (there's also Facebook and the three huge Chinese internet companies). It's well known that those companies (sometimes called the 'Super Seven') account for a majority of Intel's datacenter revenue.
Super Seven is a new term for me.
And they buy them in servers from OEMs who volume buy even bigger number of chip than any of them individually. Only this way such volume discounts were realised.
If they were buying directly, Intel would have even more leverage to milk them, than if they stood behind the back of some beefy OEM.
If they were buying directly, Intel would have even more leverage to milk them, than if they stood behind the back of some beefy OEM.
> And they buy them in servers from OEMs who volume buy even bigger number of chip than any of them individually.
No, they build their own servers. They definitely aren't racking Dell or HP servers.
Even Amazon's x86 based servers are extremely custom. That whole "Nitro" system isn't exactly a USB stick, and AWS is often using customized variants of Intel processors in their servers.
Let me repeat that: Intel literally makes custom processors specifically for AWS.
> If they were buying directly, Intel would have even more leverage to milk them, than if they stood behind the back of some beefy OEM.
That's not how bulk buying works... at all.
The scale of AWS is so much larger than you seem to think it is.
No, they build their own servers. They definitely aren't racking Dell or HP servers.
Even Amazon's x86 based servers are extremely custom. That whole "Nitro" system isn't exactly a USB stick, and AWS is often using customized variants of Intel processors in their servers.
Let me repeat that: Intel literally makes custom processors specifically for AWS.
> If they were buying directly, Intel would have even more leverage to milk them, than if they stood behind the back of some beefy OEM.
That's not how bulk buying works... at all.
The scale of AWS is so much larger than you seem to think it is.
> Intel literally makes custom processors specifically for AWS
Sort of. It's the same mask for everyone with the per customer special features either fused off, or just requiring a special MSR knock sequence.
Sort of. It's the same mask for everyone with the per customer special features either fused off, or just requiring a special MSR knock sequence.
That’s an implementation detail — an optimization on Intel’s side of things. It’s the same effect either way, and I can’t just ask Intel to customize their processors for me.
AWS operates at a large enough scale that they do exactly that, and AWS already purchases directly from Intel, both of which are my main points. Baybal2 doesn’t seem to be aware of either of these facts based on their comment.
AWS operates at a large enough scale that they do exactly that, and AWS already purchases directly from Intel, both of which are my main points. Baybal2 doesn’t seem to be aware of either of these facts based on their comment.
Well, the thing is, it doesn't seem to be really customer specific feature.
An option to fuse an individual performance profile, or few more ME features doesn't amount to be something really custom.
An option to fuse an individual performance profile, or few more ME features doesn't amount to be something really custom.
It's real custom silicon on the masks; it's not a binning thing. What I've mainly heard of is custom system integration glue for their boards.
Even if that it is, it must be something really small. It's hard to believe for me that they will put even a square millimetre of effectively dead silicon onto xeon for <10% of their sales.
You're basically admitting that you don't know much about these parts of the datacenter industry, but you keep posting comments authoritatively like you do.
Why can't you just ask questions instead of misleading people?
Why can't you just ask questions instead of misleading people?
I'm not sure how authoritative other commenter are, but I would be very surprised that Intel was going so far to accommodate them beyond fusing perf profile/ME feature/or some small IP block.
With my knowledge of their sales tactic, I would imagine Intel could've simply said "You are free to buy AMD," with full knowledge that just few years ago their clients had no other option than coming back to them eventually.
With my knowledge of their sales tactic, I would imagine Intel could've simply said "You are free to buy AMD," with full knowledge that just few years ago their clients had no other option than coming back to them eventually.
I'm just curious so ask you a question, what's the special feature on Intel processor for AWS? I had imagined something like special turbo-boost parameter to avoid performance hit.
Why? Particularly when the practicalities of layout, particularly around the uncore area, mean there's some free space anyway. Also, a square millimeter is around 30-40 million transistors on TSMC 7nm (about Pentium III level gate count), which is almost certainly way more than any of these features would need by orders of magnitude.
Most of the silicon on a chip is turned off at any given time. That dead silicon doesn't hurt as much as you think.
Here's an example of the kinds of speedups you can get from something really small: 3% fleet-wide (estimated) speedup from 0.006% marginal silicon area.
https://www.samxi.org/papers/kanev_asplos2017.pdf
https://www.samxi.org/papers/kanev_asplos2017.pdf
> No, they build their own servers. They definitely aren't racking Dell or HP servers.
Yes, they buy from Quanta, Supermicro, Wistron etc, the ones who make servers for Dell, and HP.
> Let me repeat that: Intel literally makes custom processors specifically for AWS.
Some unlockable features, and perf profiles. Those weird SKUs popup on liquidation sale websites from time to time.
Yes, they buy from Quanta, Supermicro, Wistron etc, the ones who make servers for Dell, and HP.
> Let me repeat that: Intel literally makes custom processors specifically for AWS.
Some unlockable features, and perf profiles. Those weird SKUs popup on liquidation sale websites from time to time.
Quanta is an ODM. You said OEM.
Unless this is some kind of performance art, you really should stop commenting and switch to reading.
Unless this is some kind of performance art, you really should stop commenting and switch to reading.
>Quanta is an ODM. You said OEM.
Same difference, compared to building their own from parts. I don't think parent's point lies in the OEM vs ODM semantics detail.
Same difference, compared to building their own from parts. I don't think parent's point lies in the OEM vs ODM semantics detail.
Everything about this comment is so wrong that I recommend you discard all of your beliefs about the datacenter economy and start from scratch again.
> With the US Department of Energy dumping money into SCYL and many in the industry congregating around it, the software front is accelerating rapidly.
Anybody know what SCYL is? Based on the low number of google hits I'm thinking it's a typo
Anybody know what SCYL is? Based on the low number of google hits I'm thinking it's a typo
I would assume https://www.khronos.org/sycl/
SYCL
I hope this leads to serious interest in RISC-V ecosystem. It's been what, a decade? And we still don't have a cheap Raspberry-Pi like board.
We should put a cap on M&A activities concerning more than 100 people on the payroll on either side.
Speaking of RISC-V, does RISC-V have any real traction?
Not niche traction and announcements here and there, actual heavy investments...
Or is it more like an "open arch" fantasy thing, kind of the cpu analogous to Ogg Vorbis and Open Moko?
Not niche traction and announcements here and there, actual heavy investments...
Or is it more like an "open arch" fantasy thing, kind of the cpu analogous to Ogg Vorbis and Open Moko?
Western Digital is using it on their hdd controllers. SiFive licenses IP for big cores and China apparently plans to work with it in the future.
Also I don't know why you count Ogg Vorbis as a fantasy kind of thing, it's used for pretty much any conference app and it has support on most consumer hardware and softwware for playback. Programs like EAC and dbpoweramp support it. I use it for my music collection on my phone, at half the size of mp3 it sounds completely transparent to me with my earbuds.
Also I don't know why you count Ogg Vorbis as a fantasy kind of thing, it's used for pretty much any conference app and it has support on most consumer hardware and softwware for playback. Programs like EAC and dbpoweramp support it. I use it for my music collection on my phone, at half the size of mp3 it sounds completely transparent to me with my earbuds.
Basically as much as PIC and similar chipsets, just without the tooling ecosystem.
>Also I don't know why you count Ogg Vorbis as a fantasy kind of thing, it's used for pretty much any conference app and it has support on most consumer hardware and softwware for playback.
The idea in the day was it would replace mp3/aac/etc which it obviously didn't. That players support it is also not a mark of great success, since most people don't and won't care to use it. It just means that for the rare person caring enough, it will work.
From that aspect, the fact that conference apps use it as the internal format is hardly relevant, they could license and use whatever and we wouldn't know any difference.
The idea in the day was it would replace mp3/aac/etc which it obviously didn't. That players support it is also not a mark of great success, since most people don't and won't care to use it. It just means that for the rare person caring enough, it will work.
From that aspect, the fact that conference apps use it as the internal format is hardly relevant, they could license and use whatever and we wouldn't know any difference.
>The idea in the day was it would replace mp3/aac/etc which it obviously didn't.
It did for anyone that cares about it and about file size. My portable library is vorbis. Mp3 is just very popular and there are a lot of mp3 files out there that can't be converted without further degradation of the sound quality so mp3 will remain relevant for a long time.
>From that aspect, the fact that conference apps use it as the internal format is hardly relevant, they could license and use whatever and we wouldn't know any difference.
It's relevant in terms of market support. Vorbis isn't going anywhere. The random codecs that have popped over the years, open or proprietary never got a lot of support from other companies so they went away.
It did for anyone that cares about it and about file size. My portable library is vorbis. Mp3 is just very popular and there are a lot of mp3 files out there that can't be converted without further degradation of the sound quality so mp3 will remain relevant for a long time.
>From that aspect, the fact that conference apps use it as the internal format is hardly relevant, they could license and use whatever and we wouldn't know any difference.
It's relevant in terms of market support. Vorbis isn't going anywhere. The random codecs that have popped over the years, open or proprietary never got a lot of support from other companies so they went away.
There's been some real uptake for large consumers of embedded cores who can use it to avoid paying ARM royalties and to be able to add their own custom instructions for their specific workloads.
And in teaching. If you're going to get a sophomore to build their first 3 stage RISC pipeline or a senior their first OoO machine with register renaming then RISC-V's consistent design removes a lot of unnecessary distractions.
I assume people are using it in research too. If I were to redo my thesis on improving adder efficiency today I'd probably look at using an open source RISC-V design as a base.
I'm skeptical of RISC-V's ability to succeed as an application core like ARM's A series or modern x86. But none the less I'm bullish on it having an important future.
And in teaching. If you're going to get a sophomore to build their first 3 stage RISC pipeline or a senior their first OoO machine with register renaming then RISC-V's consistent design removes a lot of unnecessary distractions.
I assume people are using it in research too. If I were to redo my thesis on improving adder efficiency today I'd probably look at using an open source RISC-V design as a base.
I'm skeptical of RISC-V's ability to succeed as an application core like ARM's A series or modern x86. But none the less I'm bullish on it having an important future.
Ogg Vorbis is actually very relevant. I remember a lot of games used Ogg Vorbis for audio files.
Some mainstream software packages are still work in progress, for example V8 doesn't target it yet.
But RISC-V is thriving in other areas like industrial controllers, and Alibaba Cloud just announced a few days ago they are using it in a new server processor, positioned as an eventual competitor to AWS Graviton.
Topically: Nvidia uses RISC-V in some GPUs as a controller (not the GPU core). Not sure if those are released yet, but they gave a presentation on it at a recent RISC-V meet-up.
But RISC-V is thriving in other areas like industrial controllers, and Alibaba Cloud just announced a few days ago they are using it in a new server processor, positioned as an eventual competitor to AWS Graviton.
Topically: Nvidia uses RISC-V in some GPUs as a controller (not the GPU core). Not sure if those are released yet, but they gave a presentation on it at a recent RISC-V meet-up.
It is more of a fantasy thing, nothing loosing sleep over, besides some early C and C++ support via GCC, there are almost no mature toolchains to chose from.
And there are only some Linux special variants for it.
And there are only some Linux special variants for it.
Its not about Huang. Its the structure of the markets and companies that makes this an obvious anti-trust problem.
The way the title of this was phrased made a little lightbulb go on:
What if Intel asked NVIDIA to buy ARM?
What if Intel asked NVIDIA to buy ARM?
Is there a corollary to Betteridge's Law, asserting that titles with a subjunctive verb from the set {may,might,could} also evaluate to false?
(https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...)
(https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...)
I simply do not understand current demand for data centers and more specifically GPU/ASIC. Are companies really squeezing that much out of data to justify this level of investments?
Have you looked at Google’s earnings? ;)
NVIDIA is famous for row of anticompetitive practices. On the other hand such a disaster will clear up the road for other, more modern alternatives - be it RISC-V or something entirely new.
So the fear here is that nvidia becomes a major provider of arm-based server chips and the rest of the arm ecosystem is forced to move to risc-v?
Both of these events would be very positive for the industry.
Both of these events would be very positive for the industry.
> the rest of the arm ecosystem is forced to move to risc-v?
In addition to selling hardware, it seems like ARM-owning Nvidia would probably be happy to sell whatever amazing new ARM cores they cook up to whoever is willing to pay to use the design. It's not obvious RISC-V will benefit from any of this. Somebody, somewhere would need to create equally amazing RISC-V cores and find a way to sell them.
In addition to selling hardware, it seems like ARM-owning Nvidia would probably be happy to sell whatever amazing new ARM cores they cook up to whoever is willing to pay to use the design. It's not obvious RISC-V will benefit from any of this. Somebody, somewhere would need to create equally amazing RISC-V cores and find a way to sell them.
So far RISC-V market is still wishful thinking, beyond a couple of maker boards.
First get C, C++, Go, Rust, Java, Erlang, .NET,.... generating competitive native code, port all their main libraries and IDE tooling, and then it might stand a chance.
First get C, C++, Go, Rust, Java, Erlang, .NET,.... generating competitive native code, port all their main libraries and IDE tooling, and then it might stand a chance.
RISC-V is far past "couple of maker boards" now. The last year has seen a lot of activity.
You're right that a number of mainstream software packages are still work in progress, for example V8 doesn't target it yet.
But RISC-V is thriving in other areas like industrial controllers, and Alibaba Cloud just announced a few days ago they are using it in a new server processor, positioned as an eventual competitor to AWS Graviton.
Topically: Nvidia uses RISC-V in some GPUs as a controller (not the GPU core). Not sure if those are released yet, but they gave a presentation on it at a recent RISC-V meet-up.
You're right that a number of mainstream software packages are still work in progress, for example V8 doesn't target it yet.
But RISC-V is thriving in other areas like industrial controllers, and Alibaba Cloud just announced a few days ago they are using it in a new server processor, positioned as an eventual competitor to AWS Graviton.
Topically: Nvidia uses RISC-V in some GPUs as a controller (not the GPU core). Not sure if those are released yet, but they gave a presentation on it at a recent RISC-V meet-up.
Point is, how much use do those controllers get versus more traditional CPU with years of mature ecosystem, so far it looks like testing waters to me, not something that even PIC has to worry about.
Big cloud companies can all chip in a few billions, like they're doing with Linux. TSMC fabs everything for everyone anyway. The big cloud boys have too much money to tolerate being screwed over.
A few years ago, an ST rep told me they were making one million STM32 per day (microcontroller class), and I can only assume that that's increased since then.
My impression is that the Cortex-Ms are popular because of the price, the rich sets of peripherals they tend to come with, and not least because they come with a proven, performant C compiler. I don't think it's impossible that a RISC-V core could make some dents in this markey fairly quickly, especially if Nvidia make the future of the platform look uncertain.
My impression is that the Cortex-Ms are popular because of the price, the rich sets of peripherals they tend to come with, and not least because they come with a proven, performant C compiler. I don't think it's impossible that a RISC-V core could make some dents in this markey fairly quickly, especially if Nvidia make the future of the platform look uncertain.
Nothing would make me happier than to see RISC-V really take off. I agree that the ARM architecture becoming untenable would speed that along.
I'm still not sure, after reading all these comments, why anyone thinks an Nvidia that owned ARM would do anything other than continue to sell ARM cores and ARM IP rights to other companies, as well as continuing to sell actual hardware products using ARM cores. Suspecting the worst in everything is sort of standard nowadays, but buying ARM Ltd. so Nvidia can stop promoting the platform and selling the IP does not make much sense.
(unless they literally have a master plan to drive everyone back to AMD64, which doesn't make any business sense since they can't make that hardware, or drive everyone to RISC-V and profit off of that, which doesn't make any business sense since they could attempt that without buying ARM Ltd. and spending tens of billions of dollars)
I'm still not sure, after reading all these comments, why anyone thinks an Nvidia that owned ARM would do anything other than continue to sell ARM cores and ARM IP rights to other companies, as well as continuing to sell actual hardware products using ARM cores. Suspecting the worst in everything is sort of standard nowadays, but buying ARM Ltd. so Nvidia can stop promoting the platform and selling the IP does not make much sense.
(unless they literally have a master plan to drive everyone back to AMD64, which doesn't make any business sense since they can't make that hardware, or drive everyone to RISC-V and profit off of that, which doesn't make any business sense since they could attempt that without buying ARM Ltd. and spending tens of billions of dollars)
The text and background makes it hard to read.
https://oxide.computer/ has a simple mission. Build hyperscale racks with open firmware/drivers - cut the wasted components like HDMI ports that Dell/HP still throw on racks by default. ARM/RISCV/x86/GPU/TPU/storage ... those are just configuration options.
Companies like Lightedge will take on the HVAC and physical security. The future is chiplets and computational memory: https://www.researchgate.net/profile/Michael_Stumm/publicati...
Companies like Lightedge will take on the HVAC and physical security. The future is chiplets and computational memory: https://www.researchgate.net/profile/Michael_Stumm/publicati...
>>ARM/RISCV/x86/GPU/TPU/storage ... those are just configuration options.
But ISA still matters. Switching from Intel to AMD likely isn't much of a switch, but switching to a different ISA in the datacenter will continue to be an uphill battle.
As the article notes, the uphill battle will take longer for RISC-V and if Nvidia follows the strategy laid out they hope to profit in the intervening gap.
But ISA still matters. Switching from Intel to AMD likely isn't much of a switch, but switching to a different ISA in the datacenter will continue to be an uphill battle.
As the article notes, the uphill battle will take longer for RISC-V and if Nvidia follows the strategy laid out they hope to profit in the intervening gap.
> but switching to a different ISA in the datacenter will continue to be an uphill battle.
It really depends on what kind of stuff the datacenter runs.
I know of datacenters where almost all the code running is Java. For those kind of datacenters, so long as JDK supports ARM (which it does), I can't see why it would be such an uphill battle.
The uphill battle is really for sites who run lots of closed source COTS software, especially that which is written in C/C++/etc, where moving to ARM needs support from the vendors and the vendors might hesitate due to the amount of work involved. There are sites where close to everything is either open-source or else developed in-house in managed languages (Java, .Net, Python, Ruby, PHP, JavaScript, etc), and those sites are likely to find it a lot easier.
It really depends on what kind of stuff the datacenter runs.
I know of datacenters where almost all the code running is Java. For those kind of datacenters, so long as JDK supports ARM (which it does), I can't see why it would be such an uphill battle.
The uphill battle is really for sites who run lots of closed source COTS software, especially that which is written in C/C++/etc, where moving to ARM needs support from the vendors and the vendors might hesitate due to the amount of work involved. There are sites where close to everything is either open-source or else developed in-house in managed languages (Java, .Net, Python, Ruby, PHP, JavaScript, etc), and those sites are likely to find it a lot easier.
Even running an interpreted language we've found that there's just a hundred small papercuts when it comes to switching over to an ARM distro. Missing native modules, third party deps, even some shell scripts mysteriously not working properly. Over time this will hopefully ease, and having all developers on Mac using ARM will help massively, but right now there's just enough friction to make it not quite worth it.
> even some shell scripts mysteriously not working properly
I'm wondering how this could happen.
I'm guessing the script is using uname to detect the platform, and gets confused by Linux on ARM.
I used to see a lot of shell scripts which detected Linux vs Solaris vs AIX vs HP-UX and did different things on each, especially due to differences in what commands and options are available. Given those commercial Unices are now shadows of their former selves, you don't see that so much any more.
But I still see it in scripts that have to run on both macOS and Linux. I've even written a few of those scripts recently.
This shouldn't be an issue, though, if you just do `uname -s` – you should get e.g. `Linux` on both ARM and x86. Maybe some people, for whatever reason, are checking `uname -p` or `uname -m` instead or as well, or even trying to parse the output of `uname -a` – not a very good practice
I'm wondering how this could happen.
I'm guessing the script is using uname to detect the platform, and gets confused by Linux on ARM.
I used to see a lot of shell scripts which detected Linux vs Solaris vs AIX vs HP-UX and did different things on each, especially due to differences in what commands and options are available. Given those commercial Unices are now shadows of their former selves, you don't see that so much any more.
But I still see it in scripts that have to run on both macOS and Linux. I've even written a few of those scripts recently.
This shouldn't be an issue, though, if you just do `uname -s` – you should get e.g. `Linux` on both ARM and x86. Maybe some people, for whatever reason, are checking `uname -p` or `uname -m` instead or as well, or even trying to parse the output of `uname -a` – not a very good practice
Ehh, once you get to a certain point you wind up poking things under /sys and /proc that are a little different per-architecture, or building snippets of C code that make syscalls which behave differently per-architecture. Not to mention that ARM distros are usually a little different, either lagging behind or a little ahead of what exists for x86 - although it's better than it used to be, especially with ARM64.
You are just defending yourself. This is simply not true. Get an arm server on packet, install software, notice nothing.
> But ISA still matters. Switching from Intel to AMD likely isn't much of a switch, but switching to a different ISA in the datacenter will continue to be an uphill battle.
I'd expect datacenter to be far easier than in a laptop or such; datacenters run a lot more software that's either open source (and already working on multiple architectures, most of the time) or in-house (in which case the happy path is "add an extra build job that builds for the new systems"). It's not like consumer space where most users are tied to proprietary software that they couldn't port if they wanted.
I'd expect datacenter to be far easier than in a laptop or such; datacenters run a lot more software that's either open source (and already working on multiple architectures, most of the time) or in-house (in which case the happy path is "add an extra build job that builds for the new systems"). It's not like consumer space where most users are tied to proprietary software that they couldn't port if they wanted.
Apple took the spearhead by promising ARM laptops. As soon as that happen it unlocks the final puzzle for ARM based datacenter.
Running on local is essential - things are so much easier to debug, especially things deep in the dependency tree.
Running on local is essential - things are so much easier to debug, especially things deep in the dependency tree.
I almost guarantee the delay in the build out of their Waukee Iowa data center is so they can fill racks with server grade Apple Silicon.
Why Apple Silicon? Things are hard primarily because of different ISA and the necessity to recompile everything, of which some doesn't. Apple Silicon is still ARM.
Not much details about that Oxide.
The team size I see on the photo don't give off much confidence about them pulling that out.
The team size I see on the photo don't give off much confidence about them pulling that out.
For whatever it's worth, the talk I gave at Stanford in February[1] goes into (much) more detail -- and given some of your other comments here, you will find many aspects of the talk educational.
[1] https://www.youtube.com/watch?v=vvZA9n3e5pc
[1] https://www.youtube.com/watch?v=vvZA9n3e5pc
Sounds like the bullshit that IBM salespeople were peddling about POWER circa 2008. The real strategy was licensing capacity with physical segmentation. Nvidia would probably pursue a similar strategy -- sell chips with lots and lots of cores and lease capacity on demand.
You could pave a road with the gravestones of technology vendors who pursued industry dominance with faster, more expensive chips. If IBM, Sun, Unisys, HP, Digital, SGI and a dozen others failed, why would a company with almost zero datacenter presence succeed?
Even with the pitiful state of 2020 Intel, I'd put my money on commodity ethernet and x86 in the datacenter. Most datacenter architecture doesn't require GPU. Nvidia could market with a kick-ass Oracle-like engineered solution for high-performance compute, game hosting or AI. But I don't think Oracle moved the needle in how we buy database compute, and I doubt Nvidia would do so here.