scieee AI-readable full text Open interactive document viewer

Embedding energy efficiency in computational communities

Greenbank, Adam; Huntley, Jessica; Al-Daas, Hussam

Abstract

The Collaborative Computational Projects (CCPs) are a set of communities funded by CoSeC (https://www.cosec.ac.uk/) that develop and maintain a wide range of scientific software. but without information on energy efficiency, it can be difficult for users and developers to make informed choices about the way they write or use that software. Current understanding is limited, and whilst some communities have started developing guidance on energy efficiency, this is often application specific and time consuming for researchers. Our cross-cutting project aims to generalise existing knowledge of sustainable computing and address common challenges across disciplines by: Surveying the CCPs to identify common software libraries, such as BLAS and LAPACK, and challenges to improving energy efficiency,Benchmarking the performance and carbon intensity of these common software libraries and their alternatives,Using this information to create best practice guidance to allow RSEs to improve the energy efficiency of their software.Acknowledgements Funded by CoSeC (https://www.cosec.ac.uk/)A recording of this session is available on YouTube: https://youtu.be/olvbS_tWQJ0

Full text

Embedding Energy Efficiency in Computational Communities Adam Greenbank, STFC Computational Mathematics Embedding Efficiency... •There is currently a drive to reduce the carbon emitted by scientific computing oSee projects like Green DiSC •There are already plenty of efforts to quantify carbon embedded in hardware and generated when running our software •Once we know this, what can we as developers do to reduce the energy consumption of software? . ...Computational Communities •This work is funded by a CoSeC green computing project oProgram run by STFC Scientific Computing •Funds 25 communities called CCPs oCollaborative computational projects oDevelop software for specific areas of science or engineering . Project aims •Understand issues faced by CCPs relating to green computing oGaps in knowledge oTechnical challenges •Running workshop and survey to find such issues •Produce guidance around green computing oDevelopers should understand basic principles of green computing in different areas oPerform benchmarking of fundamental mathematical functions used by CCP software . BLAS and LAPACK ▪We have chosen to look at the BLAS (Basic Linear Algebra System) and LAPACK (Linear Algebra PACKage), as these are very fundamental routines used in many libraries ▪The libraries lay out a number of different functions ▪There exist different implementations of the functions with different levels of optimisation ▪We have created a benchmarking framework to test the performance of these ▪Split into 3 levels: ▪L1: vector-vector operations ▪L2: matrix-vector operations ▪L3: matrix-matrix operations Survey Survey •We asked CCP developers a range of questions related to green computing and their use of mathematical libraries •Fewer responses than we would have liked, but still some interesting observations . But... •If we look at which libraries have a dependency on BLAS: . •Developers aren't always aware that BLAS/LAPACK are present Benchmarking Framework 32-bit Serial Matrix-Matrix multiply ▪ Similar story to 64-bit ▪MKL better initially, but falls off for larger problem sizes ▪Generally follows the same trend as double precision 64-bit Serial Solver for Ax=b ▪ATLAS and OpenBLAS much stronger here ▪AOCL can't keep up, even on their own processor 32-bit Serial Vector Sum ▪AOCL no better than NETLIB despite being the best option for DGEMM 64-bit Multi-Threaded Matrix-Matrix Multiply ▪Achieving a smaller fraction of peak performance than serial ▪Only about 40% ▪AOCL comes out on top again Multi-Threaded BLAS, Single Precision ▪Fairly similar to 64-bit, but as with serial execution MKL slows for larger problems 64-bit Multi-Threaded Matrix-Matrix Multiply ▪OpenBLAS and ATLAS performance massively increases at problem size of 2048 ▪Not clear why this is, but it is also present in 32-bit runs Multi-Threaded BLAS, Double Precision ▪All implementations scale in a relatively normal looking way, but at very different rates ▪400 GFLOPS/S difference between MKL and AOCL for largest problems here Multi-Threaded BLAS, Double Precision ▪ MKL far outperforms all other options Scaling performance ▪Scaling across different core counts can also vary ▪MKL's scaling performance is generally good ▪Other libraries seem not to scale at all for certain functions Conclusions and future work •It's important to know what your dependencies are and what alternatives are available •Even within the same BLAS library the performance relative to the alternatives can differ wildly between routines •We would like to make this tool available for developers to benchmark other libraries •We would like to work with specific communities to develop a case study based on this work