-
alex,tg ha ragione e sassofono no
Inizio divisioni: 1289928957 Divisioni: 22 Inizio lookups: 1289928979 Lookups: 19
su un pentium III a 700 mhz
-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 18:40:00.0 alle 2010-11-16 18:40:00.0- Scritto da: Caccola
>Inizio divisioni: 1289928957 > Divisioni: 22 > Inizio lookups: 1289928979 > Lookups: 19
>
> su un pentium III a 700 mhz

compilatore?
abbiamo già appurato in chat che gcc ottimizza via la divisione con moltiplicazioni e shift. Risultato: il lookup è circa il 40% più lento su un core2 duo 3 Ghz-
Re: alex,tg ha ragione e sassofono no> abbiamo già appurato in chat che gcc ottimizza
> via la divisione con moltiplicazioni e shift.
Cosi` non vale. Io mi riferivo alla divisione intera "dura e pura". Se il divisore era inottimizzabile ce lo volevo vedere il gcc.
-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 18:57:00.0 alle 2010-11-16 18:57:00.0- Scritto da: alex.tg
> > abbiamo già appurato in chat che gcc ottimizza
> > via la divisione con moltiplicazioni e shift.
>
> Cosi` non vale. Io mi riferivo alla divisione
> intera "dura e pura". Se il divisore era
> inottimizzabile ce lo volevo vedere il gcc.
>
questo su un ARM 400Mhz e gcc 4.4.5
Divisioni: 28
Lookups: 107
-
Re: alex,tg ha ragione e sassofono no> questo su un ARM 400Mhz e gcc 4.4.5
>
> Divisioni: 28
> Lookups: 107
Questo su un Core2 Duo 2800MHz e Linoleum 2.
Divisioni: 109
Lookups: 47
http://www.forumdeitroll.it/m.aspx?m_id=2545998&m_...
-
Re: alex,tg ha ragione e sassofono no
- Scritto da: alex.tg
> > questo su un ARM 400Mhz e gcc 4.4.5
> >
> > Divisioni: 28
> > Lookups: 107
>
> Questo su un Core2 Duo 2800MHz e Linoleum 2.
>
> Divisioni: 109
> Lookups: 47
>
> http://www.forumdeitroll.it/m.aspx?m_id=2545998&m_
perchè tu quando dividi per 25 devi moltiplicare per 100 e dividere per 4!-
Re: alex,tg ha ragione e sassofono no> > > questo su un ARM 400Mhz e gcc 4.4.5
> > >
> > > Divisioni: 28
> > > Lookups: 107
> >
> > Questo su un Core2 Duo 2800MHz e Linoleum 2.
> >
> > Divisioni: 109
> > Lookups: 47
> >
> >
> http://www.forumdeitroll.it/m.aspx?m_id=2545998&m_
>
>
> perchè tu quando dividi per 25 devi moltiplicare
> per 100 e dividere per
> 4!
Quella e` probabilmente la soluzione migliore in tutti i casi, perche` non risente delle caratteristiche dell'architettura.
-
-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 20:58:00.0 alle 2010-11-16 20:58:00.0- Scritto da: alex.tg
> > questo su un ARM 400Mhz e gcc 4.4.5
> >
> > Divisioni: 28
> > Lookups: 107
>
> Questo su un Core2 Duo 2800MHz e Linoleum 2.
>
> Divisioni: 109
> Lookups: 47
>
> http://www.forumdeitroll.it/m.aspx?m_id=2545998&m_
spero che quelli non siano secondi
-
Re: alex,tg ha ragione e sassofono noSono millisecondi.
Ho dovuto pero` raddoppiare il numero degli elementi a 20 milioni perche` il timer di Windoze non e` che sia precisissimo e c'era troppo margine d'errore con 10 milioni. Essenzialmente, significa 47 millisecondi per 20 milioni di divisioni.-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 21:03:00.0 alle 2010-11-16 21:03:00.0- Scritto da: alex.tg
> Sono millisecondi.
>
> Ho dovuto pero` raddoppiare il numero degli
> elementi a 20 milioni perche` il timer di Windoze
> non e` che sia precisissimo e c'era troppo
> margine d'errore con 10 milioni. Essenzialmente,
> significa 47 millisecondi per 20 milioni di
> divisioni.
ah ok allora i numeri non sono confrontabili, visto che il programma sassofonico ne 10M per 50 volte-
Re: alex,tg ha ragione e sassofono no> > Sono millisecondi.
> >
> > Ho dovuto pero` raddoppiare il numero degli
> > elementi a 20 milioni perche` il timer di
> Windoze
> > non e` che sia precisissimo e c'era troppo
> > margine d'errore con 10 milioni. Essenzialmente,
> > significa 47 millisecondi per 20 milioni di
> > divisioni.
>
> ah ok allora i numeri non sono confrontabili,
> visto che il programma sassofonico ne 10M per 50
> volte
um.. se time_t restituisce un tempo in secondi, allora dovrebbe essere 500 milioni di divisioni in 28 secondi, quindi
0,000000056s per divisione (listato C su ARM);
0,00000000235s per divisione (listato Linoleum su Core2 Duo).
Piu` che altro non ha senso confrontarli su architetture diverse.
-
-
-
Re: alex,tg ha ragione e sassofono no- Scritto da:
> - Scritto da: alex.tg
> > > questo su un ARM 400Mhz e gcc 4.4.5
> > >
> > > Divisioni: 28
> > > Lookups: 107
> >
> > Questo su un Core2 Duo 2800MHz e Linoleum 2.
> >
> > Divisioni: 109
> > Lookups: 47
> >
> >
> http://www.forumdeitroll.it/m.aspx?m_id=2545998&m_
>
> spero che quelli non siano secondi
linoleum: un assembler multipiattaforma fatto per ignorare ogni ottimizzazione dell'architettura specifica!
Prova anche te l'ebrezza di scegliere personalmente ogni istruzione atomica, senza che questo comporti un qualche incremento prestazionale!
Linoleum è quello che ogni vero programmatore ha sempre desiderato: un linguaggio di programmazione difficile ed equivalente su ogni piattaforma; equivalente perché fa schifo ovunque!
Linoleum: il linguaggio di programmazione assembler multipiattaforma*.
*attualmente disponibile solo per processori x86 single core.-
-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 21:15:00.0 alle 2010-11-16 21:15:00.0> Linoleum e` un assembler multipiattaforma e
> basta.
>
Cos'è sta storia? Non doveva essere due volte più veloce del C?
-
Re: alex,tg ha ragione e sassofono no> > Linoleum e` un assembler multipiattaforma e
> > basta.
> >
>
> Cos'è sta storia? Non doveva essere due volte più
> veloce del C?
>
A meta` degli anni '90, certamente si`. Anche di piu`. Oggi dipende da quanto e` scaltro l'hikikomori alla tastiera rispetto al compilatore C. Ma i compilatori C adottano soluzioni all'ingrosso, a stiracchiare la questione non possono competere. Pero` fanno fare meno fatica.-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 21:21:00.0 alle 2010-11-16 21:21:00.0> i compilatori C adottano
> soluzioni all'ingrosso, a stiracchiare la
> questione non possono competere.
Ah, meno male.
-
Re: alex,tg ha ragione e sassofono no- Scritto da: alex.tg
> > > Linoleum e` un assembler multipiattaforma e
> > > basta.
> > >
> >
> > Cos'è sta storia? Non doveva essere due volte
> più
> > veloce del C?
> >
>
> A meta` degli anni '90, certamente si`. Anche di
> piu`. Oggi dipende da quanto e` scaltro
> l'hikikomori alla tastiera rispetto al
> compilatore C. Ma i compilatori C adottano
> soluzioni all'ingrosso, a stiracchiare la
> questione non possono competere. Pero` fanno fare
> meno
> fatica.
alex dà retta a me, venditi un po' d'anima e mettiti a programmare con le dx11, con le opengl, con quel cazzo che vuoi ma roba normale... secondo me fai fatica all'inizio ma poi viaggi con la fantasia... diventerai il nuovo carmack... ferrari, pupe da sballo, interviste sulle riviste di settore, segretarie con sboccaponcio incluso.... fidaty.-
Re: alex,tg ha ragione e sassofono no> alex dà retta a me, venditi un po' d'anima e
> mettiti a programmare con le dx11, con le opengl,
> con quel cazzo che vuoi ma roba normale...
> secondo me fai fatica all'inizio ma poi viaggi
> con la fantasia... diventerai il nuovo carmack...
> ferrari, pupe da sballo, interviste sulle riviste
> di settore, segretarie con sboccaponcio
> incluso....
> fidaty.
Non sarei piu` me stesso, perderei la mia identita`, mi sentirei come tutti gli altri che programmano con le dx11, con le opengl...
Senza cuore saremmo solo macchine.
- recente pubblicita` dell'Alfa.
-
Re: alex,tg ha ragione e sassofono no
- Scritto da: alex.tg
> > alex dà retta a me, venditi un po' d'anima e
> > mettiti a programmare con le dx11, con le
> opengl,
> > con quel cazzo che vuoi ma roba normale...
> > secondo me fai fatica all'inizio ma poi viaggi
> > con la fantasia... diventerai il nuovo
> carmack...
> > ferrari, pupe da sballo, interviste sulle
> riviste
> > di settore, segretarie con sboccaponcio
> > incluso....
> > fidaty.
>
> Non sarei piu` me stesso, perderei la mia
> identita`, mi sentirei come tutti gli altri che
> programmano con le dx11, con le opengl...
>
>
> Senza cuore saremmo solo macchine.
>
> - recente pubblicita` dell'Alfa.
senza macchine saremmo dei pedoni sfigati con la tessera del metro
-
-
-
-
-
-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 21:49:00.0 alle 2010-11-16 21:49:00.0Trollate totali: 18184
- Scritto da: Caccola
> - Scritto da:
> > - Scritto da: alex.tg
> > > > questo su un ARM 400Mhz e gcc 4.4.5
> > > >
> > > > Divisioni: 28
> > > > Lookups: 107
> > >
> > > Questo su un Core2 Duo 2800MHz e Linoleum 2.
> > >
> > > Divisioni: 109
> > > Lookups: 47
> > >
> > >
> >
> http://www.forumdeitroll.it/m.aspx?m_id=2545998&m_
> >
> > spero che quelli non siano secondi
>
> linoleum: un assembler multipiattaforma fatto per
> ignorare ogni ottimizzazione dell'architettura
> specifica!
> Prova anche te l'ebrezza di scegliere
> personalmente ogni istruzione atomica, senza che
> questo comporti un qualche incremento
> prestazionale!
> Linoleum è quello che ogni vero programmatore ha
> sempre desiderato: un linguaggio di
> programmazione difficile ed equivalente su ogni
> piattaforma; equivalente perché fa schifo
> ovunque!
>
> Linoleum: il linguaggio di programmazione
> assembler multipiattaforma*.
>
> *attualmente disponibile solo per processori x86
> single
> core.
ROSIK
I think happiness is love
- Vladimir Putin-
Re: alex,tg ha ragione e sassofono no
- Scritto da: avvelentani
>
> - Scritto da: Caccola
> > - Scritto da:
> > > - Scritto da: alex.tg
> > > > > questo su un ARM 400Mhz e gcc 4.4.5
> > > > >
> > > > > Divisioni: 28
> > > > > Lookups: 107
> > > >
> > > > Questo su un Core2 Duo 2800MHz e Linoleum 2.
> > > >
> > > > Divisioni: 109
> > > > Lookups: 47
> > > >
> > > >
> > >
> >
> http://www.forumdeitroll.it/m.aspx?m_id=2545998&m_
> > >
> > > spero che quelli non siano secondi
> >
> > linoleum: un assembler multipiattaforma fatto
> per
> > ignorare ogni ottimizzazione dell'architettura
> > specifica!
> > Prova anche te l'ebrezza di scegliere
> > personalmente ogni istruzione atomica, senza che
> > questo comporti un qualche incremento
> > prestazionale!
> > Linoleum è quello che ogni vero programmatore ha
> > sempre desiderato: un linguaggio di
> > programmazione difficile ed equivalente su ogni
> > piattaforma; equivalente perché fa schifo
> > ovunque!
> >
> > Linoleum: il linguaggio di programmazione
> > assembler multipiattaforma*.
> >
> > *attualmente disponibile solo per processori x86
> > single
> > core.
>
> ROSIK
Però sotto sotto lo sai che ho ragione...
-
-
-
-
-
-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 21:46:00.0 alle 2010-11-16 21:46:00.0Trollate totali: 18184
- Scritto da: alex.tg
> > abbiamo già appurato in chat che gcc ottimizza
> > via la divisione con moltiplicazioni e shift.
>
> Cosi` non vale. Io mi riferivo alla divisione
> intera "dura e pura". Se il divisore era
> inottimizzabile ce lo volevo vedere il gcc.
>
L'ottimizzazione in questione, a quanto ho capito, e` un constant folding dell'algoritmo della divisione, lo puoi fare per qualunque divisore, purche' il divisore sia sempre lo stesso (ma se il divisore e` sempre diverso come fai a precalcolare la tabella di lookup?)I think happiness is love
- Vladimir Putin-
Re: alex,tg ha ragione e sassofono no> > > abbiamo già appurato in chat che gcc ottimizza
> > > via la divisione con moltiplicazioni e shift.
> >
> > Cosi` non vale. Io mi riferivo alla divisione
> > intera "dura e pura". Se il divisore era
> > inottimizzabile ce lo volevo vedere il gcc.
> >
>
> L'ottimizzazione in questione, a quanto ho
> capito, e` un constant folding dell'algoritmo
> della divisione, lo puoi fare per qualunque
> divisore, purche' il divisore sia sempre lo
> stesso (ma se il divisore e` sempre diverso come
> fai a precalcolare la tabella di
> lookup?)
Si`, infatti avevo torto e me ne sono reso conto dopo. Pero` ho proseguito a vedere un po' cosa risultava dall'insistere sull'idea della tabella di lookup. La curiosita` era vedere di quanto era penalizzata la tabella dalla lentezza degli accessi alla memoria.
Non ho provato a replicare in Linoleum la scomposizione della divisione in moltiplicazione per 100 e shift di due bits a destra, ma quasi certamente sarebbe piu` veloce della tabella, anche perche` saprei in anticipo che la moltiplicazione di un massimo di 65535 per 100 non causa overflows in registri e variabili di 32 bit.
Um... pero` anche la moltiplicazione richiede alcuni cicli su varie CPU derivate dal Pentium (10, mi pare, di contro ai 42 della divisione, se non ricordo male) e non dovrebbe essere accoppiabile. Il lookup, se l'accesso alla memoria non generasse ritardi, prenderebbe 4 cicli.
Boh. Non so. Bisognerebbe provare.-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 22:22:00.0 alle 2010-11-16 22:22:00.0Trollate totali: 18184
- Scritto da: alex.tg
> > > > abbiamo già appurato in chat che gcc
> ottimizza
> > > > via la divisione con moltiplicazioni e
> shift.
> > >
> > > Cosi` non vale. Io mi riferivo alla divisione
> > > intera "dura e pura". Se il divisore era
> > > inottimizzabile ce lo volevo vedere il gcc.
> > >
> >
> > L'ottimizzazione in questione, a quanto ho
> > capito, e` un constant folding dell'algoritmo
> > della divisione, lo puoi fare per qualunque
> > divisore, purche' il divisore sia sempre lo
> > stesso (ma se il divisore e` sempre diverso come
> > fai a precalcolare la tabella di
> > lookup?)
>
> Si`, infatti avevo torto e me ne sono reso conto
> dopo. Pero` ho proseguito a vedere un po' cosa
> risultava dall'insistere sull'idea della tabella
> di lookup. La curiosita` era vedere di quanto era
> penalizzata la tabella dalla lentezza degli
> accessi alla
> memoria.
>
> Non ho provato a replicare in Linoleum la
> scomposizione della divisione in moltiplicazione
> per 100 e shift di due bits a destra, ma quasi
> certamente sarebbe piu` veloce della tabella,
> anche perche` saprei in anticipo che la
> moltiplicazione di un massimo di 65535 per 100
> non causa overflows in registri e variabili di 32
> bit.
>
> Um... pero` anche la moltiplicazione richiede
> alcuni cicli su varie CPU derivate dal Pentium
> (10, mi pare, di contro ai 42 della divisione, se
> non ricordo male) e non dovrebbe essere
> accoppiabile. Il lookup, se l'accesso alla
> memoria non generasse ritardi, prenderebbe 4
> cicli.
>
> Boh. Non so. Bisognerebbe provare.
Prova a compilare il codice C e eseguirlo sul tuo computer, poi lo compariamo alla tua versione linoleum.I think happiness is love
- Vladimir Putin-
Re: alex,tg ha ragione e sassofono no> Prova a compilare il codice C e eseguirlo sul tuo
> computer, poi lo compariamo alla tua versione
> linoleum.
Mi tocca installare gpp, insomma?
-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 22:36:00.0 alle 2010-11-16 22:36:00.0Trollate totali: 18184
- Scritto da: alex.tg
> > Prova a compilare il codice C e eseguirlo sul
> tuo
> > computer, poi lo compariamo alla tua versione
> > linoleum.
>
> Mi tocca installare gpp, insomma?
non hai un compilatore c installato?!
I think happiness is love
- Vladimir Putin-
Re: alex,tg ha ragione e sassofono no> > > Prova a compilare il codice C e eseguirlo sul
> > tuo
> > > computer, poi lo compariamo alla tua versione
> > > linoleum.
> >
> > Mi tocca installare gpp, insomma?
>
> non hai un compilatore c installato?!
Non quello, ho solo il vecchio Borland per ragioni di retrocompatibilita` con certi vecchissimi lavori.
Ma perderebbe senza dubbio, e` arcistupido.
Pero` se vuoi provo lo stesso.-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 22:48:00.0 alle 2010-11-16 22:48:00.0Trollate totali: 18184
- Scritto da: alex.tg
> > > > Prova a compilare il codice C e eseguirlo
> sul
> > > tuo
> > > > computer, poi lo compariamo alla tua
> versione
> > > > linoleum.
> > >
> > > Mi tocca installare gpp, insomma?
> >
> > non hai un compilatore c installato?!
>
> Non quello, ho solo il vecchio Borland per
> ragioni di retrocompatibilita` con certi
> vecchissimi lavori.
>
>
> Ma perderebbe senza dubbio, e` arcistupido.
> Pero` se vuoi provo lo stesso.
Installa mingw, shell compresa. Magari ti piace e passi a linux.I think happiness is love
- Vladimir Putin-
Re: alex,tg ha ragione e sassofono no> Installa mingw, shell compresa. Magari ti piace e
> passi a
> linux.
Sto installando la versione per Winzozz tramite prompt, aspe'...-
Re: alex,tg ha ragione e sassofono no> > Installa mingw, shell compresa. Magari ti piace
> e
> > passi a
> > linux.
>
> Sto installando la versione per Winzozz tramite
> prompt,
> aspe'...
Mavaff... quello che chiamano RHIDE vuole inizializzare un modo testo e Vista gli risponde picche.
Cheppalle Vista.-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 22:57:00.0 alle 2010-11-16 22:57:00.0Trollate totali: 18184
- Scritto da: alex.tg
> > > Installa mingw, shell compresa. Magari ti
> piace
> > e
> > > passi a
> > > linux.
> >
> > Sto installando la versione per Winzozz tramite
> > prompt,
> > aspe'...
>
> Mavaff... quello che chiamano RHIDE vuole
> inizializzare un modo testo e Vista gli risponde
> picche.
>
> Cheppalle Vista.
Lascia perdere RHIDEI think happiness is love
- Vladimir Putin-
-
Re: alex,tg ha ragione e sassofono no> Ok sto installando MinchiaW.
Oh ecco.
Mi dice:Alex@IMAC-ALEX ~ $
E ora?
-
Re: alex,tg ha ragione e sassofono noA chiedergli "ls" si direbbe nella cartella utenti/Alex.
Mah, e come si compila?-
Re: alex,tg ha ragione e sassofono noum... allora, ~ era la directory home.
/ la root.
Nella root c'e` una bin ma non mi pare contenga tracce di compilatori. Suppongo si riferisca al sistema emulato. E il compilatore dove sara`?-
Re: alex,tg ha ragione e sassofono noHah, ho trovato C.
/C, come nel paradigma di Linoleum.
Copioni.
Qui c'e` MinGW. Ora guardo un po'.-
Re: alex,tg ha ragione e sassofono noAllora, c'e` una bin contenente varia roba tra cui gcc.exe, che se eseguito mi dice "no input files". Gia`, provero` a passargli un input file.
-
-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 23:11:00.0 alle 2010-11-16 23:11:00.0- Scritto da: alex.tg
> um... allora, ~ era la directory home.
> / la root.
>
> Nella root c'e` una bin ma non mi pare contenga
> tracce di compilatori. Suppongo si riferisca al
> sistema emulato. E il compilatore dove
> sara`?
forse in /usr/bin/gcc
per compilare: gcc -O3 -o file file.c
dove -O3 specifica il livello di ottimizzazione-
Re: alex,tg ha ragione e sassofono no> > Nella root c'e` una bin ma non mi pare contenga
> > tracce di compilatori. Suppongo si riferisca al
> > sistema emulato. E il compilatore dove
> > sara`?
>
> forse in /usr/bin/gcc
gcc l'ho trovato in /C/MinGW/bin
> per compilare: gcc -O3 -o file file.c
>
> dove -O3 specifica il livello di ottimizzazione
ora provo...-
Re: alex,tg ha ragione e sassofono no> > > Nella root c'e` una bin ma non mi pare
> contenga
> > > tracce di compilatori. Suppongo si riferisca
> al
> > > sistema emulato. E il compilatore dove
> > > sara`?
> >
> > forse in /usr/bin/gcc
>
> gcc l'ho trovato in /C/MinGW/bin
>
> > per compilare: gcc -O3 -o file file.c
> >
> > dove -O3 specifica il livello di ottimizzazione
>
> ora provo...Alex@IMAC-ALEX /C/MinGW/bin $ gcc -O3 -o ../stuff/prova ../stuff/prova.cpp ../stuff/prova.cpp: In function 'int main()': ../stuff/prova.cpp:16:53: error: 'rand' was not declared in this scope
Palle.
Forse non e` gcc quello che serve.
Provero` con gli altri...-
Re: alex,tg ha ragione e sassofono noah ecco, rand era in stdlib.
O almeno se l'aspettava li`.
Ho incluso stdlib.h e ha compilato.-
Re: alex,tg ha ragione e sassofono no
Alex@IMAC-ALEX /C/MinGW/stuff $ prova.exe Inizio divisioni: 1289946023 Divisioni: 1 Inizio lookups: 1289946024 Lookups: 2 Alex@IMAC-ALEX /C/MinGW/stuff $
1 e 2?
Mah, sara` meglio aumentare i repeats.-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 23:25:00.0 alle 2010-11-16 23:25:00.0Trollate totali: 18184
- Scritto da: alex.tg
>Alex@IMAC-ALEX /C/MinGW/stuff > $ prova.exe > Inizio divisioni: 1289946023 > Divisioni: 1 > Inizio lookups: 1289946024 > Lookups: 2 > > Alex@IMAC-ALEX /C/MinGW/stuff > $
>
> 1 e 2?
> Mah, sara` meglio aumentare i repeats.
c'e` una versione con gettimeofday:#include<stdio.h> #include<time.h> #include<limits.h> #include <sys/time.h> #define M 10000000 #define REP 50 int source[M]; int dest[M]; int divtab[65536]; long int gtod(void) { struct timeval tv; gettimeofday(&tv, NULL); return tv.tv_sec * 1000000 + tv.tv_usec; } int main(void) { int i, m; long int start; for (i = 0; i < M; ++i) source[i] = ((double)rand() / INT_MAX) * 65535; for (i = 0; i < 65536; ++i) divtab[i] = i / 25; start = gtod(); // printf("Inizio divisioni: %ld\n", start); for (m = 0; m < REP; ++m) for (i = 0; i < M; ++i) dest[i] = source[i] / 25; printf("Divisioni: %ld\n", gtod() - start); start = gtod(); // printf("Inizio lookups: %ld\n", start); for (m = 0; m < REP; ++m) for (i = 0; i < M; ++i) dest[i] = divtab[source[i]]; printf("Lookups: %ld\n", gtod() - start); return 0; }
Avete tutti il computer piu` veloce del mio
I think happiness is love
- Vladimir Putin-
Re: alex,tg ha ragione e sassofono noQuesta restituisce:
Alex@IMAC-ALEX /C/MinGW/stuff $ prova2 Divisioni: 1063000 Lookups: 1073000
-
-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 23:31:00.0 alle 2010-11-16 23:31:00.0Trollate totali: 18184
- Scritto da: alex.tg
> E` in microsecondi?
> Sarebbe 1,063 secondi e 1,073?
Si`, stai ottenendo risultati diversi rispetto ai miei e a quelli di frenchi.
I think happiness is love
- Vladimir Putin-
Re: alex,tg ha ragione e sassofono no> > E` in microsecondi?
> > Sarebbe 1,063 secondi e 1,073?
>
> Si`, stai ottenendo risultati diversi rispetto ai
> miei e a quelli di
> frenchi.
Dev'essere Windoze che incasina tutto nei bassifondi, e bara anche sui tempi. Qualunque cosa succeda, e` sempre colpa sua. Regola fondamentale.
-
Re: alex,tg ha ragione e sassofono no> > > E` in microsecondi?
> > > Sarebbe 1,063 secondi e 1,073?
Comunque, 1,063 diviso 50milioni fa:
0,00000002126 secondi per divisione.
Di contro a:
0,000000056s per divisione (listato C su ARM);
0,00000000235s per divisione (listato Linoleum su questo Core2 Duo).
C'e` uno zero di piu` dopo la virgola e un ordine di grandezza in meno in favore di Linoleum. O i tempi vengono misurati male o il compilatore si fa le seghe mentali.-
Re: alex,tg ha ragione e sassofono no> 0,000000056s per divisione (listato C su ARM);
> 0,00000000235s per divisione (listato Linoleum su
> questo Core2
> Duo).
>
> C'e` uno zero di piu` dopo la virgola e un ordine
> di grandezza in meno in favore di Linoleum. O i
> tempi vengono misurati male o il compilatore si
> fa le seghe
> mentali.
Pero` l'altra versione, che usava time_t in secondi, fatta girare per 10 miliardi di divisioni (REP 1000), dava 22 secondi, il che significherebbe 0,0000000022 secondi per divisione, che e` perfino un pochino meno del listato Linoleum (0,0000000235). Ora provo a misurare meglio il listato Lino comunque, implementando anch'io un bel REP che equalizzi le condizioni.-
Re: alex,tg ha ragione e sassofono noOk fatto.
Nuovo listato:"libraries" hmi/conout; math/random; utils/msecs24; "directors" unit = 32; display status = engage; "constants" k = 10 000 000; (di elementi) rep = 1000; (ripetizioni) "variables" t filling source range = { filling_source_range...\lf } : 8; t filling lookup table = { filling_lookup_table...\lf } : 8; t testing integer maths = { testing_integer_maths...\lf } : 8; t testing lookups = { testing_lookups...\lf } : 8; t elapsed maths time = { elapsed_maths_time:_ } : 8; t elapsed lookups time = { elapsed_lookups_time:_ } : 8; t lf = { \lf } : 8; "workspace" r source * k; r target * k; r lookup * [65536 multiplied 16] as bit size; (65536 valori di 16 bit) n to go; n start time; n stop time; "programme" mt . sgenrand: 12345; conout . t say: t filling source range; a # a; b = k; "filling source range" [r source [a]] <- mt . i rnd; [r source [a]] & ffffh; + a; ? b ^ filling source range; conout . t say: t filling lookup table; a # a; b # b; c = 65536 div 2; "filling lookup table" as, d = a; d / 25; [r lookup [b]] = d; + a; as, d = a; d / 25; @ d < 16; [r lookup [b]] | d; + a; + b; ? c ^ filling lookup table; conout . t say: t testing integer maths; [n to go] = rep; [n start time] <- msecs 24; "repeating integer maths" a # a; b = k; "testing integer maths" as, c = [r source [a]]; c / 25; [r target [a]] = c; + a; ? b ^ testing integer maths; ? [n to go] ^ repeating integer maths; [n stop time] <- msecs 24; [n stop time] - [n start time]; conout . t say: t elapsed maths time; conout . n say: [n stop time]; conout . t say: t lf; conout . t say: t testing lookups; [n to go] = rep; [n start time] <- msecs 24; "repeating lookups" a # a; b = k; "testing lookups" as, c = [r source [a]]; d = c; ' d > 1; c & 1; @ c < 4; e = [r lookup [d]]; @ e > c; + a; e & ffffh; - b; [r target [a minus 1]] = e; ? b ! zero > testing lookups; ? [n to go] ^ repeating lookups; [n stop time] <- msecs 24; [n stop time] - [n start time]; conout . t say: t elapsed lookups time; conout . n say: [n stop time]; conout . t say: t lf; as, [thread command] = suspend thread; [thread suspend timeout] = 10 000 (milliseconds); isocall; end;
Risultati:filling source range... filling lookup table... testing integer maths... elapsed maths time: 38475 testing lookups... elapsed lookups time: 27043
Danno ragione al gcc con:
0,0000000027043 contro
0,0000000022
Voglio vedere che succede a cestinare la considerazione sui 16 bit per valore e allinearli a un'unita` di memoria di 32 bit.-
Re: alex,tg ha ragione e sassofono noE` peggio, infatti.
"libraries" hmi/conout; math/random; utils/msecs24; "directors" unit = 32; display status = engage; "constants" k = 10 000 000; (di elementi) rep = 50; (ripetizioni) "variables" t filling source range = { filling_source_range...\lf } : 8; t filling lookup table = { filling_lookup_table...\lf } : 8; t testing integer maths = { testing_integer_maths...\lf } : 8; t testing lookups = { testing_lookups...\lf } : 8; t elapsed maths time = { elapsed_maths_time:_ } : 8; t elapsed lookups time = { elapsed_lookups_time:_ } : 8; t lf = { \lf } : 8; "workspace" r source * k; r target * k; r lookup * 65536; (65536 risultati in tabella) n to go; n start time; n stop time; "programme" mt . sgenrand: 12345; conout . t say: t filling source range; a # a; b = k; "filling source range" [r source [a]] <- mt . i rnd; [r source [a]] & ffffh; + a; ? b ^ filling source range; conout . t say: t filling lookup table; a # a; b = 65536; "filling lookup table" as, c = a; c / 25; [r lookup [a]] = c; + a; ? b ^ filling lookup table; conout . t say: t testing integer maths; [n to go] = rep; [n start time] <- msecs 24; "repeating integer maths" a # a; b = k; "testing integer maths" as, c = [r source [a]]; c / 25; [r target [a]] = c; + a; ? b ^ testing integer maths; ? [n to go] ^ repeating integer maths; [n stop time] <- msecs 24; [n stop time] - [n start time]; conout . t say: t elapsed maths time; conout . n say: [n stop time]; conout . t say: t lf; conout . t say: t testing lookups; [n to go] = rep; [n start time] <- msecs 24; "repeating lookups" a # a; "testing lookups" as, c = [r source [a]]; [r target [a]] = [r lookup [c]]; + a; ? a ! k > testing lookups; ? [n to go] ^ repeating lookups; [n stop time] <- msecs 24; [n stop time] - [n start time]; conout . t say: t elapsed lookups time; conout . n say: [n stop time]; conout . t say: t lf; as, [thread command] = suspend thread; [thread suspend timeout] = 10 000 (milliseconds); isocall; end;
Piu` semplice ma piu` lento: 0,0000000032 per divisione.
-
-
-
-
-
-
-
-
-
Re: alex,tg ha ragione e sassofono no
Alex@IMAC-ALEX /C/MinGW/stuff $ prova Inizio divisioni: 1289946180 Divisioni: 22 Inizio lookups: 1289946202 Lookups: 22
Ho portato REP a 1000 e ci mette 22 secondi.
Ma chissa` se sta facendo le cose per bene... i tempi col REP 50 sono brevissimi. O il mio processore e` un mostro o quello che usavi era uno scassone. Ma avevi specificato che era un Core2 Duo.
Boh.
O i tempi non erano in secondi?-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 23:29:00.0 alle 2010-11-16 23:29:00.0Trollate totali: 18184
- Scritto da: alex.tg
>Alex@IMAC-ALEX /C/MinGW/stuff > $ prova > Inizio divisioni: 1289946180 > Divisioni: 22 > Inizio lookups: 1289946202 > Lookups: 22
>
> Ho portato REP a 1000 e ci mette 22 secondi.
>
> Ma chissa` se sta facendo le cose per bene... i
> tempi col REP 50 sono brevissimi. O il mio
> processore e` un mostro o quello che usavi era
> uno scassone. Ma avevi specificato che era un
> Core2
> Duo.
>
> Boh.
> O i tempi non erano in secondi?
Il mio MacBook late 2008 con Core 2 Duo REP=200 ci mette 9 secondi per le divisioni, 13 per i lookup.I think happiness is love
- Vladimir Putin-
Re: alex,tg ha ragione e sassofono no> Il mio MacBook late 2008 con Core 2 Duo REP=200
> ci mette 9 secondi per le divisioni, 13 per i
> lookup.
Boh, questo e` un iMac dell'inizio del 2009... o era il 2008? Boh, comunque sembra TROPPO piu` veloce. Ora cerco d'interpretare i tempi della versione che invoca gettimeofday.
-
-
-
-
-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 23:20:00.0 alle 2010-11-16 23:20:00.0Trollate totali: 18184
- Scritto da: alex.tg
> > > > Nella root c'e` una bin ma non mi pare
> > contenga
> > > > tracce di compilatori. Suppongo si riferisca
> > al
> > > > sistema emulato. E il compilatore dove
> > > > sara`?
> > >
> > > forse in /usr/bin/gcc
> >
> > gcc l'ho trovato in /C/MinGW/bin
> >
> > > per compilare: gcc -O3 -o file file.c
> > >
> > > dove -O3 specifica il livello di
> ottimizzazione
> >
> > ora provo...
>
>Alex@IMAC-ALEX /C/MinGW/bin > $ gcc -O3 -o ../stuff/prova ../stuff/prova.cpp > ../stuff/prova.cpp: In function 'int main()': > ../stuff/prova.cpp:16:53: error: 'rand' was not > declared in this > scope
>
> Palle.
> Forse non e` gcc quello che serve.
> Provero` con gli altri...
Aggiungi:#include <stdlib.h>
I think happiness is love
- Vladimir Putin
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Re: alex,tg ha ragione e sassofono no
- Scritto da:
> - Scritto da: Caccola
> >Inizio divisioni: 1289928957 > > Divisioni: 22 > > Inizio lookups: 1289928979 > > Lookups: 19
> >
> > su un pentium III a 700 mhz

>
> compilatore?
>
mingsticazzi? quello del dev c++
> abbiamo già appurato in chat che gcc ottimizza
> via la divisione con moltiplicazioni e shift.
> Risultato: il lookup è circa il 40% più lento su
> un core2 duo 3
> Ghz
ficco
quando al proffe gli racconterò tutte queste cose su un esercizio di merda come quello, come minimo penserà...
CLEM CLEM!
d'oh!
-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 19:35:00.0 alle 2010-11-16 19:35:00.0- Scritto da: Caccola
>
> - Scritto da:
> > - Scritto da: Caccola
> > >Inizio divisioni: 1289928957 > > > Divisioni: 22 > > > Inizio lookups: 1289928979 > > > Lookups: 19
> > >
> > > su un pentium III a 700 mhz

> >
> > compilatore?
> >
>
> mingsticazzi? quello del dev c++
>
> > abbiamo già appurato in chat che gcc ottimizza
> > via la divisione con moltiplicazioni e shift.
> > Risultato: il lookup è circa il 40% più lento su
> > un core2 duo 3
> > Ghz
>
> ficco
quando al proffe gli racconterò tutte
> queste cose su un esercizio di merda come quello,
> come minimo
> penserà...
>
> CLEM CLEM!
>
> d'oh![img]http://indietravelpodcast.com/wp-content
gli rivelerai che frequenti il FDT?
-
Re: alex,tg ha ragione e sassofono no
- Scritto da:
> - Scritto da: Caccola
> >
> > - Scritto da:
> > > - Scritto da: Caccola
> > > >Inizio divisioni: 1289928957 > > > > Divisioni: 22 > > > > Inizio lookups: 1289928979 > > > > Lookups: 19
> > > >
> > > > su un pentium III a 700 mhz

> > >
> > > compilatore?
> > >
> >
> > mingsticazzi? quello del dev c++
> >
> > > abbiamo già appurato in chat che gcc ottimizza
> > > via la divisione con moltiplicazioni e shift.
> > > Risultato: il lookup è circa il 40% più lento
> su
> > > un core2 duo 3
> > > Ghz
> >
> > ficco
quando al proffe gli racconterò tutte
> > queste cose su un esercizio di merda come
> quello,
> > come minimo
> > penserà...
> >
> > CLEM CLEM!
> >
> >
> d'oh![img]http://indietravelpodcast.com/wp-content
>
> gli rivelerai che frequenti il FDT?
ovviamente no, mi prendo il merito di tutto, gli dico anche che ho inventato un assembler multipiattaforma.-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 20:19:00.0 alle 2010-11-16 20:19:00.0
- Scritto da: Caccola
>
> - Scritto da:
> > - Scritto da: Caccola
> > >
> > > - Scritto da:
> > > > - Scritto da: Caccola
> > > > >Inizio divisioni: 1289928957 > > > > > Divisioni: 22 > > > > > Inizio lookups: 1289928979 > > > > > Lookups: 19
> > > > >
> > > > > su un pentium III a 700 mhz

> > > >
> > > > compilatore?
> > > >
> > >
> > > mingsticazzi? quello del dev c++
> > >
> > > > abbiamo già appurato in chat che gcc
> ottimizza
> > > > via la divisione con moltiplicazioni e
> shift.
> > > > Risultato: il lookup è circa il 40% più
> lento
> > su
> > > > un core2 duo 3
> > > > Ghz
> > >
> > > ficco
quando al proffe gli racconterò
> tutte
> > > queste cose su un esercizio di merda come
> > quello,
> > > come minimo
> > > penserà...
> > >
> > > CLEM CLEM!
> > >
> > >
> >
> d'oh![img]http://indietravelpodcast.com/wp-content
> >
> > gli rivelerai che frequenti il FDT?
>
> ovviamente no, mi prendo il merito di tutto, gli
> dico anche che ho inventato un assembler
> multipiattaforma.
Quindi quando hai presentato quell'esercizio di sin4x al prof Gatto Selvaggio non è stato nemmeno nominato?
-
Re: alex,tg ha ragione e sassofono no
- Scritto da:
>
> - Scritto da: Caccola
> >
> > - Scritto da:
> > > - Scritto da: Caccola
> > > >
> > > > - Scritto da:
> > > > > - Scritto da: Caccola
> > > > > >Inizio divisioni: 1289928957 > > > > > > Divisioni: 22 > > > > > > Inizio lookups: 1289928979 > > > > > > Lookups: 19
> > > > > >
> > > > > > su un pentium III a 700 mhz

> > > > >
> > > > > compilatore?
> > > > >
> > > >
> > > > mingsticazzi? quello del dev c++
> > > >
> > > > > abbiamo già appurato in chat che gcc
> > ottimizza
> > > > > via la divisione con moltiplicazioni e
> > shift.
> > > > > Risultato: il lookup è circa il 40% più
> > lento
> > > su
> > > > > un core2 duo 3
> > > > > Ghz
> > > >
> > > > ficco
quando al proffe gli racconterò
> > tutte
> > > > queste cose su un esercizio di merda come
> > > quello,
> > > > come minimo
> > > > penserà...
> > > >
> > > > CLEM CLEM!
> > > >
> > > >
> > >
> >
> d'oh![img]http://indietravelpodcast.com/wp-content
> > >
> > > gli rivelerai che frequenti il FDT?
> >
> > ovviamente no, mi prendo il merito di tutto, gli
> > dico anche che ho inventato un assembler
> > multipiattaforma.
>
> Quindi quando hai presentato quell'esercizio di
> sin4x al prof Gatto Selvaggio non è stato nemmeno
> nominato?
>
mai presentato, e non perché mi sono ritirato, ma perché non era un esercizio da presentare al prof: si trattava solo di una "triviale dimostrazione lasciata al lettore" nella quale mi sono imbattuto mentre studiavo
-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 21:17:00.0 alle 2010-11-16 21:17:00.0> "triviale dimostrazione lasciata al lettore"
ah!
-
Re: alex,tg ha ragione e sassofono no
- Scritto da:
> > "triviale dimostrazione lasciata al lettore"
>
> ah!

ti giuro, ho pensato che ero troppo scemo per l'uni.
E forse ce l'avevo azzeccata.
-
-
-
-
-
-
-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 20:26:00.0 alle 2010-11-16 20:26:00.0
- Scritto da:
> - Scritto da: Caccola
> >Inizio divisioni: 1289928957 > > Divisioni: 22 > > Inizio lookups: 1289928979 > > Lookups: 19
> >
> > su un pentium III a 700 mhz

>
> compilatore?
>
> abbiamo già appurato in chat che gcc ottimizza
> via la divisione con moltiplicazioni e shift.
> Risultato: il lookup è circa il 40% più lento su
> un core2 duo 3
> Ghz
Se glielo chiedi "per favore", il gcc ti sbroglia anche i loop, gonfiando però a dismisura il codice generato che rischia quindi di finire fuori dalla cache delle istruzioni.-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 20:27:00.0 alle 2010-11-16 20:27:00.0- Scritto da:
>
> - Scritto da:
> > - Scritto da: Caccola
> > >Inizio divisioni: 1289928957 > > > Divisioni: 22 > > > Inizio lookups: 1289928979 > > > Lookups: 19
> > >
> > > su un pentium III a 700 mhz

> >
> > compilatore?
> >
> > abbiamo già appurato in chat che gcc ottimizza
> > via la divisione con moltiplicazioni e shift.
> > Risultato: il lookup è circa il 40% più lento su
> > un core2 duo 3
> > Ghz
>
> Se glielo chiedi "per favore", il gcc ti
> sbroglia anche i loop, gonfiando però a dismisura
> il codice generato che rischia quindi di finire
> fuori dalla cache delle
> istruzioni.
lo fa di default con -O0-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 20:31:00.0 alle 2010-11-16 20:31:00.0
- Scritto da:
> - Scritto da:
> >
> > - Scritto da:
> > > - Scritto da: Caccola
> > > >Inizio divisioni: 1289928957 > > > > Divisioni: 22 > > > > Inizio lookups: 1289928979 > > > > Lookups: 19
> > > >
> > > > su un pentium III a 700 mhz

> > >
> > > compilatore?
> > >
> > > abbiamo già appurato in chat che gcc ottimizza
> > > via la divisione con moltiplicazioni e shift.
> > > Risultato: il lookup è circa il 40% più lento
> su
> > > un core2 duo 3
> > > Ghz
> >
> > Se glielo chiedi "per favore", il gcc ti
> > sbroglia anche i loop, gonfiando però a
> dismisura
> > il codice generato che rischia quindi di finire
> > fuori dalla cache delle
> > istruzioni.
>
> lo fa di default con -O0

Sul serio?
-O0 attiva -funroll-loops?
Se lo fa è una cazzata (anche perché -O0 è impostato di default se non viene specificato un altro livello), ma ammetto di non conoscere a memoria la manpage del gcc.-
Re: alex,tg ha ragione e sassofono noScritto daNon Autenticatoil 2010-11-16 20:32:00.0 alle 2010-11-16 20:32:00.0- Scritto da:
>
> - Scritto da:
> > - Scritto da:
> > >
> > > - Scritto da:
> > > > - Scritto da: Caccola
> > > > >Inizio divisioni: 1289928957 > > > > > Divisioni: 22 > > > > > Inizio lookups: 1289928979 > > > > > Lookups: 19
> > > > >
> > > > > su un pentium III a 700 mhz

> > > >
> > > > compilatore?
> > > >
> > > > abbiamo già appurato in chat che gcc
> ottimizza
> > > > via la divisione con moltiplicazioni e
> shift.
> > > > Risultato: il lookup è circa il 40% più
> lento
> > su
> > > > un core2 duo 3
> > > > Ghz
> > >
> > > Se glielo chiedi "per favore", il gcc ti
> > > sbroglia anche i loop, gonfiando però a
> > dismisura
> > > il codice generato che rischia quindi di
> finire
> > > fuori dalla cache delle
> > > istruzioni.
> >
> > lo fa di default con -O0
>
>
>
> Sul serio?
> -O0 attiva -funroll-loops?
> Se lo fa è una cazzata (anche perché -O0 è
> impostato di default se non viene specificato un
> altro livello), ma ammetto di non conoscere a
> memoria la manpage del
> gcc.
l'ottimizzazione di cui sopra, cioè dividere per 25
-
-
-
-
-
Re: alex,tg ha ragione e sassofono noScritto daavvelentaniCubicolarioil 2010-11-16 21:45:00.0 alle 2010-11-16 21:45:00.0Trollate totali: 18184
- Scritto da: Caccola
>Inizio divisioni: 1289928957 > Divisioni: 22 > Inizio lookups: 1289928979 > Lookups: 19
>
> su un pentium III a 700 mhz

l'idea era avere i lookup piu` veloci.
I think happiness is love
- Vladimir Putin
-