El esplendor y la pobreza de la OLP - página 6
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Demostró que la llamada directa o la llamada virtual no tienen ningún efecto en los proyectos reales.
La gran mayoría de los costes se producen al llamar a las funciones del sistema, donde los programas MQL pasan casi todo su tiempo. Los costes de organización de las llamadas son insignificantes en comparación con la carga útil.
¿Dónde lo ha mostrado? ¿Es una tabla con algunos nombres de funciones y medidas un argumento? Aquí no somos expertos telepáticos, hay que ver el código de las funciones y luego se puede decir algo.
¿Dónde lo ha mostrado? Una tabla con algunos nombres de funciones y medidas - ¿es eso un argumento? No somos expertos en telepatía aquí. Necesitas ver el código de las funciones, entonces podemos hablar de otra cosa.
Demostró que en los proyectos reales, la llamada directa o la llamada virtual no tienen ningún impacto.
La gran mayoría de los costes se producen en las llamadas a funciones del sistema, donde los programas MQL pasan la mayor parte de su tiempo. El coste de organizar las llamadas es insignificante comparado con la carga de trabajo.
+100 ¡Sí, lo hace!
Además, me he dado cuenta de que cuando he tenido que reescribir las clases dispersas para que algunas de sus funciones fueran realizadas por otras clases (inclusión/descomposición), el rendimiento general ha aumentado y el control sobre el código también. En otras palabras, en la práctica, vemos lo contrario de lo que los fans de Integer y de la vieja escuela de C intentan demostrarnos: el número de clases crece, el número de métodos crece, y el rendimiento, por el contrario, crece.
¿Dónde lo ha mostrado? Una tabla con algunos nombres de funciones y medidas - ¿es eso un argumento? No somos expertos en telepatía aquí. Necesitas ver el código de las funciones, entonces podemos hablar de otra cosa.
+100 ¡Sí, eso es!
Además, me he dado cuenta de que cuando he tenido que reescribir clases dispersas para que algunas de sus funciones fueran realizadas por otras clases (inclusión/descomposición), el rendimiento general ha aumentado y el control sobre el código también. En otras palabras, en la práctica, vemos lo contrario de lo que los fans de Integer y de la vieja escuela de C intentan demostrarnos: el número de clases crece, el número de métodos crece, y el rendimiento, por el contrario, crece.
¿Una nueva forma de autocomplacencia? Vamos, vamos.
Vasily, deberías haber leído lo que intentaba demostrar aquí, sin embargo (y pienses lo que pienses, lo demostré).
Tenga en cuenta, sin embargo, que tener el código fuente no le dirá nada. La complejidad acumulada no es la misma. Incluso después de analizar las fuentes dirías "bueno, algo allí se llama, algo se cuenta, algo se saca de algún sitio, pero qué exactamente no está claro, así que de nuevo no se demuestra nada".
En general, sí, probablemente tengas razón, las funciones individuales probablemente no te digan mucho. Qué sentido tiene hablar de tu software si es un cerdo en un charco para todos los demás.
De hecho, lo que más nos interesa es el número total de pasadas por métodos virtuales, y el tiempo total invertido en ello. Aquí en su tabla hay alguna función sombreada ejecutada 5 millones de veces. Sin embargo, 5 millones es una minucia. Supongo que no tienes ningún cálculo pesado en tu programa, así que no hay mucho que discutir. Supongamos que estuvieras calculando un sistema de ecuaciones lineales de 30000x300000 y accediendo a los elementos de la matriz a través de métodos virtuales, sí habría algo que hablar.
¿Una nueva forma de autoinfluir? Vamos, vamos.
Vasily, deberías, después de todo, leer lo que intentaba demostrar aquí (y lo que pienses al respecto, lo demostró).
Dmitry, no estoy ni a favor ni en contra de ti. Para entenderlo, hay que conocer el funcionamiento interno del compilador en línea, pero abrir esta información para MQ equivale a ayudar a escribir un descompilador.
De los que están discutiendo aquí, sólo Renat tiene esa información, así que tenemos que confiar en su palabra. No veo otra manera.
Si dice que no estás configurando la prueba correctamente, probablemente lo estés haciendo.
La cuestión es diferente, sólo MQ puede establecer la prueba correctamente en tal caso, eso es lo que hay que hacer.
Como se dice prueba por prueba, mi palabra contra la tuya. Y tú tratas de demostrar lo indemostrable. Es imposible demostrar o refutar sus afirmaciones sin tener algo con lo que compararlas.
El descompilador está fuera de lugar en este caso.
Sólo hay que entender y conocer las técnicas de optimización de los compiladores para evitar probar los casos degenerados simplificados, que se optimizan brutalmente y degeneran en código lineal. Hemos lanzado la cuarta generación de compiladores para nada.
Esto es exactamente de lo que estamos hablando.
Por ejemplo, si estuviéramos calculando un sistema de ecuaciones lineales 30000x300000 y el acceso a los elementos de la matriz fuera a través de métodos virtuales, ya hay algo de lo que hablar.
En estos casos, la primera refactorización le daría una ganancia de velocidad cien veces mayor. Y la llamada virtual ocuparía el décimo lugar en cuanto a costes.
Es decir, el ejemplo es poco realista.
Entonces escribamos todo en lenguaje ensamblador. Sería más rápido de todos modos.
No entiendo el problema. Nunca he visto un Asesor Experto o indicador con 1 MB de código.
La llamada de cualquier función también lleva algún tiempo. ¡Renunciemos también a las funciones!
El control de los grandes proyectos es mucho más cómodo con la POO.
Además, la velocidad de ejecución del código no suele ser tan crítica como el tiempo de ping al broker y la respuesta a la orden del broker.
Comprueba los algoritmos HFT. Requieren la máxima velocidad, pero no encontrarás cálculos complejos.
PS. Normalmente no se necesita un supercoche o una moto de nieve para ir del punto A al punto B. ¡Un ciclomotor es suficiente! ¡Un ciclomotor es suficiente!