-- Leo's gemini proxy

-- Connecting to it.omarpolo.com:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini;lang=it

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 $

-- Response ended

-- Page fetched on Fri Mar 29 11:54:09 2024