Ho recentemente scoperto il sito rosettacode.org, che tratta la soluzione di determinati problemi o design patterns in diversi linguaggi, oltre che come i vari linguaggi approccino problematiche diffuse.
Nella seconda casistica ricadono cose tipo la chiamata di funzione con il passaggio di parametri per nome, di cui avevo parlato tempo fa nel mondo Python.
Nella prima casistica ci sono approcci di linguaggi differenti a problematiche ben note, fra cui per esempio la scomposizione in fattori primi.
Problema matematicamente noto, quindi non particolarmente interessante, che in Python viene risolto facendo uso di alcuni costruiti che non avevo mai usato.
Mi sono quindi imbastito a confrontare il programma fornito, la sua versione ottimizzata e la mia soluzione al problema.
Dopo qualche tentativo andato in fumo a causa di un erroraccio di ottimizzazione da parte mia, sono fottutamente orgoglioso di dire che la mia versione disintegra la soluzione ottimizzata proposta, con un fattore che in svariati casi è vicina al 2 a 1 su numeri oltre le 10 cifre.
Le versioni originali le trovate qui, quelle python esattamente qui, mentre la mia, la potete leggere a seguire:
Per la cronaca ho preso e completato la versione Java proposta e l'ho paragonata alla mia e risulta piuttosto evidente la superiorità della mia soluzione. Il paragone è fra Java 1.5 e Py 2.6 (lo dico a beneficio di chi dovesse confrontare java 1.6 contro Py3 e trovare risultati magari eclatantemente diversi).
Il problema è, ovviamente, di sola mancata ottimizzazione del codice Java. Dico ovviamente perché Java è più performante di py di parecchie lunghezze, se si parla di calcoli puri fortemente iterativi. L'inghippo sta nel fatto che il codice Java è scarsamente ottimizzato, mentre quello Py, e il mio in particolare, è piuttosto ben limato.
Questo per ricollegarci in modo nuovo al discorso sui benchmark di qualche tempo fa: un algoritmo ottimizzato in un linguaggio lento spesso è prestazionalmente migliore di uno scritto alla buona in un linguaggio veloce.
Ovviamente ottimizzando per quanto possibile la versione Java (non ho trovato in 5 minuti di googling come fare la radice quadrata di un BigInteger) siamo andati a pari sino a cifre molto molto grosse, poi dai 16 digits in su....ha vinto lui. Capita.
Ultima nota di colore: guardate questa implementazione nel liguaggio False (mai sentito nominare): [2[\$@$$*@>~][\$@$@$@$@\/*=$[%$." "$@\/\0~]?~[1+1|]?]#%.]d:
Astonishing!
Nessun commento:
Posta un commento