Re: Potreste non voler comprare un MacIntel [gmp et altri]
- From: riko@xxxxxxxxxxxxx (Mc Osten)
- Date: Sat, 1 Apr 2006 09:56:24 +0200
uliano <uliano@xxxxxxxxxxxxx> wrote:
aggiungo solo l'ultima considerazione
mi pare cosi' strano che usare/non usare l'assembly cambi
*sostanzialmente* (1) le cose
Nel 98% dei casi no. Non cambia proprio proprio nulla.
oggi (si suppone) abbiamo compliatori sofisticati, che ottimizzano,...
(btw hai pensato a cercarti un compilatore intel? magari ottimizza
meglio del gcc)
Non è quello. Peraltro ci sono alcuni tipi di ottimizzazione che per un
umano sono "evidenti", per una macchina no. Come sai, io lavoro nel
campo della correttezza (ovvero cerco di insegnare ad un computer a
dimostrare se un sorgente è o meno corretto). Il problema gemello è
quello dell'ottimizzazione (si tratta per il computer di capire cosa fa
il tuo codice e di modificarlo in uno equivalente più veloce)
Per esempio prendi questa funzione:
int func(){
int i;
int x = 2<<10;
for ( i=0; i < MAX; ++i){
if (i>= 0 && sqrt(i) >= 0)
x/=i;
}
}
Tu ad occhio vedi benissimo che il check dell'if è oltremodo pesante.
*sai* che i è sempre maggiore o uguale di 0. Puoi anche farne una
dimostrazione formale abbastanza agevole.
In pratica la guardia dell'if è inutile. Il check sul >= 0 non serve e
meno ancora sqrt. Nessuno dei due ha effetti collaterali (per il primo
lo sai, è facile, ma per il secondo devi sapere come è fatta sqrt, a
sboccio non hai modo di sapere che non setta un globale ad i, per cui
effettivamente non puoi semplicemente eliminarla senza cambiare la
semantica del programma.
Dicevo. Senza ottimizzare, questo compila tenendo tutta la guardia
dell'if:
L3:
cmpl $0, -16(%ebp)
js L4
cvtsi2sd -16(%ebp), %xmm0
sqrtsd %xmm0, %xmm0
movapd %xmm0, %xmm1
leal LC0-"L00000000001$pb"(%ebx), %eax
movsd (%eax), %xmm0
ucomisd %xmm0, %xmm1
jae L7
jmp L4
C'è il primo confronto i>= 0
cmpl $0, -16(%ebp)
js L4
e c'è pure il confronto con la radice (come vedi sta usando dei registri
mmx).
Bene... tutta la sezione L3 in effetti si può semplicemente togliere.
Ora in questo caso è semplicemente banale fare l'ottimizzazione. E in
effetti tutto il codice completo per la bagaglia di cui sopra
ottimizzato è:
.text
..globl _func
_func:
pushl %ebp
movl %esp, %ebp
xorl %eax, %eax
L2:
addl $1, %eax
cmpl $10, %eax
jne L2
popl %ebp
ret
.subsections_via_symbols
Lungo da solo quanto il controllo. E questo è esattamente quello che
avrebbe scritto un programmatore:
piccolo preludio, azzera il primo registro. Poi nel loop, incrementa il
primo registro (addl $1, %eax), confrontalo con il valore guardia
(nel sorgente MAX era una define a 10 ; cmpl $10, %eax), se è minore
o uguale torna a L2 (jne L2). Esci.
Ha ottimizzato perfino x/=i. Siccome vede che con x non ci faccio nulla,
allora dice: che lo calcolo a fare? Fa solo il ciclo. Fosse stato più
furbo non abrebbe fatto manco quello. Stupido io a prendere l'esempio.
Gli faccio ritornare x, ora.
Ecco... vediamo che a questo punto non è più *tanto* furbo:
.text
..globl _func
_func:
pushl %ebp
movl %esp, %ebp
pushl %ebx
xorl %ecx, %ecx
movl $2048, %eax
pxor %xmm1, %xmm1
jmp L2
L3:
testl %ecx, %ecx
js L11
L2:
cvtsi2sd %ecx, %xmm0
sqrtsd %xmm0, %xmm0
ucomisd %xmm1, %xmm0
jb L11
cltd
idivl %ecx
L11:
addl $1, %ecx
cmpl $9, %ecx
jle L3
popl %ebx
popl %ebp
ret
.subsections_via_symbols
Come vedi ritorna la radice quadrata ( sqrtsd %xmm0, %xmm0 ). Il
programmatore che avesse scritto l'assembly a mano avrebbe scritto [
metti che questo loop sia *molto* ricorrente ] un codice
significativamente più veloce.
Ammesso che questo mio esempio è del tutto cretino, è vero che il
compilatore in genere sa su quale architettura certe istruzioni sono più
sgamate, ma è vero ancora che le tecniche per le dimostrazioni formali
sono ancora relativamente poco usate (anche perchè suddette
dimostrazioni dilatano di moltissimo il tempo di compilazione, sono
*molto* difficili da scrivere, e rischiano di portare bachi su bachi con
errori minimi). Questo è parte di quasi tutti gli ambienti, non solo del
gcc.
Come dire... l'umano sulle cose "furbe" resta più furbo.
non sara' percaso che il tuo programmello al livello basso fa un uso
pesantte dell'altivec?
No. Io chiamo gmp. Come sia fatta sotto lei lo ignoro. So che ci sono
parti in assembly afaik 3-4-5 routines in tutto.
se cosi' fosse, e' mia impressione che le unita' vettoriali intel siano
ancora dietro
Questo è relativamente vero. Per lo meno per quello che ne so. Immagino
che ci siano persone che possano smentirmi o confermare.
(1) un g4 non *dovrebbe* prenderle da un core duo (2,3)
Il fatto che ormai si tende poco ad ottimizzare è noto. Il fatto che
spessissimo semplicemente non ce ne sia bisogno altrettanto.
Questo è uno di quei casi in cui invece fa davvero comodo.
(2) ma tutta quella libreria cosi intensa usa un solo core? tze'! :-P
La libreria non è multithread in se (ovviamente). Peraltro se uno lancia
un lavoro pesante, vanno entrambi i core, ma immagino sia l'os a
palleggiarsela.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
.
- Follow-Ups:
- References:
- Re: Potreste non voler comprare un MacIntel [gmp et altri]
- From: Mc Osten
- Re: Potreste non voler comprare un MacIntel [gmp et altri]
- From: uliano
- Re: Potreste non voler comprare un MacIntel [gmp et altri]
- Prev by Date: Re: Multitasking on MacIntel sucks
- Next by Date: Re: Una bella tastiera per l'iMac
- Previous by thread: Re: Potreste non voler comprare un MacIntel [gmp et altri]
- Next by thread: Re: Potreste non voler comprare un MacIntel [gmp et altri]
- Index(es):
Relevant Pages
|
