Un mostro di potenza. Un processore da 24 core capace di eseguire 48 thread simultaneamente, SSD rapidissimo, 64 GB di memoria RAM e l’ultima versione del più diffuso sistema operativo personal del pianeta, cioè Windows 10. Una macchina da sogno. Con la quale però non si riesce a muovere il mouse da quanto è inchiodata, nonostante la memoria sia libera e le risorse di calcolo siano pochissimo impegnate. Come mai?
Lasciate però che il cronista riprenda un attimo fiato: sembra di essere tornati giovani, alle storie che si sentivano all’inizio del muovo millennio. Invece la storia è di oggi, come si scopre leggendo quel che racconta l’utente randomascii, alias Bruce Dawson, programmatore che lavora per Google e si occupa niente di meno che di ottimizzazione e affidabilità dei sistemi. Con tanto di grafici e tabelle, analisi per capire come mai succede questo pasticcio. Si torna giovani, a quando Windows ci aveva abituato a questo e ben altro.
Dawson è rimasto colpito dal fatto che la sua macchina super-potente abbia problemi a registrare il movimento del mouse e rappresentarlo muovendo all’unisono il puntatore sullo schermo, con ritardi, rallentamenti, improvvisi blocchi. Da cosa dipende? Utilizzando sistemi di tracciamento per sviluppatori si è messo a guardare cosa accade frazione di secondo per frazione di secondo, considerando soprattutto che buona parte della potenza bruta della CPU e della memoria era ovviamente libera.
Dopo aver preso appunti inseguendo una serie di processi che mirano ad altri processi critici che a loro volta mirano ad altri processi critici ancora, per una dozzina di volte, alla fine ha trovato una serie di attività del sistema (soprattutto gomacc.exe) che bloccavano la catena per alcuni millesimi di secondo, quanto basta per inchiodare il mouse e renderlo malamente funzionante.
Analizzando ancora meglio l’accaduto, in 1 secondo e 125 millesimi avvenivamo più di 5.768 chiamate e cambiamenti di contesto per una somma totale di eventi che richiedeva 5 secondi e 77 per essere eseguita. Senza contare poi il problema dell’avvio e della chiusura dei processi: entrambe le fasi sono gestite direttamente dalla CPU, come ovvio, ma prima di essere terminati i processi vengono “messi in fila” e serializzati. Windows 10 non usa il multi-threading e quindi c’è un solo core che attende l’arrivo di tutti i processi da chiudere, in concomitanza con le altre attività che quel core di riferimento deve esere (tutti i lavori “single-core” poggiano sullo stesso core di riferimento, altrimenti sarebbero distribuiti parallelamente e considerati come multi-core). Siccome la macchina ha molti core lo sbilanciamento tra il numero di thread che vengono attivati e vanno in esecuzione in parallelo e il numero di processi che poi devono essere terminati dal core principale è fortemente sbilanciata.
Secondo Dawson, che cita la legge di Amdahl, le parti che non possono essere parallelizzate dominano l’esecuzione del programma o del sistema. In questo caso, a meno di non riavviare il computer ogni pochi giorni, la coda di processi che attendono di essere terminati diventa enorme e alla fine impicca il movimento del mouse, che “poggia” su quello stesso core e ha una velocità che richiede spazio di esecuzione non più disponibile.
Insomma, conclude Dawson, “non si tratta del fatto che ho un processore da 24 core ma non posso muovere il muose, bensì del fatto che proprio perché ho un processore da 24 core non posso muovere il mouse”.
Se siete sviluppatori o comunque appassionati di computer science con competenze su Windows, potete seguire il dibattito sollevato dall’articolo di Dawson al termine della sua pagina.
