Balancing Cost & Performance
In #HPC, as in motorsport, often it is not about all about raw performance but rather, balancing several parameters to achieve the fastest possible results.
At Cadwell Park, as you come round the sharp right hander and head up the Mountain you’ll want to be rolling onto the throttle as early as smoothly as possible. As you crest Mountain, you’ll have at least the front wheel off the ground. BSB riders will usually have both wheels off the ground. Great fun to watch and if you’re spectating at Cadwell the top of Mountain is a great spot if you can find space.
Come onto the throttle too hard at the wrong point though and the bike will flip over. I’ve seen it myself on track days as novices, too eager with the throttle coming up the mountain, give it a handful as they approach the crest. An expensive mistake the usually brings their day to an end (but hopefully results in no injuries to the rider)
Balancing putting down the power with keeping the nose of the bike down is imperative.
#FinancialRisk systems are often the same. The best performance may not be achieved by spinning up every single hpc7a (or hpc6i for you poor souls stuck on Intel) instance #AWS can provide. This may (probably will) overwhelm the trade and market data services or caches providing the input data. Or the results services/caches attempting to store the output. The metaphorical equivalent to flipping the bike over whilst cresting Mountain. Probably more expensive a mistake than your average track day rider flipping his bike too.
All too often it is a balancing act, running as many calculations as possible in parallel without overwhelming the infrastructure feeding your compute nodes, or the network. Or your budget. Whilst avoiding the wrath of the PRA/FINMA/SEC for not meeting your SLA.
Just aiming to maximise every possible parameter sometimes isn’t the fastest way to get your results. In HPC or on the track.
