superpi: linux vs windows

[thegood85]

Originariamente inviato da homero
piccola disquisizione sul calcolo di PI-greco:

metodo di shanks:

PI=24*arctan(1/8)+arctan(1/57)+arctan(1/239)

formula degli anni '60 sono state calcolate 100.000 cifre

il metodo in assoluto piu' efficente per calcolare PI-greco e' quello basato sulle formule di Ramanujan

Premetto che non sono un esperto in materia, non vado ancora all'università quindi la mia parola contro di voi può valere molto poco più di NIENTE.
Ma dovendo creare un software che calcolasse le cifre del pi greco, ho girato un pò su internet e ho trovato tre implementazioni con le librerie GMP.

La prima, più lenta, utilizza delle piccole varianti dell'algoritmo di Gauss-Legendre, quello utilizzato dai creatori di SuperPi.

La seconda, di mezzo, usa proprio Ramanujan.

La più veloce, però, è quella che usa l'algoritmo di chudnovsky, quindi non so se sia vero che l'algoritmo di Ramanujan sia il più veloce in assoluto.

Sempre specificando che, cmq, non sono andato a vedere in dettaglio le implementazioni degli algoritmi, quindi se la versione di ramanujan sia ottimizzata o utilizzi l'algoritmo da te indicato.

Cmq, in questa pagina è pieno di programmi che calcolano il pigreco.
Le differenze tra un programma e l'altro sono abissali.

Ci sono anche i sorgenti dei tre programmi di cui ho parlato, se volete conferme.

http://www.myownlittleworld.com/pi/otherpi.html

Vorrei anche dire che anche le ottimizzazioni a livello di compilatore sono abbastanza importanti in questi casi, e permettono di guadagnare secondi "preziosi".

[homero]

"quello basato sulle formule di Ramanujan algoritmi adattati da Borwein"

allora Ramanujan non ha fatto nessun algoritmo per il calcolo di Pi-Greco, Borwein nel 1996 tramite alcune disquisizioni sulla convergenza delle serie quadratiche ha per cosi' dire strutturato un algoritmo con cui si sono raggiunte le 100.000 milioni di cifre di PI-greco, un record..
parlo del 1996.

in 8 anni se e' stato elaborato un nuovo metodo piu' efficente questo non e' tra le mie conoscenze.

le librerie di calcolo GNU o altre non fanno alcun testo riguardo alle prestazioni di calcolo assolute degli algoritmi di Pi-greco.

l'importanza dell'algoritmo di Borwein e' quella di aver dimostrato che le cifre di un numero razionale sono in generale indipendenti le une dalle altre, ecco perche' questo ha suscitato un grande interesse negli anni passati....

per quanto riguarda l'efficenza degli algoritmi sul calcolo di PI, esiste una vasta anzi vastissima letteratura a riguardo, che pero' almeno nel stragrande maggioranza la farei rientrare nei giochi matematici o nelle olimpiadi della matematica, niente di piu'.

[DJ RUDY HDI]

le librerie di calcolo GNU o altre non fanno alcun testo riguardo alle prestazioni di calcolo assolute degli algoritmi di Pi-greco.

invece si xkè facendo lo stesso algoritmo di s-pi ma implementandolo su una liberia gnu va mollto+ forte....

garantito...

ciao

[homero]

scusa non ho ben capito cosa intendi...

una volta strutturato un algoritmo di calcolo, uno usa quello che piu' gli aggrada, e le librerie GNU sono soltanto un metodo tra molti, didatticamente valido ma nulla di piu', tanto meno e' quello privilegiato.

non sto parlando di prestazioni dovute alla compilazione, ma ai metodi di programmazione dell'algoritmo.

il fatto che le librerie GNU siano piu' o meno performanti di quella o quell'altra applicazione non ha alcun significato nella mia esposizione, ho soltanto messo in evidenza come sia articolato questo argomento.

a tal proposito se volte misurare le prestazioni pure di due sistemi basta usare software come Mathematica o matlab sia sotto linux che sotto windows e far calcolare le 1m di PI mediante gli algoritmi gia' implementati nei due software, che per forza di cose sono i medesimi, pertanto tutto viene lasciato alla compilazione e all'OS.

questo e' un risultanto piu' attendibile dell'efficenza dei due sistemi operativi rispetto a superPI.

se qualcuno fa la prova e posta i risultati...
io non ho un sistema dual boot linux/win se no li avrei postati io con matlab

[DJ RUDY HDI]

ho capito cosa intendi,....


stiamo andando verso la discussione che ho avuto cn cdimauro x s-pi e yasp e i bench in generale...

è chiaro ke ki ci capisce di infomatica considera i bench sintetici come s-pi una cavolata....ma a noi clokker ci piacciono punto e basta...

yasp è nato da una mia idea x fare s-pi cn la virgola...e invece nn è stato possibile e quindi abbiamo deciso di fare un bench a se sempre basato sul calcolo del pi-greco ma molto + performante....poi ke sia un programma poco valido o molto valido non posso certo io giudicarlo....a me basta che sia funzionale...e divertirmi a limare qualche decimo o centesimo ottimizzando al max hw e sw ke ho a disposizione....proprio come si fa cn qualsiasi altro bench.....solo ke questo è fatto da un italiano....e tra parentesi un mio grande amico....

[homero]

i benchmark sono un ottima cosa cosi' come limare i decimi....
ti consiglio di usare x86 assembler per fare i bench cosi' vedi i materialmente i punti di forza di ogni processore

[thegood85]

Originariamente inviato da homero
"quello basato sulle formule di Ramanujan algoritmi adattati da Borwein"

allora Ramanujan non ha fatto nessun algoritmo per il calcolo di Pi-Greco, Borwein nel 1996 tramite alcune disquisizioni sulla convergenza delle serie quadratiche ha per cosi' dire strutturato un algoritmo con cui si sono raggiunte le 100.000 milioni di cifre di PI-greco, un record..
parlo del 1996.

Come detto in precedenza, non ho le competenze per questo argomento. L'ho chiamato "algoritmo di Ramanujan" più che altro per praticità

le librerie di calcolo GNU o altre non fanno alcun testo riguardo alle prestazioni di calcolo assolute degli algoritmi di Pi-greco.

Certo, le librerie di calcolo non fanno testo, in quanto un algoritmo può "ipoteticamente" dover utilizzare funzioni che nelle GNU MP impiegano tempi maggiori ad altre utilizzate da altri algoritmi, solo xkè queste funzioni sono implementate male nelle librerie.
E' xò un caso strano, non impossibile (basti vedere la differenza tra l'output di interi e quello di float) ma almeno "particolare".
Per aver la certezza andrebbero implementati gli algoritmi almeno con altre librerie o cmq studiare il comportamento delle librerie utilizzate.
In ogni caso, se controlli la pagina linkata prima, i programmi più veloci non usano "l'algoritmo di Ramanujan", ma quello di chudnovsky.

Ripeto, non voglio mettere in dubbio le tue conoscenze, che sono sicuramente più elevate delle mie, senza ombra di dubbio.
Volevo solo dirti che avevo visto questo algoritmo che mi sembrava più veloce di quello di cui avevi parlato.

l'importanza dell'algoritmo di Borwein e' quella di aver dimostrato che le cifre di un numero razionale sono in generale indipendenti le une dalle altre, ecco perche' questo ha suscitato un grande interesse negli anni passati....

per quanto riguarda l'efficenza degli algoritmi sul calcolo di PI, esiste una vasta anzi vastissima letteratura a riguardo, che pero' almeno nel stragrande maggioranza la farei rientrare nei giochi matematici o nelle olimpiadi della matematica, niente di piu'.

Mai piaciute le olimpiadi della matematica. Non sono un gran matematico (cosa piuttosto brutta per un informatico) e il massimo che ho fatto è stato raggiungere le selezioni provinciali.
Anche se alle Olimpiadi di Informatica ho trovato gente che di informatica conosceva un c***o e andava avanti solo grazie alla matematica.
Tanto di cappello per loro e per la matematica in generale.
In ogni caso, non ho mai messo in discussione l'importanza dell'algoritmo da te citato (almeno credo; se l'ho fatto, chiedo scusa)

[thegood85]

Originariamente inviato da homero
i benchmark sono un ottima cosa cosi' come limare i decimi....
ti consiglio di usare x86 assembler per fare i bench cosi' vedi i materialmente i punti di forza di ogni processore

Dj Rudy non sa neanche cos'è un assembler!!!

Io, purtroppo, si!

Oltre ad averlo fatto a scuola, ho programmato un bel pò con dei pic, che usano un linguaggio assembly, ovviamente specifico per quei processori!

Cmq, dal mio punto di vista, è puù comodo interfacciarsi a librerie già pronte, senza dover riscrivere tutto, solo per "limare qualche decimo"
Certo, 'sta cosa è criticabile, ma, al giorno d'oggi, con la potenza di calcolo, penso sia più uno spreco riscrivere tutto il codice personalmente (che tra l'altro comporta non poca fatica e oltretutto bisogno di conoscenze enormi) che utilizzare librerie già pronte, magari non perfette dal punto di vista della velocità.

In ogni caso, mia modesta opinione, niente di più.

[cdimauro]

Originariamente inviato da Yashiro
Stavo per scrivere quando ho visto l'intervento di DJ RUDY HDI per il suo lavoro, e di quello volevo parlare...

ottimizzando l'algoritmo di calcolo si può scendere di molto coi tempi, così come cambiando sistema operativo, ma si falserebbe il metro di misura....

Allora facciamoci un programma super ottimizzato e un sistema operativo realizzato appositamente per questo, e sofndiamo i 25secondi con i PII!

E' più che altro una questione di comodità, per mantenere un paragone valido con tutti i test già fatti..

Questo può andare bene SE E SOLO SE verrà utilizzato un compilatore che genera lo STESSO codice per i due sistemi operativi diversi (fatta eccezione per le chiamate di sistema, ovviamente).

[cdimauro]

Piccola nota tecnica: si scrive assembly, linguaggio assembly. Assembler è il compilatore!

P.S. Quello dei PIC è veramente ORRIBILE.

[thegood85]

Originariamente inviato da cdimauro
Piccola nota tecnica: si scrive assembly, linguaggio assembly. Assembler è il compilatore!

P.S. Quello dei PIC è veramente ORRIBILE.

Lo so che è orribile, non a caso per la tesina di maturità, dovendo portare un circuito che filtrasse i movimenti ottenuti da un mouse e li rimandasse elaborati al PC, dopo un pò di lavoro sono passato ad un compilatore C!!!

Il codice era, ovviamente, meno ottimizzato, ma potevi fare MOLTE più cose senza sbatterti troppo.

Ovviamente poi ricontrollavo il codice generato e dove utile sostituivo con codice assembly, in alcuni casi guadagnavi un casino, visto che il compilatore faceva rigiri pazzeschi!!!

[cdimauro]

Ti posso capire benissimo: per poter lavorare coi PIC mi sono scritto un compilatore assembly ad alto livello per disperazione. Ma anche così, non è che fosse comodo lavorarci: l'architettura fa veramente schifo, ivi compresa la parte embedded (timer, porte, ecc.). Per fortuna alla fine il progetto su cui dovevo lavorare è saltato, per cui ho smesso di perdere tempo a josa su quest'abominio.

P.S. Se avessero messo un 6502 e i VIA del VIC20, il chip sarebbe costato meno e i programmatori sarebbero stati molto più produttivi...