2014-12-08 17 views
6

Zastanawiam się, o ile szybszy jest a!=0 niż !a==0 i użyłem mikroprocesora pakietu R. Oto kod (zmniejszenie 3E6 i 100 Jeśli komputer jest powolny):Czas obliczeń! =

library("microbenchmark") 
a <- sample(0:1, size=3e6, replace=TRUE) 
speed <- microbenchmark(a != 0, ! a == 0, times=100) 
boxplot(speed, notch=TRUE, unit="ms", log=F) 

Everytime, mam działkę, jak ten poniżej. Zgodnie z oczekiwaniami pierwsza wersja jest szybsza (mediana 26 milisekund) niż druga (33 ms).

Ale skąd pochodzą te bardzo wysokie wartości (wartości odstające)? Czy to jakiś efekt zarządzania pamięcią? Jeśli ustawię czas na 10, nie ma wartości odstających ...

Edycja: sessionInfo(): R wersja 3.1.2 (2014-10-31) Platforma: x86_64-w64-mingw32/x64 (64-bit)

computation time unequal and not_equal

+2

Nie sądzę, to będzie łatwo wyśledzić; Widziałem podobne wyniki nawet z 'times = 10' lub podobnym. Pamiętaj, że 'microbenchmark' nie jest kuloodporny. Istnieje kilka blogów gdzieś wskazujących na semibug w jaki sposób zbiera informacje o czasie. Może też być tak, że od czasu do czasu w normalnym toku operacji 'R' dzieje się coś podobnego - wywołanie' gc' lub czekanie na realokację RAM na poziomie systemu, itd. Być może spróbuj uruchomić pętlę wokół 'system.time', aby zobaczyć, jaka jest dystrybucja wyników? –

Odpowiedz

2

Mówisz, że nie masz odstających gdy times=10, ale prowadzony microbenchmark z times=10 kilka razy i jest prawdopodobne, aby zobaczyć dziwne odrębne stanowisko. Oto porównanie jednego przebiegu times=100 z dziesięcioma przebiegami times=10, co pokazuje, że wartości odstające występują w obu sytuacjach.

W zależności od wielkości obiektów związanych z wyrażeniem, wyobrażam sobie, że wartości odstające mogą powstać, gdy urządzenie zmaga się z ograniczeniami pamięci, ale mogą one również wystąpić z powodu obciążenia procesora, np. ze względu na procesy inne niż R.

a <- sample(0:1, size=3e6, replace=TRUE) 
speed1 <- microbenchmark(a != 0, ! a == 0, times=100) 
speed1 <- as.data.frame(speed1) 

speed2 <- replicate(10, microbenchmark(a != 0, ! a == 0, times=10), simplify=FALSE) 
speed2 <- do.call(rbind, lapply(speed2, cbind)) 

times <- cbind(rbind(speed1, speed2), method=rep(1:2, each=200)) 
boxplot(time ~ expr + method, data=times, 
     names=c('!=; 1x100', '!==; 1x100', '!=; 10x10', '!==; 10x10')) 

enter image description here

+0

Na tym poziomie rozdzielczości uważam, że wartości odstające są prawie zawsze wynikiem zbierania śmieci. – hadley

0

myślę, że porównanie jest slighlty niesprawiedliwe. Oczywiście można uzyskać wartości odstające, czas obliczeń zależy od kilku czynników (odśmiecanie, wyniki w pamięci podręcznej, itp.), Więc nie jest to naprawdę niespodzianka. Używasz tego samego wektora a we wszystkich testach porównawczych, więc buforowanie z pewnością odegrałoby pewną rolę.

I dostosowane nieco się proces randomizacji a zmienna przed obliczeń i mam stosunkowo porównywalne wyniki:

library("microbenchmark") 
do.not<-function() { 
    a <- sample(0:1, size=3e6, replace=TRUE) 
    a!=0; 
} 

do<-function() { 
    a <- sample(0:1, size=3e6, replace=TRUE) 
    a==0; 
} 

randomize <- function() { 
    a <- sample(0:1, size=3e6, replace=TRUE) 
} 


speed <- microbenchmark(randomize(), do.not(), do(), times=100) 
boxplot(speed, notch=TRUE, unit="ms", log=F) 

Boxplot

również dodaje funkcję sample jako wartości odniesienia patrz jak to jest "niestabilne".

Osobiście nie jestem zaskoczony tymi odstającymi. Ponadto, nawet jeśli uruchomisz ten sam test porównawczy dla size=10, nadal otrzymasz punkty odstające. Nie są one wynikiem obliczeń, ale ogólny stan PC (z systemem inne skrypty, obciążenie pamięci, etc)

Dzięki

+2

Porównujesz '! =' I '=='.Różny czas jest wynikiem dodatkowego wywołania '!' W '! (A == 0)'. – Roland

Powiązane problemy