Vlákno názorů k článku
Má být kompilátor energeticky úsporný? od Jazz - Je to zbytečná snaha jako chtít ostříhat Kožaka....

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.