![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
tiempo = 1018
suma = 894782460
tiempo = 371
suma = 894782460
No sé por qué, pero µl lo supera (y las variantes más intrincadas de rand() también).
Y para mí es obvio: sacarlo del bucle.
Sí, tienes razón, yo también lo probé en VS y por alguna razón no optimizaba nada, aunque parece una variante tan sencilla... De hecho se reduce a esto:
Sí, tienes razón, lo he probado también en VS - por alguna razón no está optimizado en lo más mínimo, aunque una opción tan simple, parece... En esencia se reduce a esto:
¿Estás seguro de que has activado toda la optimización en la configuración del proyecto? En casos extraños conecto la generación del listado de ensamblaje y lo reviso, es muy instructivo.
Decidí probarlo también en C# por curiosidad. No sólo los resultados son casi iguales en velocidad, sino que también funcionan mucho más rápido que en C++.
Resultados:
Suma: 894782460, Tiempo: 69 ms.
Suma: 894782460, Tiempo: 56 ms
Y aquí hay un análogo en C++:
Suma: 894782460, Tiempo: 2947 ms
Suma: 894782460, Tiempo: 684 ms
Lo pruebo en VS 2019,toda la optimización está habilitada .
Que se joda tal C++).
p.s. Los resultados en C# varían gratamente de una prueba a otra, pero en promedio ambas variantes son igualmente rápidas.
Primero hay que entender las razones de los frenos. He investigado un poco, y todo está en línea excepto la llamada
que se encuentra en libstdc++. Es decir, en el fondo del bucle casi desnudo el cuello de botella son las propias llamadas a la función (y hay un par de llamadas de ...replaceEmmPKcm también). El compilador puede optimizar dentro de una sola unidad de traducción. Puede intentar utilizar LTO (link time optimization), es decir, esto permite optimizar en la fase de enlace. Pero no lo he usado, no lo haré ahora. Bueno, no hay nada particularmente complicado - pasar al compilador/linker la opción -flto (pero me falta algún plugin), demasiado perezoso para averiguarlo + puede que tenga que reconstruir libstdc++.
¿Cómo será la optimización del código en relación con el próximo atornillado de módulos (desde C++20)? No sé, puedes probar en vs, aunque todo es crudo y experimentalhttps://habr.com/en/company/pvs-studio/blog/328482/
c++'u se echará de menos )).
Por interés, decidí hacer la prueba también en C#. Los resultados no sólo son casi iguales en términos de velocidad, sino que además funcionan un orden de magnitud más rápido que en C++.
Resultados:
Suma: 894782460, Tiempo: 69 ms
Suma: 894782460, Tiempo: 56 ms
Y aquí hay un análogo en C++:
Suma: 894782460, Tiempo: 2947 ms.
Suma: 894782460, Tiempo: 684 ms
Lo pruebo en VS 2019,toda la optimización está habilitada .
Que se joda tal C++).
p.s. Los resultados en C# fluctúan significativamente de una prueba a otra, pero en promedio ambas variantes son iguales en velocidad.
¡Br-r-r-r, no puede ser! Sharp siempre gana a los profesionales puros por un factor de dos, pon el proyecto plz.
Niños pequeños :)
Han estirado el juguete a 10 páginas...
Aquí debemos entender las razones de la lentitud al principio. He investigado un poco y todo está en línea excepto la llamada
que se encuentra en libstdc++.
Así que parece que se ha dado cuenta de que asigna y borra memoria cada vez incluso en este caso:
Por cierto, puede que haya dado resultados erróneos la última vez. Lo más probable es que fuera en modo x86. Ahora estoy probando en modo x64 y los resultados por C++ son mucho mejores:
1) ~ 2000 mseg.
2) ~ 200 ms (es 3 veces más rápido).
Aunque también actualicé Studio a la última versión, debe haber influido también ya que incluso x86 es más rápido ahora que las pruebas anteriores.
Bueno, ahora C++ no está tan vergonzosamente por detrás de Sharp. Sólo por 3 veces aproximadamente )
Así que parece que se ha dado cuenta de que asigna y borra memoria cada vez incluso en este caso:
Por cierto, puede que haya dado resultados erróneos la última vez. Lo más probable es que fuera en modo x86. Ahora estoy probando en modo x64 y los resultados por C++ son mucho mejores:
1) ~ 2000 mseg.
2) ~ 200 ms (es 3 veces más rápido).
Aunque también actualicé Studio a la última versión, debe haber influido también ya que incluso x86 es más rápido ahora que las pruebas anteriores.
Bueno, ahora C++ no pierde tan vergonzosamente contra Sharp. Sólo por 3 veces aproximadamente )
Brrr-r-rr, ¡no puede ser! Sharp siempre ha sido el doble de bueno que clean pluses, pon el proyecto plz.
Mejor prueba los módulos plus, los resultados son más interesantes allí, aunque todavía pueden estar indocumentados.
Lo he buscado, resulta que ningún compilador de https://en.cppreference.com/w/cpp/compiler_support ha terminado los módulos, así que no hay nada que ver.