đž Archived View for it.omarpolo.com âş articoli âş ottimizzazioni.gmi captured on 2024-06-16 at 12:24:27. Gemini links have been rewritten to link to archived content
âŹ ď¸ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Stamattina ho notato un thread curioso su openbsd-misc: un tale chiedeva un feedback su unâissue di 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.
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 $