Nadat ik in mijn eerste verhaal tijd had besteed aan codeoptimalisatie om mijn rekentijd met 90% te verminderen, was ik geïnteresseerd in het CO2-equivalent dat ik bespaarde door mijn wijzigingen. Geïnspireerd door de Microsoft DevBlog, besloot ik mijn eigen methode te ontwikkelen op basis van het artikel van Sara Bergman.
In dit artikel doorlopen we elke fase van het proces, dat in drie verschillende delen kan worden opgesplitst:

Elk onderdeel zal vergezeld gaan van de daadwerkelijke implementatie ervan op een notebook in Azure ML Studio.
Stap 1: De code profileren
Het doel van deze eerste stap is vrij eenvoudig: het vinden van het geheugen- en CPU-verbruik van uw code. In het geval van onze machine wordt er rekening gehouden met drie belangrijke parameters:
We kunnen online gemakkelijk informatie vinden om de Power Usage Effectiveness (PUE) te schatten, maar het meten van het CPU- / Geheugenverbruik van onze Python-notebook is niet zo eenvoudig. Er bestaan veel oplossingen (timeit, cProfile, psutil), maar die zijn meer gericht op tijdsprofilering dan op CPU- en geheugenverbruik.
Omwille van eigendom en eenvoud besloot ik mijn eigen profileringsscript in Bash te coderen en het verbruik van mijn machine in een oneindige lus te meten, aangezien de code die ik moest beoordelen zich op een JupyterLab-instance bevond die op Linux (18.04.1-Ubuntu SMP) draaide.
Het eerste script, dat werd gebruikt om elke seconde het exacte geheugengebruik te meten, werd opgeslagen als geheugen_profiler.sh :

Het tweede script, dat werd gebruikt om elke seconde het gemiddelde CPU-verbruik tijdens de laatste minuut te meten, werd opgeslagen als cpu_profiler.sh :

Maar het was niet genoeg om deze twee scripts te hebben, want ik moest ook precies weten wanneer mijn code werd uitgevoerd. Hiervoor voegde ik een cel toe bovenaan mijn notitieblok:

En nog een cel, onderaan mijn notitieblok:

Nu alles klaar was, hoefde ik alleen nog maar :
1. Zorg ervoor dat mijn omgeving niet vervuild is met andere taken die op de achtergrond draaien en sluit alle lopende instanties door op de knop Shut Down All (Alles afsluiten) te klikken.

2. Open een terminalinstantie om het script memory_log.sh op de achtergrond uit te voeren
./geheugen_log.sh
3. Open een andere terminalinstantie om het script cpu_log.sh op de achtergrond uit te voeren
./cpu_log.sh
4. Instantiëren en uitvoeren van al mijn notebookcellen

Zodra het hele notitieboek is uitgevoerd, kan ik beide Linux scripts stoppen door CTRL + C in elke terminal in te drukken, controleren of mijn memory.log en cpu.log bestanden met succes zijn aangemaakt, en de begintijd en eindtijd van de uitvoering van mijn notitieboek noteren door gebruik te maken van de twee toegevoegde cellen met datetime.now().

Ik had nu alles wat ik nodig had voor de volgende rekenfase.
Stap 2: Omrekenen naar energie
Nu we alle data over het grondstofverbruik hebben verzameld, kunnen we beginnen met alles om te zetten in kWh, een maat voor het energieverbruik.
Om dat te bereiken, zullen we de volgende vergelijking gebruiken:

Laten we eerst beginnen met de CPU-gerelateerde statistieken.
Als eerste stap kopieer ik de inhoud van het cpu.log-bestand in een Google Spreadsheet die ik later zal gebruiken om mijn gemiddelde CPU-verbruik te krijgen:

Ik doe een paar manipulaties op mijn Sheet (Tekst naar kolom splitsen, Ongebruikte kolommen verwijderen, Kolomnamen toevoegen) om iets handigers te krijgen om te gebruiken:

Mijn notebook liep van 12:33:20 tot 13:14:09, dus ik kan gewoon een formule toevoegen om het gemiddelde van cpu_1 tussen die tijden weer te geven, en dat gemiddelde delen door het aantal CPU's van mijn machine:

Ik begrijp nu dat mijn Notebook gemiddeld het volgende gebruikt 8.038 CPU's tijdens de 40 minuten van uitvoering die overeenkomen met 100,47% gemiddeld CPU-gebruik.
Maar wat is het verbruik van mijn CPU?
Dit hangt af van het model CPU dat wordt gebruikt, ik heb meer informatie over de CPU die door mijn machine wordt gebruikt gevonden in de Azure Microsoft Documentatie. Op het moment van mijn experimenten (oktober 2021) gebruikte mijn machine een van de 4 verschillende types Intel Xeon CPU:
- Intel Xeon Platinum 8270
- Intel Xeon Platinum 8171M
- Intel Xeon-processor E5-2697 v4
- Intel Xeon E5-2673 v3 @ 2,40 GHz
Nadat ik online op de website van Intel had gekeken, kon ik CPU-modellen vergelijken met hun stroomverbruik, door gebruik te maken van het Thermal Design Power (TDP), dat staat voor het gemiddelde vermogen, in watt, dat de processor afgeeft wanneer deze op basisfrequentie werkt met alle kernen actief.

Aangezien de gebruikte CPU bij elke uitvoering van mijn code kan veranderen, heb ik besloten om de gemiddelde TDP van deze vier CPU's te nemen, namelijk 158.75 in dat geval.
Ik heb nu beide gevonden Pc (=1,0047) en Cc (=158.75)
Laten we nu eens kijken naar het bestand memory.log
Volgens dezelfde processen als voorheen kopieer ik de inhoud van mijn bestand naar een Google Sheet, verdeel de tekst in kolommen en rangschik ze om het volgende formaat te krijgen:

Vervolgens pas ik een gemiddeldeformule toe op kolom C, om de gemiddeld geheugengebruik tussen 12:33:20 en 13:14:09 in MB. Ik deel dit getal door 1024 om het om te zetten in GB.

Om het stroomverbruik van één GB data te schatten, zal ik een vuistregel volgen die gevonden is hier : 3W per 8GB dus 0,375W/GB en 1.88W in totaal voor mijn geheugengebruik van 5.015GB.
Ik heb nu het volgende gevonden Pm (=1.88). Merk op dat het vermogen dat wordt verbruikt door mijn geheugen 85 keer minder belangrijk lijkt te zijn dan het vermogen dat wordt verbruikt door mijn CPU en kan worden overgeslagen om een iets minder nauwkeurige maar snellere beoordeling te krijgen.
Aangezien ik geen GPU gebruik, kan ik direct overgaan naar de laatste ontbrekende term: de Power Usage Effectiveness. PUE is een verhouding die bepaalt hoeveel energie het data centrum gebruikt voor iets anders dan het hosten van cloud diensten zoals koeling, compensatie van reactief vermogen, verlichting ...
Kijken naar de Microsoft Datacenter Factsheet van 2015, was de gemiddelde PUE in zijn nieuwe datacenter 1.125. Dit is het getal dat we voor dit voorbeeld zullen gebruiken, maar een meer gedisciplineerde aanpak zal zijn om de werkelijke PUE van het data center te vinden dat we voor onze berekeningen gebruiken.
We hebben nu alle termen van onze vergelijking, laten we gaan rekenen!

Aangezien onze code werd uitgevoerd tussen 12:33:20 en 13:14:09, duurde het 40 minuten en 49 seconden om uit te voeren (wat gelijk is aan 0,68 uur). Dit betekent dat het in totaal verbruikt : 0.182 * 0.68 = 0,1238 kW
Stap 3: De impact beoordelen
Als laatste stap van onze koolstofmeetreis moeten we nu de impact van dit elektriciteitsverbruik beoordelen, die sterk afhangt van de plaats waar de energie is verbruikt. Om dit te berekenen gebruiken we de Carbon Intensity factor die we gemakkelijk kunnen vinden in Elektriciteitskaart website, een project om openbare elektriciteit data uit 150 landen te verzamelen, voorbewerken en verenigen.

Toen ik de CO2eq impact van mijn in Nederland draaiende code berekende, was de Carbon Impact waarde 487 gram per kW. Dat brengt de impact van mijn code op 487 * 0,1238 = 60,3 gCO2eq.
Deze waarde lijkt misschien laag, maar wetende dat mijn stukje code elke dag en het hele jaar draaide, werd de impact gebracht op 60,3 * 365,25 = 22,0 kgCO2eq per jaar.
Maar wat stelt het voor in vergelijking met andere activiteiten? Als we het bijvoorbeeld vergelijken met het gebruik van een auto en de 2019 gemiddelde C02-uitstoot voor alle nieuwe auto's, is gelijk aan de voetafdruk van een reis van 180 km.
Gebruik monconvertisseurco2.fr Ik kan meer equivalente activiteiten krijgen door “Base Carbon” open data te gebruiken, verzameld door een organisatie van de Franse staat: het “Nationaal Agentschap voor Milieu en Energiebeheer” of ADEME.

Conclusie
Het is ons gelukt!
Na het profileren van onze code om het geheugen- en cpu-gebruik te achterhalen, het omrekenen van deze getallen naar elektriciteitsverbruik en het beoordelen van de impact in CO2eq, zijn we erin geslaagd om de CO2-voetafdruk van onze code beter te begrijpen. Dit is een belangrijke mijlpaal om een stap terug te doen wat betreft de impact van onze code op het milieu, en om het belang van codeoptimalisaties te benadrukken.
In dit specifieke geval, zoals vermeld in het eerste deel over het opsporen en vermijden van prestatieproblemen in Jupiter Lab, Door slechts één regel code te optimaliseren, kon ik 90% van mijn rekentijd en 92% van mijn CO2eq-impact besparen, waardoor ik van 22kgCO2eq naar minder dan 2kgCO2eq per jaar ging.
Tegenwoordig beloven de meeste cloud providerplatformen, inclusief Azure, het volgende een neutraal effect op het milieu hebben dankzij koolstofcompensatieprojecten. Milieudeskundigen zijn het er echter over eens dat, hoewel effectief en belangrijk, koolstofcompensatieprojecten alleen zijn niet genoeg om de impact van onze activiteiten op de planeet te beheersen, en dat de de beste oplossing is nog steeds om de uitstoot bij de bron te verminderen, zoals in dit optimalisatieproject.
Dit is wat we bij Artefact proberen te promoten door middel van onze verschillende milieu-initiatieven!

BLOG







