Názory k článku
Má být kompilátor energeticky úsporný?

Mate preklep v nadpisu ;)

A pouziti disku/flash/... je mene energeticky narocne? To bych se hodne divil ... nekam se totiz ta data ulozit musi. Ale jo, klidne si dovedu predstavit nacitani jednotlivych instrukci mist z RAMky rovnou z disku ... sice to pak misto vterin pobezi stovky hodin, ale co, hlavne ze se "usetri" ...

Prijde mi to naprosto stejne jako nahrada (zcela ekologickych) zarovek vybojkama, ktery obsahujou hromadu toxickych prvku (a navic svitej naprd, dlouho startujou ...).

arm je risc takze ma obrovske mnozstvo registrov....

To byla ironie?

Vskutku "obrovske" mnozstvi! :-)
http://en.wikipedia.org/wiki/ARM_architecture#Registers

Tak to zrejme mysleno neni. Mezi pameti a rychlosti je casto trade off - k danemu algoritmu existuje ekvivalentni algoritmus, ktery je o neco pomalejsi, ale spotrebovava mene pameti. O nejakem disku nebo flash pameti to vubec neni ...

ano, divím se že se tomu chcete divit.. ram vyžaduje neustálý příkon na samotné udržení dat narozdíl od hdd nebo flash

vidím že o problematice energetické efektivity máte neskonale hluboké znalosti, smekám.

tento přispěvek může obsahovat stopy ořechů a sarkasmu.

Tak si prosím spočítejte, kolik stojí příkon hodiny RAM a kolik stojí každé roztočení disku a jeho následné točení.

RAM (desktopové DDR3) spotřebovává cca 4 W na modul, to je nějaký 8 Wh pro počítač. Disk při roztáčení spotřebovává do 30 W a roztáčí se do 10 sekund. To je 0,08 Wh, tedy jedna setina toho, co sežere RAM za hodinu ;-)

Ale protože jde o ARM, tak to nejspíš bude porovnání RAM × SSD, kde jsou ty výsledky ještě zajímavější.

A po roztočení už funguje jako perpetuum mobile?

Překvapivá odpověď zní ne. Při idle žere zhruba těch 8W, při read/write o něco víc. Takže jsme na 8.8 Wh, což je o kus více než při použití RAM.

Uvážíme-li do toho, že výsledná aplikace poběží déle (protože bude mít IO wait) a CPU nebude upadat do čekajících stavů, tak nebude šetřící...

U SSD to pochopitelně bude lepší, ale pořád je potřeba přemýšlet nad stavy procesoru...

Fascinuje me ta neuveritelna tupost nekterych lidi (ovsem v pripade eurouredniku je nutne nahradit "nekterych"->"temer vsech") - neustale, znovu a znovu a znovu se snazi "optimalizovat" nejakou vec, aniz by ani na sekundu uvazovali nad tim, jak efektivni takova optimalizace je.

Priklady

EU zakaze zarovky, prestoze sviceni predstavuje vesmes mene nez 5% spotreby energie domactnosti (u firem to byva vyrazne mene nez 5) - vysledkem je plytvani penezi, zkazene oci, vice rtuti v zivotnim prostredi. I kdyby EU magicky vyrobila zarovky co sviti bez spotreby energie, nemuze sniznit spotrebu o vice nez 5%

EU chce zakulacovat nakladaky aby snizila aerodynamicky odpor, aniz by provedla skutecne mereni (pak by totiz zjistila ze vetsina nakladaku, vcetne kamionu, se pohybuje vetsinu casu takovymi rychlostmi, pri kterych je odpor vzduchu zanedbatelny (cca do 60km/h), nehlede na to ze tvarovy odpor kabiny je vzhledem k celkovemu odporu soupravy kamionu s navesem opet zanedbatelny.

... atd, atd.. jiste sami prijdete na podobne pripady...

a ted, opet nekdo resi optimalizaci kompilatoru, tedy neceho, co nejspise ani nikdo poradne nezmeril, protoze je docela dost mozne ze se tato hodnota nachazi na hranici merici chyby beznych mericich pristroju.

Na druhou stranu nikoho netrapi, ze spousta zarizeni, ktere by i teoreticky mely mit malou spotrebu, sviti treba 3 jasnymi modrymi ledkamy (protoze je to COOL), pricemz jen spotreba techto ptakovin sezere treba 60mA.

Optimalizovat - ANO - ale POUZE po tom co najdu neco, kde bude mit optimalizace VLIV. Optimalizaci neceho co prispiva 0.01% ke spotrebe neziskam NIC.

Argument by nebyl, že? No, nedivím se, eurohujeři je nikdy nemají.

ty okrasny ledky me taky pekne stvou, mel jsem doma dvd, kde to ani neslo vypnout bez toho aniz by to clovek kompletne odpojil od energie. V noci jsem si pripadal jako kdybych bydlel na kryptonu;)

Takové p*čoviny nekupovat!

Amdahlův zákon se zkrátka obejít nedá. I já si myslím, že půjde spíše o mikrooptimalizace a i v takřka ideálním světě, kde programy jsou napsány algoritmicky optimálně, bude optimalizace na rychlost skoro dokonalým a nejspíš dostatečným řešením.

Energetická náročnost výroby stejně jako cena recyklace je zahrnuta v ceně zářivky ;-)

Myslíte, že elektřina mimo EU je nějak zázračně levná? I v Číně stojí elektřina cca 2 Kč/kWh.

Pokud se recyklace dělá jen na papíře, tak za to zářivky nemohou, v jejich ceně platíte plnou recyklaci.

Ano, to je tak, když tomu někdo rozumí ;-)

Na svícení se jen v domácnostech spotřebuje cca 16 % elektřiny. V současné době, kdy už je mnoho žárovek pryč. Ve firmách je to ještě výrazně víc. Výsledkem výměny žárovek za zářivky je mimo jiné i značná úspora peněz (např. nahradit 60 W žárovku za 10 W zářivku se vrátí již do jednoho roku, u LEDek to jsou cca dva roky). Zářivky jsou (stejně jako např. baterie) nebezpečný odpad a je potřeba je vracet do prodejen, ne vyhazovat do popelnic. Světlo zářivek je bližší dennímu, tedy je pro oči šetrnější.

Skutečná měření u snižování spotřeby náklaďáků se samozřejmě prováděla. Většinu času se náklaďáky pohybují 80 km/h (při jízdě mimo obce a po dálnicích), kdy odpor vzduchu rozhodně není zanedbatelný. Například Concept S od MANu má o 25 % (!) nižší spotřebu pouze díky lepší aerodynamice.

EU se snaží omezovat spotřebu zařízení v idle, mnoho nových zařízení smí mít idle maximálně do 1 W (a třeba nové monitory mají typicky i o dost méně, za cenu delšího startu). Spotřebu za běhu by měly řešit energetické štítky, ale u mnoha elektronických zařízení není jasné, jak to měřit. Pokud máte nějaký nápad, můžete se obrátit na svého europoslance ;-)

Ani denní světlo nemá spojité spektrum. Tenhle problém je ale většinou jen u levných zářivek, které kromě větších mezer ve spektru svítí UV (to skutečně poškozuje oči) či blikají (když jim chybí účinný předřadník).

„např. nahradit 60 W žárovku za 10 W zářivku“

Vy jste někde viděl 10W zářivku se světelným tokem jako má 60W žárovka? Nebo jste si ji prostě vymyslel, aby ta čísla vypadala lépe?

„např. nahradit 60 W žárovku za 10 W zářivku se vrátí již do jednoho roku“

Zkusil jsem to v chodbě (svícení 3x2 minuty denně) a nevrátilo se mi to, navíc zářivka odešla (výrobce tvrdí, že prý kvůli častému a krátkému rozsvěcení). Kde jsem udělal chybu?

„Světlo zářivek je bližší dennímu, tedy je pro oči šetrnější.“

Viděl jste někdy spektrum zářivky? Můžete si to snadno zkusit doma, stačí vám k tomu vypálené CDčko (https://en.wikipedia.org/wiki/File:Fluorescent_lamp_spectrum.jpg).

Me zase zarazi ignorance nekterych diskutujicich. Kdyz mate prispevek, ktery nesouvisi s clankem o LLVM tak ho oznacte jako "offtopic".

PS: to plati pro cely tenhle thread.

Úspora energie je téma, které má smysl. Jde zejména o mobilní zařízení - kde se projeví na delší výdrži.

Myslím si ale, že jedna volba nestačí. Aby tato optimalizace nezhoršila výslednou binárku ve všech parametrech, musel by mít kompilátor přesné informace o cílové platformě (energetické a časové ocenění některých typů činnosti - nějaká unifikovaná tabulka) - tj. kolik energie stojí udělat to různými způsoby a na to by se dal vygenerovat optimální kód.

Drobným problémem ale je, že to zvýší energetickou náročnost kompilace :-)
a aby to fungovalo, tak by se muselo všechno kompilovat přesně na míru danému zařízení - což zase pro mobilní aplikace je spíše nevhodné.

Tak to je pekna haluz. Fakt by ma zaujimalo, ak by sa do toho islo, ake by zvolili parametre podla ktorych sa ma optimalizovat, respektive co by sa vlastne optimalizovalo. Pri multithreadovych app core parking ? Potom by jaksi stratilo vyznam mat tych jadier viac v cpu. Ostatne toto moze priamo riesit HW, nehovoriac o vyraznom dopade na vykon. Analyzovat kod a podla toho ako casto a ake zariadenia pouziva ? Hmm no mozno by sa dalo povedzme nejakym sposobom zistit ako casto pristupuje kod k IO ale potom si viem predstavit komicke situacie kedy si kompiler, okrem uvedomenia si sameho seba, povie ze tato hra nejak moc pouziva GPU a moc to zere tak to "zoptimalizujem" (ehm vyhodim)....

Finta je v tom, že skoro všechny polovodiče jsou CMOS. Tzn. čím větší rychlost, tím víc žere. Takže kompilátor bude vědět, z čeho CPU bere hodiny a bude si přehazovat po každou funkci PLL? To sotva...

Další žrout, L1 cache a L2 cache. Taky záleží na tom, jak se softwarově nakonfiguruje... Ví komplátor, kde jsou příslušný registry a co do nich narvat A hodiny bere obvykle ty samý, jako jádro...

Dostat program a data do cache... No, obvykle z SDRAM, že. Tam to je hodně o frekvenci hodin, jinak bude žrát DDR 133MHz, jinak DDR na 266... A odběr se liší i podle velikosti burstu, latence,... Takže kompilátor inteligentně nakonfiguruje řadič RAMky a samotný paměti? On nějak ví, co a jak je připojeno? S jakou šířkou sběrnice atd., kde je uložena konfigurace paměti (v EEPROM na SMB, nebo někde natvrdo v BIOSu...?) Nebo bude za běhu šibovat z rychlostí RAM? To se mě nějak nezdá...

Zkrátka, nejlepší optimalizace na odběr je taková, kterou si udělá sám programátor nebo designér desky. Správně nastavit rychlosti a velikost paměti, zastavování hodin periferkám, optimální dělící poměry na PLL (proč honit oscilátor na 196MHz a pak dělit čtyřma pro USB, když stačí 96MHz/2?) ... To se podepíše na odběru víc, než nějaký nesmyslný prokládání kódu NOPama...

A snížení počtu přístupů do paměti? Pokud má SW modul svoje data ve struktuře, natáhnou se do cache najednou a nehrozí, že by kvůli 20B rozstrkaných kompilátorem, 6x sahal do systémové RAM... Souvislost proměnných s modulem nebo četností využití zná zase nejlíp programátor.

Proc se nikdo nenamaha, aby zjistil, v cem ty optimalizace vlastne maji spocivat? Pak tady vsichni tak akorat mluvite o ho*ne...

In theory, some compiler and hardware optimizations such as instruction-level parallelism (ILP), speculative execution and pre-fetching increase the energy consumption per cycle. If the same speed can be achieved using less energy per cycle by controlling such optimizations, the total energy consumption will be less. Some of these optimizations may be controlled by the compiler. Also, the switching energy from one instruction to another depends on the instruction order. So, in theory, if there are multiple instruction orders that give the same speed, the order that minimizes the switching energy will consume less overall energy. There is some academic research on this with simulation data.

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061208.html

To by davalo jistej smysl, ne? I kdyz si nejsem jistej, nakolik je mozne pri kompilaci ovlivnovat prefetch a spekulativni vykonavani, vzdycky jsem mel za to, ze jsou to vlastnosti CPU, ktere pro program maji vypadat, jako by vlastne neexistovaly...

Je to zbytečná snaha jako chtít ostříhat Kožaka. Pokud se programátoři nenaučí efektivně programovat, tak k čemu to je? Spoléhat se donekonečna na to, že máme výkonný hardware a spoustu, a to nepopírám, užitečných optimalizací, takže můžu programovat jako čuně nikam nikdy nepovede... Leda že by bylo něco, co by dokázalo zoptimalizovat už tu prvotní myšlenku, kterou se někdo snaží, kolikrát lajdácky, ztvárnit jako program.

Přesně tak. Když použiju na stejným jádře místo MOV R0, #0 instrukci XOR R0, R0, výsledek je stejný, ale ušetřím si jedno čtení operandu (cyklus sběrnice). To už ale kompilátor dělá při optimlizaci na velikost i na rychlost...Prefetch a spekulativní vykonávání si kompilátor taky optimalizuje na rychlost... A jinak to už moc ovlivnit nejde a když, tak nastavením pár bitů ve status registru jádra - a to v případě potřeby stačí "#pragma asm ... " v initu.

Pokud jde o energetickou účinnost, je spíš potřeba používat to kulatý na krku. Za šílnýho / nevzdělanýho / hloupýho programátora (nehodící se škrtněte) to kompilátor nezachrání.

Příklad: Datalogger se záznamem RS-485, provoz z baterky, vyčítání a nabíjení po USB. Na USB jede jádro a periferky na 48MHz, FLASH se záznamem zapnutá, protože se do ní furt leze. Při logování rozumný člověk nechá jet UART, jádro a datovou FLASH sestřelí a čeká na IRQ. A stáhne periferní hodiny třeba na 11,0592MHz, aby zbytečně nehonil CMOS obvod moc rychle... A bufferuje v RAM, kde stejně musí držet čas, stack atd., zápis fo FLASH po sektorech...Odběr jednočipu se tak dá stáhonut o hodně desítek procent proti rychlé komunikaci na USB.

Platí Paretovo pravidlo, že optimalizací 80% kódu kompilátorem se řeší 20% úspory a chytrou úpravou 20% kódu pro inicializaci a přepínání módu hardware se dosáhne úspora 80%... A stačí na to u páce myslet.