2010-07-08 20 views
35

... además del hecho de que RSCRIPT se invoca con #!/usr/bin/env Rscript y más pequeño con #!/usr/local/bin/r (en mi sistema) en la primera línea del archivo de script. He encontrado ciertas diferencias en la velocidad de ejecución (parece que littler es un poco más lento).Diferencia entre RSCRIPT y Littler

He creado dos scripts dummy, ejecuté cada 1000 veces y comparé el tiempo promedio de ejecución.

Aquí está el archivo RSCRIPT:

#!/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) 

y es el archivo más pequeño aquí:

#!/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) 

Como se puede ver, son casi idénticos (primera línea y se hunden argumento de archivo difieren). La salida es sink ed a archivo de texto, por lo tanto, se importa en R con read.table. Creé el script bash para ejecutar cada script 1000 veces, luego los promedios calculados.

Aquí es escritura del golpe:

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

y los resultados son:

# 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 

larga historia: al lado (obvio) la diferencia en tiempo de ejecución, ¿hay alguna otra diferencia? La pregunta más importante es: ¿por qué debería/no debería preferir littler sobre Rscript (o viceversa)?

+1

+1 Gran pregunta; amar los detalles – Shane

+0

Gracias Shane, el archivo de datos está disponible aquí: http://bit.ly/ac0Fb1 Observe que tengo una máquina muy lenta, por lo que si decide ejecutar estos scripts, es más probable que obtenga valores más bajos. Las grandes respuestas de Dirk, como de costumbre, llamaron la atención sobre otros problemas con estos scripts de referencia ... así que tome estos resultados cum grano salis. – aL3xa

Respuesta

20

par de comentarios rápidos:

  1. El camino /usr/local/bin/r es arbitraria, se puede utilizar /usr/bin/env r, así como lo hacemos en algunos ejemplos. Por lo que recuerdo, que limita lo que otros argumentos que se pueden dar a r tan sólo se necesita una Cuando se invoca a través de env

  2. No entiendo su punto de referencia, y por qué lo haría de esa manera. Nosotros do tenemos comparaciones de tiempo en las fuentes, vea tests/timing.sh y tests/timing2.sh. Tal vez quiera dividir la prueba entre el inicio y la creación del gráfico o lo que sea que esté buscando.

  3. Siempre que ejecutamos esas pruebas, ganó el littler. (Todavía ganó cuando volví a ejecutar esos en este momento.) Lo cual tenía sentido para nosotros porque si mira las fuentes a Rscript.exe, funciona de manera diferente configurando el entorno y una cadena de comando antes de llamar eventualmente al execv(cmd, av). el pequeño puede comenzar un poco más rápido.

  4. El precio principal es la portabilidad. La forma en que se construye más pequeño, no llegará a Windows. O al menos no fácilmente. OTOH tenemos RInside portado así que si alguien realmente quisiera ...

  5. Littler llegó primero en septiembre de 2006 frente a Rscript, que venía con R 2.5.0 en abril de 2007.

  6. Rscript está ahora en todas partes donde está R. Esa es una gran ventaja.

  7. Las opciones de la línea de comandos son un poco más sensatas para los más pequeños desde mi punto de vista.

  8. Ambos funcionan con los paquetes CRAN getopt y optparse para el análisis de opciones.

Así que es una preferencia personal. Co-escribí más pequeño, aprendí mucho haciendo eso (por ejemplo, para RInside) y todavía lo encuentro útil, así que lo uso docenas de veces al día. Conduce CRANberries. Conduce cran2deb. Su kilometraje puede, como dicen, variar.

Descargo de responsabilidad: littler es uno de mis proyectos.

Postscriptum: habría escrito la prueba como

habría escrito esto como

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

o incluso

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

para deshacerse de los valores atípicos. Además, solo se miden esencialmente las E/S (una impresión y un gráfico) que ambos obtendrán de la biblioteca R, por lo que esperaría poca diferencia.

+1

Dirk, gracias por su respuesta rápida y completa. Esperaba su respuesta con mucha ansiedad, debido a su participación en este proyecto (y, sí, lo sabía antes de comenzar una publicación). Anuncio 1: yo uso ArchLinux, y obtengo solo '/ usr/local/bin/r' con' whereis r'. Si pongo el error '/ usb/bin/env r', ocurre. Anuncio 2: voy a probar las pruebas. Sé que el pequeño debe realizar más rápido, y todavía estoy sorprendido por el hecho de que el pequeño desempeño fue más lento con la creación del gráfico. Anuncio 3: no entiendo, ¿ejecutaste guiones de mi publicación y obtuve resultados diferentes? ¿Puedes, por favor, publicarlos? – aL3xa

+0

Podrías haberme enviado un correo electrónico :) Re 1: No hay error aquí, asegúrate de tener los modos correctos y todo. Re 2: Mis pruebas fueron sobre cuán rápido comienza cada variante diferente; una vez que comencé, esperaría que hicieran lo mismo ya que todos usan la misma R. Re 3 subyacente: No, yo no utilicé tu script; Solo estaba tratando de mostrar que uno debe usar 'system.time (expression)' en lugar de la construcción 'proc.time()'. –

+1

OK, cambiaré las secuencias de comandos ficticias (nombradas por su autor) y veré qué sucede. – aL3xa