La toile est cool ! - page 17

 
Алексей Тарабанов:

Analyse morphométrique - analyse des cellules tuées. D'abord on les tue, puis on les met sous le microscope.

Morphométrie (grec : forme morphe + ...métrie)

C'est tout. Assez de cet encombrement du sujet.

 
fxsaber:


Double int est deux fois plus rapide que double

Vous ne vous rendez pas compte de l'échelle et vous ne faites pas les tests correctement en microsynthétique, sans tenir compte des conséquences de l'exécution non pas de 30 fonctions d'assemblage mais d'un tableau de 50k-100k instructions.

Réfutez chaque point que j'ai soulevé ci-dessus dans ma réponse originale.

 
Renat Fatkhullin:

Vous ne vous rendez pas compte de l'échelle et vous effectuez à tort des tests en microsynthétique, sans tenir compte des conséquences de l'exécution non pas de 30 fonctions d'assemblage, mais d'un tableau de 50k-100k instructions.

Réfutez chacun de mes points ci-dessus dans votre réponse originale.

J'ai réfuté ce point (bien qu'avec des actions primitives à chaque tic).

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading

La toile est géniale !

Renat Fatkhullin, 2019.01.15 22:37

En tenant compte du code 64 bits et de notre compilateur, nous devons oublier les entiers dans la classe de tâche basée sur les calculs doubles...

Le testeur est basé sur un double calcul. Et il y en a tellement à chaque tic que même une course à vide se déroule à 7 millions de tics par seconde.


Vous pouvez écrire un simulateur avec des actions plus compliquées sur chaque tick. Mais la base du Testeur est la comparaison du prix du tick actuel avec le prix de l'ordre, ce qui rend les codes plus élevés. Cette affirmation n'est pas faite dans le vide. J'ai publié des mesures reproductibles et des alternatives de calcul dans le domaine public.

 
fxsaber:

Démontrer ce point (bien que par des actions primitives sur chaque tick)

Le testeur est basé sur un double calcul. Et ils sont si nombreux à chaque tic que même une course à vide se déroule à un rythme de 7 millions de tics par seconde.


Il est possible d'écrire un simulateur avec des actions plus compliquées à chaque tick. Mais la base du Testeur est de comparer le prix actuel du tick avec le prix de l'ordre, ce qui rend les codes plus élevés.

Réfutez cela :

  1. tout devra être converti en ints
  2. obtenir beaucoup de décalages lors de la conversion des données
  3. obtenir une consommation de mémoire sauvage
  4. obtenir 100% de chances de débordements dans chaque opération et la mort totale du système
  5. obtenir un mépris des développeurs qui vous proposent de lire leurs indicateurs et de travailler en ints au lieu de dubs
  6. Et ta da, il n'y a plus de différence entre les dubs et les ints en termes de vitesse. Difficile à croire, mais oui.

Chaque point, s'il vous plaît.

Gardez à l'esprit que même un seul point 4 ou 5 suffit à faire fusionner l'idée de l'accélération des nombres entiers.

Je ne parle pas du fait que le testeur n'est pas for(i=0;i<limit;i++ ) { }

Mais je peux aussi souligner que l'on ne peut pas espérer préserver les résultats de l'optimisation locale du microcode dans les opérations sur les entiers. Il suffit parfois d'ajouter une chaîne inoffensive dans une boucle pour perdre des dizaines de pourcents de vitesse. Et si l'on se tourne vers les tâches réelles, lorsque le code est gonflé de travail réel, toutes les comparaisons y passent.

 
Renat Fatkhullin:

Réfutez cela :

  1. tout devra être converti en ints
  2. obtenir beaucoup de décalages lors de la conversion des données
  3. obtenir une consommation de mémoire folle
  4. obtenir une chance de 100% de débordements dans chaque opération et la mort totale du système
  5. obtenir un mépris des développeurs qui vous proposent de lire leurs indicateurs et de travailler en ints au lieu de dubs
  6. Et ta da, il n'y a plus de différence entre les dubs et les ints en termes de vitesse. Difficile à croire, mais oui.

Chaque point, s'il vous plaît.

Gardez à l'esprit que même un seul point 4 ou 5 suffit à faire fusionner l'idée de l'accélération des nombres entiers.

Le but était de montrer qu'il existe des problèmes qui peuvent encore être résolus en nombres entiers afin d'accélérer. Un testeur comme celui-ci n'est pas universel, car il ne correspond pas au moins au point 5.


Quant aux quatre premiers points, les problèmes sont tirés par les cheveux. Parce que la vitesse du testeur n'est nécessaire que pendant l'optimisation. Il ne convertit les tics qu'une fois pour l'ensemble des passes.

 
fxsaber:

L'objectif était de montrer qu'il existe des problèmes qui peuvent encore être résolus en nombres entiers afin de gagner en rapidité. Un testeur comme celui-ci n'est pas universel, car il ne correspond pas au moins au point 5.


Quant aux quatre premiers points, les problèmes sont tirés par les cheveux. Parce que la vitesse du testeur n'est nécessaire que pendant l'optimisation. Il convertit les tics une seule fois pour l'ensemble des passes.

C'est-à-dire que ni les points 4 et 5 ne sont réfutés.

Et même la conversion que vous voulez sauver, ce qui augmente immédiatement le coût du temps de plusieurs fois. Oui, parfois, y compris la mémoire pour la conversion. Je pensais que vous suggériez que toute la plate-forme soit convertie en prix int64 pour se débarrasser des conversions.

Même théoriquement, il n'y a pas de bénéfice à tirer de la migration vers l'int depuis 10 ans déjà.
 
Renat Fatkhullin:

Je ne parle pas de la façon dont un testeur n'est pas for(i=0;i<limit;i++ ) { }

S'il s'agit d'un testeur sans minuterie, il est prouvé qu'un testeur est pour par des tics.

 
fxsaber:

S'il s'agit d'un testeur sans minuterie, il est prouvé qu'un testeur est fait pour les tics.

Ce n'est pas un testeur, mais un faux. Sans indicateurs, sans bénéfices ou quoi que ce soit d'autre. Mais avec un risque constant de dépassement d'entier.

Il n'y a aucun sens à en discuter.

Et encore :

Mais je peux également souligner que vous ne pouvez pas espérer sauvegarder les résultats de l'optimisation locale du microcode dans les opérations sur les entiers.

Il suffit parfois d'ajouter une chaîne inoffensive dans une boucle pour perdre des dizaines de pour cent de vitesse. Et si vous vous tournez vers les tâches réelles, lorsque le code se gonfle de travail réel, toutes les comparaisons s'envolent là.

Comprenez-vous que l'optimisation de 20 commandes assembleur et d'un bloc réel pour plusieurs centaines ou milliers de commandes va tuer votre exemple ?
 
Renat Fatkhullin:

Ainsi, ni le point 4 ni le point 5 ne sont réfutés.

Et vous voulez même enregistrer la conversion, ce qui multiplie immédiatement le temps passé. Oui, plusieurs fois, y compris la mémoire de conversion. Je pensais que vous suggériez de passer toute la plateforme aux prix int64 pour se débarrasser des conversions.

Il semble qu'il s'agisse d'une mauvaise compréhension de ce dont je parlais. Je parlais d'un exemple de problème de testeur privé, où les prix entiers peuvent donner un gain dans certaines situations. Le cas universel n'était pas en tête. C'est pourquoi mon Testeur, dont j'ai donné un lien ci-dessus, est implémenté sur les dubs, puisqu'il est universel.

Même théoriquement, il n'y a aucun gain à aller à l'int depuis 10 ans maintenant.

Je ne peux pas être d'accord à 100%.

 
Renat Fatkhullin:

Ce n'est pas un testeur, c'est un raté. Sans indicateurs, sans bénéfices, et sans rien du tout. Mais avec un risque constant de dépassement d'entier.

Il s'agit d'un add-on pour votre testeur, qui effectue un passage complet avec toutes les transactions et les bénéfices, sans aucune modification du code de tout conseiller expert (avec tous les indicateurs). Mais il le fait plus rapidement que le Testeur normal. Toutes les preuves reproductibles ont été données. Des personnes de la ressource ont vérifié ces affirmations.