El Wed, Jun 02, 2021 at 08:13:46AM +0200, Leopold Palomo-Avellaneda deia: > El 1/6/21 a les 23:00, Àlex ha escrit: > > Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i > > el temps total (wall time). A tu t'interessa el cpu time: > > > > https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9 > > > > > Genial!!! > > Però és una passada perquè el CPU time hauria de ser més o menys constant i > no ho és. Nosaltres hem trobat variacions de fins al un 10%. > > Leo
Jo no hi entenc però és que no veig perquè la CPU hauria de ser constant. Si agafes un model de processador com el que feiem a primer de carrera a Computadors potser sí. Però amb les complicacions que tenen les CPUs actuals ja és molt si aconsegueixen que els resultats siguin deterministes. Que el temps sigui determinista en condicions diferents és demanar molt. Algú ha parlat de temperatura, i sí, els processadors poden baixar la freqüència de rellotge si s'escalfen. També hi ha les caches (L1,L2,L3 al processador, TLBs, buffers de disc a RAM... alguns canvis de velocitat causats per aquests te'ls deuen comptar com temps de cpu d'usuari). Si tens pocs processos la probabilitat que les dades encara estiguin a alguna cache després d'un parell de canvis de context puja. Amb les mitigacions dels atacs de canals laterals a CPU (Spectre & cia.?) potser baixi aquest efecte, però no crec que l'eliminin. Quan l'ordinador té diferents processadors i cada processador diferents nuclis, també pots tenir més rendiment si tots els processos/fils de la teva aplicació acaben a nuclis del mateix processador i comparteixen alguna cache o tenen rutes més curtes per comunicar-se. Si al sistema hi ha molts processos potser el linux no aconsegueix distribuir els teus tan òptimament. Fulleja per aquí per una idea del merder que representa https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/ Els perifèrics també poden reaccionar diferent segons la càrrega. Imagina't que tens processos que no toquen un disc i el disc s'arriba a parar per estalviar energia quan aquests processos els toca una estona llarga de CPU. Llavors quan el necessita el procés que medeixes s'ha de tornar a accelerar (si és dels que giren, en qualsevol cas també incorporen caches). Això hauria de ser temps de S.O. meś que d'usuari, però no śe si es pot comptar del tot bé si fa que el procés que medeixes surti de la CPU abans d'hora i perdi continuitat de cache o el que sigui... Després separar temps de cpu d'usuari i de S.O. està bé, però no sé si avui en dia hi pot haver temps de supervisors que estiguin per sobre del S.O. i no es vegin en cap compte (gestors de màquines virtuals, system management, UEFI, etc.). Dubto que això influeixi molt, o diferent segons càrrega, però qui sap. No em facis molt de cas, parlo per parlar, no vull dir que aquests efectes siguin significatius, vull dir que hi ha moltes coses interconnectades. El programador té un model simplificat d'una màquina de von Neumann i prou (o quasi), però el S.O. i maquinari són bastant més complicats, i això fa que el rendiment tingui tot de peripècies. Has mirat perf ? https://perf.wiki.kernel.org/index.php/Tutorial
