4 ms·
Nvidia’s success is due to a decade+ of investment into their software stack (CUDA and friends), built on a world view that more software can and should be mass
by kiratp 2y ago
Nvidia’s success is due to a decade+ of investment into their software stack (CUDA and friends), built on a world view that more software can and should be massively parallel.
They were a key cause for LLMs being a thing in the first place.
- BobbyJo 2y agoThis. I worked in HPC between 2010 and 2013, and people were trying to compete with NVidia in the GPGPU space even back then, seeing the way the wind was blowing. Compute bandwidth, and FLOPS/watt has steadily been more and more important the last 15 years, even before AI. NVidia has continued to stay ahead because every alternative to CUDA is half baked trash, even when the silicone make sense. As a tech company, trading $$ for time not spent dealing with compatibility bugs and broken drivers pretty much always makes business sense.
- otabdeveloper4 2y ago> half baked trash > dealing with compatibility bugs > broken drivers Describes my experience trying to use CUDA perfectly. We have a long way to go and we haven't even started yet.
- initplus 2y agoGiven that experience, think about what state the alternatives must be in!
- disgruntledphd2 2y agoTo be fair, Cuda has improved a lot since 2014 or so. I messed up my Linux box multiple times trying to install Cuda but the last time it was just apt install and maybe setting ld library and it all just worked.
- yieldcrv 2y agoIt’s pretty bad. just when you think you can order AMD chips since there is no shortage, and use a translation layer and have a cheap AI datacenter, it turns out AMD is fumbling the ball at every step of the way
- bottled_poe 2y agoIt’s interesting. They have had plenty of time and resources available to mount solid competition. Why haven’t they? Is it a talent hiring problems or some more fundamental problem with their engineering processes? The writing has been on the wall for gpgpu for more than 10 years. Definitely enough time to catch up.
- BobbyJo 2y agoIts a commitment problem IMO. NVidia stuck with CUDA for a long time before it started paying them what it cost. AMD and Intel have both launched and killed initiatives a couple times each, but abandon them within a few years because adoption didn't happen overnight. If you need people to abandon an ecosystem thats been developed steadily over nearly 20 years for your shiny new thing in order to keep it around, you'll never compete.
- the__alchemist 2y agoHave you tried Vulkan Compute or OpenCL? I recommend evaluating this relatively, vice compared to an ideal.
- neurostimulant 2y agoWasn't Intel's commercial compiler also dominated HPC space around that time period? I remember back then people would use cuda and icc for hpc stuff.
- rbanffy 2y agoI believe their compilers still dominate in CPU-bound workloads.
- knappe 2y agoI can't speak to modern hpc, since I've been out of the game for a few years but icc was absolutely the preferred compiler for almost any workload and Intel procs were the desired hardware to run on. AMD was joked about as the only reason Intel wasn't considered a monopoly at the time and that Intel would happily take wheelbarrows of cash over to AMD to prop them up, just to ensure they didn't even appear like a monopoly. But no one in the field was buying AMD procs for their workloads.
- BobbyJo 2y agoMost super computers were still Intel/IBM, but around that time is when the shift to GPU clusters started. #1 super computer spot was taken by an Nvidia cluster in 2012, but I remember other big projects were done before as well.
- ghaff 2y agoNvidia did a lot of things right. But it sure didn't hurt that the crypto bubble gave way to LLMs with almost perfect timing. Luck favors the prepared and all that but Nvidia also would have had trouble timing market changes better.
- toasterlovin 2y agoYeah, exactly, it has never been clear that we would find a use for parallel computation outside of niches like graphics and HPC. And in fact most of the history of computing has been evidence of the opposite: useful computation has been predominantly serial in nature. But here we are now.
- FredPret 2y agoNvidia did ride a perfect storm of gaming + bitcoin + AI. But AMD and others could have done the same, had they been better at riding that wave. There’s a reason it was Nvidia who won out.
- llm_trw 2y agoMore than a decade. I was using it as soon as it came out in 2007 and my dinky desktop workstation was out performing the main frame in the basement.
- mullingitover 2y ago> a world view that more software can and should be massively parallel. Twenty years ago I was thinking we'd be speccing machines in kilocores by now.
- epcoa 2y agohttps://en.wikipedia.org/wiki/Connection_Machine https://en.wikipedia.org/wiki/Connection_Machine
- otabdeveloper4 2y ago128 and 512 cores are normal now, so not that far off.
- Keyframe 2y ago4090 has 16384 cuda cores, so there's that!
- atq2119 2y agoNvidia's marketing is misleading. Those "cuda cores" are more SIMD lanes than cores. Number of SMs is a more appropriate equivalent to CPU core count.
- Keyframe 2y agoyou're right
- dahart 2y agoAre you sure that isn’t what @mullingitover meant? > Number of SMs is a more appropriate equivalent to CPU core count. What do you mean by this? Why should an SM be considered equivalent to a CPU core? An SM can do 128 simultaneous adds and/or multiplies in a single cycle, where a CPU core can do, what, 2 or maybe 4? Obviously depends on the CPU / core / hyperthreading / # math pipelines / etc., but the SM to CPU-core ratio of the number of simultaneous calculation is in the double digits. It’s a tradeoff where the GPU has some restrictions in return for being able to do many multiples more at the same time. If you consider an SM and a CPU equivalent, then the SM’s perf can exceed the CPU core by ~2 orders of magnitude — is that the comparison you want? If you consider a GPU thread lane and a CPU thread lane equivalent, the the GPU thread lane is slower and more restricted. Neither comparison is apples to apples, CPUs and GPUs are made for different workloads, but arguing that an SM is equivalent to a CPU core seems equally or more “misleading” when you’re leaving out the tradeoff. I’d argue that comparing SMs to cores is misleading and that it makes more sense to compare chips is by their thread counts. Or, don’t compare cores at all and just look at the performance in, say, FLOPS.
- seanhunter 2y ago100%. If you ever tried to build pytorch (or tensorflow) gpu accellerated using NVidia vs AMD it was absolutely chalk and cheese for the longest time. Nvidia/CUDA process: Download package. Run the build. It works. Run your thing- it's GPU accelerated. Go get a beer/coffee/whatever while your net runs. AMD process: Download package. Run the build. Debug failure. Read lots of articles about which patches to apply. Apply the patches. Run the build. It fails again. Shit. OK ok now I know what to do. I need a special fork of the package. go get that. Find it doesn't actually have the same API that the latest pytorch/tf relies on. OK downgrade those to an earlier version. OK now we're good. Run the build again. Aw shit. That failed again. More web searches. Oh ok now I know - there's some other patches you need to apply to this branch. OK cool. Now it compiles. Install the package. Run the thing. Huh. That's weird. GPU accelleration isn't on.... sigh....