La toile est cool ! - page 16

Nouveau commentaire
 

Au niveau actuel des processeurs, vous pouvez oublier les freins de la double mathématique. Il n'y a pas de décalage.

Et les méthodes d'optimisation par conversion en nombre entier sont déjà vraiment dépassées. Vous perdrez beaucoup plus sur la conversion que vous ne gagnerez sur les mathématiques.


En tenant compte du code 64 bits et de notre compilateur, vous devriez oublier les entiers dans la classe des tâches basées sur les calculs doubles.

Voici un échantillon précédent des tentatives d'optimisation de Nikolaï : https://www.mql5.com/ru/forum/1111/page2164#comment_6796332.

Le compilateur a réussi à combiner les calculs de deux racines doubles de 64 bits provenant d'expressions différentes en une seule commande assembleur de 128 bits. Lorsque vous travaillez avec des mathématiques doubles, il est fortement déconseillé de sauter/convertir vers des types entiers. Il y a des surcharges sauvages de CPU sur la conversion (pas la nôtre).

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2018.03.11
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
Nikolai Semko:

Vous n'avez pas à arrondir quoi que ce soit.

Voici un script à titre d'exemple.

Exécutez-le d'abord avec les paramètres par défaut (avec des cercles anticrénelés et des coordonnées et dimensions de type double)

et ensuite l'exécuter avec le paramètre typ = not_smoothed_circles (avec des cercles non lissés et des coordonnées et tailles de type int - de la classe CCanvas).

Ça a bien marché.

J'ai obtenu 347 fps sans antialiasing et 97 avec antialiasing sur une toile de 2100x550 pixels.

Pour information, nous avons un limiteur de taux de mise à jour de la fenêtre de 500fps. Cela montre combien de performances peuvent être atteintes dans les graphiques.

 
Renat Fatkhullin:

Au niveau actuel des processeurs, vous pouvez oublier le freinage des doubles maths. Il n'y a pas de freins.

Et les méthodes d'optimisation par conversion en nombre entier sont déjà vraiment dépassées. Vous perdrez beaucoup plus sur la conversion que vous ne gagnerez sur les mathématiques.


En tenant compte du code 64 bits et de notre compilateur, vous devriez oublier les entiers dans la classe des tâches basées sur les calculs doubles.

Voici un échantillon précédent des tentatives d'optimisation de Nikolaï : https://www.mql5.com/ru/forum/1111/page2164#comment_6796332.

Le compilateur a réussi à combiner les calculs de deux racines doubles de 64 bits provenant d'expressions différentes en une seule commande assembleur de 128 bits. Lorsque vous travaillez avec des mathématiques doubles, il est fortement déconseillé de sauter/convertir vers des types entiers. Il y a des surcharges sauvages de CPU sur la conversion (pas la nôtre).

Je suis presque sûr que si nous faisons en sorte que les ticks soient basés sur des nombres entiers, le testeur commencera à travailler beaucoup plus rapidement.

 
Artyom Trishkin:

Non, ce n'est pas un morphing. C'est un peu exagéré d'appeler ça un morphing :


En fait, j'étais trop paresseux pour en faire un vrai moi-même - je l'ai trouvé dans les dossiers d'exemples.

Morphing, littéralement - mortification.

 
fxsaber:

Il est presque certain que si vous rendez les ticks entiers, le Testeur commencera à travailler beaucoup plus rapidement.

C'est clair pour le cheval, comme l'a dit Elena Yurievna.

 
Nikolai Semko:

Basé sur Doom et sur les conseils de @fxsaber.

J'ai utilisé l'algorithme dece site avec quelques légères modifications.

Vraiment cool !

Qu'est-ce que tu utilises pour faire des photos, Nikolaï ?

 
fxsaber:

Il est presque certain que si vous rendez les ticks entiers, le Testeur commencera à travailler beaucoup plus rapidement.

Non.

Pour commencer, sachez que :

  1. tout devra être converti en ints.
  2. obtenir beaucoup de décalages lors de la conversion des données
  3. obtenir la consommation de mémoire sauvage
  4. obtenir une chance de 100% de débordements dans chaque opération et la mort complète du système
  5. obtenir un mépris des développeurs à qui l'on propose de lire leurs indicateurs et de travailler en ints plutôt qu'en 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.
Je n'ai pas cité les preuves ci-dessus pour rien. Là, Nikolaï a essayé d'appliquer la méthode d'optimisation par le biais de tables de racines précalculées et a perdu face au calcul en temps réel des racines sur le processus.
 
Алексей Тарабанов:

Morphing, littéralement - la mort.

Cela ne vaut pas la peine d'en discuter ici, mais le morphing ( morphing) Où voyez-vous des personnes mortes, dégrisez...

 
Artyom Trishkin:

Cela ne vaut pas la peine d'être discuté ici, mais le Morphing ( morphing- transformation) Où vous voyez des personnes mortes - dégrisez...

L'analyse morphométrique est l'analyse des cellules mortes. D'abord on les tue, puis on les met sous le microscope.

 
Renat Fatkhullin:

Non.

#define  BENCH(A)                                                              \
{                                                                             \
  const ulong StartTime = GetMicrosecondCount();                              \
  A;                                                                          \
  Print("Time[" + #A + "] = " + (string)(GetMicrosecondCount() - StartTime)); \
}  

template <typename T>
T Tester( const int Amount = 1 e7 )
{
  T Sum = 1;
  T Price = 1;
  
  for (int i = 0; i < Amount; i++)
  {
    Price = 1 - Price;
    
    Sum += (Sum > Price) ? 1 : 0;
  }
  
  Print(Sum);
  
  return(Sum);
}

void OnStart()
{
  BENCH(Tester<int>());
  BENCH(Tester<double>());
}


Double int est deux fois plus rapide que double

10000001
Time[Tester<int>()] = 25523
10000001.0
Time[Tester<double>()] = 51253
1...91011121314151617181920212223...93
Nouveau commentaire