2013-04-22 19 views
7

Ho analizzato il seguente programma utilizzando Matlab profile. Sia double che uint64 sono variabili a 64 bit. Perché il confronto di due doppi è molto più veloce rispetto al confronto di due uint64? Non sono entrambi paragonati per bit?Perché il confronto è doppio più veloce di uint64?

big = 1000000; 

a = uint64(randi(100,big,1)); 
b = uint64(randi(100,big,1)); 
c = uint64(zeros(big,1)); 
tic; 
for i=1:big 
    if a(i) == b(i) 
     c(i) = c(i) + 1; 
    end 
end 
toc; 

a = randi(100,big,1); 
b = randi(100,big,1); 
c = zeros(big,1); 
tic; 
for i=1:big 
    if a(i) == b(i) 
     c(i) = c(i) + 1; 
    end 
end 
toc; 

Questa è la misura del profilo:

profile screenshot

Questo è ciò che le misure Tictoc:

Elapsed time is 6.259040 seconds. 
Elapsed time is 0.015387 seconds. 

L'effetto scompare quando uint8..uint32 o int8..int32 sono utilizzato al posto dei tipi di dati a 64 bit.

+0

Non so di Matlab, ma spesso i doppi vengono confrontati per vedere se sono a una distanza epsilon l'uno dall'altro. Ciò rende il confronto più macchinoso. –

+0

@EricJ. Non è il caso in MATLAB, ho paura. Anche un po 'confuso da questa domanda. – jazzbassrob

+1

dai risultati sembra che il confronto dei doppi sia molto più veloce di uint64 – Jonas

risposta

6

Probabilmente è una combinazione dell'interprete Matlab e della CPU sottostante che non supporta i tipi int a 64 bit e gli altri.

Matlab favori double su int operazioni. La maggior parte dei valori sono memorizzati nei tipi double, anche se rappresentano valori interi. Le operazioni double e int== eseguiranno percorsi di codice diversi e MathWorks avrà dedicato molta più attenzione all'ottimizzazione e all'ottimizzazione del codice per double che per inte, in particolare int64. In effetti, le versioni precedenti di Matlab non supportavano operazioni aritmetiche su int64. (E IIRC, non supporta ancora la matematica con numeri interi.) Quando si esegue la matematica int64, si sta utilizzando un codice meno maturo e meno sintonizzato e lo stesso può essere applicato a ==. I tipi int non sono una priorità in Matlab. La presenza di int64 potrebbe persino interferire con il JIT, ottimizzando tale codice, ma è solo un'ipotesi.

Ma potrebbe esserci anche un motivo hardware sottostante. Ecco un'ipotesi: se sei su x86 a 32 bit, stai lavorando con registri a uso generale a 32 bit (interi). Ciò significa che i tipi int più piccoli possono essere contenuti in un registro e confrontati con istruzioni rapide, ma i valori int a 64 bit non si adattano a un registro e possono richiedere sequenze di istruzioni più costose da confrontare. Gli double s, sebbene siano larghi 64 bit, si inseriscono negli ampi registri in virgola mobile dell'unità x87 in virgola mobile e possono essere confrontati in hardware utilizzando istruzioni di confronto in virgola mobile rapide. Ciò significa che gli [u]int64 s sono gli unici che non possono essere confrontati utilizzando operazioni di registrazione singola rapide a singola istruzione.

In questo caso, se si esegue questo stesso codice su 64-bit x86-64 (in Matlab a 64 bit), la differenza potrebbe scomparire perché si hanno quindi registri di ampio uso a 64 bit. Ma poi di nuovo, non può, se il codice dell'interprete Matlab non è compilato per trarne vantaggio.

+1

+1, sembra che l'hardware sia principalmente guasto qui. Ho provato su R2010 su una APU (che ha una matematica aritmetica a doppia precisione veloce ma una matematica orribile di interi), e il problema era identico per 'single' e' (u) int8,16,33'. Poi ho provato su CPU 64-bit, Matlab R2012 a 64-bit (che ha registri general purpose larghi 64-bit), e tutti i problemi sono scomparsi. –

+0

@RodyOldenhuis: Ooh, dicci di più su questa APU su cui stai lavorando. Sembra interessante ed è nuovo per me. –

+1

Vedere [questo elenco] (http://en.wikipedia.org/wiki/List_of_AMD_Accelerated_Processing_Unit_microprocessors); Ho un AMD A6-3650, soprattutto grazie ai feticci del nostro responsabile IT;) Fino ad ora, non è stato molto buono per me; ci sono molti strani effetti collaterali (come quello che ho menzionato prima). Per le computazioni/simulazioni scientifiche ad alte prestazioni che sto facendo/progettando, preferisco CPU + GPU per ora :) Concesso, la mia APU è piuttosto nuova e non proprio la migliore, quindi spero che questo cambi in futuro (perché credo che abbiano un sacco di potenziale) –

Problemi correlati