Implémentations alternatives de fonctions/approches standard - page 11

Nouveau commentaire
 
Nikolai Semko:
Pouvez-vous m'envoyer le lien ?

Je ne l'ai pas gardé. Mentionné sur le forum ici. J'ai cherché dans les moteurs de recherche moi-même.

Вопрос к сообществу программистов по поводу авторства
Вопрос к сообществу программистов по поводу авторства
  • 2017.11.24
  • www.mql5.com
Общее обсуждение: Вопрос к сообществу программистов по поводу авторства
 
fxsaber:

Je ne l'ai pas gardé. Mentionné sur le forum ici. J'ai cherché moi-même dans les moteurs de recherche.

Je l'ai vu. Tout cela est très primitif sans le mélange des couleurs des pixels.
C'est juste que tout ce que j'ai trouvé sur les forums était du niveau de la maternelle. Et je suis déjà en 5ème année.
 
Nikolai Semko:
C'est juste que tout ce que j'ai rencontré sur les forums était du niveau de la maternelle. Et je suis déjà en 5ème année.

Il est évident que toutes ces motos ont été reconstruites plusieurs fois. Des livres ont même été publiés, jusqu'aux implémentations asm.

Aujourd'hui, les bases sont difficiles à trouver, car presque tout le monde utilise des API pertinentes pour toutes les occasions.

Il suffit donc de s'inscrire sur les forums et de se renseigner.

 
fxsaber:

Il est évident que toutes ces motos ont été reconstruites plusieurs fois. Des livres ont même été publiés, jusqu'à et y compris des implémentations asm.

Aujourd'hui, les bases sont difficiles à trouver, car presque tout le monde utilise des API pertinentes pour toutes les occasions.

Il suffit donc de s'inscrire sur les forums et de demander.

C'est ça le problème : c'est difficile. Quoi qu'il en soit, je n'ai pas pu le trouver. Peut-être que je ne cherchais pas assez. Sur les forums, tout le monde vous enverra vers les bibliothèques standard fermées et se demandera pourquoi vous en avez besoin, alors que tout est disponible. Bien sûr, je ne me ferais pas de souci si j'écrivais en Java, JavaScript et autres. ou si le marché n'était pas nécessaire.
Ok, je suis déjà habitué à être fièrement seul dans cette affaire pour le moment. Je vais continuer, d'ailleurs, je n'ai pratiquement aucun blanc dans la compréhension de presque toute mise en œuvre dans ce sens. Et en même temps, j'ai acquis des compétences uniques.
 
pavlick_:

Pourquoi n'utilisez-vous pas LONG_MAX/MIN? Ce serait plus joli d'une certaine façon. C'est joli, je trouve. J'ai fait vos tests avec gcc (avec des modifications minimes, bien sûr, le compilateur est très ancien 5.4.0, ce que j'avais sous la main) :


Eh bien, oui, ce n'est pas gentil. MaisLONG_MAX= 9223372036854775807 est supérieur à 9007199254740992. Et la forme hexadécimale de ce nombre - 0x20000000000000 est rejetée car elle ne doit être utilisée que pour le type ulong. Je ne sais même pas comment le rendre plus clair. Je ne peux pas écrire (ulong)(1<<53) car c'est une opération qui prend du temps.

Le type double commence à contenir des entiers sans parties fractionnaires non pas à partir de la valeurLONG_MAX mais à partir de la mantisse maximale possible. Mais 53 bits sont autorisés pour la mantisse, c'est-à-dire 2^53=9007199254740992.

pavlick_:

Votre code de synchronisation échoue - la sortie est en milisecondes (pas en nano), et je ne comprends toujours pas pourquoi nous avons besoin de moins t0.

t0 est le temps d'un cycle complet de 1000000 passages de la somme d'un double premier

tandis que t est le temps du même cycle de la somme des mêmes valeurs doubles, mais passé par les fonctions ceil, ceil, round etc.

Je suis parti de la logique que la différence (t-t0) est le temps net passé sur ces fonctions.

Bien entendu, une plus grande objectivité ne peut être obtenue qu'en effectuant plusieurs mesures.

- En nano, je calcule sur la base du temps nécessaire pour réaliser une fonction sur 1 000 000. Exactement en nano est correct.

pavlick_:

J'ai exécuté vos tests sur gcc (avec des modifications mineures, bien sûr, le compilateur est très vieux 5.4.0, ce qui était à portée de main) :

1. Compilation avec -O3.

2. Compilation avec -Ofast

Il s'avère donc que. Que le code MQL5 compilé s'exécute plus rapidement que même Ofast ? C'est difficile à croire. Vous deviez avoir un compilateur 32 bits.
 
Nikolai Semko:

Ne pas écrire (ulong)(1<<53), car c'est déjà une opération qui prend du temps.

Cette opération ne prend pas de temps, comme toutes les opérations avec des constantes, y compris les chaînes de caractères.

input long l = (ulong)1 << 53;
input string s = (string)__DATETIME__ + __FILE__;
 
fxsaber:

Cette opération est intemporelle comme toutes les constantes, y compris les chaînes de caractères.

Wow - cool ! Merci. Et je pensais que ça comptait à chaque fois. Oui, eh bien, c'est logique, on peut déjà le calculer au moment de la compilation.
Eh bien, c'est tout alors :

double Ceil (double x) { return double((x>(long)1 << 53 || x<-(long)1 << 53 )?x:(x-(long)x>0)?(long)x+1:(long)x);}
double Round(double x) { return double((x>(long)1 << 53 || x<-(long)1 << 53 )?x:(x>0)?(long)(x+0.5):(long)(x-0.5));}
double Floor(double x) { return double((x>(long)1 << 53 || x<-(long)1 << 53 )?x:(x>0)?(long)x:((long)x-x>0)?(long)x-1:(long)x);}
2018.08.26 18:04:07.638 TestRound (EURUSD,M1)   Время цикла без округления = 1.302 наносекунд, сумма = 115583114403605978808320.00000000
2018.08.26 18:04:07.642 TestRound (EURUSD,M1)   Время выполнения функции ceil =  2.389 наносекунд, Контрольная сумма = 1.15583114403606 e+23
2018.08.26 18:04:07.644 TestRound (EURUSD,M1)   Время выполнения функции Ceil =  0.223 наносекунд, Контрольная сумма = 1.15583114403606 e+23
2018.08.26 18:04:07.648 TestRound (EURUSD,M1)   Время выполнения функции floor = 2.884 наносекунд, Контрольная сумма = 1.15583114403606 e+23
2018.08.26 18:04:07.649 TestRound (EURUSD,M1)   Время выполнения функции Floor = 0.122 наносекунд, Контрольная сумма = 1.15583114403606 e+23
2018.08.26 18:04:07.654 TestRound (EURUSD,M1)   Время выполнения функции round = 3.413 наносекунд, Контрольная сумма = 1.15583114403606 e+23
2018.08.26 18:04:07.656 TestRound (EURUSD,M1)   Время выполнения функции Round = 0.222 наносекунд, Контрольная сумма = 1.15583114403606 e+23
2018.08.26 18:04:07.656 TestRound (EURUSD,M1)   Идет бесконечный поиск расхождения по случайным числам double ... Прервите скрипт, когда надоест ждать

Cependant, il serait plus correct d'écrireDBL_MANT_DIG au lieu de 53

double Ceil (double x) { return double((x>(long)1 << DBL_MANT_DIG || x<-(long)1 << DBL_MANT_DIG )?x:(x-(long)x>0)?(long)x+1:(long)x);}
double Round(double x) { return double((x>(long)1 << DBL_MANT_DIG || x<-(long)1 << DBL_MANT_DIG )?x:(x>0)?(long)(x+0.5):(long)(x-0.5));}
double Floor(double x) { return double((x>(long)1 << DBL_MANT_DIG || x<-(long)1 << DBL_MANT_DIG )?x:(x>0)?(long)x:((long)x-x>0)?(long)x-1:(long)x);}

Cas de gain minimal si toutes les valeurs du double sont fractionnaires.

2018.08.26 18:20:35.408 TestRound (EURUSD,M1)   Время выполнения функции sqrt = 1.083 наносекунд, сумма = 81969849.90928555
2018.08.26 18:20:35.413 TestRound (EURUSD,M1)   Время выполнения функции ceil =  3.579 наносекунд, Контрольная сумма = 5250492895.0
2018.08.26 18:20:35.416 TestRound (EURUSD,M1)   Время выполнения функции Ceil =  1.249 наносекунд, Контрольная сумма = 5250492895.0
2018.08.26 18:20:35.422 TestRound (EURUSD,M1)   Время выполнения функции floor = 3.931 наносекунд, Контрольная сумма = 5249492896.0
2018.08.26 18:20:35.424 TestRound (EURUSD,M1)   Время выполнения функции Floor = 0.513 наносекунд, Контрольная сумма = 5249492896.0
2018.08.26 18:20:35.427 TestRound (EURUSD,M1)   Время выполнения функции round = 1.519 наносекунд, Контрольная сумма = 5249992896.0
2018.08.26 18:20:35.429 TestRound (EURUSD,M1)   Время выполнения функции Round = 0.571 наносекунд, Контрольная сумма = 5249992896.0
Dossiers :
TestRound.mq5  11 kb
 
Nikolai Semko:
Il s'avère donc que. Que le code MQL5 compilé fonctionne plus rapidement que même Ofast ? Je trouve difficile de croire que vous deviez avoir un compilateur 32 bits.

J'ai enlevé le moins t0 de tout (je pensais que c'était une sorte d'erreur) et ma sortie a la boucle entière mesurée, pas un seul passage. Si nous convertissons à votre forme de sortie en nanosecondes par itération (dans la première ligne "Cycle time without rounding" - nous avons la même façon de compter), nous obtenons :

-O3
Время цикла без округления = 1.099 наносекунд, сумма = 1.15583114 e+23
-Ofast
Время цикла без округления = 0.552 наносекунд, сумма = 1.15583114 e+23

Il n'y a pas beaucoup d'accélération sur gcc (et encore moins sur -Ofast). Sur mcc il y a une accélération significative à en juger par votre test, mais.. :

vous avez 985'651 sur 1'000'000 c'est-à-dire que presque toutes les itérations satisfont la condition x < MIN || x > MAX.


-Ofast désactive toutes les vérifications inf/nan, le paramètre errno, c'est-à-dire que l'arrondi nu sur le fpu est laissé. Et cet arrondi nu ne peut être mis en échec par une simple comparaison de x < MIN || x > MAX.

 
pavlick_:

Il n'y a pas beaucoup d'accélération sur gcc (et encore moins sur -Ofast). Sur µl, c'est significatif.

Cependant, c'est difficile à dire. Nous avons jeté t0 pour de beaux chiffres et obtenu 20 fois la différence. Même un code supplémentaire minime sous la forme d'une boucle (+t0) fait passer un beau résultat en plusieurs dizaines de fois à un résultat moins attrayant en environ deux fois. Et que dire si ce n'est pas une simple boucle mais un véritable algorithme qui fait quelque chose d'utile ? La différence ne sera pas du tout visible, elle errera quelque part loin après la virgule et ne deviendra guère un goulot d'étranglement. Dans une application réelle, la récupération des mutex, les barrières du processeur, l'allocation de mémoire sont beaucoup plus coûteuses que l'arrondi. En somme, le jeu n'en vaut pas la chandelle, à mon avis.

 
pavlick_:

Oui, la différence ne sera pas du tout visible, elle se situera quelque part bien après la virgule et il est peu probable qu'elle constitue un goulot d'étranglement. Dans une application réelle, l'utilisation de mutex, de barrières de cpu, l'allocation de mémoire sont beaucoup plus coûteux que l'arrondi. En somme, le jeu n'en vaut pas la chandelle, à mon avis.

C'est vrai 99% du temps, oui.

Avant d'optimiser, vous devez vous assurer que vous avez quelque chose à optimiser.

Dans ma pratique, je ne me souviens que d'un seul cas où ma propre mise en œuvre d'atof m'a vraiment aidé. Bien qu'il me semblait que c'était le cas.

Et vous devez garder à l'esprit que toute optimisation (sauf ***) n'est pas gratuite.

1...45678910111213
Nouveau commentaire