Pregunta para los desarrolladores: uso de todos los núcleos de cálculo durante la optimización - 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
Este no es el enfoque correcto: en lugar de dar las tareas de una en una, hay que redistribuir la capacidad si se tienen recursos libres, es decir, cancelar las tareas ya repartidas y darlas a otros para que las ejecuten. Al mismo tiempo, es necesario analizar el rendimiento de cada agente para dar al núcleo el número correcto de nuevos trabajos.
esto es una tontería, lo siento
> Hay que cancelar los trabajos existentes y devolverlos al núcleo para que sean ejecutados por otros.
Creo que esto no es realista, y por qué, cuando es más fácil crear un lote de trabajos, dar un trabajo al primer hilo disponible, esperar hasta que se ejecute, dar el siguiente trabajo al primer hilo disponible (llamo la atención sobre la palabra hilo, no el núcleo del procesador, la restricción de los hilos debe ser eliminado - no es el derecho de los programadores, pero los derechos de los usuarios, recuerde que ahora los hilos de la red son sólo el núcleo real, no hilos, lo que reduce artificialmente el rendimiento a la mitad)
>es necesario analizar el rendimiento de cada agente para dar al núcleo el número necesario de nuevos trabajos para su ejecución.
y esto no es necesario en absoluto, porque los núcleos de un mismo procesador con el mismo rendimiento, dependiendo de las tareas, cuentan con diferente velocidad, no hay necesidad de contar algo cuando no se puede contar nada en absoluto
eso es una mierda, lo siento.
> cancelar las tareas ya emitidas y devolverlas a otros para que las ejecuten
Creo que esto no es realista, y para qué, es más fácil crear un lote de trabajos, dar un trabajo al primer hilo disponible, esperar a que se ejecute, dar el siguiente trabajo al primer hilo disponible (nótese la palabra hilo, no el núcleo del procesador, la restricción de los hilos debe ser eliminada - no es el derecho de los programadores, sino del usuario, recuerde que ahora los hilos de la red son sólo núcleos reales, no hilos, lo que baja artificialmente el rendimiento a la mitad)
>es necesario analizar el rendimiento de cada agente para dar al núcleo el número necesario de nuevos trabajos para su ejecución.
y no lo necesita porque los núcleos de un procesador con el mismo rendimiento dependiendo de las tareas cuentan con diferente velocidad, ¿por qué debería contar algo allí, cuando puede no contar nada?
Parece que tienes poca experiencia con el optimizador y no entiendes que la información sobre los pases completados llega tarde, que después de un trabajo el agente envía una trama, que puede ser muy pesada, todo esto provocará retrasos en la comunicación y ralentizará la optimización. Por lo tanto, las asignaciones deben ser emitidas en lotes y controlar su progreso, emitiendo nuevas asignaciones a aquellos agentes que están cerca de completar el trabajo.
Parece que tienes poca experiencia con el optimizador, y no entiendes que la información sobre los pases completados llega tarde, que una vez que un trabajo se completa un agente envía una trama, que puede ser muy pesada, todo lo cual causará retrasos en la comunicación y ralentizará la optimización. Por lo tanto, las tareas deben emitirse por lotes y controlar el progreso de las mismas, emitiendo nuevas tareas a aquellos agentes que estén cerca de completar el trabajo.
>Parece que tienes poca experiencia con el optimizador,
¿estás bromeando? 6 años ininterrumpidos
>La información sobre los pases completados llega tarde, que después de completar un trabajo un agente envía una trama, que puede ser muy pesada, todo esto llevará a retrasos en la comunicación y ralentizará la optimización. Por lo tanto, las asignaciones deben ser emitidas en lotes y controlar su progreso, emitiendo nuevas asignaciones a aquellos agentes que están cerca de completar el trabajo.
>esto provocará retrasos en la comunicación y ralentizará la optimización.
y no importa, las redes son rápidas ahora.
pero tener los núcleos parados mientras un pobre núcleo termina un montón de trabajos del montón ralentiza la optimización porque todo el resto (docenas de núcleos) se quedan parados y los núcleos tienen que seguir contando continuamente sin parar
parece que nunca has optimizado muchos parámetros ... y no argumenten que no tienen experiencia práctica
>Parece que tienes poca experiencia con el optimizador,
¿estás bromeando? 6 años ininterrumpidos
>La información sobre los pases completados llega tarde, que después de un trabajo el agente envía una trama que puede ser muy pesada, todo esto llevará a retrasos en la comunicación y ralentizará la optimización. Por lo tanto, las asignaciones deben ser emitidas en lotes y controlar su progreso, emitiendo nuevas asignaciones a aquellos agentes que están cerca de completar el trabajo.
>esto provocará retrasos en la comunicación y ralentizará la optimización.
y no importa, las redes son rápidas ahora.
pero tener los núcleos sentados en reposo mientras un pobre núcleo termina un montón de trabajos del montón ralentiza la optimización porque todo el resto (docenas de núcleos) permanecen en reposo y los núcleos necesitan seguir contando continuamente sin parar
parece que nunca has optimizado para un montón de parámetros ... y no argumente que no tiene experiencia práctica...
No se puede ser ególatra, las redes son rápidas, qué egocéntricas. Por el contrario, las redes no son rápidas cuando se trata de decenas y cientos de megabytes.
La optimización primitiva de los EA no es todo lo que parece: amplía tus horizontes y utiliza el cálculo matemático.
Sí, y ten en cuenta que se trata de un proyecto principalmente lucrativo, no para el disfrute de los usuarios, y como tal, el mecanismo debe tener en cuenta la distribución aleatoria de las tareas y la correcta contabilidad financiera de su realización...
No se puede ser ególatra, las redes son rápidas, qué egocéntricas. Por el contrario, las redes no son rápidas cuando se trata de decenas y cientos de megabytes.
La optimización primitiva de los EA no es todo lo que parece: amplía tus horizontes y utiliza el cálculo matemático.
Ah, y ten en cuenta que este es un proyecto principalmente con fines de lucro, no para complacer a los usuarios, y como tal el mecanismo debe dar cuenta de la distribución aleatoria de los puestos de trabajo y la correcta contabilidad financiera de su rendimiento...
decenas y cientos de megas no es nada, el tiempo empleado es mínimo y por cierto no tiene nada que ver con esto, deberías pensar antes de escribir que en un lote que uno por uno de todas formas este tráfico tendrá que pasar
> Laoptimizaciónprimitiva deEA no es lo único que se utiliza, amplía tus horizontes y utiliza los cálculos matemáticos.
Te deseo lo mismo sobre los horizontes
También sobre el egoísmo.
Estoy lejos de ser primitivo, y para qué sirve, así que ilumínanos a los ignorantes.
Su iniciativa me parece completamente absurda en cuanto a consumo de tiempo y velocidad de optimización.
Tú sólo estás mirando tu caso particular de optimización, mientras que Alexey está mirando el suyo (su EA tiene varios cientos de MB y tarda mucho en transferirse).
Y MQ mira el uso general del optimizador y lo ajusta a la mayoría, no a ti y a Alexey.
Las tareas se redistribuyen, al menos para mí, en los núcleos locales. Si en algún lugar no se redistribuyen, dame un ejemplo para reproducir, para que los desarrolladores puedan tenerlo en cuenta también.
Tú sólo estás mirando tu caso particular de optimización, mientras que Alexey está mirando el suyo (su EA tiene varios cientos de MB y tarda mucho en transferirse).
Y MQ mira el uso general del optimizador y lo ajusta a la mayoría, no a ti y a Alexey.
Las tareas se redistribuyen, al menos para mí, en los núcleos locales. Si en algún lugar no se redistribuyen, dame un ejemplo para reproducir, para que los desarrolladores puedan tenerlo en cuenta también.
Estoy de acuerdo en que mi caso es especial.
Hay un problema con la asignación de tareas si se conectan nuevos agentes remotos - esto ocurre cuando se liberan recursos de otras tareas.
Tú sólo estás mirando tu caso particular de optimización, mientras que Alexey está mirando el suyo (su EA tiene varios cientos de MB y tarda mucho en transferirse).
Y MQ mira el uso general del optimizador y lo ajusta a la mayoría, no a ti y a Alexey.
Las tareas se redistribuyen, al menos para mí, en los núcleos locales. Si en algún lugar no se redistribuyen, dame un ejemplo para reproducirlo, para que los desarrolladores también lo tengan en cuenta.
>quizás también tenga un privado, pero realmente "probablemente"
>Dar un ejemplo a reproducir para que los desarrolladores puedan tenerlo en cuenta también.
en realidad no... no puedo mostrar mi EA, no me interesan los estándar, puedo hacer capturas de pantalla para demostrar que no se redistribuyen
Si se redistribuyeran, sería una solución al problema
.... el tiempo de cálculo se ha triplicado ¿alguna vez conseguirán que el optimizador funcione correctamente???? un montón de núcleos libres están ociosos ...
el segundo día no cuenta nada, todos los núcleos son 12 locales y unos 30 de red están inactivos, no los toco a propósito... No sé en qué está pensando, probablemente en buscar el sentido de la vida o una cura para el coronovirus :-)
Creo que deberíamos abandonar el optimizador por su inoperancia y lentitud
y las recientes decisiones de MT de limitar sólo los núcleos físicos, distribuir persistente y estúpidamente un montón de trabajos a sólo ciertos núcleos en lugar de cada núcleo - un trabajo - demuestra una total falta de comprensión de los cálculos de alto rendimiento por parte de los desarrolladores