Ayuda con la POO - página 7
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
Comparación incorrecta, ya que no tiene en cuenta el tiempo de eliminación automática de los objetos.
Modificado.
De dónde salen los 123 megabytes después de la V3, no lo sé.
No, es correcto. Y esto es una cuestión de principios. El borrado automático no se produce en el hilo principal, donde el coste de tiempo es extremadamente caro. Se puede iniciar una nueva ejecución sin esperar a que el hilo paralelo devuelva la memoria utilizada. Sí, también se llamará y consumirá recursos de la CPU, pero será una operación lateral ejecutada en segundo plano. Con cualquier optimización, incluso la más agresiva, una parte de los recursos de la CPU estará disponible para otros hilos, porque así es como funcionan todos los sistemas operativos modernos hoy en día. Poner una carga del 100% en la CPU en los procesadores modernos es casi imposible.
--
Lo diré de otra manera. Supongamos que hay una tarea que debe ejecutarse en 5 unidades de tiempo. Se puede ejecutar con un hilo en 5 unidades, o con dos hilos en 3 y 2 unidades respectivamente. Obviamente, el tiempo total de ejecución sería el mismo: 5 unidades, pero el tiempo físico necesario en el segundo caso sería 2 unidades menos ya que la tarea es concurrente en el segundo caso y no en el primero. Existe el contraargumento de que la optimización ocupa todos los núcleos físicos disponibles de la CPU. Pero esto no es cierto. Cualquier optimización asignará, en el mejor de los casos, un número de hilos igual al número de núcleos del sistema operativo. Sin embargo, además de estas tareas, se ejecutarán cientos de otras tareas en el sistema operativo, y los 8 núcleos del procesador (si hay ocho) se dividirán entre cientos de hilos del sistema, en lugar de los 8 hilos asignados por el optimizador. Así, asignar un hilo más en modo 8+1 u 8+8, es siempre más sensato que pensar ingenuamente que una vez que una aplicación ha asignado 8 hilos, utilizará todos los recursos de la CPU con el 100%.
--
En general, es divertido escuchar argumentos como"no contamos este tiempo, porque el tiempo total de todo el sistema lo incluye"."O el argumento de que"los métodos de los objetos creados a través de new se llaman más lentamente" - Si es así, probablemente deberíamos descartar el punto de referencia para este momento, porque es injusto cuando los métodos se llaman más lentamente en un sentido y más rápido en el otro )))))) En ese caso, ¿por qué fingir que nos ahogamos en el rendimiento? Pero reconozcámoslo, somos de los 90 y no admitimos más que los falsos eslóganes "¡el ensamblador es más rápido de todos modos!" o "cuando trabajo con punteros, lo controlo todo".
--
Segundo punto. Presta atención a la V2. No hay borrado de objetos y hay una fuga de memoria directa deliberada. Aun así, la asignación de objetos tarda 1,4 segundos frente a los 1,2 segundos de la V1, aunque no se invierte nada de tiempo en el borrado.
No sé de dónde salen los 123 Mbytes después de la V3.
Es difícil de decir. Es necesario conocer la especificación de la máquina virtual mql. Pero nadie lo sabe, excepto los desarrolladores. A juzgar por el análisis en ProcessHacker, parece que los objetos seleccionados a través de * new se asignan individualmente en un lugar de alguna manera difícil y luego se mueven a otra zona de memoria como grandes matrices. Es decir, podría ser algún objeto temporal o algo más.
No, correcto. Y esto es una cuestión de principios. El borrado automático no se produce en el hilo principal, donde el coste de tiempo es extremadamente caro. Puede iniciar una nueva ejecución sin esperar a que el hilo paralelo devuelva la memoria utilizada. Sí, también se llamará y consumirá recursos de la CPU, pero será una operación lateral ejecutada en segundo plano. Con cualquier optimización, incluso la más agresiva, una parte de los recursos de la CPU estará disponible para otros hilos, porque así es como funcionan todos los sistemas operativos modernos hoy en día. Poner una carga del 100% en la CPU en los procesadores modernos es casi imposible.
--
Lo diré de otra manera. Supongamos que hay una tarea que debe ejecutarse en 5 unidades de tiempo. Se puede ejecutar con un hilo en 5 unidades, o con dos hilos en 3 y 2 unidades respectivamente. Obviamente, el tiempo total de ejecución sería el mismo: 5 unidades, pero el tiempo físico necesario en el segundo caso sería 2 unidades menos ya que la tarea es concurrente en el segundo caso y no en el primero. Existe el contraargumento de que la optimización ocupa todos los núcleos físicos disponibles de la CPU. Pero esto no es cierto. Cualquier optimización asignará, en el mejor de los casos, un número de hilos igual al número de núcleos del sistema operativo. Sin embargo, además de estas tareas, se ejecutarán cientos de otras tareas en el sistema operativo, y los 8 núcleos del procesador (si hay ocho) se dividirán entre cientos de hilos del sistema, en lugar de los 8 hilos asignados por el optimizador. Así, asignar un hilo más en modo 8+1 u 8+8, es siempre más sensato que pensar ingenuamente que una vez que una aplicación ha asignado 8 hilos, utilizará todos los recursos de la CPU con el 100%.
--
En general, es divertido escuchar argumentos como:"Bueno, no contamos este tiempo porque el tiempo total de todo el sistema lo incluye"."O el argumento de que"los métodos de los objetos creados a través de new se llaman más lentamente" - Si es así, probablemente deberíamos descartar el punto de referencia para este momento, porque es injusto cuando los métodos se llaman más lentamente en un sentido y más rápido en el otro )))))) En ese caso, ¿por qué fingir que nos ahogamos en el rendimiento? Pero reconozcámoslo, somos de los 90 y no admitimos más que los falsos eslóganes "¡el ensamblador es más rápido de todos modos!" o "cuando trabajo con punteros, lo controlo todo".
--
Segundo punto. Presta atención a la V2. No hay borrado de objetos y hay una fuga de memoria directa deliberada. Incluso entonces, la asignación de objetos tarda 1,4 segundos frente a los 1,2 segundos de la V1, aunque no se invierte nada de tiempo en el borrado.
Es difícil de decir. Es necesario conocer la especificación de la máquina virtual mql. Y esto no lo sabe nadie más que los desarrolladores. A juzgar por el análisis en ProcessHacker, parece que los objetos seleccionados a través de * new se asignan individualmente en un lugar de alguna manera difícil y luego se mueven a otra zona de memoria como grandes matrices. Es decir, podrían ser algunos objetos temporales u otra cosa.
Entonces, si el borrado no está en el hilo principal, ¿qué diferencia hay en que se incluya o no en la medición? No es que vaya a afectar a )))) Entonces, ¿por qué no incluirlo para ver la verdad?
Y, por cierto, Vasily, ahí te espera una pregunta (última línea).
... O el argumento de que"los métodos de los objetos creados con new se llaman más lentamente"...
¿No tienes el valor de medirlo? Eres una cáscara vacía, Vasya, serpiente de cascabel.
¿No tienes las agallas para medir?
¿Quieres dormir la mona?
¡Sólo duerme la mona!
Soñar... y pisar fuerte...
Entonces, si el borrado no se produce en el hilo principal, ¿qué diferencia hay en que se incluya o no en la medición? No es que vaya a afectar a )))) Entonces, ¿por qué no incluirlo para ver la verdad?
Pues bien, incluye en el benchmark el tiempo total que pasan Explorer, telegram, Chrome funcionando durante la optimización. Incluso si matas todo eso, y dejas sólo MT, habrá un centenar de otros hilos del sistema que desperdiciarán el tiempo de la CPU, inclúyelos.
Pues bien, incluye en el benchmark el tiempo total que pasan Explorer, telegram, Chrome funcionando durante la optimización. Incluso si matas todo eso, y dejas sólo MT, habrá un centenar de otros hilos del sistema que desperdiciarán el tiempo de la CPU, inclúyelos.
Está en hilos paralelos))) (© Vasya)
¡Vasya, eres realmente estúpido!
Pero sigue adelante, sigue persistiendo.
Y por cierto, Vasily, hay una pregunta esperándote ahí (última línea).
Puedes demostrar que eres un idiota y un nulo codificador en poco tiempo. Pero quién y por qué lo necesitaría cuando lo está demostrando año tras año, ensuciando literalmente todos los hilos de este foro. He pasado dos años sin publicar nada aquí, sólo de vez en cuando miró - y cada vez, en cada hilo era usted, con su "opinión autorizada" en el estilo de "todos ustedes son idiotas, no entienden nada, y cómo hacer - no voy a decir. Eres un hombre podrido, Dima.
Puedes demostrar que eres un idiota y un nulo codificador en poco tiempo. Pero quién lo necesita cuando lo demuestran año tras año, cagándose literalmente en cada hilo de este foro. He pasado dos años sin publicar nada aquí, sólo de vez en cuando miró - y cada vez, en cada hilo era usted, con su "opinión autorizada" en el estilo de "todos ustedes son idiotas, no entienden nada, y cómo hacer - no voy a decir. Eres un hombre podrido, Dima.
¿Qué? El problema es que no te digo cómo hacerlo bien?
Sí, y ya has demostrado algo muy bien aquí))
¿Y soy yo el que está podrido? Tú eres el que tiene tanto diarrea como escrófula cuando escribo código.