Discusión sobre el artículo "Distribuciones Estadísticas en MQL5: tomando lo mejor de R" - página 6

Nuevo comentario
 
Renat Fatkhullin:

Esto no es más que una pura prueba práctica y teórica de la falacia de la postura expresada por algunos operadores en el tema https://www.mql5.com/ru/forum/96176/page10 (había una mención en alguna parte):

  • en R todas las librerías están optimizadas y son lo más rápidas posible
  • hay muchas optimizaciones en R, incluyendo Intel Threading Building Blocks, etc.


Resultó que esto no es cierto. En la función más simple, resultó ser un drenaje y MQL5 es más eficiente. Por otra parte, he fundamentado por qué es más rápido teóricamente. Además de los resultados prácticos.

R incluso se llama oficialmente "lenguaje y entorno" - por dentro en realidad es un esquema con sus dsl, macros, sexpr y basura que "pega" a diferentes libs y entorno...Pero es compacto y fácil de extender, en realidad es bueno, por eso se valora. Y no hace mucho los apologistas de los paquetes mat.stat. por un lado y los fans de FP por otro estaban denunciando a R por los frenos :-).

PD. por cierto, existe la sospecha de que en microbenchmark seq() se despliega ya dentro de las medidas. Una minucia, por supuesto.

 
Maxim Kuznetsov:

R incluso se llama oficialmente "lenguaje y entorno" - por dentro es en realidad un esquema con sus dsl, macros, sexpr y basura que "pegan" a diferentes libs y entorno...Pero es compacto y fácil de extender, en realidad es así de bueno, por eso es apreciado. Y no hace mucho los apologistas de los paquetes mat.stat. por un lado y los fans de FP por otro estaban denunciando a R por los frenos :-))

Que se llame como se quiera.

Es sólo que la afirmación sobre su optimización resultó ser falsa aunque tenga muchas funciones en DLL nativas de 64 bits. Ahora señalaremos en todas partes que nuestros cálculos matriciales son más rápidos que en R. Y que la transferencia de las ideas desarrolladas de R a MQL5 dará una ventaja real.


PS. por cierto, hay una sospecha de que en microbenchmark seq() se despliega ya dentro de las mediciones. Una tontería, por supuesto.

No, seq está fuera de la medición.

Intente llamarlo usted mismo muchas veces después de un único llenado mediante seq

res <- microbenchmark(a<-dbinom(k, n, pi/10, log = TRUE))
print(res)
 
Siendo teórico nunca me atrevería a discutir con un desarrollador-practicante, porque siendo desarrollador-practicante en mi campo, siempre miro con condescendencia las críticas de los teóricos.
 
Renat Fatkhullin:

En MQL5 se cuenta el doble de rápido: 10 microsegundos contra 20 microsegundos en R.

Tengo un poco diferente.
Tiempo medio: MT5 12 microsegundos, R 16 microsegundos
Mínimo: MT5 8 microsegundos, R 15 microsegundos.

Windows 10 Pro (x64 basado en PC), IE 11.00, UAC, Intel Core i7-6700 @ 3.40GHz
R - 3.3.1 x64
MT5 1445

Enhorabuena, mql compilador puede buena optimización.

<nerd mode>.

A los resultados de MT5 hay que sumarle 100 milisegundos gastados en la compilación.
R en 16 microsegundos consigue interpretar la entrada de una cadena y pasarla a la librería y obtener el resultado de vuelta.

</ modo nerd>

 
Dr.Trader:
< modo nerd>

A los resultados de MT5 debes añadir 100 milisegundos gastados en la compilación.
R tarda 16 microsegundos en interpretar el resultado de una cadena y pasarlo a la biblioteca y obtener el resultado de vuelta.

</ modo nerd>.

No es así.

Yo también creía que se debería optimizar en R. Pero lo instalé yo mismo, empecé a entenderlo yo mismo y me di cuenta absolutamente de que este sistema no puede exprimir al máximo debido a la sobrecarga del sistema del lenguaje dinámico.


Deberías fijarte en el tiempo mínimo. Tienes una confirmación directa de mis resultados: 8 frente a 15.

 
Renat Fatkhullin:

Que se llame como quiera.

Es sólo que la afirmación sobre su optimización resultó ser falsa aunque tenga muchas funciones en DLL nativas de 64 bits. Ahora señalaremos en todas partes que nuestros cálculos matriciales son más rápidos que en R. Y que la transferencia de ideas desarrolladas de R a MQL5 dará una ventaja real.


No, seq está fuera de medida.

Trate de llamar muchas veces a ti mismo después de un solo llenado a través de seq.

No es un hecho en absoluto..R es un FP, puede "omitir" una parte significativa de los cálculos simplemente porque es innecesario, puede hacer una conclusión específica sobre la ruta de cálculo. Solo cosas incomparables, como agrio y suave :-)

 
Maxim Kuznetsov:

no es un hecho en absoluto..R es un FP, puede "omitir" una parte significativa del cómputo simplemente por innecesaria, puede hacer una inferencia específica sobre el camino del cómputo. Solo cosas incomparables, como agrio y blando :-)

Ya esta bien de tonterias.

Una y otra vez intentando refutar la realidad.

 

Estoy hablando de R, pero mi habilidad es muy pequeña)) ¿alguien puede comprobar la corrección del código?

library(microbenchmark)
library(compiler)
n <- 2000
k <- seq(0,n,by=20)
q<- function(xx) { dbinom(k, n, pi/10, log = TRUE) }
res <- microbenchmark(cmpfun(q))
print(res)


Los resultados muestran los mismos gráficos para este código




y el código de Renate.


Si el código es correcto, ¿puedes comprobar el benchmark?

 
Dr.Trader:

A los resultados de MT5 hay que añadir 100 milisegundos gastados en la compilación.

Quiero decir que el compilador mql ya conoce todos los parámetros de entrada durante la compilación. Basta con que calcule todo durante la compilación, y al llamar al script - sólo devuelve el resultado precalculado. He visto algunos artículos en el hub donde se comparaban compiladores de c++, y a juzgar por el análisis del código ensamblador, esto es exactamente lo que ocurre allí.

 
ivanivan_11:

Si el código es correcto, ¿puedes comprobar el benchmark?

La pregunta se cancela, en la primera prueba los resultados fueron en microsegundos, aquí están en milisegundos. no prestó atención al principio

12345678910111213...20
Nuevo comentario