La splendeur et la pauvreté de l'OLP - page 2
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
Pourquoi devrais-je comprendre les mécanismes de compilation ? Juste pour croire qu'un mauvais résultat est meilleur qu'un bon ?
Écrire les tests correctement et ne pas induire les gens en erreur.
Vous ne comprenez même pas ce que vous avez écrit dans vos tests et ce que vous testez réellement.
C'est la conséquence de la formation de masse à dotnet et aux langages similaires. Les programmeurs n'ont absolument aucune envie de comprendre ce qui fonctionne réellement et comment cela fonctionne.
Écrire les tests correctement et ne pas induire les gens en erreur.
Vous ne comprenez même pas ce que vous avez écrit dans votre test et ce que vous testez réellement.
Telles sont les conséquences de la formation de masse à dotnet et aux langages similaires. Les programmeurs n'ont absolument aucune envie de comprendre ce que et comment les choses fonctionnent dans la réalité.
Chacun a ses propres œillères sur les yeux, comme les chevaux (pour ne pas trop voir).
L'un voit les siens, l'autre les siens. Mais cela ne signifie pas que les deux ont raison ou tort.
La vérité est quelque part proche.
Le promoteur voulait une chose et en a obtenu une autre. Cela ne signifie pas que la tâche est accomplie. Mais ça marche. Peut-être pas de la manière attendue ou souhaitée.
L'utilisateur effectue son test (qui est assez prévisible). Cela ne signifie pas que le test satisfera toutes les parties.
La vérité est là.
La vitesse des opérations est trop importante. Ce n'est pas mon caprice, c'est la vie.
Et vous devez le prouver par des tests, pas par des mots.
La vitesse d'exécution a trop d'importance. Ce n'est pas mon caprice, c'est la vie.
Et vous devez le prouver par des tests, pas par des mots.
J'ai immédiatement signalé les erreurs dans les tests proposés. Puis j'ai expliqué le point plusieurs fois.
Les méthodes virtuelles seront toujours plus coûteuses que les méthodes normales, mais les tests d'optimisation des compilateurs doivent être effectués correctement en comprenant ce qui est minimisé et optimisé et comment.
Dans ce cas, nous n'avons pas encore mis en œuvre une méthode d'optimisation permettant de convertir automatiquement une fonction virtuelle en fonction régulière (d'autres compilateurs le font lorsque cela est possible), ce qui modifierait immédiatement les résultats de ce test et induirait à nouveau en erreur (un appel de méthode virtuelle pourrait soudainement être plus rapide qu'un appel de méthode régulière).
Les méthodes virtuelles seront toujours plus coûteuses que les méthodes normales, mais les tests d'optimisation des compilateurs doivent être effectués correctement en comprenant ce qui est réduit et optimisé et comment.
Dans ce cas, nous n'avons pas encore mis en œuvre une méthode d'optimisation permettant de convertir automatiquement une fonction virtuelle en fonction régulière (d'autres compilateurs le font lorsque cela est possible), ce qui modifierait immédiatement les résultats de ce test et induirait à nouveau en erreur (un appel de méthode virtuelle pourrait soudainement être plus rapide qu'un appel de méthode régulière).
C'est-à-dire qu'à ce stade, Integer a raison. Tu ne pouvais pas juste admettre et expliquer tout de suite. Ou bien il y a quelque chose dans le chemin ?
Les méthodes virtuelles seront toujours plus coûteuses que les méthodes conventionnelles, mais les tests d'optimisation des compilateurs doivent être effectués correctement en comprenant ce qui est minimisé et optimisé et comment.
Dans ce cas, nous n'avons pas mis en œuvre la méthode d'optimisation consistant à convertir automatiquement une fonction virtuelle en fonction régulière (d'autres compilateurs le font lorsque cela est possible), ce qui modifierait immédiatement les résultats de ce test et induirait à nouveau en erreur (un appel d'une méthode virtuelle pourrait soudainement être plus rapide qu'un appel d'une méthode régulière).
En fait, ce n'est pas le compilateur qui est testé, mais deux méthodes pour résoudre le même problème. Peu importe la façon dont le réfrigérateur ronronne oooh ou wooh, c'est la façon dont il gèle qui compte.
En fait, ce n'est pas le compilateur qui était testé, mais deux méthodes pour résoudre le même problème. Peu importe la façon dont le réfrigérateur ronronne oooh ou wooh, ce qui compte c'est la façon dont il gèle.
Vous avez fait un test incorrect en présentant un cas de test simplifié et dégénéré. Ce n'est pas un problème, c'est un exemple dégénéré à rien.
Vous n'avez pas prêté attention à l'optimiseur du compilateur qui optimise fortement l'option des appels directs aux mannequins.
Vous avez effectué un test incorrect en présentant un cas de test simplifié et dégénéré. Il ne s'agit pas d'une tâche, mais exactement d'un exemple dégénéré en rien.
Vous n'avez pas prêté attention à l'optimiseur du compilateur qui optimise fortement l'option des appels directs aux mannequins.
Relisez attentivement l'ensemble du sujet, s'il vous plaît.