Performance considerations in the age of SPECTRE and Retbleed
This is an open discussion regarding the mitigation costs incurred by the patches made to the Linux kernel regarding the Retbleed vulnerability.
See a summary here: https://comsec.ethz.ch/research/microarch/retbleed/
and the paper here: https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf
One paragraph is particular of interest:
Our performance evaluation shows that mitigating Retbleed has unfortunately turned out to be expensive: we have measured between 14% and 39% overhead with the AMD and Intel patches respectively. Please refer to the paper if you want to know more. Mitigating Phantom JMPs with a generic flushing of the branch predictor unit on kernel transitions imposes up to 209% performance overhead.
This is not great, and as we are slowly (but surely) exiting the era of "software engineers write software, hardware engineers make software go fast", it is my opinion that we should invest in optimising the programs generated by the compiler to keep up with the stop of infinite growth by hardware chips.
This is not something that lives in a vacuum, as GHC's own memory and CPU footprint have long been decried. If we wish to onboard new demographics that do not have easy access to 32GB of RAM and ThreadRippers to compensate for GHC's usage cost and the several kernel and CPU mitigations against the vulnerabilities of the SPECTRE family, we must invest in making our beloved compiler more lightweight and kind to our hardware.