Live data from Hacker News

Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

blogs.nvidia.com

131–140 of 347 posts

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#132
post #21

For those in the industry: When a new generation like this is released, will a typical AI company replace the current GPUs? Is there a chance to acquire the older versions for private use or is it too early for that?

A fun quick of GPU pricing economics is that on Google Cloud platform, the relatively recent T4 (on Turing and has FP16 support) is cheaper than the ancient K80s. https://cloud.google.com/compute/gpus-pricing

That's not a great comparison at all though. The K80 is a general purpose chip while the T4 is explicitly marketed as an inference chip. The K80 has more ram (super important for batch sizes during training), can access that ram faster (480 GB/s versus 320 GB/s), and is an overall more powerful chip than the T4 is.

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#133
post #38

> DGX-A100 - The First HPC System With 140 Peta-OPs Compute Shipping Now For $199,000 Crazy pricing for a chip that basically started as a game solution. Anybody actually seen these Nvidia DGX systems in the wild?

Yup- they're cheaper than renting from AWS.

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#134
post #93
post #31

Earlier quoted context omitted.

It's irrelevant to researchers. Research operates on rapid cycles: prototype, publish, move on. It does impact businesses. It doesn't prevent adoption for e.g. deep learning, but I haven't seen e.g. GPU-based databases reach broad adoption, or many other places where MIMD/SIMD would reduce costs or improve performance. Using classical hardware is clearly cheaper than the business risk and engineering time of relying…

NVidia is not to blame if the competition is stuck using C, printf debugging for computing shaders, cannot make their minds about which bytecode to support for heterogenous GPGPU programming. The situation is so bad that OpenCL 1.2 got promoted to OpenCL 3.0 and SYSCL is now backend independent, while hip only works on Linux. As for Python, guess who is on the forefront of GPU Programming with Python, https://www.nvi…

> NVidia is not to blame if the competition is stuck using C, printf debugging for computing shaders, cannot make their minds about which bytecode to support for heterogenous GPGPU programming.

I don't bite this argument.

Nvidia made close to no effort to support OpenCL and promoted their own technology CUDA. Even in 2020, OpenCL support for Nvidia hardware is close to nonexistent.

When the main actor of the market does not support a technology, why the hell would you use it or even develop its ecosystem (SYSCL)

> The situation is so bad that OpenCL 1.2 got promoted to OpenCL 3.0 and SYSCL is now backend independent.

OpenCL 3.0, presented by an Nvidia official(https://khr.io/ocl3slidedeck), head of the working group on it. A company that made close to 0 effort to support OpenCL 2.0 revert the spec to 1.2. Astonishing right ?

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#135
post #120
post #55

Earlier quoted context omitted.

GPU based databases haven't reached broad adoption because sending things over the PCIe link is a huge waste of time if you can avoid it. Working around this with custom design like NVLink/NVSwitch do is ridiculously expensive (and why a DGX costs a gajillion dollars), and there is simply not enough volume to subsidize it. They are largely analytics focused, because the parallel hardware can obviously map onto primit…

I don't underestimate the complexity. But I do claim that the complexity can and should be hidden behind programming language constructs. I've worked both on the design of MIMD hardware, back when I was a graduate student, and on programming languages. These aren't easy problems, but they are solvable. The reason for openness isn't abstract. I don't think NVidia will solve these problems alone. NVidia can make really…

I'm not making a claim about the necessity of experimentation. I spent years (and working a paid job) doing programming language work, and also design hardware these days in my spare time, so I'm not against that. I'm specifically addressing the claim that "GPU databases haven't taken off because of lack of open source CUDA" or whatnot. Database tech is one of the most R&D heavy engineering subfields, almost all major innovations come from it. The points I made up are not coming from thin air, they're the result of people (engineers) doing a lot of experimentation and coming to similar conclusions for many years. You don't need open source designs to prove this, by the way, you only need to do basic napkin math about the characteristics of the system, and how data moves around, to come to similar conclusions. You need a correct (and I hate this word) synergy of hardware, software, and programming model to do it. A programming language, a new model, does not change the theoretical bandwidth of PCIe 3.0, or the fact you have a memory hierarchy to optimize for best performance. Just having one and none of the others, or having lopsided characteristics, isn't sufficient, and innovations across the stack are one of the major things people are reaching for, in order to differentiate themselves.

That said, I agree and would love to see less crappy programming models here. As a PL geek, I have numerous reasons why I think that's necessary. It really needs to be easier to compose sets of small languages, and design them -- one for designing streaming systems, one for latency sensitive ones. They need to model the memory hierarchy available to us (a huge thing most do not do, and vital to system performance.) I'd love this. But it doesn't undermine anything I said earlier about why things are the way they are, today. No amount of fancy programming languages is going to change the fact a $10,000 Supermicro server is more cost effective than $70,000 worth of V100s for 90% of OLAP workloads you'd want a database for. Engineers design accordingly.

There is also the problem of needing huge amounts of capital, where most of this work can only be done by exceedingly well funded groups with deep ties to hardware divisions in question. The future of hardware innovation comes from billion dollar companies, because only they can sustain it, not plucky engineers. Sure, for us, CUDA being open source would be awesome. But you don't really need open source drivers when you're working directly with the vendor on your requirements and you pay them millions for support and you just use Linux for everything. You just let them solve it and move on. The engineering world is designed this way (both by engineers, and by capitalists), because it is how we make money from it in a capitalist society!

> I would argue NVidia underestimates both the potential and the complexity if they think they can go it (relatively) alone, come up with the right programming constructs, and provide the right set of tools for programmers to consume.

Nope. Nvidia understands that they alone may not hit a global optimum or whatever in all these fields. I suspect given that they have entire divisions of highly skilled engineers dedicated to programming tools -- they understand it better than either of us. But what they also understand is that their software stack is a differentiator for them, because it actually works (the competitors don't) and it makes them money to keep it that way. You're confusing a technical problem with one of politics and vision -- a categorical mistake about their priorities and where they lie. I don't want to sound crass, but people saying "I would argue that I, the sole, lone gun engineer, understand their business and future and everything way better than they do" is typical of engineers, and it is almost always a categorical mistake to think so.

Nvidia fully understands that maybe some nebulous benefit might come to them by open sourcing things, maybe years down the line. They understand plucky researchers can do amazing things, sometimes. But they understand much better that keeping it closed makes them money and keeps them distinct from their competitors in the short term. If you think this is a contradiction, or seemingly short sighted: don't worry, because you are correct, it is. What is more "surprising" is recognizing that all of capitalist society is built on these sorts of contradictions. I'm afraid we're all going to have to get used to waiting for FOSS nvidia drivers/CUDA.

EDIT: I'll also say that if this changes from their "major open source announcement" they were going to do at GTC, I'll eat my hat. I'm not expecting much from Nvidia in terms of open source, but I'd happily be proven wrong. But broadly I think my general point stands, which is that thinking about it from the POV of "open source drivers are the limitation" isn't really the right way to think about it.

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#136

Nvidia is one of the major GPU suppliers (as well as AMD and others) as there are more compute needs in autonomous vehicles, robotics, etc. For future demand, will there be more increases in demand for CPU's (or decrease here in favor of GPU's), GPU's or some development other favorable processing unit? Google had TPU's mentioned a few years back as one example. So curious to know what market segments would likely in…

For dedicated neural network use cases like vehicles, robots, and datacenters, dedicated accelerator chips are going to be huge. Tesla's been shipping custom silicon for a while, I'd be surprised if Waymo cars didn't have a TPU in them, and there's like a dozen companies making AI accelerators but as far as I know, none of them are for sale yet.

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#137
post #23

Earlier quoted context omitted.

Yeah. That's been my general problem with adopting NVidia for anything. They make good hardware, but there's a lot of lock-in, and not a lot of transparency. That introduces business risk. I'm not in a position where I need GPGPU, but if there wasn't that risk, and generally there were mature, open standards, I'd definitely use it. The major breakpoint would be when libraries like Numpy do it natively, and better yet…

> They make good hardware, but there's a lot of lock-in, and not a lot of transparency. This sounds like you'd like NVIDIA to open-source all their software. I see this type of request a lot, but I don't see it happening. NVIDIA's main competitive advantage over AMD and Intel is its software stack. AMD could release a 2x powerful GPGPU tomorrow for half the price and most current NVIDIA users wouldn't care because wh…

People who are into RISC-V and other side projects/open stacks obviously have not worked on mission critical problems.

When you have a Jet engine hoisted up for a test rig, and something fails in your DSP library, you don't hesitate to call Matlab engineering support to help on within next 30 mins. Try that with some python library. People give a lot of flak to Matlab for being closed source but there is a reason they exist. Not for building a stupid toy project, but for real things where big $$$ is on the line. Python is also used in production everywhere, but if your application is a niche one and using PyVISA library to connect to some DSP hardware that you git cloned is not very "production" ready. You need solid deps.

Don't get me wrong - open source software runs in prod all the time - PostgreSQL/Linux, etc. The smaller the application domain (specific DSP libraries or analysis stacks for wind turbines and such), the lower the availability of high quality open source software (and support).

My point is that reality hits you hard when it is anything where a lot of $$$ or people's time depend on it. Don't blame their engineers for using closed source tools.

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#138
post #128

Earlier quoted context omitted.

Well considering they are filing for bankruptcy you are going to be waiting a while...

Speaking of vapor, still waiting for rex computing to ship...

Me too; sadly we had silicon that ran great (We had better performance per watt for FP32 and FP64 on 28nm process vs the A100's 7nm GFLOPs/watt) but targeting a market that had 3 customers that didn't want to work with a startup, plus investors that were opposed to us going into the "risky" and "unproven" AI space. Still have 183 of the chips in my closet waiting to see the light of day :/

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#139

Nvidia is one of the major GPU suppliers (as well as AMD and others) as there are more compute needs in autonomous vehicles, robotics, etc. For future demand, will there be more increases in demand for CPU's (or decrease here in favor of GPU's), GPU's or some development other favorable processing unit? Google had TPU's mentioned a few years back as one example. So curious to know what market segments would likely in…

In general computing, FPGAs will likely see a rise in popularity (latest mac pro offers an FPGA card as an option). In task specific computing, GPUs and ASICs will likely lead.

Tesla replaced their Nvidia GPUs over a year ago with a custom chip (I believe they hired a chip designer away from Apple to develop their own silicon).

Re: Nvidia CEO Introduces Nvidia Ampere Architecture, Nvidia A100 GPU

#140
post #120
post #55

Earlier quoted context omitted.

GPU based databases haven't reached broad adoption because sending things over the PCIe link is a huge waste of time if you can avoid it. Working around this with custom design like NVLink/NVSwitch do is ridiculously expensive (and why a DGX costs a gajillion dollars), and there is simply not enough volume to subsidize it. They are largely analytics focused, because the parallel hardware can obviously map onto primit…

I don't underestimate the complexity. But I do claim that the complexity can and should be hidden behind programming language constructs. I've worked both on the design of MIMD hardware, back when I was a graduate student, and on programming languages. These aren't easy problems, but they are solvable. The reason for openness isn't abstract. I don't think NVidia will solve these problems alone. NVidia can make really…

Except there is a community, a CUDA community and from GTC sessions, a very big one.

Ironically this walled garden as you put it, has produced more programming languages and tooling for GPGPU programming than the open conglomerate design by committee from Khronos has been able to achieve together against a single company, which kept pushing their C mantra until it was too late.

Post reply on HN