Des idées ambitieuses ! !! - page 5
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
Vous vous trompez parce que vous ne connaissez pas les choses les plus simples.
Les données d'un tableau sont stockées en mémoire selon une séquence linéaire. Du premier au dernier, et pour adresser un élément x[15], le compilateur va calculer l'adresse du début du tableau plus le décalage de 15 pour calculer l'adresse de cette variable. Avec un tableau à deux dimensions, par exemple, x[2][5], il faut d'abord calculer le décalage pour la deuxième ligne, puis y ajouter le décalage pour le 5e élément, soit deux fois plus d'opérations.
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
tout ceci est au niveau du compilateur, mais ArrayRange(x[0]) pour un tableau statique est TOUJOURS constant, il n'a pas besoin d'être calculé tout le temps, juste une fois et enregistré au moment de la compilation
Vous pratiquez l'assembleur ? pourquoi ces problèmes ? si vous faites de l'assembleur, hélas - je n'ai vu aucune documentation russe pour le chargement DROIT du pipeline d'instructions sur les processeurs plus anciens que le Pentium-I, et le chargement DROIT du processeur n'est même pas engagé par les développeurs de compilateurs, mais par les développeurs de l'OS et de l'architecture du processeur
Si vous craignez que l'exécution d'une opération d'addition prenne plus de temps en cycles d'horloge du processeur qu'une opération d'addition, hélas, ce navire a pris le large avec le processeur 486th, le chargement des caches et des pipelines d'instructions prend plus de temps que les opérations arithmétiques et logiques.
SZZY : Je lance un nouvel appel - commencez à lire les sources primaires, ici https://www.mql5.com/ru/docs/basis/types/classes les développeurs mql5 décrivent comment organiser l'alignement des données, la même info est pour tous les compilateurs, il y a des informations sur comment utiliser correctement les fonctions du système d'appel de Windows, etc. - J'écris ceci pour dire qu'il y a peu de documentation russe qui correspond aux capacités modernes du système d'exploitation et des processeurs, et les vieux trucs - ceux qu'ils enseignent dans les collèges et les universités - ne correspondent pas à la réalité à ce stade de développement du système d'exploitation et du matériel...
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
tout ceci est au niveau du compilateur, mais ArrayRange(x[0]) pour un tableau statique est TOUJOURS constant, il n'a pas besoin d'être calculé constamment, il suffit de le calculer et de le sauvegarder une fois au moment de la compilation
Seule l'adresse du premier élément est calculée à l'étape de la compilation. Tous les autres éléments seront comptés en mode comptage par le biais du décalage, qui est différent à chaque fois.
Pour un tableau à deux dimensions, vous devez compter deux décalages par colonnes et par lignes multipliés par le numéro de ligne, et bien sûr dans le processus de comptage également. L'assembleur et le compilateur n'ont absolument rien à voir avec cela, il s'agit simplement d'un adressage de base de la mémoire pour une utilisation correcte des ressources informatiques dans la pratique.
Vous pouvez facilement constater que même s'il y a une perte de performance aussi importante entre les tableaux unidimensionnels et bidimensionnels, les temps d'adressage sont d'autant plus lents dans des cas plus complexes, par exemple avec des objets.
Seule l'adresse du premier élément est calculée au moment de la compilation. Tous les autres éléments seront comptés en mode comptage via un décalage, qui est différent à chaque fois.
Pour un tableau à deux dimensions, vous devez calculer deux décalages par colonne et par ligne, multipliés par le numéro de la ligne, ainsi que dans le processus de comptage, bien sûr. L'assembleur et le compilateur n'ont absolument rien à voir avec cela, il s'agit simplement d'un adressage de base de la mémoire pour une utilisation correcte des ressources informatiques dans la pratique.
Vous pouvez facilement constater que même s'il y a une perte de performance aussi importante entre les tableaux à une et à deux dimensions, le temps d'adressage est d'autant plus lent pour les cas plus complexes, par exemple les objets.
les succès dans la compréhension de ce qui se passe et la perte de productivité
Je n'ai aucun problème à optimiser les compilateurs et à écrire mes propres conceptions d'accès aux données.
SZY : les objets ne sont pas des cas complexes - toutes les manipulations pour créer des liens - tout cela au niveau du compilateur, hélas, le processeur ne se soucie pas d'objet ou non, il n'a aucun problème avec le calcul des décalages relatifs aux données alignées, même si le "programmeur miracle" économise de la mémoire - écrit les données dans des tableaux comme des octets, mais ne regarde pas la documentation au compilateur, l'efficacité de ce code ne sera visible que dans le reflet d'une physionomie suffisante du programmeur dans le miroir, mais en réalité c'est un faux
tout est au niveau du compilateur, hélas le processeur ne se soucie pas de savoir s'il s'agit d'un objet ou non, il n'a aucun problème à calculer les offsets relatifs aux données alignées
Il semble que l'on vienne de vous expliquer sur un exemple simple combien le tableau bidimensionnel par rapport au tableau unidimensionnel ralentira pendant l'exécution du programme, et non pendant la compilation. Je ne vois pas l'intérêt de me répéter. Vous voyez donc que la tâche d'écrire un code de calcul plus ou moins optimal ne prend pas trop de votre temps, et peut-être n'en avez-vous pas besoin. Dans ce cas, la POO est créée pour vous. :)
Vous pensez en catégories d'amibes :) .
"Nous devrions oublier les petits gains d'efficacité, disons environ 97% du temps : l 'optimisation prématurée est la racine de tous les maux. Pourtant, nous ne devons pas laisser passer nos chances dans ces 3% critiques".
C'est la quatrième fois que je suis cité dans ce forum.
Il semble que l'on vienne de vous expliquer, sur un exemple simple, à quel point un tableau à deux dimensions est plus lent qu'un tableau à une dimension dans le processus d'exécution du programme, et non de compilation. Je ne vois pas l'intérêt de me répéter. Vous voyez donc que vous ne vous donnez pas la peine d'écrire un code de calcul plus ou moins optimal, et peut-être n'en avez-vous pas besoin. Dans ce cas, la POO est créée pour vous. :)
De quel type de code optimal parlons-nous ? Vous n'avez absolument aucune idée du fonctionnement des compilateurs et des machines virtuelles.
Le programmeur n'a pas besoin de découvrir comment l'accès et l'adressage aux éléments de la mémoire physique dans chaque compilateur particulier est fait (même si en diagonale, pas en colonne - rien ne peut être fait ici) - c'est la tâche des développeurs, si le programmeur n'est pas satisfait du code - il optimisera son code :
- en augmentant la taille du code et en diminuant la taille des données et en perdant la vitesse de calcul
- en augmentant la taille des données dans le code et en obtenant une vitesse plus élevée.
- alternativement, il/elle utilise un compilateur différent
TOUTES LES OPTIONS ont disparu !
La POO est une autre branche pour écrire du code EFFICACE, l'efficacité de la POO est que le programmeur peut créer un modèle mathématique sous la forme d'une sorte d'architecture - et ainsi atteindre une grande polyvalence de votre code, si vous pensez que les classes ont un autre type d'adressage pour l'accès physique aux données - vous vous trompez, cette quantité supplémentaire microscopique de données - une table d'objets liés n'augmentera en aucun cas le temps d'accès aux données physiques dans la mémoire et les données supplémentaires seront plus que compensées par le multi
Je suis choqué - vous avez commencé à chier sur la POO, puis vous êtes passé aux arguments sur l'adressage dans les tableaux multidimensionnels et unidimensionnels - avez-vous étudié cela quelque part, ou juste - toutes les spéculations et les fantasmes ?
Le travail avec des tableaux multidimensionnels a été mis en œuvre depuis longtemps au niveau du fer - le même Z-buffer lors du travail avec des cartes vidéo, ah, oui, "les moutons, les développeurs de fer" - ne vous ont pas consulté et n'ont pas appris l'efficacité de l'adressage des tableaux multidimensionnels, et ne vous ont pas consulté - tous les programmeurs utilisent des tableaux multidimensionnels sans y réfléchir à deux fois, et ne cherchent pas le bonheur en augmentant le code au nom d'une efficacité imaginaire lors du travail avec des tableaux unidimensionnels
La fiabilité d'une information dépend-elle de la personne qui la présente ? Toute personne sensée devrait comprendre que l'information est objective, et non subjective. :)
si le programmeur n'est pas satisfait de son code, il l'optimise :
- en augmentant la taille du code et en diminuant la taille des données et en perdant la vitesse de calcul
- en augmentant la taille des données dans le code et en gagnant plus de vitesse
- utilise alternativement un compilateur différent
TOUTES LES OPTIONS ont disparu !
L'optimisation du code nécessite que le programmeur ait une compréhension minimale de l'intensité en ressources d'un fragment de code en termes d'opérations élémentaires effectuées (addition, multiplication, accès à la mémoire, calculs d'adresses, etc.) Sans cela, aucune optimisation n'est en principe possible, et même le meilleur compilateur sera impuissant face à ce pauvre programmeur. Cela semble évident, mais je vois que cela peut être une grande nouvelle pour de nombreux programmeurs aussi. :)
Et quiconque cherche à comprendre la question se rendra compte que l'information, comme la quantité, est une chose subjective, et non objective :)))
Eh bien, vous devez confondre et mélanger dans un mélange de crotales différentes choses. :)
L'un est une source d'information, qui est objective, et l'autre est un récepteur, qui est subjectif car il n'est pas toujours capable de percevoir toutes les informations, mais seulement une partie.