Aide sur la POO - page 7
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
Comparaison erronée, car elle ne tient pas compte du temps de retrait automatique des objets.
Modifié.
D'où viennent les 123 mégaoctets après V3, je ne sais pas.
Non, c'est correct. Et c'est une question de principe. La suppression automatique ne se fait pas dans le fil principal, où le coût en temps est extrêmement élevé. Vous pouvez commencer une nouvelle exécution sans attendre que le thread parallèle rende la mémoire utilisée. Oui, il sera également appelé et consommera des ressources CPU, mais il s'agira d'une opération secondaire exécutée en arrière-plan. Avec toute optimisation, même la plus agressive, une partie des ressources du CPU sera disponible pour d'autres threads, car c'est ainsi que fonctionnent tous les systèmes d'exploitation modernes aujourd'hui. Il est pratiquement impossible de charger à 100% le processeur des processeurs modernes.
--
Laissez-moi le dire autrement. Supposons qu'il y ait une tâche à exécuter en 5 unités de temps. Vous pouvez l'exécuter soit avec un seul thread en 5 unités, soit avec deux threads en 3 et 2 unités respectivement. Évidemment, le temps d'exécution total serait le même : 5 unités, mais le temps physique nécessaire dans le second cas serait inférieur de 2 unités puisque la tâche est concurrente dans le second cas et non dans le premier. Il existe un contre-argument selon lequel l'optimisation occupe tous les cœurs physiques disponibles du CPU. Mais ce n'est pas vrai. Toute optimisation permettra au mieux d'allouer un nombre de threads égal au nombre de cœurs du système d'exploitation. Cependant, en plus de ces tâches, des centaines d'autres tâches seront exécutées dans le système d'exploitation, et les huit cœurs du processeur (s'il y en a huit) seront répartis entre des centaines de threads du système, au lieu des huit threads alloués par l'optimiseur. Ainsi, allouer un thread supplémentaire en mode 8+1 ou 8+8 est toujours plus judicieux que de penser naïvement qu'une fois qu'une application a alloué 8 threads, elle utilisera toutes les ressources du CPU à 100%.
--
En général, il est amusant d'entendre des arguments tels que :"Nous ne comptons pas ce temps parce que le temps total de l'ensemble du système l'inclut."Ou l'argument selon lequel"les méthodes des objets créés par new sont appelées plus lentement" - Si c'est le cas, nous devrions probablement écarter le benchmark à ce moment-là, parce que c'est injuste quand les méthodes sont appelées plus lentement dans un sens et plus rapidement dans l'autre)))))). Dans ce cas, pourquoi prétendre qu'on se noie dans la performance ? Regardons les choses en face, nous venons des années 90 et n'admettons rien d'autre que les faux slogans "l'assembleur est de toute façon plus rapide !" ou "quand je travaille avec des pointeurs, je contrôle tout".
--
Deuxième point. Faites attention à la V2. Il n'y a pas de suppression d'objet et une fuite de mémoire directe est délibérément commise. Malgré cela, l'allocation des objets prend 1,4 seconde contre 1,2 seconde dans V1, bien qu'aucun temps ne soit consacré à la suppression.
Je ne sais pas d'où viennent les 123 Moctets après la V3.
C'est difficile à dire. Vous devez connaître les spécifications de la machine virtuelle mql. Mais personne ne le sait, sauf les développeurs. À en juger par l'analyse de ProcessHacker, il semble que les objets sélectionnés par * new soient alloués individuellement à un endroit d'une manière délicate, puis déplacés vers une autre zone de mémoire sous forme de grands tableaux. Il peut s'agir d'objets temporaires ou d'autres choses.
Non, c'est exact. Et c'est une question de principe. La suppression automatique ne se produit pas dans le thread principal, où le coût en temps est extrêmement élevé. Vous pouvez commencer une nouvelle exécution sans attendre que le thread parallèle rende la mémoire utilisée. Oui, il sera également appelé et consommera des ressources CPU, mais il s'agira d'une opération secondaire exécutée en arrière-plan. Avec toute optimisation, même la plus agressive, une partie des ressources du CPU sera disponible pour d'autres threads, car c'est ainsi que fonctionnent tous les systèmes d'exploitation modernes aujourd'hui. Il est pratiquement impossible de charger à 100% le processeur des processeurs modernes.
--
Laissez-moi le dire autrement. Supposons qu'il y ait une tâche à exécuter en 5 unités de temps. Vous pouvez l'exécuter soit avec un seul thread en 5 unités, soit avec deux threads en 3 et 2 unités respectivement. Évidemment, le temps d'exécution total serait le même : 5 unités, mais le temps physique nécessaire dans le second cas serait inférieur de 2 unités puisque la tâche est concurrente dans le second cas et non dans le premier. Il existe un contre-argument selon lequel l'optimisation occupe tous les cœurs physiques disponibles du CPU. Mais ce n'est pas vrai. Toute optimisation permettra au mieux d'allouer un nombre de threads égal au nombre de cœurs du système d'exploitation. Cependant, en plus de ces tâches, des centaines d'autres tâches seront exécutées dans le système d'exploitation, et les 8 cœurs du processeur (s'il y en a huit) seront répartis entre des centaines de threads du système, au lieu des 8 threads alloués par l'optimiseur. Ainsi, allouer un thread supplémentaire en mode 8+1 ou 8+8 est toujours plus judicieux que de penser naïvement qu'une fois qu'une application a alloué 8 threads, elle utilisera toutes les ressources du CPU à 100%.
--
En général, il est amusant d'entendre des arguments tels que :"Nous ne comptons pas ce temps parce que le temps total de l'ensemble du système l'inclut."Ou l'argument selon lequel"les méthodes des objets créés par new sont appelées plus lentement" - Si c'est le cas, nous devrions probablement écarter le benchmark à ce moment-là, parce que c'est injuste lorsque les méthodes sont appelées plus lentement dans un sens et plus rapidement dans l'autre)))))). Dans ce cas, pourquoi prétendre qu'on se noie dans la performance ? Regardons les choses en face, nous venons des années 90 et n'admettons rien d'autre que les faux slogans "l'assembleur est de toute façon plus rapide !" ou "quand je travaille avec des pointeurs, je contrôle tout".
--
Deuxième point. Faites attention à la V2. Il n'y a pas de suppression d'objet et une fuite de mémoire directe est délibérément commise. Même dans ce cas, l'allocation des objets prend 1,4 seconde contre 1,2 seconde dans V1, bien qu'aucun temps ne soit consacré à la suppression.
C'est difficile à dire. Vous devez connaître les spécifications de la machine virtuelle mql. Et personne ne le sait, sauf les développeurs. À en juger par l'analyse de ProcessHacker, il semble que les objets sélectionnés par * new soient alloués individuellement à un endroit d'une manière délicate, puis déplacés vers une autre zone de mémoire sous forme de grands tableaux. Il peut s'agir d'objets temporaires ou d'autres choses.
Donc, si la suppression n'est pas dans le fil principal, quelle différence cela fait-il qu'elle soit incluse dans la mesure ou non ? Ce n'est pas comme si cela allait affecter)))). Alors pourquoi ne pas l'inclure pour voir la vérité ?
Et d'ailleurs Vasily, il y a une question qui t'attend là (dernière ligne).
... Ou l'argument selon lequel"les méthodes des objets créés avec new sont appelées plus lentement"...
Vous n'avez pas le courage de le mesurer ? Tu es une coquille vide, Vassia, espèce de serpent à sonnette.
Vous n'avez pas le courage de mesurer ?
Tu vas juste dormir !
Il suffit de dormir !
Rêve... et taper du pied...
Donc, si la suppression n'est pas dans le fil principal, quelle différence cela fait-il qu'elle soit incluse dans la mesure ou non ? Ce n'est pas comme si cela allait affecter)))). Alors pourquoi ne pas l'inclure pour voir la vérité ?
Il faut ensuite inclure dans le benchmark le temps total passé par Explorer, telegram, Chrome pendant l'optimisation. Même si vous les tuez tous, et que vous ne laissez que MT, il y aura une centaine d'autres fils système qui gaspilleront du temps CPU, y compris eux.
Il faut ensuite inclure dans le benchmark le temps total passé par Explorer, telegram, Chrome pendant l'optimisation. Même si vous supprimez tout cela, et ne laissez que MT, il y aura une centaine d'autres fils système qui gaspilleront du temps CPU, incluez-les.
C'est dans des fils parallèles)))) (© Vasya)
Vassia, tu es vraiment stupide !
Mais continuez, continuez à persister.
Et d'ailleurs, Vasily, il y a une question qui t'attend là (dernière ligne).
Vous pouvez prouver que vous êtes un idiot et un codeur nul en un rien de temps. Mais qui et pourquoi en aurait besoin alors que vous le prouvez année après année, en salissant littéralement chaque fil de discussion sur ce forum. J'ai passé deux ans sans rien poster ici, je n'ai regardé qu'occasionnellement - et à chaque fois, dans chaque fil de discussion, c'était toi, avec ton "avis autorisé" dans le style "vous êtes tous des crétins, vous ne comprenez rien, et comment faire - je ne dirai pas. Tu es un homme pourri, Dima.
Vous pouvez prouver que vous êtes un idiot et un codeur nul en un rien de temps. Mais qui en a besoin quand tu le prouves année après année, en chiant littéralement sur chaque fil de discussion de ce forum. J'ai passé deux ans sans rien poster ici, je n'ai regardé qu'occasionnellement - et à chaque fois, dans chaque fil de discussion, c'était toi, avec ton "avis autorisé" dans le style "vous êtes tous des crétins, vous ne comprenez rien, et comment faire - je ne dirai pas. Tu es un homme pourri, Dima.
Quoi ? Le problème, c'est que je ne te dis pas comment le faire, n'est-ce pas ?
Oui, et vous avez déjà prouvé quelque chose de très bien ici ;))
Et c'est moi qui suis pourri ? C'est toi qui as à la fois la diarrhée et la scrofule quand j'écris du code.