modulusshift

~

@modulusshift

  • he/him-ish

Stupid thoughts and hopefully less stupid articles occasionally. Gaming and tech thoughts mostly, but I have a smattering of completely off-the-wall interests as well.

~~

hey! future me! I'm looking at you. You're gonna find some way to be nostalgic about literally anything I write here, aren't you? Knock it off and do something useful. thx bb

~~

enelphant here

log inask
fedi
digipres.club/@modulusshift
website under construction
modulusshift.com/
modulusshift
@modulusshift
jckarter
@jckarter
lizthegrey
@lizthegrey

Sustainability of compute is a major problem (but there are solutions)

The amount of carbon emissions caused by IT may be as high as 3.8% (double the 1.9% of emissions caused by aviation). We need to grapple with our industry's role in this, rather than just saying "oh, it's been offset" and pretending like it's not a problem.

We have some of the solutions already in the form of open source build toolchains enabling us to switch to the more efficient processor architectures (ARM64 and RISC-V). Embracing these technologies can drop the carbon intensity of our compute activities by 1.5-2x with minimal changes to the software.

more from my slides presented at DDD Brisbane here: https://drive.google.com/file/d/1WhQuFYpoxvbnHGyUft4XxfFgs5coyny1/view?usp=share_link

modulusshift
@modulusshift

offsets are fake!

I mean, they're sometimes better than nothing, but not by much. Usually it's just justifying terrible practices by saying "well at least someone's doing it right." but what if they'd be doing it right either way?

recently heard a theory that Tesla is effectively a carbon offset scam that happens to sell some cars, while allowing the rest of the industry to lag behind, I believe it.

I actually really liked this slide deck, you're clearly balancing actual best practices (do we really need to be doing this work at all?) with showing actual benefits even the least-environmentally sensitive would like to get. can't eye roll your way past this improvement in TCO and latency! lol

You must log in to comment.

in reply to @lizthegrey's post:

NireBryce
@NireBryce

a whooooole lot of offsets are essentially fake / worthless (monoculture forests in wildfire areas, re-planting somewhere that was logged with the intent to sell the land for replanting, etc) so 'it's been offset' is at best an unintentional lie in many cases

login to reply
ceo-of-eurogaming
@ceo-of-eurogaming

As far as I can tell, the c5.xlarge instances you were previously using where a mix of skylake and cascade lake cores. So getting quite old at this stage. Did you evaluate other options like say, newer amd or intel cores? I'm guessing since everything is running on amazon it's hard to migrate towards anything that they don't directly support, though.

It's kind of an interesting dynamic I think from a sustainability perspective. Because on one hand, upgrading to the newest architectures will absolutely improve your efficiency. But it's kind of skipping over the bit where you have to throw away all the old infrastructure to do so, and that had a non-zero cost to build in the first place.

Additionally, did you do any bare-metal performance comparisons between the machines? I'm kind of curious whether you expect a drop in performance over time as more customers begin migrating to graviton instances. Have seen that kind of thing before when testing on clouds with low utilization with GCP at least.

login to reply
lizthegrey
@lizthegrey

We've seen HUGE drops in performance on AWS Lambda when we were stretching the capacity limits of what Graviton workers were available under the hood (causing us to contend ourselves); that's part of why we had to feature flag it and only slowly increase to 100%. We don't see that problem with using EC2 instances though as Nitro is very very good in terms of virtualization overhead and when you buy X cores you actually get X cores dedicated on that machine.

There definitely is the issue of eWaste, but Amazon has already to some degree or another amortized the cost of building the stuff, they can make use of it for other things like x86 lambda, spot instances, etc. -- but fundamentally, a majority of the cost of running a space heater that happens to generate computation is the electricity rather than the space heater itself :)

At the time we did the eval of m6g, m6i and m6a were not yet available; but now the apples to apples comparison of the latest current hardware is c7g to m6i which, c7g wins hands-down. :) our experience with AMD on AWS has been very underwhelming though. We tried putting c5a into rotation against c5 and found it just couldn't keep up and tail latencies were shooting up.

login to reply
ceo-of-eurogaming
@ceo-of-eurogaming

Ah super cool.

It's going to be really interesting to see how arm competes with the Big Cores in the server space I think. They're still a bit behind on raw performance, but I'm interested to see how they go scaling out compared with interesting semi-custom designs compared to amd's chiplets and intel's big/little. Interesting times.

I'd like to give the gcp tau arm instances a shot at some point as well, but it's reasonably intractable at the moment to bring up arm support. :'(

login to reply
lizthegrey
@lizthegrey

Thing to remember is it's early days for ARM64 single-core performance. You can regularly find 10% wins by adding hand assembly implementations or writing compiler optimizations, whereas those discoveries don't exist on Intel these days, they're all found already.

login to reply