11–20 of 22 posts
https://theartofhpc.com/ Great book series on the subject of HPC. Not sure if it actually touches GPU. Great material anyway. BONUS: it's free!
Newer editions of Computer Organization and Design: The Hardware Software Interface covers GPUs [1] Multiflow still has some relevant ideas [2] Programming on Parallel Machines: GPU, Multicore, Clusters and More. Gives you a look at some of the issues [3] SPIRV-VM is a virtual machine for executing SPIR-V shaders [4] NyuziRaster: Optimizing Rasterizer Performance and Energy in the Nyuzi Open Source GPU [5] Ocelot is…
Newer editions of Computer Organization and Design: The Hardware Software Interface covers GPUs [1] Multiflow still has some relevant ideas [2] Programming on Parallel Machines: GPU, Multicore, Clusters and More. Gives you a look at some of the issues [3] SPIRV-VM is a virtual machine for executing SPIR-V shaders [4] NyuziRaster: Optimizing Rasterizer Performance and Energy in the Nyuzi Open Source GPU [5] Ocelot is…
wow, Thanks! Some super interesting resources, some that I haven't even heard of.
A major problem I had was register pressure. Even with a decent sized register file. Memory accesses in the hundred of cycles range, made it very difficult to fill those 'free' cycles while you are waiting for data to be loaded. Double buffering data really just cut the effective size of the register file making everything worse. That did lead to some interesting way of optimising code to reduce temp storage over execution time.
Another was trying to access different memory locations and getting poor usage of the cache. Giving larger gaps to try and fill with something useful.
This was sometime ago now. So the tradeoffs will be different. Different types of RAM and transistor budgets
Here is a Phd thesis for a GPU programming language that compiles on the gpu itself: https://scholarworks.iu.edu/dspace/items/3ab772c9-92c9-4f59-...
This work describes a general, scalable method for building data-parallel by construction tree transformations that exhibit simplicity, directness of expression, and high-performance on both CPU and GPU architectures when executed on either interpreted or compiled platforms across a wide range of data sizes, as exemplified and expounded by the exposition of a complete compiler for a lexically scoped, functionally oriented programming commercial language. The entire source code to the compiler written in this method requires only 17 lines of simple code compared to roughly 1000 lines of equivalent code in the domain-specific compiler construction framework, Nanopass, and requires no domain specific techniques, libraries, or infrastructure support. It requires no sophisticated abstraction barriers to retain its concision and simplicity of form. The execution performance of the compiler scales along multiple dimensions: it consistently outperforms the equivalent traditional compiler by orders of magnitude in memory usage and run time at all data sizes and achieves this performance on both interpreted and compiled platforms across CPU and GPU hardware using a single source code for both architectures and no hardware-specific annotations or code. It does not use any novel domain-specific inventions of technique or process, nor does it use any sophisticated language or platform support. Indeed, the source does not utilize branching, conditionals, if statements, pattern matching, ADTs, recursions, explicit looping, or other non-trivial control or dispatch, nor any specialized data models.
Here is a Phd thesis for a GPU programming language that compiles on the gpu itself: https://scholarworks.iu.edu/dspace/items/3ab772c9-92c9-4f59-...
That undersells it IMHO. Here's the abstract: This work describes a general, scalable method for building data-parallel by construction tree transformations that exhibit simplicity, directness of expression, and high-performance on both CPU and GPU architectures when executed on either interpreted or compiled platforms across a wide range of data sizes, as exemplified and expounded by the exposition of a complete com…
Some of the stuff in this playlist might be relevant to you, though it is mostly about programming GPUs in a functional language that compiles to Cuda. The author (me) sometimes works on the language during the video, either fixing bugs or adding new features.
This makes a rather spectacular mess of the tooling. Instead of localising the cuda semantics in clang, we scatter it throughout the entire compiler pipeline, where it does especially nasty things to register allocation and generally obstructs non-cuda programming models. It's remarkably difficult to persuade GPU people that this is a bad thing.
Also the GPU programming languages use very large compiler runtimes to do a degree of papering over the CPU-host GPU-target assumption that also dates from long ago, so expect to find a lot of complexity in multiple libraries acting somewhat like compiler-rt. Those are optional in reality but the compiler usually emits a lot of symbols that resolve to various vendor libraries.
Faith Ekstrand has an impressive track record of compiler work and has written a few blog posts[1], [1a]. Her Mastodon[2] is also worth a follow. SPIR-V is important in the compute shader space, especially because DXIL and Metal's AIR are similar. I'm going to link three articles critical of SPIR-V: [3], [4], [5]. WebGPU [6] is interesting for a number of reasons, largely because they're trying to actually nail down…
There's increasing danger of non-freestanding C++ working too as the libc++ port improves. Some fraction of libc is there already.