The art of high performance computing
High-performance computing emerges here as both a mature craft and a messy ecosystem: powerful abstractions like MPI, OpenMP and BLAS coexist with primitive schedulers, fragile batch tooling and clusters that are often under‑instrumented or misused. Commenters praise Victor Eijkhout’s free “Art of HPC” book series and UT Austin’s role in numerical software, while stressing that real performance still demands deep understanding of hardware, thermodynamics, and scalability—not just programming models. Alongside technical details on GPUs, interconnects, and liquid cooling, many note gaps in education, the rise of research software engineering as a role, and the cultural gatekeeping around HPC jobs.
Book and educational value
- Many readers praise the HPC book series as unusually comprehensive and freely available, useful even beyond HPC (e.g., C++ and Unix tools).
- Several commenters say such a resource would have significantly improved or reshaped their past teaching/learning decisions.
- Some contrast it favorably with broad “scientific computing” courses that skimmed HPC topics; they see this as suitable for a dedicated semester-long parallel computing course.
HPC programming abstractions vs hardware awareness
- MPI and OpenMP are described as main abstractions; for many workloads, one can program at that level without deep hardware details.
- Others argue abstractions are not sufficient for peak performance or scaling: understanding memory hierarchies, NUMA, interconnects, GPUs, and topology is seen as essential.
- Libraries (BLAS, LAPACK, Eigen, vendor-tuned kernels) hide much of the low-level optimization for linear algebra, but not all problems can be reduced to these.
Tooling, schedulers, and user experience
- Workload managers (Slurm, PBS, UGE, LSF) receive criticism as archaic, fragile, and poorly documented, especially configuration via shell-script comments.
- Counterpoints: shell is a common cross-disciplinary lingua franca; Slurm is viewed by some as straightforward, well-documented, and improving via REST APIs.
- There is disappointment that, after decades, job management APIs/protocols are still fragmented; prior standardization attempts (e.g., DRMAA) saw limited adoption.
Real-world HPC practice and careers
- Many academic jobs are “embarrassingly parallel” script farms: hundreds of independent jobs via Slurm, no MPI, minimal tuning.
- HPC admins report much time spent on user support, fixing over-requested resources, and basic monitoring rather than deep profiling.
- Some lament gatekeeping via master’s degree requirements for admin roles and poor code quality from research groups, arguing for dedicated research software engineers.
Hardware, cooling, and datacenter constraints
- Thermodynamics and power density dominate modern HPC design; supercomputers and GPU-heavy nodes routinely require liquid or immersion cooling.
- Commodity data centers often cannot handle HPC power densities; attempts to colocate GPU clusters can exceed rack power budgets by an order of magnitude.
- Discussion highlights complexity and risk of liquid cooling (CDUs, leaks, coolant management) versus brute-force air, but consensus is that liquid becomes mandatory at scale.
C++ and Python for HPC
- The C++ volume is seen as a solid modern introduction; suggestions include more on move semantics, RVO, and tail-call optimization.
- Recommended next steps: modern C++ for scientists, architectural/CI-focused C++ books, and key topics such as smart pointers, ranges, concurrency.
- Some note that Python HPC is increasingly done with Dask and GPU-backed libraries, not only MPI bindings.
Cluster management and queuing theory
- One thread explores hardware management as a complex system: hierarchical Markov chains, repair workflows, logistics, and workload interactions.
- Queuing theory is cited as a foundational but still incomplete framework; real systems are far more complex than standard M/G/k models.