2010-07-08 10 views
35

... neben der Tatsache, dass Rscript mit #!/usr/bin/env Rscript und weggeworfener mit #!/usr/local/bin/r (auf meinem System) aufgerufen wird, in erster Linie der Skriptdatei. Ich habe bestimmte Unterschiede in der Ausführungsgeschwindigkeit gefunden (scheint littler ist ein bisschen langsamer).Unterschied zwischen Rscript und weggeworfener

Ich habe zwei Dummy-Skripts erstellt, die jeweils 1000 Mal ausgeführt und durchschnittliche Ausführungszeit verglichen.

Hier ist die Rscript Datei:

#!/usr/bin/env Rscript 

btime <- proc.time() 
x <- rnorm(100) 
print(x) 
print(plot(x)) 
etime <- proc.time() 
tm <- etime - btime 
sink(file = "rscript.r.out", append = TRUE) 
cat(paste(tm[1:3], collapse = ";"), "\n") 
sink() 
print(tm) 

und hier ist die littler Datei:

#!/usr/local/bin/r 

btime <- proc.time() 
x <- rnorm(100) 
print(x) 
print(plot(x)) 
etime <- proc.time() 
tm <- etime - btime 
sink(file = "little.r.out", append = TRUE) 
cat(paste(tm[1:3], collapse = ";"), "\n") 
sink() 
print(tm) 

Wie Sie sehen können, sind sie fast identisch (erste Zeile und versenken Dateiargument unterscheiden). Ausgabe ist sink Ed in Textdatei, daher in R mit importiert. Ich habe ein Bash-Skript erstellt, um jedes Skript 1000-mal auszuführen, dann berechnete Durchschnittswerte.

Hier Bash-Skript:

for i in `seq 1000` 
do 
./$1 
echo "####################" 
echo "Iteration #$i" 
echo "####################" 
done 

Und die Ergebnisse sind:

# littler script 
> mean(lit) 
    user system elapsed 
0.489327 0.035458 0.588647 
> sapply(lit, median) 
    L1 L2 L3 
0.490 0.036 0.609 
# Rscript 
> mean(rsc) 
    user system elapsed 
0.219334 0.008042 0.274017 
> sapply(rsc, median) 
    R1 R2 R3 
0.220 0.007 0.258 

lange Kurzgeschichte: neben (offensichtlich) execution-Zeitdifferenz, gibt es einen anderen Unterschied? Wichtigere Frage ist: Warum sollten/sollten Sie nicht bevorzugen little über Rscript (oder umgekehrt)?

+1

+1 Große Frage; liebe das Detail. – Shane

+0

Danke Shane, Datendatei ist hier verfügbar: http://bit.ly/ac0Fb1 Beachten Sie, dass ich sehr langsame Maschine habe. Wenn Sie also diese Skripts ausführen, erhalten Sie wahrscheinlich niedrigere Werte. Dirks großartige Antworten, wie immer, haben die Aufmerksamkeit auf andere Probleme mit diesen Benchmark-Skripten gelenkt ... also nimm diese Ergebnisse cum grano salis. – aL3xa

Antwort

20

Paar schnelle Kommentare:

  1. Der Weg /usr/local/bin/r willkürlich ist, können Sie /usr/bin/env r auch verwenden, wie wir in einigen Beispielen tun. Soweit ich mich erinnere, schränkt sie, was andere Argumente können Sie r geben, da es nur ein nimmt, wenn sie über env

  2. aufgerufen Ich verstehe nicht, Ihre Benchmark, und warum Sie würde es auf diese Weise tun. Wir haben do Timing-Vergleiche in den Quellen, siehe tests/timing.sh und tests/timing2.sh. Vielleicht möchten Sie den Test zwischen dem Start und der Erstellung von Graphen aufteilen oder was auch immer Sie wollen.

  3. Immer wenn wir diese Tests durchführten, gewann wenig. (Es hat immer noch gewonnen, als ich diese jetzt gerade wieder lief.) Das ergab für uns Sinn, denn wenn man sich die Quellen zu Rscript.exe ansieht, funktioniert es anders, indem man die Umgebung und eine Befehlsfolge einrichtet, bevor schließlich execv(cmd, av) aufgerufen wird. Kleiner kann etwas schneller anfangen.

  4. Der Hauptpreis ist Portabilität. Die Art, wie Littler gebaut wird, wird es nicht zu Windows schaffen. Oder zumindest nicht leicht. OTOH wir haben RIside ported also wenn jemand wirklich wollte ...

  5. Littler kam zuerst im September 2006 gegen Rscript, das mit R 2.5.0 im April 2007 kam.

  6. Rscript ist jetzt überall wo R ist. Das ist ein großer Vorteil.

  7. Befehlszeilenoptionen sind aus meiner Sicht etwas sinnvoller für kleine.

  8. Beide arbeiten mit den CRAN-Paketen getopt und optparse für das Parsen von Optionen.

So ist es eine persönliche Vorliebe. Ich habe Kleinbücher geschrieben, viel gelernt (zB für Rinside) und finde es immer noch nützlich - also benutze ich es Dutzende Male jeden Tag. Es treibt CRANberries an. Es fährt cran2deb. Ihre Meilenzahl kann, wie sie sagen, variieren.

Haftungsausschluss: Kleiner ist eines meiner Projekte.

Postscriptum: Ich würde den Test als

geschrieben habe

ich würde dies als

geschrieben
fun <- function { X <- rnorm(100); print(x); print(plot(x)) } 
    replicate(N, system.time(fun)["elapsed"]) 

oder sogar

mean(replicate(N, system.time(fun)["elapsed"]), trim=0.05) 

auf dem Ausreißer loszuwerden. Darüber hinaus messen Sie im Wesentlichen nur I/O (einen Druck und eine Grafik), die beide aus der R-Bibliothek erhalten, so dass ich wenig Unterschied erwarten würde.

+1

Dirk, danke für die schnelle und gründliche Antwort! Ich habe Ihre Antwort mit großer Angst erwartet, wegen Ihrer Beteiligung an diesem Projekt (und, ja, das wusste ich, bevor ich einen Posten begann). Ad 1: Ich benutze ArchLinux und bekomme nur '/ usr/local/bin/r' mit' whereis r'. Wenn ich '/ usb/bin/env r' Fehler auftritt. Ad 2: Ich werde Tests versuchen. Ich weiß, dass Kleinere schneller arbeiten sollten, und ich bin immer noch erstaunt über die Tatsache, dass Kleinere langsamer mit der Graphenerstellung arbeiteten. Ad 3: Ich verstehe nicht, Sie haben Skripte von meinem Beitrag ausgeführt und unterschiedliche Ergebnisse erzielt? Kannst du sie bitte posten? – aL3xa

+0

Sie hätten mir eine E-Mail schicken können :) Zu 1: Kein Fehler hier, stellen Sie sicher, dass Sie die richtigen Modi und alles haben. Zu 2: Bei meinen Tests ging es darum, wie schnell jede unterschiedliche Variante startet; Wenn ich einmal angefangen habe, würde ich erwarten, dass sie dasselbe tun, da sie alle das gleiche zugrundeliegende R verwenden. Re 3: Nein, ich habe dein Skript nicht benutzt; Ich wollte nur zeigen, dass man 'system.time (Ausdruck)' anstelle des 'proc.time()' Konstrukts verwenden sollte. –

+1

OK, ich werde Dummy-Skripte ändern (benannt nach ihrem Autor) und sehen, was passiert. – aL3xa