Mostra notizie nelle discussioni
Avatar
☺
Scritto da
il 2010-11-16 23:00:00.0 alle 2010-11-16 23:00:00.0
Trollate totali: 3444
Re: alex,tg ha ragione e sassofono no
Ok sto installando MinchiaW.

Dio Porco

Ad hhttps://bestemmietraamicidioporco
Perché non bestemmiare tra amici? È una cosa divertente!‎
Avatar
☺
Scritto da
il 2010-11-16 22:55:00.0 alle 2010-11-16 22:55:00.0
Trollate totali: 3444
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.
Avatar
☺
Scritto da
il 2010-11-16 22:52:00.0 alle 2010-11-16 22:52:00.0
Trollate totali: 3444
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'...
Avatar
☺
Scritto da
il 2010-11-16 22:42:00.0 alle 2010-11-16 22:42:00.0
Trollate totali: 3444
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? Triste
>
> non hai un compilatore c installato?! A bocca storta

Non quello, ho solo il vecchio Borland per ragioni di retrocompatibilita` con certi vecchissimi lavori. Deluso

Ma perderebbe senza dubbio, e` arcistupido.
Pero` se vuoi provo lo stesso.
Avatar
☺
Scritto da
il 2010-11-16 22:32:00.0 alle 2010-11-16 22:32:00.0
Trollate totali: 3444
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. Anonimo

Vaffan

Ad https://duckduckgo.com/?t=ffab&q=vaffanculo&ia=web
CULOOOO!!!!‎
Avatar
☺
Scritto da
il 2010-11-16 22:26:00.0 alle 2010-11-16 22:26:00.0
Trollate totali: 3444
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? Triste
Avatar
☺
Scritto da
il 2010-11-16 22:23:00.0 alle 2010-11-16 22:23:00.0
Trollate totali: 3444
Re: Avve ti spiego come si studia
> gcc ottimizza la divisione cosi`:
>
>
>         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.
Avatar
☺
Scritto da
il 2010-11-16 22:15:00.0 alle 2010-11-16 22:15:00.0
Trollate totali: 3444
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.
> > Con la lingua fuori
>
> 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.
Avatar
☺
Scritto da
il 2010-11-16 21:18:00.0 alle 2010-11-16 21:18:00.0
Trollate totali: 3444
Re: alex,tg ha ragione e sassofono no
> > Linoleum e` un assembler multipiattaforma e
> > basta.
> > Annoiato
>
> Cos'è sta storia? Non doveva essere due volte più
> veloce del C?
> Arrabbiato

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.

DAI CHE È VENERDÌ!!!

Ad https://www.youtube.com/@daiche_e_venerdi
Figa a nastroooo!‎
Avatar
☺
Scritto da
il 2010-11-16 21:12:00.0 alle 2010-11-16 21:12:00.0
Trollate totali: 3444
Re: alex,tg ha ragione e sassofono no
Linoleum e` un assembler multipiattaforma e basta. Annoiato
Avatar
☺
Scritto da
il 2010-11-16 21:10:00.0 alle 2010-11-16 21:10:00.0
Trollate totali: 3444
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.
Avatar
☺
Scritto da
il 2010-11-16 21:03:00.0 alle 2010-11-16 21:03:00.0
Trollate totali: 3444
Re: Avve ti spiego come si studia
> > Insomma, non e` che uno debba prendersela troppo
> > se non risulta ehm... di immediata
> > comprensibilita.
> > Imbarazzato
>
> Se lo scrivessi in assembler...

Be', Linoleum e` un assembler.
Avatar
☺
Scritto da
il 2010-11-16 21:01:00.0 alle 2010-11-16 21:01:00.0
Trollate totali: 3444
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.

abcdefghi

Ad www.www.www
qwerty‎
Avatar
☺
Scritto da
il 2010-11-16 21:00:00.0 alle 2010-11-16 21:00:00.0
Trollate totali: 3444
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.
Avatar
☺
Scritto da
il 2010-11-16 20:48:00.0 alle 2010-11-16 20:48:00.0
Trollate totali: 3444
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_...
Avatar
☺
Scritto da
il 2010-11-16 20:45:00.0 alle 2010-11-16 20:45:00.0
Trollate totali: 3444
Re: Avve ti spiego come si studia
> In lacrime Non capirò mai nulla di algoritmi, per me o
> un problema dò una formula o è irrisolvibile
> In lacrime

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. Imbarazzato
Avatar
☺
Scritto da
il 2010-11-16 20:33:00.0 alle 2010-11-16 20:33:00.0
Trollate totali: 3444
Re: Avve ti spiego come si studia
> 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:

"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.‎
Avatar
☺
Scritto da
il 2010-11-16 18:50:00.0 alle 2010-11-16 18:50:00.0
Trollate totali: 3444
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. Con la lingua fuori
Avatar
☺
Scritto da
il 2010-11-16 18:47:00.0 alle 2010-11-16 18:47:00.0
Trollate totali: 3444
Re: Avve ti spiego come si studia
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. In lacrime

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. Imbarazzato
Avatar
☺
Scritto da
il 2010-11-16 18:35:00.0 alle 2010-11-16 18:35:00.0
Trollate totali: 3444
Re: quando l'energia
> > 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`.

Pagina generata in 205 millisecondi

Utenti attivi: 11 nell'ultimo minuto, 23 negli ultimi cinque minuti, 40 negli ultimi 15 minuti