Továbbra is azt mondom, hogy nem a RAM random vs sequential sávszélességét méred
Valojaban a fogyasztast akartam merni, es sikerult is :) De akarok meg keriteni egy ampermeros USB sticket es egy RPi-t is, hogy ugyis lassam... Egyebkent a fenti peldaban a fordito mar semmit nem tudott kioptimalizalni mert a maszk-ertekek meg a bitszelessegek immaron command line parameterkent erkeznek. Nade akkor sorrendben:
- itt nincs semmi extra branch prediction, vagyis a branch szerkezet az fuggetlen attol hogy az eleres mennyire random vagy mennyire szekvencialis... az LFSR szerkezet is fuggetlen ettol (ott abban ugye lehet branch, de ha a LFSR tap regiszer - ronda 32bites hexa szam - erteket mondjuk CMOV-szeruen allitja elo, akkor ott a gyakorlatban nincs is branch);
- igen, a cache hit-miss arany az a wait state-k miatt aranyos lesz a fogyasztassal illetve az effektiv sebessggel, szoval ezt is tenyleg merjuk;
- igen, az L1-L3 esetere is vonatkozik: ahogy viszem fel a maszk szelesseget, szepen lehet latni a futasi idokbol hogy mikor lepem at az L1-et, mikor az L2-t es mikor az L3-at. A randomizalas miatti atfedesek okan nem annyria elesek ezek a hatarok, de ott vannak kb ahol varjuk;
- multithreading es tarsai: hat, egy headless gepen mertem ezt, semmi grafika, semmi flanc nem futott rajta, csak az a nehany tucat minimal processz amit egy "beeseshazos-dolgozos" gepen kell fusson... szoval igen, ez termeszetesen beleszolhat de a wall time vs. user time meglehetosen ugyanaz- szoval talan nem torzitotta annyira.
Szoval egyelore igy.