Dio Porco
Ad
hhttps://bestemmietraamicidioporco
Perché non bestemmiare tra amici? È una cosa divertente!
> > 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.
> 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.
> Installa mingw, shell compresa. Magari ti piace e
> passi a
> linux.
Sto installando la versione per Winzozz tramite prompt, aspe'...
> passi a
> linux.
Sto installando la versione per Winzozz tramite prompt, aspe'...
> > > 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.
> > 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.
> 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.
> 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.
> Prova a compilare il codice C e eseguirlo sul tuo
> computer, poi lo compariamo alla tua versione
> linoleum.
Mi tocca installare gpp, insomma?
> computer, poi lo compariamo alla tua versione
> linoleum.
Mi tocca installare gpp, insomma?
> gcc ottimizza la divisione cosi`:
>
>
Non ho il gpp installato, ma... rax?
L'accumulatore a 64 bit qui non c'e`.
Non produrrebbe lo stesso codice, temo.
>
>
> movslq %ebx,%<b>rax</b> >
Non ho il gpp installato, ma... rax?
L'accumulatore a 64 bit qui non c'e`.
Non produrrebbe lo stesso codice, temo.
> > > 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.
> > > 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.
> > 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.
> > 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.
> > 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.
> >
> > 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.
> > Insomma, non e` che uno debba prendersela troppo
> > se non risulta ehm... di immediata
> > comprensibilita.
> >
>
> Se lo scrivessi in assembler...
Be', Linoleum e` un assembler.
> > se non risulta ehm... di immediata
> > comprensibilita.
> >

>
> Se lo scrivessi in assembler...
Be', Linoleum e` un assembler.
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.
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.
> > > 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.
> > >
> > > 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.
> 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_...
>
> 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_...
>
Non capirò mai nulla di algoritmi, per me o
> un problema dò una formula o è irrisolvibile
>
E` un listato Linoleum che utilizza rotazioni e shift binari per accedere a una tabella di elementi di 32 bit suddivisi in words alte e basse per tenere in memoria due risultati per elemento, onde dimezzare la dimensione della tabella in memoria per aumentare le prestazioni. Inoltre nel ciclo di lookup fa uso di ottimizzazioni a basso livello sulla disposizione e l'accoppiabilita` delle istruzioni che operano tramite registri su (almeno) due pipelines di esecuzione (per esempio incrementa l'indice dei vettori sorgente e destinazione prima di depositare il risultato nel vettore destinazione, quindi aggiunge uno spiazzamento immediato di meno 1, in [r target [a minus 1]] = e.
Insomma, non e` che uno debba prendersela troppo se non risulta ehm... di immediata comprensibilita.
Non capirò mai nulla di algoritmi, per me o> un problema dò una formula o è irrisolvibile
>

E` un listato Linoleum che utilizza rotazioni e shift binari per accedere a una tabella di elementi di 32 bit suddivisi in words alte e basse per tenere in memoria due risultati per elemento, onde dimezzare la dimensione della tabella in memoria per aumentare le prestazioni. Inoltre nel ciclo di lookup fa uso di ottimizzazioni a basso livello sulla disposizione e l'accoppiabilita` delle istruzioni che operano tramite registri su (almeno) due pipelines di esecuzione (per esempio incrementa l'indice dei vettori sorgente e destinazione prima di depositare il risultato nel vettore destinazione, quindi aggiunge uno spiazzamento immediato di meno 1, in [r target [a minus 1]] = e.
Insomma, non e` che uno debba prendersela troppo se non risulta ehm... di immediata comprensibilita.
> Non state tenendo conto dell'architettura.
> La lookup table rischia di non essere in cache e
> di dover essere sempre letta dalla RAM, che è di
> diversi ordini di grandezza più lenta della cache
> istruzioni del procio, che invece eseguirà molto
> più velocemente le operazioni del loop che
> effettua la
> divisione.
Si`, e` un grosso rischio con un'operazione cosi` semplice.
Sul mio iMac Core2 Duo 2800 pero` questo programmino Linoleum:
Si direbbe mostrare che la lookup table e` piu` veloce:
Probabilmente l'ottimizzazione migliore in questo caso e` procedere a moltiplicare e shiftare come fa il gcc: breve in esecuzione, e non rischia ritardi di accesso alla memoria. Ma la lookup table sembra comunque ancora un po' piu` veloce della divisione intera nvda e crvda, quando viene organizzata a basso livello, quindi anche la mia ottimizzazione era relativamente valida.
Se volete provare vi uploado l'eseguibile, oppure scaricate Linoleum e ve lo compilate.
> La lookup table rischia di non essere in cache e
> di dover essere sempre letta dalla RAM, che è di
> diversi ordini di grandezza più lenta della cache
> istruzioni del procio, che invece eseguirà molto
> più velocemente le operazioni del loop che
> effettua la
> divisione.
Si`, e` un grosso rischio con un'operazione cosi` semplice.
Sul mio iMac Core2 Duo 2800 pero` questo programmino Linoleum:
"libraries"
hmi/conout;
math/random;
utils/msecs24;
"directors"
unit = 32;
display status = engage;
"constants"
k = 20 000 000; (di elementi)
"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 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 start time] <- msecs 24;
a # a;
b = k;
"testing integer maths"
as,
c = [r source [a]];
c / 25;
[r target [a]] = c;
+ a;
? b ^ testing 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 start time] <- msecs 24;
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 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;Si direbbe mostrare che la lookup table e` piu` veloce:
filling source range... filling lookup table... testing integer maths... elapsed maths time: 109 testing lookups... elapsed lookups time: 47
Probabilmente l'ottimizzazione migliore in questo caso e` procedere a moltiplicare e shiftare come fa il gcc: breve in esecuzione, e non rischia ritardi di accesso alla memoria. Ma la lookup table sembra comunque ancora un po' piu` veloce della divisione intera nvda e crvda, quando viene organizzata a basso livello, quindi anche la mia ottimizzazione era relativamente valida.
Se volete provare vi uploado l'eseguibile, oppure scaricate Linoleum e ve lo compilate.
Arricchimento culturale in Svezia
Ad
https://www.breitbart.com/europe/2019/01/04/patient-placed-in-quarantine-after-suspected-ebola-case-in-sweden/
The Emergency Room of a Swedish hospital was closed down Friday morning after a patient recently returned from Africa arrived vomiting blood, a possible symptom of the deadly and contagious Ebola virus.
> 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.
> 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.
Proca miseria, perche` ti sei preso la briga di controllare? I computer moderni hanno la tendenza ad essere piu` veloci a fare che a ricordare. 
Comunque, non saprei. Bisognerebbe che riprovassi in Linoleum, usando 16 bit per elemento della tabella di lookup e disponendo le istruzioni atomiche appropriatamente. Devo andare a fare la spesa, poi vedo un po' che salta fuori. Intuitivamente, la lookup table potrebbe ancora guadagnare qualcosa. Ma si`, se non ci perde nei ritardi di accesso alla memoria, guadagna probabilmente molto poco. Se pero` non controllavi ci facevo bella figura.

Comunque, non saprei. Bisognerebbe che riprovassi in Linoleum, usando 16 bit per elemento della tabella di lookup e disponendo le istruzioni atomiche appropriatamente. Devo andare a fare la spesa, poi vedo un po' che salta fuori. Intuitivamente, la lookup table potrebbe ancora guadagnare qualcosa. Ma si`, se non ci perde nei ritardi di accesso alla memoria, guadagna probabilmente molto poco. Se pero` non controllavi ci facevo bella figura.
> > Cosa disegni? Perché lo fai?
- Che sta guardando? Quand'e` che questo accade nel film?
- Sta guardando l'adesso, signore. Tutto quel che accade adesso sta avvenendo adesso.
- Che e` successo al prima?
- E` passato.
- Quando?
- Adesso. Siamo all'adesso, adesso!
- Torniamo al prima!
- Quando?
- Adesso.
- Non posso.
- Perche`?
- Perche` e` passato.
...
- Quando il prima sara` adesso?
- Presto!
> Il sonno ha avuto il sopravvento.
Gia`.
- Che sta guardando? Quand'e` che questo accade nel film?
- Sta guardando l'adesso, signore. Tutto quel che accade adesso sta avvenendo adesso.
- Che e` successo al prima?
- E` passato.
- Quando?
- Adesso. Siamo all'adesso, adesso!
- Torniamo al prima!
- Quando?
- Adesso.
- Non posso.
- Perche`?
- Perche` e` passato.
...
- Quando il prima sara` adesso?
- Presto!
> Il sonno ha avuto il sopravvento.
Gia`.