Vlákno názorů k článku Architektury mikroprocesorů od Kvakor - Budou v nejakem dilu i dalsi architerty, jakou...

Problém je, že u jazyku typu C neurčíš nijak latence instrukcí přistupujících do paměti.

Není znám algoritmus, který by se podíval na zdroják nebo na assembler a s rozumnou přesností určil, která proměnná se bude nahrávat z L1 cache, která z L2 cache a která z hlavní paměti.

Proto mají ty x86 procesory out-of-order vykonávání, protože tohle kompilátor neudělá.

Kdybys chtěl určovat latence kompilátorem, tak bys musel mít just-in-time kompilátor --- kde se to za běhu naměřit dá.

Mimochodem, z tohoto důvodu existuje pár případů, kdy je java rychlejší než C (v podstatě se v té javě nesmí nic alokovat jenom dělat operace už s naalokovanými poli --- pak to JIT může zkompilovat líp než C kompilátor)

A BLEKu, proc to nezkompilovat nejdriv s testem, pak to nechat probehnout nejakymi testy a na zaklade tech testu odhadnout, ktera promenna se bude cist z ktere cache, a pomoci teto informace to pak staticky zkompilovat? Nechces namet na dalsi projekt? ;-)

Jak přesně si to představujete? Cache je víceméně transparentní, až na tu latenci, samozřejmě... Možná by zaangažovat nástroj typu Intel VTune, ale podle mě by v tom bylo docela dost hádání. Buďme rádi, že už máme aspoň těch šestnáct general-purpose registrů! Vivat AMD!

Nebejt AMD a jejího šílenýho x86 everywhere, třeba se mohlo časem prosadit Itanium se 128 GPR integer registrama. Smrt AMD :-)

Itanium se potopilo samo (tím, že je přepatlané featurami => drahé a pomalé). Nikdo si nebude kupovat počítač, který je 20x dražší než běžné PC a navíc ještě pomalejší.

Ruku na srdce - nebyl by nejlepší MIPS? ;-) Jednoduchý, pěkný, energeticky úsporný... :-) (Nebo MMIX :-D)

Vsak neboj, MIPS se pouziva docela casto. Absolutni cisla asi nikdo nevi, ale rekl bych, ze MIPSu se vyrobi vic nez neceho na bazi x86.

No, jak si to predstavuju, copak jsem BLEK, abych resil tenhle problem? :) Ja jenom navrhuji postup, jak obecne dohnat vyhodu JIT kompilatoru proti statickemu kompilatoru tim, ze se ta staticka kompilace provede na zaklade nejake statistiky bezneho chovani programu. Sam BLEK pise, ze se ta latence zmerit da, takze asi vi jak na to, ja o tom nemam tuseni. A ani me to nezajima, protoze vim o mnohem lepsi tride optimalizaci zalozenych na tomto principu, ale nehodlam to zatim nikde sirit, protoze si to chci vyzkoumat sam. :)

To umí gcc pouze pro určení skoků, zda se provedou nebo ne. S cachovaností proměnných by to bylo zajímavé. Kdyby se mezi každým přístupem do paměti četly performance-monitoring-countery, tak by to asi ten program šíleně zpomalilo.

Ale možná by bylo zajímavé udělat tohle:

Pustit si timer a občas z zapnout Trace flag a z trap signálu si číst performance countery (a po několika stovkách instrukcí ho zase vypnout, aby ten program taky mohl běžet). Tím získat profil nejen, kde to nejvíc čeká, ale i na čem to nejvíc čeká (cache apod). Kdybych byl ještě na škole, nebylo by špatný to vypsat jako projekt/diplomku :)

Nebo už je nějaký nástroj, který tohle dělá?