OpenCL: pruebas de implementación interna en MQL5 - página 4
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
Si he entendido bien, ¿1 GPU es un agente muy potente? ¿Se pueden desactivar los agentes de la CPU en ese caso (debido a su baja velocidad en relación con el vídeo)? Y de nuevo: ¿es posible tener dos ATI sin crossfire?
AMD desaconseja fuertemente el uso de Crossfire para OpenCL - ya que con Crossfire hay realmente dos GPUs pero el driver TIENE que dividir UN trabajo gráfico entre ellas. Por el contrario, en el caso de OpenCL 1.1, todavía no hay forma de que el propio controlador de la tarjeta de vídeo pueda dividir un mismo trabajo OpenCL entre las dos GPU (véase más arriba).
Lo mismo para nvidia SLI.
¿Cómo afectará la inclusión de OpenCL al coste del cálculo en la nube?
El coste de un agente con GPU será mayor que el de un agente sin GPU, ya que el tiempo estimado del primer agente será significativamente menor?
Dado que sólo un agente en la máquina local recibirá una GPU, resulta que el coste de diferentes agentes en la misma máquina local será diferente (y precalculado)...
¿Cómo afectará la inclusión de OpenCL al coste de la computación en la nube?
¿Será el coste de un agente con GPU mayor que el de un agente sin GPU porque el tiempo de cálculo del primero será significativamente menor?
Dado que sólo un agente en la máquina local recibirá la GPU, resulta que el coste de diferentes agentes en la misma máquina local será diferente (y precalculado)...
Por defecto, el terminal/agente elige el dispositivo de GPU más potente por su conjunto de características al iniciarse. Hasta ahora, no hay ninguna idea de seleccionar dispositivos de MQL5 - esto sólo complicará el código y conducirá a errores adicionales.
En su lugar, hay una idea más bonita en forma de asignación automática de cada GPU física a agentes separados, lo que permitirá utilizarlos a su máximo potencial.
Digamos que tenemos un EX5 (usando OpenCL) que optimiza 20 veces más rápido en agentes con GPU que sin GPU.
Ejecutamos la optimización en la nube. Es evidente que es más beneficioso (en términos de tiempo) ejecutar la optimización en primer lugar en aquellos agentes que tienen una GPU física. Dándoles la mayor parte de las opciones de enumeración. Equivale a que su PR es 20 veces mayor. PERO, sus relaciones públicas sin usar la GPU son las mismas. Es decir, hay que introducir un nuevo cálculo de PR, PR_gpu.
"Cuando se realiza una tarea, el trabajo realizado por el agente de pruebas se cuenta como el producto de su RP por el Tiempo empleado. "
De esta fórmula se deduce que si no hay PR_gpu, el coste de toda la optimización en la nube con GPU será más barato que sin ella.
Desgraciadamente, la introducción de un cálculo alternativo de PR - pase de prueba único del archivo EX5 optimizado contiene un gran número de escollos, debido a los cuales es imposible utilizarlo de forma universal.
De esta fórmula se deduce que si no hay PR_gpu, el coste de toda la optimización en la nube con GPU será más barato que sin ella.
Desgraciadamente, la introducción de un cálculo alternativo de PR -una sola pasada de prueba de un archivo EX5 optimizado- contiene un gran número de escollos que hacen imposible su uso universal.
sin entrar en detalles, que los desconozco, si no se revisa el PR real, no tiene sentido volcarse en la nube con la GPU
Además, si introduces un nuevo concepto, y te encanta) Por ejemplo, si está introduciendoun nuevo concepto, lo que le gusta hacer, entonces es mejor definirlo inmediatamente o adivinar que se trata del lado del usuario en este caso.
Actualmente PR = Const Koef / tiempo que se tarda en completar la tarea de referencia.
El coste de la optimización es igual al número de tareas de referencia que podrían calcularse en el tiempo que duró la optimización. Es decir, el coste del cálculo no depende de cómo la nube asigna las tareas entre los agentes. Pero la duración final de la optimización depende de la asignación adecuada, que es la métrica más importante.
Está claro que la nube asigna las tareas a los agentes en proporción al PR precalculado para reducir el tiempo de cálculo (pero no el coste - CONST).
Por supuesto, las tareas OpenCL se asignarán primero a los agentes con la GPU adecuada.
el coste del cálculo no depende de cómo la nube asigna las tareas entre los agentes.
Desgraciadamente, la introducción de un cálculo alternativo del RP -una sola prueba de un archivo EX5 optimizado- contiene un gran número de escollos que hacen imposible su uso universal.
Dado que el coste para el optimizador es siempre constante, pero su duración depende en gran medida de un adecuado (para la tarea dada) cálculo de PR, tal vez deberíamos introducir el optimizador para introducir su código EX5 PR_calculate en su conciencia. Donde el optimizador, basándose en las características de su algoritmo, establecerá el RP distributivo más adecuado para su tarea.
Por ejemplo, si la tarea es puramente computacional, el énfasis en PR_calculate estará en las matemáticas.
Si la tarea maneja grandes cantidades de datos, el énfasis se pondrá en la velocidad de manejo de la memoria.
Si la GPU se utiliza un poco - mostrarlo en su PR_calculate.
Si la GPU se utiliza en todas partes en EX5 - escriba un PR_calculate apropiado (con el uso apropiado de la GPU).
Con este sistema, los que alquilan la energía a la nube no pierden nada, y los que utilizan la energía de la nube tienen la oportunidad de acelerar sus cálculos de forma significativa.
Si no se especifica PR_calculate, se utiliza la tarea de referencia universal ya aceptada.
P.D. PR_calculate sólo se utiliza para asignar tareas en la nube. Para el cálculo de los costes, se sigue utilizando el mismo PR de siempre.
P.P.S. Hay, por supuesto, trampas - PR_calculate necesita ser ejecutado previamente en todos los agentes libres. PR_calculate puede escribirse por error - en bucle. Así que también hay que cobrar por el tiempo de PR_calculado según el esquema clásico de PR. Etc.
Dado que el coste para el optimizador es siempre constante, pero su duración depende fuertemente de un adecuado (para la tarea dada) cálculo de PR, tal vez vale la pena introducir a la conciencia del optimizador de entrada a su código EX5 PR_calculate. Donde el optimizador, basándose en las características de su algoritmo, establecerá el RP distributivo más adecuado para su tarea.