Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 19
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Il vous faudrait donc passer par plusieurs millions de transactions d'autres séquences ! C'est exactement ce que je veux dire.
Je parle de vérifier un seul numéro (numéro de séquence), un million n'est pas beaucoup pour une opération aussi élémentaire. Si nous comptons le critère de manière récursive, cela ne représente qu'un seul passage du fichier, et nous devrons le faire de toute façon. Une autre chose à considérer est que la carte de données de la récursion contiendra les mêmes plusieurs millions d'éléments (multipliés par le nombre de paramètres pour une séquence).
Une autre solution consiste à recalculer entièrement les critères et à les stocker avant le tri. Là encore, la possibilité d'utiliser la récursion est essentielle.
Il est clair qu'il y aura beaucoup d'opérations, mais y en a-t-il moins dans la version originale ?
En C++, vous pouvez le faire sans analyseur si :
en poussant l'idée 10 fois - commencez un autre fichier avec les valeurs des positions de départ des séquences dans un autre fichier, alors vous n'avez même pas besoin de stocker le nombre de transactions dans la structure de la séquence.
Vous obtiendrez un index ordinaire, qui a déjà été mentionné auparavant.
J'ai implémenté l'algorithme que j'ai décrit ci-dessus.
Le traitement de mes données avec X = 20 (calcul de critère sur 20 affaires) a pris environ112 minutes (je n'ai pas saisi exactement), la part du lion a été mangée par le décalage de tableau (40% selon le profiler).
Après des boucles de tableaux et quelques autres optimisations, le traitement est devenu plus rapide :
La mémoire n'était suffisante que pour 65 transactions (multipliées par un million de séquences). Bien sûr, cela ne suffit pas - je comptais sur au moins 100.
L'étape suivante consistait à éliminer toutes les informations inutiles sur les métiers. En ne laissant que les temps d'ouverture et de fermeture, et le profit en pips, on a réussi à décoller avec X = 185.
Ensuite - il suffit d'accélérer le travail avec le fichier, FileReadXXX prend maintenant 30% du temps (et le répartiteur dit qu'il n'y a pas de travail avec le disque, mais le CPU est chargé).
FileRead est exactement le premier après FileSeek, c'est-à-dire que la lecture séquentielle fonctionne rapidement.
Je vous tiendrai au courant des nouveaux résultats.
En C++, c'est fait par fread dans un tampon de 64K-128K, en l'analysant de préférence par votre propre analyseur, car les sscanf-es sont très lents.
Je vais essayer de travailler avec les fichiers via WinAPI, c'est ce que m'a conseillé le service d'assistance :
Je pousse l'idée 10 fois - de commencer un autre fichier avec les valeurs des positions de début des séquences dans un autre fichier, alors dans la structure de la séquence il ne sera même pas nécessaire de stocker le nombre de donnes.
Je ne comprends pas ce que fera l'indice.
Le fait d'écrire le nombre de métiers ne fait pas de différence, la lecture séquentielle fonctionne rapidement, le problème est de lire exactement le bloc après s'être déplacé dans le fichier.
Veuillez rédiger une proposition d'algorithme.
Le problème n'est pas trivial, mais il n'y a pas encore une seule ligne de code. Andrey, beaucoup de gens ici sont intéressés - formulez le problème et proposez des données de test. Organisons une programmation sportive.
Nous avons besoin de données de test + pseudocode, avec des principes généraux de travail avec les données.
La tâche est formulée du début à la fin.
Et les données de test peuvent être générées avec un script légèrement modifié, que j'ai posté plus tôt.
Je le ferai un peu plus tard.
pourquoi passer par les options de la base ? serait-il préférable de générer des trades sur l'historique selon les critères ? non ? ne serait-ce pas la même chose que ce qui est demandé ?
Si c'est pour des tests, bien sûr, oui, mais si c'est pour résoudre le problème, bien sûr, non ;)
Candidat:
Nous parlons de la vérification d'un seul numéro (numéro de séquence), un million n'est pas beaucoup pour une opération aussi élémentaire. Si on considère le critère de manière récursive, c'est juste un passage de fichier, on devra le faire de toute façon. Une autre chose à considérer est que la carte de données de la récursion contiendra les mêmes plusieurs millions d'éléments (multipliés par le nombre de paramètres pour une séquence).
Une autre solution consiste à recalculer entièrement les critères et à les stockeravant le tri. Là encore, la possibilité d'utiliser la récursion est essentielle.
Il est clair qu'il y aura beaucoup d'opérations dans tous les cas, mais est-ce moins dans la version originale ?
Dans la variante initiale, vous pouvez calculer le critère une fois lors de la recherche de la dernière transaction dans l'historique passé.
Et vous devez lire un fragment du fichier tel qu'il contienne un nombre X de donnes de toutes les séquences. Il sera bien plus grand que X *nombre de séquences, car il y a différentes quantités de transactions et elles peuvent ne pas être distribuées de manière égale.
2 tous :
En tout cas, merci pour le soutien.
Si cela ne vous dérange pas, veuillez exécuter le script de test et partager les résultats.
Et les données de test peuvent être générées avec le script légèrement modifié que j'ai posté plus tôt.
Je joins le script mis à jour, maintenant il ne se contente pas d'enregistrer des transactions identiques, mais génère des séquences aléatoires avec des paramètres spécifiés(durée de vie - de et à, profit - de et à).
Pour obtenir un fichier comparable au mien, exécutez le script avec les paramètres par défaut :
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15 : 140,000 secuences amorties en 57.1 sec
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15 : 6632 Mo chargés en 44.0 sec(150.7 Mo/sec)
Après cela, vous pouvez élaborer l'algorithme sur celui-ci.
Pour les plus paresseux, archivez le fichier sur google drive.
komposter:
1. Dans la variante originale, vous pouvez calculer le critère une fois lors de la recherche de la dernière donne dans l'historique des passes.
Dans votre variante, vous devez lire un morceau de fichier tel qu'il contiendrait X offres de toutes les séquences. Il sera beaucoup plus grand que X *nombre de séquences, car le nombre de transactions est différent et elles peuvent ne pas être réparties de manière égale.
1 Ce n'est pas très clair, si nous recherchons le critère maximum (minimum), nous devons toujours calculer le critère pour tous les candidats à la fin. Il n'est même pas important de savoir si l'on recherche un extrémum local ou global.
2. Il est clair que la question de la taille acceptable ou non en termes de mémoire requise se pose davantage. De plus, une taille de bloc plus importante en termes de vitesse de lecture du disque est encore meilleure. Ce n'est certainement pas encore un problème pour la RAM. Il est fondamental que la lecture se fasse de manière séquentielle et une seule fois.
La variante consistant à calculer les critères avant de trier nécessite toutefois une double lecture. Mais elle a ses propres avantages, surtout si l'on considère la possibilité de diviser les données en plusieurs fichiers plus petits et leur traitement conjoint ultérieur.
Sans mise en œuvre, cependant, tous les arguments resteraient abstraits. Donc, à ce stade de la discussion, je vais devoir prendre congé :)
Comment faire l'assemblage de fichiers avec l'indexation de quel bit est le début et la fin de quel fichier.
Par exemple, faire 1000 métafichiers à partir de 1000 fichiers, et si les critères sont connus, faire un classement statistique pour faire rentrer les fichiers similaires dans un seul métafichier.
Une meilleure expérience avec FileOpen, comment il fonctionne plus rapidement pour ouvrir un grand fichier ou un petit, dans le sens d'ouvrir 1000 fois un grand fichier de taille égale à 1000 petits ou 1000000 fois pour ouvrir un petit ?
Il peut s'avérer que les fichiers ne doivent pas être fusionnés, mais divisés.
Comment faire l'assemblage de fichiers avec l'indexation de quel bit est le début et la fin de quel fichier.
Par exemple, faire 1000 métafichiers à partir de 1000 fichiers, et si les critères sont connus, faire un classement statistique pour faire rentrer les fichiers similaires dans un seul métafichier.
Une meilleure expérience avec FileOpen, comment il fonctionne plus rapidement pour ouvrir un grand fichier ou un petit, dans le sens d'ouvrir 1000 fois un grand fichier de taille égale à 1000 petits ou 1000000 fois pour ouvrir un petit ?
Il peut s'avérer que les fichiers ne doivent pas être fusionnés, mais divisés.
Je travaille actuellement avec un gros fichier, mais je voulais passer à un million de petits fichiers.
D'une part, ils peuvent être ajoutés, et d'autre part, on peut y accéder par leur nom (pas besoin de stocker "début de chaque séquence").
J'ai posé une question au service d'assistance à propos d'un million d'ouvertures de différents fichiers (j'ai mis en place un cache de cette manière). La réponse est claire et nette.
Je testerai les fonctions d'api à la fois pour un gros fichier et pour des millions de petits fichiers, je publierai les résultats.
Cependant, sans implémentation, tous les arguments resteront abstraits. Donc, à ce stade de la discussion, il serait approprié pour moi de me retirer :)
J'aurais dû commencer avec elle ;)
Mais en tout cas, merci pour votre participation, les idées sans code sont précieuses aussi.
Avec un million de fichiers, vous ruinerez le ntfs de telle manière que vous pleurerez cette idée folle de microsoft, qui a enfermé tout le monde dans son implémentation follement retardée du système de fichiers pour toujours.
Tout ce que ms a fait dans leurs systèmes de fichiers est un poids monstrueux, un retard et une stupidité. Ces idiots n'ont fait aucun effort pour optimiser et accélérer le processus, et l'API est tout simplement primitive. En 2014, on peut l'affirmer sans équivoque. Eh bien et pleure.
Quiconque veut améliorer l'efficacité de la manipulation d'un tas de fichiers dans Windows, la première chose qu'il fait est d'aller dans les chunks - regroupement et leur propre structure de données dans un seul fichier.
Dès que vous commencez à stocker plus d'un millier (et encore moins des dizaines ou des centaines de milliers) de fichiers disparates dans Windows, vous êtes foutu.
Les opérations sur les fichiers dans MQL4/5 passent par nos mécanismes de mise en cache très efficaces, qui nous permettent d'atteindre des vitesses de lecture et d'écriture très efficaces et élevées.
Vous pouvez transmettre des données en continu, octet par octet. Toutes les données seront rapidement collectées dans le tampon interne et écrites sur le disque uniquement par gros morceaux. Le nombre d'appels WinAPI est minimal, ce qui permet un fonctionnement très rapide. La lecture est similaire - elle fonctionne de manière proactive, en lisant par gros morceaux, en faisant très rarement appel à l'interface WinAPI et en restituant très rapidement les données de son cache avec une surcharge minimale.
En gros, par rapport à la version 509, nous avons augmenté la vitesse des opérations sur les fichiers dans MQL4/5 d'un ordre de grandeur (si l'on parle d'opérations régulières basées sur des morceaux, plutôt que d'écrire par blocs de mégaoctets pour maximiser les mesures de vitesse).