View Full Version : superpi: linux vs windows
bionicoz
26-07-2004, 23:08
ho provato a spingere senza pretese il mio northwood 2.8, ecco i risultati di superpi..
qui con winzozz..
http://www.bionicoz.biz/images/superpi_win_260704.jpg
e qui con GNU/linux:
http://www.bionicoz.biz/images/superpi_linux_260704.jpg
commenti a proposito di questa differenza di prestazioni? :)
folagana
26-07-2004, 23:14
Questo dimostra come linux usi meno risorse di windows;)
interessante... possibile che nessuno se ne fosse mai accorto? :D
Originariamente inviato da GiSje!
interessante... possibile che nessuno se ne fosse mai accorto? :D
:old:
|unknown|
26-07-2004, 23:24
Originariamente inviato da stock
:old:
esatto :D
ci mette troppo di meno... evidentemente viene pure calcolato in maniera diversa e quindi non si puo paragonare
cmq non è riconosciuto ed è x quello che si usa winzoz penso
folagana
26-07-2004, 23:30
Originariamente inviato da |unknown|
esatto :D
ci mette troppo di meno... evidentemente viene pure calcolato in maniera diversa e quindi non si puo paragonare
cmq non è riconosciuto ed è x quello che si usa winzoz penso
non può essere calcolato in modo diverso..... è l'archittettura di linux che lascia libere più risorse... provate a fare girare il PI su Win95 e mi saprete dire
|unknown|
27-07-2004, 10:34
Originariamente inviato da folagana
non può essere calcolato in modo diverso..... è l'archittettura di linux che lascia libere più risorse... provate a fare girare il PI su Win95 e mi saprete dire
lo so... ho usato e uso a volte linux e con l'interfaccia figa che ha funziava alla perfezione senza swappamenti pure con 128mb di ram del pc vecchio ;)
boh
secondo me oltre ad essere piu veloce perchè usa meno risorse linux, lo è perchè sarà fatto anche meglio il programmino del superPi
|unknown|
27-07-2004, 10:38
Originariamente inviato da fratus
boh
secondo me oltre ad essere piu veloce perchè usa meno risorse linux, lo è perchè sarà fatto anche meglio il programmino del superPi
appunto... qualche ottimizzazione e qualche decina di mb in meno sulla ram non possono dare così tanto... dietro ci sta una versione ottimizzata pure del calcolo imho
Originariamente inviato da |unknown|
appunto... qualche ottimizzazione e qualche decina di mb in meno sulla ram non possono dare così tanto... dietro ci sta una versione ottimizzata pure del calcolo imho
Aggiungo che secondo me il programmino da Linux gira meglio perche' essendo scritto per un OS open source si integra meglio.
Io l'ho fatto il Super pi su linux (debian)
sul mio server di casa :read:
P 200 mmx :read:
28 minuti :rotfl:
Originariamente inviato da folagana
provate a fare girare il PI su Win95 e mi saprete dire
veramente su win9x è molto + lento che su 2k/xp :muro: :p :D
almeno su Win98 ho provato e il test 1M ci metteva anche 10-15" in + rispetto a win2k :eek:
byez!
The DeViL's
27-07-2004, 12:45
Originariamente inviato da Sengo
Io l'ho fatto il Super pi su linux (debian)
sul mio server di casa :read:
P 200 mmx :read:
28 minuti :rotfl:
beato te che c hai messo cosi poco :D
Malachia[PS2]
27-07-2004, 14:24
mah la differenza mi sebra davvero troppa...e cmq in quello di win scusa hai fatto un risultato penoso per quella frequenza no?
secondo me comunque lì non è linux che va meglio, è la tua installazione di windows che è alla frutta: 43 sec per quella configurazione sono un'enormità, mentre 36 sono ok.
bionicoz
27-07-2004, 17:59
mmm dunque secondo voi questo
-> Installed: (XP was installed 153wks 1day 20hrs 57mins 7secs)
può centrare qualcosa? (ho anche cambiato mobo e procio senza reinstallare durante quel periodo :rolleyes: )
|unknown|
27-07-2004, 18:26
cioe cambi mobo e magari chipset senza formattare?? altro che secondi ti prendi :asd:
Originariamente inviato da stock
:old:
potresti motivare questa tua faccina?...grazie ;)
se hai qualche fonte da citare, ben venga :O
|unknown|
27-07-2004, 22:38
Originariamente inviato da Qnick
potresti motivare questa tua faccina?...grazie ;)
se hai qualche fonte da citare, ben venga :O
ha risposto al "nessuno lo sapeva??"... pure io lo sapevo da un casino e lo stesso lui...
spero di giustificare giusto :D
beh..se si riferiva al fatto che in genere linux utilizzi molte meno risorse di win, certamente non vi erano dubbi :)
rispetto invece a tale differenza di prestazioni tra i due S.O. con tale bench, beh io personalmente non ne ero al corrente e ne sono rimasto colpito, se fosse stata cosa largamente risaputa chiedo venia..anzi mi piacerebbe leggere qualche articolo o commento in proposito ;)
|unknown|
27-07-2004, 23:00
Originariamente inviato da Qnick
beh..se si riferiva al fatto che in genere linux utilizzi molte meno risorse di win, certamente non vi erano dubbi :)
rispetto invece a tale differenza di prestazioni tra i due S.O. con tale bench, beh io personalmente non ne ero al corrente e ne sono rimasto colpito, se fosse stata cosa largamente risaputa chiedo venia..anzi mi piacerebbe leggere qualche articolo o commento in proposito ;)
io lo sapevo ma x sentito dire... questi fatti danno confema. forse è esagerato old però novità non è tutto qua ;)
anzi dal successo del 3d direi che non molti lo sapevano...
Capirossi
07-08-2004, 17:04
Ma il SuperPi l'hai fatto con Gentoo ?
Il punteggio che hai fatto con win e' troppo alto, c'e' qualcosa che non va'. A quella frequenza dovresti fare almeno 40.
E poi, premesso che considero anche io Linux meno avido di risorse e piu' efficiente, non si possono confrontare i risultati ottenuti da due programmi diversi, anche se fanno la stessa cosa.
Se guardi il 3ad in rilievo su Yasp, puoi vedere che differenze ci siano tra due programmi simili ma con "sorgenti" diversi.
Io a 3500mhz il superpi' da 1mb lo faccio in 40sec, con Yasp 23!!!
Ciao!
cdimauro
08-08-2004, 06:37
Originariamente inviato da folagana
Questo dimostra come linux usi meno risorse di windows;)
Le dimostrazioni vanno fatte con una metodologia rigorosa. Una di queste impone l'utilizzo della STESSA applicazione... ;)
cdimauro
08-08-2004, 06:52
Originariamente inviato da folagana
non può essere calcolato in modo diverso.....
Come fai a dirlo con tanta leggerezza? Se cerchi in giro noterai che esistono altri programmi che fanno la stessa cosa, ma in modi diversi. :rolleyes:
è l'archittettura di linux che lascia libere più risorse... provate a fare girare il PI su Win95 e mi saprete dire
E questo è abbastanza strano, perché l'incidenza del s.o. dovrebbe essere ridotta ai minimi termini con questo tipo di applicazioni "intensive": in pratica soltanto lo scheduler dovrebbe portare via una PICCOLA parte del tempo di CPU, comunque trascurabile rispetto alla mole di calcoli.
E' da vedere, poi, in che modo è stato implementato l'algoritmo. Certamente, a parte l'allocazione del buffer di memoria per contenere i risultati, l'applicazione dovrebbe entrare in un ciclo che si occupa esclusivamente di portare a termine i conti, al più chiamando ogni tanto il s.o. per visualizzare qualche risultato parziale (ma anche qui, l'incidenza dovrebbe essere ridottissima).
Insomma, la questione non è certamente così semplice come la si potrebbe immaginare...
cdimauro
08-08-2004, 06:58
Originariamente inviato da rip82
Aggiungo che secondo me il programmino da Linux gira meglio perche' essendo scritto per un OS open source si integra meglio.
Questa cosa non sta né in cielo né in terra...
|unknown|
08-08-2004, 10:40
vi ricordo che in tempo reale risorse o meno risorse prima viene il superpi e dopo l'os solo quando lo decide lui:rolleyes:
ricordo che un solo processo ha il "tempo reale"...
linux e win non si possono confrontare..
insomma quoto cdimauro :D
folagana
08-08-2004, 22:22
calcolare il PI greco è un algoritmo univoco, che poi possa essere
tradotto in linguaggio di programmazione in maniera differente
non vi è dubbio. Ammetto che alcuni algoritmi potrebbero essere meglio sviluppati di altri ma non credo sia questo il caso il calcolo matematico è semplice e non vi sono tante ottimizzazioni da fare, cmq...
per il sistema operativo io realizzo tempi migliori quando
il sistema operativo non è stato ancora installato.
Su win98 faccio 1 secondo in meno a sistema operativo "fresco"
questa è la mia esperienza.
DJ RUDY HDI
08-08-2004, 22:29
dal 3 luglio fatta la prova nel team...
6 sec di differenza....
http://alemhz.altervista.org/phpBB2/viewtopic.php?t=1395
cdimauro
09-08-2004, 06:17
Originariamente inviato da folagana
calcolare il PI greco è un algoritmo univoco,
Come fai a dirlo con tanta leggerezza? :rolleyes:
1) Esiste almeno un metodo basato sulla somma di particolari frazioni, che ho visto quindici anni fa un un libro delle superiori e che purtroppo non ho più da tempo.
2) Puoi ottenerlo calcolando 4 * ArcTan(1) (come dovresti sapere, Tan(PI / 4) = 1, per cui applicando la funzione inversa di Tan, ArcTan, possiamo ottenere Pi Greco). Procedendo in questo modo, esistono diverse possibilità, ma te ne espongo due che sono le più usate:
a) Applicando il teorema di Taylor/McLaurin ti ricavi la sommatoria necessaria, e la implementi
b) Utilizzi il sistema CORDIC (utilizza solamente somme, sottrazioni, e shift per implementare su calcolatore le funzioni anche complesse come queste) e implementi le iterazioni necessarie per calcolarti quanto scritto sopra (a ogni iterazione viene ricavato un nuovo bit del risultato finale).
Queste sono le prime cose che mi sono vengono in mente. Come vedi la tua affermazione è alquanto discutibile...
che poi possa essere
tradotto in linguaggio di programmazione in maniera differente non vi è dubbio.
Questo è soltanto un dettaglio. Che può essere anche rilevante (basta programmare male, e non è che ci voglia molto), ma sempre dettaglio rimane...
Ammetto che alcuni algoritmi potrebbero essere meglio sviluppati di altri ma non credo sia questo il caso il calcolo matematico è semplice e non vi sono tante ottimizzazioni da fare, cmq...
Questo lascialo dire agli esperti... ;)
per il sistema operativo io realizzo tempi migliori quando il sistema operativo non è stato ancora installato.
Su win98 faccio 1 secondo in meno a sistema operativo "fresco"
questa è la mia esperienza.
Bene. Io ho riportato la mia... :)
Beh,provate il superpi con windows ME...solo con azoto si scende sotto i 40s.:D
DJ RUDY HDI
09-08-2004, 09:15
confermo....ci sn vari modi x calcolare pi-greco.....
con thegood ne abbiamo provati vari.....per vedere di trovarne un performante....x yasp....
cdimauro hai visto l'ultima versione....????
ToO_SeXy
09-08-2004, 10:33
Solo io ho la release di linux che non parte su PC overclokkati???
cdimauro
09-08-2004, 21:31
Originariamente inviato da DJ RUDY HDI
confermo....ci sn vari modi x calcolare pi-greco.....
con thegood ne abbiamo provati vari.....per vedere di trovarne un performante....x yasp....
cdimauro hai visto l'ultima versione....????
No, francamente aspetto che il programma arrivi a una certa maturità per provarlo: non ho ADSL e ho poco tempo a disposizione, sfortunatamente...
folagana
10-08-2004, 00:18
Originariamente inviato da DJ RUDY HDI
confermo....ci sn vari modi x calcolare pi-greco.....
con thegood ne abbiamo provati vari.....per vedere di trovarne un performante....x yasp....
cdimauro hai visto l'ultima versione....????
ma uno solo è veloce.... cmq
vedo che siete piuttosto documentati....
PS ho esperienza acquisista all'università con ben 3 esami di
analisi numerica è ho scritto diverse routine per calcolare
il PI greco per il piacere dei miei prof. ed onestamente
quando dico che ne esiste uno solo intendo quello più
veloce....
voglio dire in soldoni che se voi dovreste scrivere un algoritmo
per l'ordinamento cosa usate bubble sort?
cmq non volevo essere frainteso..... nella mia definizione di univoco intendo che esiste un solo algoritmo apprezzato a livello accademico ...
ciao
grazie per la piacevole dissertazione
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..
cdimauro
10-08-2004, 06:12
Originariamente inviato da folagana
ma uno solo è veloce.... cmq
Questo è un altro discorso: non l'avevi scritto nel tuo precedente messaggio. ;)
vedo che siete piuttosto documentati....
PS ho esperienza acquisista all'università con ben 3 esami di
analisi numerica è ho scritto diverse routine per calcolare
il PI greco per il piacere dei miei prof. ed onestamente
quando dico che ne esiste uno solo intendo quello più
veloce....
Non conosco tutta la documentazione in materia, e quindi non ti posso rispondere. Comunque anch'io ho abbastanza esperienza acquisita all'università, visto che mi sono laureato da poco... :D
voglio dire in soldoni che se voi dovreste scrivere un algoritmo per l'ordinamento cosa usate bubble sort?
Dipende:
- se l'insieme dei dati è piccolo (sul centinaio di valori), l'operazione va effettuata una volta ogni tanto e ho poco tempo per realizzare questa parte di codice, allora uso il Bubble-Sort, o meglio il Select-Sort (il più semplice da implementare, IMHO);
- altrimenti, bisogna vedere in quale contesto verrà utilizzato l'algoritmo di ordinamento: normalmente preferisco usare l'Heap-Sort (caso generico), ma nel caso in cui i dati sono "abbastanza casuali" (leggi: non ci troviamo mai di fronte a dati già ordinati in ordine inverso) e ci possono essere problemi di swap (i dati si trovano su pagine che possono essere spostare sul file di swap), allora preferisco il Quick-Sort;
- infine, se ho a disposizione un buffer di memoria temporaneo, posso prendere in considerazione il Merge-Sort, o meglio ancora l'ordinamento a chiave multipla (che è "quasi" lineare).
La questione non è così banale, insomma. :) E penso che potrebbe essere la stessa cosa per il calcolo di Pi Greco... ;)
cmq non volevo essere frainteso..... nella mia definizione di univoco intendo che esiste un solo algoritmo apprezzato a livello accademico ...
ciao
grazie per la piacevole dissertazione
Idem. Come ho già detto, non conosco la letteratura in materia, per cui non mi posso esprimere...
Ciao
DJ RUDY HDI
10-08-2004, 09:49
cambiando algoritmo....abbiamo fatto anke 5 sec nel s-pi da 1mb cn un barton 3200....quali siano gli algortimi usati io nn lo so (io nn sn programmatore ma solo un overclocker.....) lo sa thegood che ho invitato a partecipare qui alla discussione....
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
dopo una attenta analisi dell'errore si verifica a quale ordine approssimare arctan....
il perche' di arctan si trova in un libro di analisi II vecchio ordinamento...
mentre il calcolo dell'ordine a cui arrestarsi per ottenere risultati esatti dipende da quante cifredi PI vogliamo calcolare....
il metodo in assoluto piu' efficente per calcolare PI-greco e' quello basato sulle formule di Ramanujan algoritmi adattati da Borwein la formula e' la seguente
Y0=1/sqrt(2)
Yn=(1-sqrt(1-(Yn-1)^2))/(1+sqrt(1-(Yn-1)^2))
A0=1/2
An=(An-1)*(1+Yn)^2-(2^n)*Yn
An approsima 1/PI con convergenza quadratica(ovvero ad ogni ciclo raddoppia il numero di cifre esatte)
200 volte piu' efficente di quello usato negli anni '60
esiste anche un algortimo che usa soltanto le 4 operazioni, penso lo si trovi nei libri di liceo o di trigonometria.....
molti altri algoritmi per il calcolo di questo storicamente famoso numero sono stati elaborati nei secoli e paragonare software diversi per il calcolo di PI senza averne tra le mani il listato e' soltanto elucubrazione...
a parita di treand aperti le differenze tra windows e linux nel calcolo matematico sono trascurabili 5% circa si rileva con matlab...
altra storia se siutilizzano software compilati e ottimizzati per un determinato hardware specifico.
thegood85
10-08-2004, 11:27
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".
"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
10-08-2004, 17:24
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
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
10-08-2004, 20:03
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....
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
11-08-2004, 00:56
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
11-08-2004, 01:03
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!!! :D :D :D :D
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":D :D :D :D
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
11-08-2004, 06:38
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
11-08-2004, 06:41
Piccola nota tecnica: si scrive assembly, linguaggio assembly. Assembler è il compilatore!
P.S. Quello dei PIC è veramente ORRIBILE. :eek:
thegood85
11-08-2004, 23:06
Originariamente inviato da cdimauro
Piccola nota tecnica: si scrive assembly, linguaggio assembly. Assembler è il compilatore!
P.S. Quello dei PIC è veramente ORRIBILE. :eek:
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
12-08-2004, 05:59
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... :oink:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.