💾 Archived View for it.omarpolo.com › articoli › ottimizzazioni.gmi captured on 2024-08-25 at 00:05:35. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Ottimizzazioni?

Stamattina ho notato un thread curioso su openbsd-misc: un tale chiedeva un feedback su un’issue di starlark-go

google/starlark-go

starlark-go sembra essere un’implementazione in go di un linguaggio per la configurazione. Prima d’oggi non l’avevo mai sentito nominare, e di mio non ho una grande considerazione per i linguaggi per la configurazione, ma salverò questo argomento per un’altra volta.

L’issue riguardava un comportamento curioso: l’interprete prova ad allocare 4GB di memoria virtuale per rappresentare tutti i possibili numeri a 32 bit.

int_posix64.go

Ora, allocare un po’ di spazio extra per valori noti non è qualcosa di così tanto strano, anzi, direi piuttosto diffuso. Alcuni linguaggi, come Python e Go mi sembra, allocano dello spazio per rappresentare i primi 50-100 numeri naturali, che spesso sono i più frequenti nei sorgenti, in modo da risparmiare un po’ di allocazioni durante l’esecuzione.

Quale è la linea tra un’ottimizzazione utile e uno spreco di risorse? Riservare 4GB di memoria virtuale per ottimizzare un linguaggio per la configurazione — manco fosse calcolo numerico — è troppo? Sui moderni sistemi 64 bit riservare 4GB di memoria virtuale, per di più inutilizzata, non è un enorme problema: lo spazio degli indirizzi disponibile è enorme. D’altra parte, riservare un quantitativo non banale di spazio, sebbene ci sia la possibilità e in teoria non abbia controindicazioni per una minuscola ottimizzazione in un linguaggio che a occhio non sembra essere pensato per il calcolo numerico sembra uno spreco.

Per me, esterno al progetto, l’opinione è facile: spreco. Ma se fossi uno sviluppatore di starlark, riuscirei a resistere alla tentazione di usare un po’ di memoria virtuale extra per un tempo migliore nei benchmark?

In un caso estremo del genere confido ancora nel mio senno e credo lo considererei uno spreco, ma per un caso un po’ meno esagerato?

Sidebar sull’uso della memoria: i 4GB di memoria virtuale allocata non sono usati ma vengono solo riservati e, a detta di uno dei dev, tentare di accedere a quella memoria risulterebbe in un crash del programma (SIGSEGV). L’ottimizzazione sembra stare nel non dover comparare i valori degli oggetti ma solo i relativi puntatori. Se tutti i numeri naturali “vivono” in un certo range di memoria il loro puntatore sarà ‘$indirizzo_base + n’ per il numero naturale ‘n’. Un’interessante conseguenza è che questo puntatore sarà unico: comparare ‘n’ con un big.Int non richiederà di comparare i valori ma solo i relativi puntatori.

$BlogIt: ottimizzazioni.gmi,v 1.1 2021/10/20 07:41:40 op Exp $