¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 11
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
Yurichik, me refería a que no hay que manipular el procesamiento de archivos, la compresión, etc. Trabajando puramente con SQL y la lógica del robot/indicador. Trabajé con muchas bases de datos, el único problema era hacer que MQL y SQL funcionaran juntos)). Creé una solución de buen aspecto sin arrays ni estructuras.
En general, prefiero no reinventar la rueda y resolver los problemas con los mejores medios.
Zhenya sí, te tengo ...
Eso es exactamente lo que prefiero
... especialmente si se dispone de una herramienta profesional... mejor que se integre bien...
¡Qué discusión! Gracias a todos por su participación.
Responderé a todos juntos, intentando no perder nada (ni a nadie).
1. Перейти на x64
Tardé en darme cuenta de que no había especificado la versión del terminal. Estoy trabajando con la 4, y no voy a migrar este EA a la 5 todavía. MT4, desafortunadamente, es de 32 bits solamente.
Laeliminación de la limitación de memoria de 4 GB en Windows 8 / 8.1 de 32 bits no ayudará, mi sistema es x64 como es.
2. Cortar en pedazos / leer en partes / cargar bloques pequeños
No funcionará para las condiciones de la tarea.
Intentaré dar más detalles a continuación, tal vez así se entienda mejor el problema.
3. Comprar más memoria / alquilar un servidor potente o en la nube / pasar todo a SSD
Por supuesto, pondré otros 16 GB de memoria en las ranuras disponibles, pero esa no es la solución.
Ese volumen no es el límite, y ampliar la capacidad sólo resolverá un caso especial del problema.
Creo que sólo se debería recurrir a esto cuando se tenga la certeza de que está 100% exprimido algorítmicamente.
4. Comprimir datos
Eso es lo que estoy haciendo ahora.
La caché de texto (que tiene 20 GB) se comprimió por un factor de 2, y probablemente se comprimirá algo más.
No resuelve el problema del tamaño de la memoria, pero se acerca a otras soluciones (disco RAM).
Yo también lo convertiré a binario, agilizará la lectura y reducirá el volumen.
No está clarocómo los asistentes dehttp://www.nanex.net/historical.htmlcomprimen los datos. Sus estructuras de datos son bastante redundantes.
5. Comprimir/codificar los datos y descomprimir/descomprimir el trozo deseado antes de utilizarlo
Se acepta como opción.
Pero algo me dice que también va a tardar mucho (aquí nos vamos a atascar con el procesador).
6. Transferir el cálculo a un programa externo(Matlab/R/etc).
No quiero, hay muchas razones.
A no ser que esté en un entorno bien integrado con la MT. Pero eso aún llevaría tiempo para aprender el software/entorno y/o pedir la solución a un desarrollador externo. Es incómodo y costoso en la fase de desarrollo (en la que me encuentro).
En fin, intentando quedarme en la caja de arena por ahora, con todos sus pros y contras.
No veo cómo esto puede ayudar.
Sigue teniendo que recuperar repetidamente los datos del archivo principal (releyéndolo constantemente).
8. Utilizar una base de datos
Una opción muy tentadora, dado:
Pero hay algunas desventajas:
- Entorno relativamente nuevo para mí (no he trabajado estrechamente, sólo consultas básicas);
- La complejidad de la instalación en una sola máquina cliente (versión autónoma);
- Probablemente algo más.
De todos modos, si otras opciones no funcionan, probablemente volveré a esta.9. Comprender y probar términos nuevos y oscuros
Esto es sólo una nota a mí mismo para el futuro y / o una solicitud de más información a los autores ;)
Se deja sin revelar: mapeo de archivos,soluciones basadas en hash, árboles B.
10. Mover el terminal con todas las cachés a un disco RAM virtual
Hasta ahora esta es la opción más prometedora (en términos de relación coste/beneficio).
Disco RAM de SoftPerfect instalado, voy a terminar la compresión de la caché, reescribir la calculadora a la lectura permanente de archivos y comprobar el rendimiento.
11. Haz bien la tarea =)
Muy buenos consejos, sobre todo teniendo en cuenta la escasez de información de entrada.
Como he prometido, intentaré dar más detalles.
Hay muchas secuencias de operaciones similares, cada secuencia está ordenada por tiempo.
Los tratos en las distintas secuencias son diferentes y se distribuyen de forma desigual en el tiempo (y de forma diferente en cada secuencia). El número de acuerdos es diferente. Pero todos ellos están en el intervalo de Fecha1 a Fecha2.
La tarea es pasar de D1 a D2 con un paso de M minutos (o mejor - exactamente por puntos de hacer intercambios de todas las secuencias), encontrar una secuencia que es mejor que otras por el criterio K (una tarea separada - no sólo para encontrar la mejor secuencia, pero para ordenar todo el conjunto por el criterio y la salida de los 10 primeros - pero es un opcional, no se requiere todavía).
El criterio K se calcula sobre la base de X operaciones anteriores de la secuencia correspondiente, y en los cálculos se utiliza casi toda la información sobre cada una de las X operaciones (el beneficio por sí solo, por ejemplo, no es suficiente).
El criterio (K), el número de operaciones (X) y otros parámetros que influyen en los resultados son modificados por un usuario. Es decir, no se pueden "escribir" en el algoritmo.
Algo así.
En idea, podemos reestructurar el archivo para que sea lineal para todos los oficios de todas las secuencias.
Pero, ¿cómo se puede hacer esto sin poner toda la información en la memoria? ¿Y cómo puedo volver a calcular el Criterio, si los tratos de una secuencia se van a "manchar" por todo el archivo?
Ahora, con suerte, la tarea está clara.
Una vez más, muchas gracias por vuestra participación, debates, preguntas, enlaces y respuestas concretas:
TheXpert,Urain,sergeev,elugovoy,anonymous,meat,ALXIMIKS,IvanIvanov,Integer,C-4,marketeer,barabashkakvn,Silent,GT788,papaklass,grizzly_v,artemiusgreat,YuraZ,Candid,Contender yservidor
Gracias.
¡Qué discusión! Gracias a todos por su participación.
....Una opción muy tentadora, teniendo en cuenta:
Pero hay algunas desventajas:
- Entorno relativamente nuevo para mí (no he trabajado estrechamente, sólo consultas básicas);
- La complejidad de la instalación en una sola máquina cliente (versión autónoma);
- Probablemente algo más.
En general, si otras opciones no funcionan, probablemente volveré a esta.Si vamos en la dirección de SQL
Puede ser un gran obstáculo en la curva de aprendizaje.
Si elige esta variante, es mejor construir toda la lógica de negocio con procedimientos almacenados
dejando al Asesor Experto sólo dos funciones - enviar una solicitud al servidor y obtener un resultado completamente terminado
todos los cálculos en el servidor
De hecho, en la red se pueden encontrar muchas descripciones de cómo poner SQL server
( ORACL, SYBASE + CENTOS por ejemplo ) ORACL, SYBASE, MS SQL+WINDOWS máquina independiente
La ORACL es un poco más difícil de aprender - menos expertos, menos literatura.
MS SQL - quizás la mayor cantidad de información y más literatura en la web.
no habrá dificultades - hay muchas descripciones en la web y más libros en la tienda.
MSSQL 2012 por sus parámetros está muy cerca de ORACL - ya en 2014.
SQL + LINUX se suele elegir para fines de producción y si no se sabe nada de LINUX es mejor usar WINDOWS.
komposter:
Hay muchas secuencias similares de tratos, cada secuencia está ordenada por tiempo.
Las transacciones en las distintas secuencias son diferentes, distribuidas de forma desigual en el tiempo (y de forma diferente en cada secuencia). El número de acuerdos es diferente. Pero todos ellos están en el intervalo de Fecha1 a Fecha2.
La tarea es pasar de D1 a D2 con un paso de M minutos (o mejor - exactamente por puntos de hacer intercambios de todas las secuencias), encontrar una secuencia que es mejor que otras por el criterio K (una tarea separada - no sólo para encontrar la mejor secuencia, pero para ordenar todo el conjunto por el criterio y la salida de los 10 primeros - pero es un opcional, no se requiere todavía).
El criterio K se calcula sobre la base de X operaciones anteriores de la secuencia correspondiente, y en los cálculos se utiliza casi toda la información sobre cada una de las X operaciones (el beneficio por sí solo, por ejemplo, no es suficiente).
El criterio (K), el número de operaciones (X) y otros parámetros que influyen en los resultados son modificados por un usuario. Es decir, no se pueden "escribir" en el algoritmo.
Algo así.
En idea, podemos reestructurar el archivo para que sea lineal para todos los oficios de todas las secuencias.
Pero, ¿cómo se puede hacer esto sin poner toda la información en la memoria? ¿Y cómo puedo volver a calcular el Criterio, si los tratos de una secuencia se van a "manchar" por todo el archivo?
Ahora, espero, la tarea está clara.
Tradicionalmente, por la mañana voy más despacio :).
¿Cabrá una secuencia en la memoria o ya hay un problema con ella?
Si es lo primero, ¿cuándo se producen las lecturas múltiples desde el disco, cuando el usuario cambia los criterios y los parámetros?
En caso afirmativo, ¿el cambio es por algún algoritmo o manualmente por algún motivo subjetivo?
Tradicionalmente, por la mañana voy más despacio :).
¿Cabrá una secuencia en la memoria o ya hay un problema con eso?
Si es lo primero, ¿cuándo se producen las lecturas múltiples desde el disco, cuando el usuario cambia los criterios y los parámetros?
En caso afirmativo, ¿el cambio es por algún algoritmo o manualmente por algún motivo subjetivo?
Un millón de secuencias.
Y luego en cada uno de ellos se encuentra un punto con la fecha correcta y se analiza el historial anterior.
Y se elige la mejor de las secuencias.
Y pasa al siguiente punto de la "historia".
Creo que si no se quiere molestar a los usuarios finales con la instalación de un SGBD, se pueden sintetizar varios (una docena) criterios K típicos (por ejemplo, llamarlos trading conservador, trading agresivo, etc.) y guardarlos realmente en el algoritmo, calcular una vez para todas las secuencias el cambio del indicador seleccionado en el tiempo y luego trabajar con vectores unidimensionales.
Digamos que sólo hay 2 criterios.
Pero hay varios parámetros que configuran el criterio, y cada uno puede tomar un valor diferente.
Incluso si tomamos de forma muy aproximada varios valores de cada parámetro, obtendremos no un vector unidimensional, sino un array de 3 o 4 dimensiones.
Entonces seguro que no hay suficiente memoria =)
Un millón de secuencias.
Y luego en cada uno de ellos se encuentra un punto con la fecha correcta y se analiza el historial anterior.
Y se elige la mejor de las secuencias.
Y pasa al siguiente punto de la "historia".
La secuencia completa se carga en la memoria. Entonces "encuentra el punto con la fecha deseada y analiza el historial anterior". El valor del criterio se compara con el mejor conseguido. Si es mejor, se recuerda el criterio y lo que hay que saber sobre la mejor secuencia. A continuación, se carga la siguiente secuencia en lugar de la procesada. Y así un millón de veces.
El archivo se lee secuencialmente y sólo una vez.
¿Qué ocurre?
La secuencia completa se carga en la memoria. A continuación, "encuentra el punto con la fecha correcta y analiza el historial anterior". El valor del criterio se compara con el mejor conseguido. Si es mejor, se recuerda el criterio y lo que hay que saber sobre la mejor secuencia. A continuación, se carga la siguiente secuencia en lugar de la procesada. Y así un millón de veces.
El archivo se lee secuencialmente y sólo una vez.
¿Qué pasa?
Así es.
Y entonces la "fecha correcta" se desplaza por el punto de cierre de la secuencia seleccionada y el algoritmo se repite.
Y así un millón de veces más =)
Es así.
Y entonces la "fecha correcta" se desplaza por el punto de cierre de la operación de la secuencia elegida y se repite el algoritmo.
Y así un millón de veces más =)
Pero las secuencias son independientes entre sí, ¿no? Entonces, ¿por qué no podemos hacer un ciclo de fechas en una secuencia cargada a la vez? Aquí, por cierto, sólo podría ser una oportunidad para ir a algún algoritmo de recurrencia eficiente, pero eso es la suerte. El tamaño de un millón sobre un millón se mantendrá, y el archivo se leerá una vez.
Por supuesto, un problema en el que el número de pasos sigue siendo el mismo en la siguiente iteración (es decir, el área de búsqueda no se reduce a medida que avanza el cálculo) no parece muy robusto. Pero esto es subjetivo, por supuesto.