La splendeur et la pauvreté de l'OLP - page 6
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 a montré que l'appel direct ou l'appel virtuel n'ont aucun effet dans les projets réels.
La grande majorité des coûts sont engendrés par les appels aux fonctions du système, où les programmes MQL passent presque tout leur temps. Les coûts d'organisation des appels sont négligeables par rapport à la charge utile.
Où a-t-il montré ? Un tableau avec des noms de fonctions et des mesures est-il un argument ? Nous ne sommes pas des experts en télépathie ici. Vous devez voir le code des fonctions, et ensuite vous pourrez dire quelque chose.
Où l'a-t-il montré ? Un tableau avec quelques noms de fonctions et des mesures - est-ce un argument ? Nous ne sommes pas des experts en télépathie ici. Vous devez voir le code des fonctions, ensuite nous pourrons parler d'autre chose.
Il a montré que dans les projets réels, l'appel direct ou l'appel virtuel n'ont aucun impact.
La grande majorité des coûts sont engendrés par les appels de fonctions système, où les programmes MQL passent la plupart de leur temps. Le coût de l'organisation des appels est négligeable par rapport à la charge utile.
+100 Oui, c'est vrai !
De plus, j'ai remarqué que lorsque j'ai dû réécrire les classes tentaculaires pour que certaines de leurs fonctions soient exécutées par d'autres classes (inclusion/décomposition), les performances globales ont augmenté et le contrôle sur le code s'est accru. En d'autres termes, dans la pratique, nous constatons le contraire de ce qu'Integer et les fans du C de la vieille école tentent de nous prouver : le nombre de classes augmente, le nombre de méthodes augmente, et les performances, au contraire, augmentent.
Où l'a-t-il montré ? Un tableau avec quelques noms de fonctions et des mesures - est-ce un argument ? Nous ne sommes pas des experts en télépathie ici. Vous devez voir le code des fonctions, ensuite nous pourrons parler d'autre chose.
+100 Oui, c'est ça !
De plus, j'ai remarqué que lorsque je devais réécrire des classes tentaculaires afin que certaines de leurs fonctions soient exécutées par d'autres classes (inclusion/décomposition), les performances globales augmentaient, et le contrôle sur le code s'accroissait. En d'autres termes, dans la pratique, nous constatons le contraire de ce qu'Integer et les fans du C de la vieille école tentent de nous prouver : le nombre de classes augmente, le nombre de méthodes augmente, et les performances, au contraire, augmentent.
Une nouvelle façon de se faire plaisir ? Allez, allez.
Vasily, vous auriez dû lire ce que j'essayais de prouver ici, cependant (et quoi que vous en pensiez, je l'ai prouvé).
Notez toutefois qu'avoir le code source ne vous apprendra rien. La complexité cumulée n'est pas la même. Même après avoir analysé les sources, vous diriez : "Eh bien, quelque chose est appelé, quelque chose est compté, quelque chose est pris de quelque part, mais ce qui est exactement n'est pas clair, donc encore une fois rien n'est prouvé.
En général, oui, vous avez probablement raison, les fonctions individuelles ne vous diront probablement pas grand-chose. À quoi bon parler de votre logiciel si c'est un cochon dans un piquet pour tout le monde.
En fait, la principale chose qui nous intéresse est le nombre total de passages par des méthodes virtuelles, et le temps total passé dessus. Ici, dans votre tableau, il y a une certaine fonction ombrée exécutée 5 millions de fois. Je ne sais pas ce que c'est, peut-être que c'est juste une méthode virtuelle avec l'action la plus simple. Cependant, 5 millions, c'est une bagatelle. Je suppose que vous n'avez pas de calculs lourds dans votre programme, il n'y a donc pas grand-chose à discuter. Si vous deviez calculer un système d'équations linéaires 30000x300000 et accéder aux éléments de la matrice par des méthodes virtuelles, il y aurait de quoi discuter.
Une nouvelle façon de s'influencer soi-même ? Allez, allez.
Vasily, vous auriez dû lire ce que j'essayais de prouver ici, après tout (et quoi que vous en pensiez, je l'ai prouvé).
Dmitry, je ne suis ni pour ni contre vous. Pour le comprendre, il faut connaître les rouages du compilateur en ligne, mais ouvrir ces informations pour MQ revient à aider à l'écriture d'un décompilateur.
De tous ceux qui discutent ici, seul Renat possède cette information, nous devons donc nous fier à sa parole. Je ne vois pas d'autre moyen.
S'il dit que vous ne réglez pas le test correctement, c'est probablement le cas.
La question est différente, seul MQ peut définir le test correctement dans un tel cas, c'est ce qu'il faut faire.
Comme on dit, test pour test, ma parole contre la vôtre. Et vous essayez de prouver l'indéfendable. Il est impossible de prouver ou de réfuter vos affirmations sans avoir quelque chose à quoi les comparer.
Le décompilateur est hors de question ici.
Il suffit de comprendre et de connaître les techniques des compilateurs d'optimisation pour éviter de tester des cas dégénérés simplifiés, qui sont optimisés brutalement et dégénèrent en code linéaire. Nous avons publié la quatrième génération de compilateurs pour une raison précise.
C'est exactement ce dont nous parlons.
Par exemple, si nous calculons un système d'équations linéaires 30000x300000 et que l'accès aux éléments de la matrice se fait par des méthodes virtuelles, il y a déjà matière à discussion.
Dans ce cas, le premier remaniement vous permettra de gagner cent fois plus de vitesse. Et l'appel virtuel se classerait au dixième rang en termes de coûts.
C'est-à-dire que l'exemple n'est pas réaliste.
Écrivons tout en langage assembleur alors. Ce serait plus rapide de toute façon.
Je ne comprends pas le problème. Je n'ai jamais vu un conseiller expert ou un indicateur avec 1 MB de code.
L'appel d'une fonction prend également un certain temps. Renonçons aussi aux fonctions !
Le contrôle des grands projets est beaucoup plus aisé avec la POO.
En outre, la vitesse d'exécution du code n'est souvent pas aussi importante que le temps de transmission au courtier et la réponse de ce dernier à un ordre.
Jetez un coup d'œil aux algorithmes HFT. Ils exigent une vitesse maximale, mais vous n'y trouverez pas de calculs complexes.
PS. En général, on n'a pas besoin d'une supercar ou d'une motoneige pour se rendre d'un point A à un point B. Un cyclomoteur suffit ! Un cyclomoteur suffit !