-
Ok, argomento informatico.Scritto daaltgutente che non utieneil 2017-04-16 04:10:30.0 alle 2017-04-16 04:10:30.0Trollate totali: 11540Aspe' qual'era?
M'e` passato di mente ma ce l'avevo 5 secondi fa...
AH! Le divisioni.
Si`, le divisioni invarianti per moltiplicazione.
O divisioni per moltiplicazioni invarianti.
O come cacchio le chiamano.
Concettualmente sono semplici: si approssima la divisione pre-moltiplicando tutto per 2N (N = wordsize, 32 bit su IA-32), e poi si ri-divide per 2N, cioe` ci si limita a prendere la word alta di una moltiplicazione a 2(2*N) bits. A seconda della dimensione in bits del denominatore, serve quel tot di bits in piu` per evitare errori di troncamento.
Pero` qui:
https://gmplib.org/~tege/divcnst-pldi94.pdf
La spiegazione della figura 4.1, paragrafo "CAUTION", dice che la formula di base e` quella (appunto, quoziente = shift right logico della somma della costante di approssimazione e del numeratore), ma che servono degli shift di aggiustamento per evitare che ci sia un overflow sull'addizione e sullo shift.
Pero`.
Non considera, mi pare, che x86 in particolare ha un'istruzione ADC (add with carry) per fare somme a 64-bit, e siccome li` l'overflow e` sempre al massimo 1 bit, basterebbe aggiungere il carry al risultato, con "ADC qh, 0" dove qh e` l'operando che contiene la word alta del quoziente), inoltre sempre x86 ha la double-precision shift right che "importa" i bits in eccesso dalla word alta. Sicche` non vorrei che considerando tutto questo in effetti si POSSA calcolare q senza preoccuparsi degli shift di aggiustamento.
Non capisco se non l'hanno considerato perche` non tenevano presenti queste istruzioni specifiche di quell'architettura, visto che hanno implementato quest'ottimizzazione in modo generico nel compilatore, oppure se non hanno tenuto presente il caso perche` anche su x86 ADC e SHRD sarebbero piu` lente.
Tanto per dire quali sono i miei "argomenti informatici" del momento.
Ma penso che la risposta dovrebbe essere "si` vabbe' ma in fondo chissenefrega".-
Re: Ok, argomento informatico.Scritto daaltgutente che non utieneil 2017-04-16 04:15:33.0 alle 2017-04-16 04:15:33.0Trollate totali: 11540Comunque nel mio caso la implementerei nel semi-assemblatore, che e` la parte che risponde a un'architettura specifica, e non nel compilatore che si limiterebbe a dire "mah, dividi questo per questa costante intera". Vero che poi ogni volta che si scrive un semi-assemblatore per un'architettura diversa va reimplementata, ma almeno si potrebbe decidere caso per caso se e` possibile/conveniente applicarla o no, ed esattamente come.
PRRResempio x86 ha anche modi tipo lea eax, [eax + eax*8] per moltiplicare per 9 con l'AGU, in un ciclo e basta.-
Re: Ok, argomento informatico.Scritto daNon Autenticatoil 2017-04-16 09:52:21.0 alle 2017-04-16 09:52:21.0Scritto da: altg
> Comunque nel mio caso la implementerei nel semi-assemblatore, che e` la parte che risponde a un'architettura specifica, e non nel compilatore che si limiterebbe a dire "mah, dividi questo per questa costante intera". Vero che poi ogni volta che si scrive un semi-assemblatore per un'architettura diversa va reimplementata, ma almeno si potrebbe decidere caso per caso se e` possibile/conveniente applicarla o no, ed esattamente come.
>
> PRRResempio x86 ha anche modi tipo lea eax, [eax + eax*8] per moltiplicare per 9 con l'AGU, in un ciclo e basta.
Interessante

interessante l'ora a cui hai scritto il pippolone. Smisto l'onere della risposta su Wakko che mi sembra il più competente in cose come queste.-
Re: Ok, argomento informatico.Scritto daWakko WarnerWakkus Horribilisil 2017-04-16 10:09:11.0 alle 2017-04-16 10:09:11.0Trollate totali: 6779Scritto da:
> Scritto da: altg
> > Comunque nel mio caso la implementerei nel semi-assemblatore, che e` la parte che risponde a un'architettura specifica, e non nel compilatore che si limiterebbe a dire "mah, dividi questo per questa costante intera". Vero che poi ogni volta che si scrive un semi-assemblatore per un'architettura diversa va reimplementata, ma almeno si potrebbe decidere caso per caso se e` possibile/conveniente applicarla o no, ed esattamente come.
> >
> > PRRResempio x86 ha anche modi tipo lea eax, [eax + eax*8] per moltiplicare per 9 con l'AGU, in un ciclo e basta.
>
> Interessante
>
>
>
> interessante l'ora a cui hai scritto il pippolone. Smisto l'onere della risposta su Wakko che mi sembra il più competente in cose come queste.
Io la moltiplicazione la lascio fare al compilatore, mi sembra l'approccio più semplice.
Gli Svizzeri non sono tutti ricchi - Mattia-
Re: Ok, argomento informatico.Scritto daNon Autenticatoil 2017-04-16 10:17:02.0 alle 2017-04-16 10:17:02.0Scritto da: Wakko Warner
> Scritto da:
> > Scritto da: altg
> > > Comunque nel mio caso la implementerei nel semi-assemblatore, che e` la parte che risponde a un'architettura specifica, e non nel compilatore che si limiterebbe a dire "mah, dividi questo per questa costante intera". Vero che poi ogni volta che si scrive un semi-assemblatore per un'architettura diversa va reimplementata, ma almeno si potrebbe decidere caso per caso se e` possibile/conveniente applicarla o no, ed esattamente come.
> > >
> > > PRRResempio x86 ha anche modi tipo lea eax, [eax + eax*8] per moltiplicare per 9 con l'AGU, in un ciclo e basta.
> >
> > Interessante
> >
> >
> >
> > interessante l'ora a cui hai scritto il pippolone. Smisto l'onere della risposta su Wakko che mi sembra il più competente in cose come queste.
>
> Io la moltiplicazione la lascio fare al compilatore, mi sembra l'approccio più semplice.
Ma il compilatore lo sta scrivendo lui
-
Re: Ok, argomento informatico.Scritto daWakko WarnerWakkus Horribilisil 2017-04-16 10:40:14.0 alle 2017-04-16 10:40:14.0Trollate totali: 6779Scritto da:
> Scritto da: Wakko Warner
> > Scritto da:
> > > Scritto da: altg
> > > > Comunque nel mio caso la implementerei nel semi-assemblatore, che e` la parte che risponde a un'architettura specifica, e non nel compilatore che si limiterebbe a dire "mah, dividi questo per questa costante intera". Vero che poi ogni volta che si scrive un semi-assemblatore per un'architettura diversa va reimplementata, ma almeno si potrebbe decidere caso per caso se e` possibile/conveniente applicarla o no, ed esattamente come.
> > > >
> > > > PRRResempio x86 ha anche modi tipo lea eax, [eax + eax*8] per moltiplicare per 9 con l'AGU, in un ciclo e basta.
> > >
> > > Interessante
> > >
> > >
> > >
> > > interessante l'ora a cui hai scritto il pippolone. Smisto l'onere della risposta su Wakko che mi sembra il più competente in cose come queste.
> >
> > Io la moltiplicazione la lascio fare al compilatore, mi sembra l'approccio più semplice.
>
> Ma il compilatore lo sta scrivendo lui
Questa è anche colpa tua che gli dai corda...
Gli Svizzeri non sono tutti ricchi - Mattia
-
-
Re: Ok, argomento informatico.Scritto daaltgutente che non utieneil 2017-04-16 20:42:38.0 alle 2017-04-16 20:42:38.0Trollate totali: 11540> Io la moltiplicazione la lascio fare al compilatore, mi sembra l'approccio più semplice.

Il thread originario e` sulle divisioni per costanti intere.
Per esempio di norma puoi fare:
xor edx, edx
mov ebx, 3
div ebx
per dividere (senza segno) eax per 3, e ottenere il quoziente in eax e il resto in edx. Ma usa un sacco di registri fissi che vanno flushati, o salvati e ripristinati se il programma li ha allocati. E poi e` un'operazione di per se` penosamente lenta (tipo una quarantina di cicli). Pero` si puo` riscrivere come:
mov ebx, 55555555h
mul ebx
che prende 4 cicli, e usa solo eax come registro implicito (contiene il primo fattore) e fa una moltiplicazione di due valori a 32 bit dando un risultato di 64 bit. La parte alta del risultato viene depositata in edx, ed e` il quoziente della divisione per 3 (perche` 100000000h/3 = 55555555h) (h = esadecimale). Risponde all'equazione
n * 232 / 3 / 232 = n / 3
in cui l'errore di arrotondamento dovuto all'approssimazione intera del dividendo scalato, diviene insignificante purche` la costante per cui si moltiplica abbia una precisione di 2(32+x) bits, dove x e` il numero minimo di bits in grado di rappresentare il denominatore, meno uno.
Pero` non e` cosi` facile.
Poi ho menzionato della roba sull'ottimizzazione della moltiplicazione ma e` un altro discorso.
**Modificato dall'autore il 16.04.2017 20:44**-
Re: Ok, argomento informatico.Scritto daavvelentaniCubicolarioil 2017-04-16 20:55:50.0 alle 2017-04-16 20:55:50.0Trollate totali: 18184Scritto da: altg
> E poi e` un'operazione di per se` penosamente lenta (tipo una quarantina di cicli).
nei processori moderni e` meno lenta mi pare.
I think happiness is love
- Vladimir Putin-
Re: Ok, argomento informatico.Scritto daaltgutente che non utieneil 2017-04-16 21:04:10.0 alle 2017-04-16 21:04:10.0Trollate totali: 11540> > E poi e` un'operazione di per se` penosamente lenta (tipo una quarantina di cicli).
>
> nei processori moderni e` meno lenta mi pare.
Bene a sapersi, ma l'ottimizzazione per le invarianti serve lo stesso.
Poi se non ho tempo e/o voglia di farne diverse altre che servirebbero, le rimando al futuro. Vorrei tirare fuori il nuovo L.in.oleum tipo intorno a quest'estate e a un certo punto dovro` rimandare i dettagli, se no diventa la Novella Dello Stento™.
-
-
-
-
-
-