studio - time r
Diferencia entre Rscript y Littler (1)
... además del hecho de que Rscript se invoca con #!/usr/bin/env Rscript
y littler 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 el littler es un poco más lento).
Creé dos scripts ficticios, 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 aquí está el archivo más pequeño:
#!/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 puede ver, son casi idénticos (los argumentos de la primera línea y del archivo de frenado difieren). La salida se read.table
al 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í está el script bash:
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 corta: además de la diferencia de tiempo de ejecución (obvia), ¿hay alguna otra diferencia? La pregunta más importante es: ¿por qué debería / no debería preferir el littler sobre Rscript (o viceversa)?
Par comentarios rápidos:
La ruta
/usr/local/bin/r
es arbitraria, puede usar/usr/bin/env r
, así como lo hacemos en algunos ejemplos. Según recuerdo, limita qué otros argumentos puedes darle ar
ya que solo requiere uno cuando se invoca a través deenv
No entiendo su punto de referencia, y por qué lo haría de esa manera. Tenemos comparaciones de tiempo en las fuentes, ver
tests/timing.sh
ytests/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.Cada vez que realizamos esas pruebas, Littler ganó. (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 diferente al configurar el entorno y una cadena de comandos antes de llamar finalmente aexecv(cmd, av)
. el pequeño puede comenzar un poco más rápido.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 ...
Littler llegó primero en septiembre de 2006 frente a Rscript, que venía con R 2.5.0 en abril de 2007.
Rscript está ahora en todas partes donde R es. Esa es una gran ventaja.
Las opciones de la línea de comando son un poco más sensatas para los más pequeños, desde mi punto de vista.
Ambos funcionan con los paquetes CRAN getopt y optparse para el análisis de opciones.
Entonces 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
Yo 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.