Live data from Hacker News

The art of high performance computing

theartofhpc.com

51–60 of 125 posts

Re: The art of high performance computing

#51
post #22
post #6

It's very interesting how abtracted away HPC sometimes looks from hardware. The books seem to revolve a lot around SPMD programming, algo & DS, task parallelism, synchronization etc, but very little about computer architecture details like supercomputer memory subsystems, high-bandwidth interconnects like CXL, GPU architecture and so on. Are the abstractions and tooling already good enough that you don't need to worr…

There is a lot of abstraction, but knowing which abstraction to use still takes knowing a lot about the hardware. > I’m also curious if HPC practitioners have to fiddle a lot of black-box knobs to squeeze out performance? In my experience with CUDA developers, yes the Shmoo Plot ( https://en.wikipedia.org/wiki/Shmoo_plot , sometimes called a ‘wedge’ in some industries) is one of the workhorses of every day optimizati…

Could you explain how you use a shmoo plot for optimization? Do you just have a performance metric at each point in parameter space?

Re: The art of high performance computing

#52
I'm interested in what people think of the approach to teaching C++ used here. Any particular drawbacks?

I'm a very experienced Python programmer with some C, C++ and CUDA doing application level research in HPC environments (ML/DL). I'd really like to level up my C++ skills and looking through book 3 it seems aimed exactly at the right level for me - doesn't move too slowly and teaches best practices (per the author) rather than trying to be comprehensive.

Re: The art of high performance computing

#53
post #6

It's very interesting how abtracted away HPC sometimes looks from hardware. The books seem to revolve a lot around SPMD programming, algo & DS, task parallelism, synchronization etc, but very little about computer architecture details like supercomputer memory subsystems, high-bandwidth interconnects like CXL, GPU architecture and so on. Are the abstractions and tooling already good enough that you don't need to worr…

HPC admin here, generally serving "long tail of science" researchers.

In today's x86_64 hardware, there's no "supercomputer memory subsystem". It's just a glorified NUMA system, and the biggest problem is putting the memory close to your core, i.e. keeping data local in your NUMA node to reduce latencies.

Your resource mapping is handled by your scheduler. It knows your hardware, hence it creates a cgroup which satisfies your needs and as optimized as possible, and stuffs your application into that cgroup and runs it.

Currently king of high performance interconnects is Infiniband, and it accelerates MPI at the fabric level. You can send messages, broadcasts and reduce results like there's no tomorrow. Because when the message arrives you, it's already reduced. When you broadcast, you only send a single message which is broadcasted at fabric layer. Multiple Context IB cards have many queues and more than one MPI job can run on the same node/card with queue/context isolation.

If you're using a framework for GPU work, the architecture & optimization is done at that level automatically (the framework developers do the hard work generally). NVIDIA's drivers are pure black magic, too. They handle some parts of the optimization, too. InterGPU connection is handled by a physical fabric, managed by drivers and its own daemon.

If you're CPU bound, your libraries are generally hand tuned by its vendor (Intel MKL, BLAS, Eigen, etc.). I personally used Eigen, and it has processor specific hints and optimizations baked in.

The things you have to worry is to compile your code for the correct architecture, make sure that the hardware you run on can satisfy your demands (i.e.: do not make too many random memory accesses, keep the prefetcher and branch predictor happy if you're trying to go "all-out fast" on the node, do not abuse disk access, etc.).

On the number crunching side, keeping things independent (so they can be instruction level parallelized/vectorized), making sure you're not doing unnecessary calculations, and not abusing MPI (reducing inter-node talk to only necessary chatter) is the key.

It's way easier said than done, but when you get the hang of it, it becomes like a second nature to think about these things, if these kinds of things are your cup of tea.

Re: The art of high performance computing

#54
post #48

The hardware / datacenter side of this is equally fascinating. I used to work in AWS, but on the software / services side of things. But now and then, we would crash some talks from the datacenter folks. One key relevation for me was that increasing compute power in DCs is primarily a thermodynamics problem than actual computing. The nodes have become so dense that shipping power in and shipping heat out, with all ki…

Seymour Cray used to say this all the way back in the 1970s: his biggest problems were associated with dissipating heat. For the Cray 2 he took an even more dramatic approach: "The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™" (https://www.computerhistory.org/revolution/supercomputers/10...)

Re: The art of high performance computing

#55
post #6

It's very interesting how abtracted away HPC sometimes looks from hardware. The books seem to revolve a lot around SPMD programming, algo & DS, task parallelism, synchronization etc, but very little about computer architecture details like supercomputer memory subsystems, high-bandwidth interconnects like CXL, GPU architecture and so on. Are the abstractions and tooling already good enough that you don't need to worr…

I wrote scientific simulation software in academia for a few years. None of us writing the software had any formal software engineering training above what we’d pieced together ourselves from statistics courses. We wrote our simulations to run independently on many nodes and aggregated the results at the end, no use of any HPC features other than “run these 100 scripts on a node each please, thank you slurm”. That approach worked very well for our problem.

I’d bet a significant part of compute work on HPC clusters in academia works the same way. The only thing we paid attention to was number of cores on the node and preferring node local storage over the shared volumes for caching. No MPI.

There are of course problems requiring “genuine” HPC clusters but ours could have run on any pile of workers with a job queue.

Re: The art of high performance computing

#56
post #48

The hardware / datacenter side of this is equally fascinating. I used to work in AWS, but on the software / services side of things. But now and then, we would crash some talks from the datacenter folks. One key relevation for me was that increasing compute power in DCs is primarily a thermodynamics problem than actual computing. The nodes have become so dense that shipping power in and shipping heat out, with all ki…

It always made me wonder why liquid cooling wasn't more of a thing for datacenters.

Water has a massive amount of thermal capacity and can quickly and in bulk be cooled to optimal temperatures. You'd probably still need fans and AC to dissipate heat of non-liquid cooled parts, but for the big energy items like CPUs and GPUs/compute engines, you could ship out huge amounts of heat fairly quickly and directly.

I guess the complexity and risk of a leak would be a problem, but for amazon sized data centers that doesn't seem like a major concern.

Re: The art of high performance computing

#57

Earlier quoted context omitted.

aren't the lapack people in tennessee?

Sort of like BLAS, LAPACK is more than just one implementation. Dongarra described what everybody should do from Tennesse, but other places implemented it elsewhere.

plasma and magma are also from there.

I'm not aware of any other significant lapack-related developments, but I might just not know about them.

Re: The art of high performance computing

#58
post #22

Earlier quoted context omitted.

There is a lot of abstraction, but knowing which abstraction to use still takes knowing a lot about the hardware. > I’m also curious if HPC practitioners have to fiddle a lot of black-box knobs to squeeze out performance? In my experience with CUDA developers, yes the Shmoo Plot ( https://en.wikipedia.org/wiki/Shmoo_plot , sometimes called a ‘wedge’ in some industries) is one of the workhorses of every day optimizati…

Could you explain how you use a shmoo plot for optimization? Do you just have a performance metric at each point in parameter space?

The shmoo plot is just the name for measuring something (such as perf) over a range of parameter space. The simplest and most straightforward application is to pick a parameter or two that you don’t know what value they should be using, do the shmoo over the range of parameter space, and then set the knobs at whatever values give you the optimal measurement.

Usually though, you have to iterate. Doing shmoos along the way can help with understanding the effects of code changes, help understand how the hardware works, and it can sometimes help identify what code changes you might need to make. A simple abstract example might be I know what my theoretical peak bandwidth is, but my program only gets 30% of peak. I suspect it has to do with how many registers are used, and I have a knob to control it, so I turn the knob and plot all possible register settings, and find out that I can get 45% of peak with a different value. Now I know it was partially registers I was limited by, but I also know to look for something else too. Then I profile, examine the code, maybe refactor or adjust some things, hypothesize, test, and then shmoo again on a different knob or two if I suspect something else is the bottleneck.

Re: The art of high performance computing

#59
post #48

The hardware / datacenter side of this is equally fascinating. I used to work in AWS, but on the software / services side of things. But now and then, we would crash some talks from the datacenter folks. One key relevation for me was that increasing compute power in DCs is primarily a thermodynamics problem than actual computing. The nodes have become so dense that shipping power in and shipping heat out, with all ki…

It always made me wonder why liquid cooling wasn't more of a thing for datacenters. Water has a massive amount of thermal capacity and can quickly and in bulk be cooled to optimal temperatures. You'd probably still need fans and AC to dissipate heat of non-liquid cooled parts, but for the big energy items like CPUs and GPUs/compute engines, you could ship out huge amounts of heat fairly quickly and directly. I guess…

OVH prominently uses water cooling including custom components with their own design.

https://blog.ovhcloud.com/water-cooling-from-innovation-to-d...

https://blog.ovhcloud.com/water-cooling-from-innovation-to-d...

https://blog.ovhcloud.com/new-hybrid-immersion-liquid-coolin...

Re: The art of high performance computing

#60
post #48

The hardware / datacenter side of this is equally fascinating. I used to work in AWS, but on the software / services side of things. But now and then, we would crash some talks from the datacenter folks. One key relevation for me was that increasing compute power in DCs is primarily a thermodynamics problem than actual computing. The nodes have become so dense that shipping power in and shipping heat out, with all ki…

It always made me wonder why liquid cooling wasn't more of a thing for datacenters. Water has a massive amount of thermal capacity and can quickly and in bulk be cooled to optimal temperatures. You'd probably still need fans and AC to dissipate heat of non-liquid cooled parts, but for the big energy items like CPUs and GPUs/compute engines, you could ship out huge amounts of heat fairly quickly and directly. I guess…

> It always made me wonder why liquid cooling wasn't more of a thing for datacenters.

Liquid cooling is almost a defacto-standard in data centers in the HPC world. The Top of the TOP500 machines are all liquid cooled. Not by choice, but due to physics constraints.

There is a big gap in power density between the HPC world and the usual datacenter-commodity-hardware world.

Commodity DS are designed with the assumption that the average machine will run with a fraction of it's maximum load. HPC systems at the opposite are designed to operate safely at 100% load all the time.

In a previous company where I worked, we attempted to install a medium size HPC cluster in a well-known commerical datacenter and network provider. The commercial of the DS almost felt from his chair when we announced the power requirements.

Post reply on HN