I actually looked at this in detail about a year ago for some automated driving compute work at my previous job, and I found that the detailed info you'd want from Nvidia was just 100% unavailable. There's pretty good proxies in some of the data you can get out of Nvidia tools, and there's some extra info you can glean from some of the function call stack in the open source Nvidia driver shim layer (because the actual main components are still binary blob, even with the "open source" driver), but over all you still can't get much useful info out.<p>Now that Brendan works for Intel, he can get a lot of this info from the much more open source Intel GPU driver, but that's only so useful since everyone is either Nvidia or AMD still. The more hopeful sign is that a lot of the major customers of Nvidia are going to start demanding this sort of access and there's a real chance that AMD's more accessible driver starts documenting what to actually look at, which will create the market competition to fill this space. In the meantime, take a look at the flamegraph capabilities in PyTorch and similar frameworks, up an abstraction level and eek what performance you can.
> Imagine halving the resource costs of AI and what that could mean for the planet and the industry -- based on extreme estimates such savings could reduce the total US power usage by over 10% by 20301.<p>Why would it be the case that reducing the costs of AI reduces power consumption as opposed to increase AI usage (or another application using electricity)? I would think with cheaper AI their usage would be come more ubiquitous: LLMs in fridges, toasters, smart alarms, etc.
> Imagine halving the resource costs of AI and what that could mean for the planet and the industry<p>Google has done this:
"In eighteen months, we reduced costs by more than 90% for these queries through hardware, engineering, and technical breakthroughs, while doubling the size of our custom Gemini model." <a href="https://blog.google/inside-google/message-ceo/alphabet-earnings-q3-2024/" rel="nofollow">https://blog.google/inside-google/message-ceo/alphabet-earni...</a>
Being able to ‘connect’ call stacks between python, c++, and the gpu/accelerator seems useful.<p>I wonder if this pushes a bit much towards flamegraphs specifically. They were an innovation when they were first invented and the alternatives were things like perf report, but now I think they’re more one tool among many. In particular, I think many people who are serious about performance often reach for things like pprof for statistical profiles and various traceing and trace-visualisation tools for more fine-grained information (things like bpftrace, systemtap, or custom instrumentation on the recording side and perfetto or the many game-development oriented tools on the visualisation (and sometimes instrumentation) side).<p>I was particularly surprised by the statement about intel’s engineers not knowing what to do with the flamegraphs. I read it as them already having tools that are better suited to their particular needs, because I think the alternative has to be that they are incompetent or, at best, not thinking about performance at all.<p>Lots of performance measuring on Linux is done through the perf subsystem and Intel have made a lot of contributions to make it good. Similarly, Intel have added hardware features that are useful for measuring and improving performance – an area where their chips have features that, at least on chips I’ve used, easily beat AMD’s offerings. This kind of plumbing is important and useful, and I guess the flamegraphs demonstrate that the plumbing was done.
> based on Intel EU stall profiling for hardware profiling<p>It wasn't clearly defined but I think EU stall means Execution Unit stall which is when a GPU "becomes stalled when all of its threads are waiting for results from fixed function units" <a href="https://www.intel.com/content/www/us/en/docs/gpa/user-guide/2022-4/gpu-metrics.html" rel="nofollow">https://www.intel.com/content/www/us/en/docs/gpa/user-guide/...</a>
I've tried using flame graphs, but in my view nothing beats the simplicity and succinctness of gprof output for quickly analyzing program bottlenecks.<p><a href="https://ftp.gnu.org/old-gnu/Manuals/gprof-2.9.1/html_chapter/gprof_5.html#SEC12" rel="nofollow">https://ftp.gnu.org/old-gnu/Manuals/gprof-2.9.1/html_chapter...</a><p>For each function you know how much CPU is spent in the function itself, as opposed to child calls. All in a simple text file without the need for constantly scrolling, panning, and enlarging to get the information you need.
This is so cool! Flame graphs are super helpful for analyzing bottlenecks. The eflambe library for elixir has let us catch some tricky issues.<p><a href="https://github.com/Stratus3D/eflambe/blob/master/README.adoc">https://github.com/Stratus3D/eflambe/blob/master/README.adoc</a>
I never really liked flamegraphs much but I am going to put that aside for a bit and try to be as objective as possible.<p>I don't find the usecase presented here compelling. Cutting out the "yo we will save you $x billion in compute" costs the tools presented here seem to be…stacktraces for your kernels. Stacktraces that go from your Python code through the driver shim to the kernel and finally onto the GPU. Neat. I don't actually know very much about what Intel has in this area so perhaps this is a step forward for them? If so, I will always applaud people figuring out how to piece together symbols and whatnot to make profiling work.<p>However, I am still not very impressed. Sure, there are some workloads where it is nice to know that 70% of your time is spent in some GEMM. But I think the real optimization doesn't look like that all. For most "real" workloads, you already know the basics of how your kernels look and execute. Nobody is burning a million dollars an hour on a training run without knowing what each and every one of the important kernels are. Some of them were probably written by hand. Some might be written in higher-level PyTorch/Triton/JAX/whatever. Still others might be built on some general library. But the people who do this are not stupid, and they aren't going to be caught unawares that a random kernel has suddenly popped up on their flamegraph. They should already know what is there. And most of these tools have debugging facilities to dump intermediate state in forms that tools understand. Often this is incomplete and buggy, I know. But it's there and people <i>do</i> use them.<p>What these people are optimizing are things that flamegraphs do not show. That's things like latency in kernel launches, or synchronization overhead with the host. It's global memory traffic and warp stalls. Sure, the tools to profile this are immature compared to what the hyperscalers have for CPUs. But they are still present and used heavily: I don't buy the argument that knowing that your python code calls a kernel through __cuda12_ioctl_whatever is actually helpful. This seems like a solution searching for a problem, or maybe a basic diagnostic tool at best.
> Imagine halving the resource costs of AI and what that could mean for the planet and the industry -- based on extreme estimates such savings could reduce the total US power usage by over 10% by 2030<p>The way this is phrased threw me off. It sounded to me like the author was comparing the power use of a more efficient LLM industry to US usage <i>without</i> LLMs and expecting it to be 10% lower.<p>Looking into the source linked with the claim, it doesn't even hold up when compared against how much power LLMs use today. The linked article raises an estimate that LLM power use could increase 15-23 times between 2023 and 2027, and that by 2030 LLMs could account for 20-25% of our total energy use.<p>Working that match backwards, the benefit the author is hailing as a success is that we would <i>only</i> increase energy use by say 7.5-11.5 times by 2027 and that in 2030 LLMs would <i>only</i> be 10% of the total energy use. That's not a win in my book, and doesn't account for the Jevan's Paradox problem where we would almost certainly just use all that efficiency gain to further grow LLM use compared to the 2030 prediction without the efficiency gains.
> Imagine halving the resource costs of AI ... based on extreme estimates such savings could reduce the total US power usage by over 10% by 2030<p>Is that implying that by 2030 they expect at least 20% of all US energy to be used by AI?
This is super interesting and useful. I tried reading the code to understand how GPU workloads worked last year and it was easy to get lost in all the options and pluggable layers.
I do not really understand the mentioned difficulties with instruction profiling.<p>Are they saying it is hard to sample the stacks across the boundary? Are they saying it is hard to do so coherently because the accelerator engine is actually asynchronous so you need to do some sort of cross-boundary correlation?<p>However, they then talk about file systems and /proc representations which have nothing to do with the actual sampling process; only posing problems for the display of human-readable information. Many naive profiling, tracing, and logging implementations conflate these actions to their detriment; are they being conflated here or is it just a generic statement of the scope of problems?
Trying to find out more about this EU stall thing Brendan talks about. Is it instruction sampling that gives you the reason for the stall? Sounds like a pretty advanced hw functionality.
Would love it if it was available and open source so people could use it in their own projects (or on their own hardware), instead of only being available on Intel's AI Cloud. But cool idea and execution nevertheless!
i am actually working on a platform that makes this sort of stuff easy. We use BPF under the hood and let you remotely deploy them across a cluster and visualize them.<p>Check us out: <a href="https://yeet.cx" rel="nofollow">https://yeet.cx</a><p>Our current package index is a bit thin:<p><a href="https://yeet.cx/discover" rel="nofollow">https://yeet.cx/discover</a><p>We have a ton in the pipeline and are going to add more in the coming weeks and release an SDK.
Unrelated, but on the topic of reducing power consumption, I want to once again note that both AMD and NVidia max out a CPU core per blocking API call, preventing your CPU from entering low power states even when doing nothing but waiting on the GPU, for no reason other than to minimally rice benchmarks.<p>Basically, these APIs are set up to busyspin while waiting for a bus write from the GPU by default (!), rather than use interrupts like every other hardware device on your system.<p>You turn it off with<p>NVidia: `cudaSetDeviceFlags(cudaDeviceScheduleBlockingSync)`<p>AMD: `hipSetDeviceFlags(hipDeviceScheduleBlockingSync)`<p>On Pytorch<p>NVidia: `import ctypes \ ctypes.CDLL('libcudart.so').cudaSetDeviceFlags(4)`<p>AMD: `import ctypes \ ctypes.CDLL('libamdhip64.so').hipSetDeviceFlags(4)`<p>This saves me 20W whenever my GPU is busy in ComfyUI.<p>Every single device using the default settings for CUDA/ROCM burns a CPU core per worker thread for no reason.
There has been a bit of hyperbole of late about energy saving AI.<p>There isn't a magic bullet here, it's just people improving a relatively new technology. Even though the underlying neural nets are fairly old now, the newness of transformers and the newness of the massive scale means there's quite a lot of low hanging fruit still. Some of the best minds are on this problem and are reaching for the hardest to get fruit.<p>A lot of these advancements work well together improving efficiency a few percent here, a few percent there.<p>This is a good thing, but people are doing crazy comparisons by extrapolating older tech into future use cases.<p>This is like estimating the impact of cars by correctly guessing that there are 1.4 Billion cars in the world and multiplying that by the impact of a single model-T Ford.