Re: Mesurar rendiment d'una aplicació
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
Reply to: