Reprise du message précédent :

 
ah passke toi tu maitrises
 
Et faudra que tu me dises OU JE ME SUIS PLANTE bordel...
 
toi, j;en vois plein, mais moi
 
Enfin, ma question se trouve en bas du topic que tu as quote.
 
Et tu dis que je lis pas les posts des autres. sic.

 
C'[est le bouquin qu'on etudie en cours d'archi ( qui casse pas des briques meme si le prof detaille pas tout ).
 
Le titre : Computer Systems "a programmer's perspective"
Randal E. Bryant and David O'Hallaron
Pearson Education

Tetedeiench a écrit a écrit :     Bah 1 acces memoire au lieu de deux, en l'occurence c'est 50% de perfs de gagnees, mais 50% de place perdue en plus.   A eux de voir si il vaut mieux economiser 2 octets ou gagner un acces memoire...   Enfin ce cas doit pas se rencontrer souvent hors jeux videos.   Bref, je me demande quand meme comment se font les acces memoire 64 bits alors que le proco est 32 bits... il assigne 2 registres en meme temps ?   et c'est quoi l'instruction ? Curieux le iench

A priori, le gain en perf dépend surtout de la taille du (ou des ? suis pas allé voir ...) bus mémoire de ton proc ... s'il a UN seul bus mémoire à 32 bits, ca lui coutera tjrs au moins deux cycles d'horloge pour rapatrier les 64 bits via le controleur mémoire, même si ca se fait en une instruction ...

 
yep, mais d'apres ce que je sais, les cycles d'horloge CPU sont BCP moins couteux que de rapatrier une donnee en memoire...
 
C'est quoi le rapport deja en general ? 1:5 ?

 
j'avais decidé de pas reposter sur ce topic mais là c'est trop gros
un cycle d'horloge c'est couteux  
voilà, après quand je dis que tu as tord c'est pour ce genre d'annerie que tu dis si fréquemment  
quand à rapatrier une donnée, ça prend certainement pas 5 cycles
l'opération que tu fais dessus, p-t, mais certainement pas son rapatriement

djoh a écrit a écrit :     j'avais decidé de pas reposter sur ce topic mais là c'est trop gros un cycle d'horloge c'est couteux   voilà, après quand je dis que tu as tord c'est pour ce genre d'annerie que tu dis si fréquemment   quand à rapatrier une donnée, ça prend certainement pas 5 cycles l'opération que tu fais dessus, p-t, mais certainement pas son rapatriement

 
J'ai jamais dit qu'un cycle CPU etait couteux ( bordel ouvre les yeux). J;ai dit que ct bcp moins coutuex qu;un acces memoire vive ( qui lui est couteux).
 
T'es con ou quoi.
 
Quand j'avais etudie le motorola je sais pu quoi, pendant une lecture memoire on casait 3 instructions CPU facile.
 
Alors maintenant que le rapport vitesse proco / memoire est mechamment en faveur du proco...
 

 
Et je sais tjs pas ou se trouve l'etape permettant de trouver une utilite au bus memoire 64 bits .
 
Pour lui filer une utilite faut rapatrier 2 variables int en meme temps ( par exemple), ou 8 char ( encore un exemple).
 
Mais ou sont stockes les 64 bits ? vu qu'on ne peux faire qu'une lecture a la fois, un assignement de registre a la fois,et que les registres ne font que 32 bits...  
 
Sinon, je vois mal comment rentabiliser les 64 bits du bus memoire si c;est uniquement sur des double.
 
nan ?
 
Doit y avoir une etape avec des registres, et j;aimerai savoir :  
1- son nom
2- la taille de son registre
3- comment effectuer un rapatriement de 64 bits ( par exemple 2 int) d'un coup en assembleur.

Euh kektu dis là ??   ... y'a pas d'histoire d'être moins couteux ... qd le proc fait un fetch dans la mémoire, il doit être synchro avec celle ci pour mener l'operation à bien et ca le ralentit ... C'est pour ca que la mémoire cache est née, car comme elle travaille à des fréquences proches de celle du core du proc, afin d'éviter de trop le ralentir ... cé tout ...
Résultat, dans les archis d'aujourd'hui, le processeur ne voit plus que la mémoire cache (d'où son nom car elle "cache" la mémoire principale au processeur en lui faisant croire qu'elle va à la même vitesse qu'elle ...) et cé le controleur mémoire qui a pour tache de faire les fetch et maj entre la mémoire cache et la mémoire principale (voire entre la mémoire cache L1, la mémoire cache L2, et la mémoire principale ... dans certains cas) ... on peut même rajouter entre la mémoire principale et la mémoire virtuelle sur le disque ...
Tout ca pour dire quoi ? Que même si le proc fait un fetch en mémoire cache, ses perfs, au niveau gestion mémoire, sont qd même très dépendantes de la taille du (ou des bus mémoires) ... et un fetch de 64 bits sur un proc avec un bus mémoire de 32 bits coutera toujours au moins deux cycles d'horloge ... même si c'est écrit en une instruction ...

Zzozo a écrit a écrit :   Euh kektu dis là ??   ... y'a pas d'histoire d'être moins couteux ... qd le proc fait un fetch dans la mémoire, il doit être synchro avec celle ci pour mener l'operation à bien et ca le ralentit ... C'est pour ca que la mémoire cache est née, car comme elle travaille à des fréquences proches de celle du core du proc, afin d'éviter de trop le ralentir ... cé tout ... Résultat, dans les archis d'aujourd'hui, le processeur ne voit plus que la mémoire cache (d'où son nom car elle "cache" la mémoire principale au processeur en lui faisant croire qu'elle va à la même vitesse qu'elle ...) et cé le controleur mémoire qui a pour tache de faire les fetch et maj entre la mémoire cache et la mémoire principale (voire entre la mémoire cache L1, la mémoire cache L2, et la mémoire principale ... dans certains cas) ... on peut même rajouter entre la mémoire principale et la mémoire virtuelle sur le disque ... Tout ca pour dire quoi ? Que même si le proc fait un fetch en mémoire cache, ses perfs, au niveau gestion mémoire, sont qd même très dépendantes de la taille du (ou des bus mémoires) ... et un fetch de 64 bits sur un proc avec un bus mémoire de 32 bits coutera toujours au moins deux cycles d'horloge ... même si c'est écrit en une instruction ...

 
OK, la je suis entierement d'accord, et je capte un peu mieux.
 
Maintenant, reste une inconnue : Et si l'info est pas en cache ? Le proco est bien oblige d'attendre comme un con que l'info arrive nan ?

 
 
ben si tu sais plus ce que tu dis je vais t'aider :
 

 
pour info on ne mesure pas le cout d'un cycle d'horloge puisque c'est ça l'unité de mesure du cout d'une opération    
 
 
raaah nan mais là c'est trop bon  

Il attend encore plus que si la donnée se trouvait en cache L1 (voire que en cache L2 pour les procs destinés aux serveur avec de la mémoire cache L1 "On die", qui veut dire carrément incorporé sur la même puce que le core) ...
C'est pour ca que les ingenieurs et chercheurs s'acharnent à mettre au point des algo de prédiction afin que le controleur mémoire puisse anticiper les fetchs de la mémoire centrale vers la (ou les mémoire caches) avant quele proc en ait réellement besoin ... cé une discipline très pointue ...

 
Dis, la, tu cherches vraiment la merde, c'est le moins que l'on puisse dire.
 
Un cycle d'horloge a un cout de 1, non, vu que c'est l'unite ? Donc ca a un cout. c'est pas pour rien qu'on essaie de les economiser...
 
Hopla, tu peux sortir now.

et quand je pense que je dis depuis le début qu'il faudra forcément  deux cycle pour rapatrier un mot de 64 bits

 
et voilà, là on aborde le sujet de probabilité qui a aussi été abordé, mais faut tout lui redire au moins 2 fois au iench

 
   
raaah ce que j'me marre ... ça va les branches ? elles sont solides ?  

Bon la conclusion de tout ca, cé qu'un proc n'est rien sans un bon compilateur ... qui lui "réarrange" les instructions afin de tirer le meilleur de lui même ... l'optimisation elle peut porter sur le proc lui même, sur le compilo, voire les deux ... et dans pas mal de domaines ... optimisation de l'utilisation des registres, utlisation de jeux d'instructions spécifiques à certaines applis (MMX, SSE, SSE2, 3D Now, AltiVec, etc ... encore que là il s'agisse plus de la responsabilité du programmeur qu'autre chose ...), mémoire, prédiction, reséquencement, etc ...

 
Moi j'ai le bouquin "Architecture de l'ordinateur" 4e édition de A. Tanenbaum
 
Ce n'est pas une référence trop technique mais qui a l'avantage de bien décrire le concept
 
Je ne m'en sers plus depuis que j'ai changé de branche en info : je me suis tourné vers le génie logiciel Le "hardware" ce n'est pas pour moi, je préfère être ingénieur et faire de la POO, modélisation UML,

Laaaaaaaaa djoh, ca c'est du mec qui a du talent : bjone .
 
http://forum.hardware.fr/forum2.ph [...] ubcat=#bas

Tetedeiench a écrit a écrit :     Il a lu le topic le monsieur   J;ai juste dit que la facon de ranger les variables longues en memoire etait plus efficace chez windows (i.e. les compilo sous dows) que sous linux (i.e. les compilos sur linux), ce dernier etant plus econome.   Alors lis le topic et apporte moi des preuves comme quoi ce que je dis est une connerie non maitrisee   je suis tout oui ma poule.

 
Il a pas tort sur plusieurs points Djoh :
 
1) Ca dépend des compilateurs, je suis loin d'être spécialiste des options de compilation gcc mais vu les possiblités que j'ai déjà vu je pense qu'il est possible de compiler avec un gcc réglé pour gérer "à la Visual".
 
2) En tant que codeur, les doubles c'est à éviter absolument si on veut faire du code rapide, raison pour laquelle beaucoup de monde attends les CPU 64 bits ( et raison pour laquelle un alpha explose un i386 sur des programmes ou une opti 64 bits est possible, genre une IA sur un plateau de 64 cases pour des tests binaires )
 
 
Bref s'il serait intéressant de voir en pratique avec quelques bouts de code ce que ça donne, il semble peu probable que ton cas soit rencontré bien souvent et généraliser à partir de la découverte d'un paragraphe dans un livre sans maitriser le contexte est une grâve erreur je trouve.
 
C'est quelque chose qu'on voit tout de suite dans le topic, tu prends un truc imagé, tu ne poses aucun contexte et tu généralises sur une partie simplement du problème. Tu ne parles même pas de la mémoire cache qui a un rôle déterminant dans la gestion des données en mémoire !  
 
Franchement tu pourrais te passer de ce titre raccoleur et de ton cours majistral basé sur une recherche personnelle qui se limite à un paragraphe d'un livre. Même si ensuite tu tentes de compléter en allant voir à droite à gauche ce qui peut se goupiller avec ton explication, c'est bancal de partout, personne n'est dupe... Oses dire que tu connaissais tes explications en page 2 et 3 au moment où tu postais le topic ? Non et tu l'avoues toi même.  
 
Je pense qu'avant de faire ce genre de discours hautain, on essaye de maitriser quand même le sujet et son environnement, autant j'aurais apprécié un topic sur le sujet d'une personne qui travaille ou se passionne pour ce sujet depuis longtemps, autant ça m'énerve de voir ça posté de cette manière qui plus est par une personne qui découvre...
 
Quelle est la différence entre un prof et un élève après un cours : L'élève connait un morceau du domaine, le prof maitrise sait interprêter le morceau dans le domaine.
 
Iench : Tu devrais lire plusieurs thèses différentes sur un même domaine, ça te ferait surement revoir ta façon de juger les connaissances ( je parle en général, pas sur ce sujet là ).

 
Bah la prochaine fois demandes lui de faire le topic à ta place ( ça sera surement beaucoup mieux )

Comme si j'avais eu pour ambition de donner une image parfaite et directe, en comparant parfaitement la gestion de la memoire de linux a windows...
 
Mais vous avez lu le truc ou quoi ?
 
Ouai j'ai vulgarise a mort, c'etait voulu !
 
J'ai pas voulu, encore une fois ( putain sly, lis un post en entier avant de poster, marre de me repeter) comparer les approches win et nux EXACTEMENT.
 
J'ai voulu balancer ce que je venais d'apprendre en cours, qui etait tres surprenant ( j'avais jamais pense a un truc pareil, personellement), et qui m'a un peu fait bondir.
 
c'est tout.
 
Maintenantm tu interprete ca comme tu veux ( enfin de toute maniere des que tu peux me critiquer t'y va, alors), mais je sais d'ou ma demarche part etc.
 
OK, le titre racoleur c'etait pour me marrer, mais force est de constater qu'en theorie ( ou aie-je eu la pretention de dire que ct la pratique integrale d'ailleurs ? interpretation encore une fois... devriez apprendre a lire et a comprendre, surtout le dernier point), l'approche de windows preferait plus les performances.
 
Vu le credo linux + rapide et + mieux, ca m;a fait franchement marrer et j;ai poster.
 
Sans me preoccuper de la memoire cache ni autre. EN me focalisant sur un point rpecis.
 
Alors oui, si tu veux un expose, tu va lire une these. Et la tu saura tout.
 
Suelement ici, c'est un forum, pas un recueil d'ingenieur. Et j'aime exposer des points precis ultra vulgarises pour que tout le monde comprenne ( si moi je comprends le point et arrive a en faire une image un tant soit peu realiste, tout le monde peut y arriver).
 
Ensuite effectivement c;est pose l;excellente question des variables 64 bits et de l'utilisation de ce bus 64 bits vu que le proco etait en 32 bits.
 
Et la je reconnais mon erreur d'avoir tout base sur mes souvenirs du motorola qui n'avait pas de memoire cache.
 
Maintenant, tu sais, j;ai pas besoin de lire une these pour faire un post comme celui ci. Je suis sur que 90% des gens qui ont lu le truc ont compris les deux approches.
 
Et ont aussi integres quelques concepts annexes.
 
Alors que si t;avais poste ta these, tu serai comme un con a te masturber devant ton post de 15 pages de long que personne ne lit.
 
Deux approches differentes, stoo.
 
djoh m;a enerve a balancer des trucs sans queue ni tete ( relis le debut du topic), a parer d'Extended double alors qu'on en etait reste au double ( et d'avoir voulu me faire dire que dows accedait a n'importe quelle variable en 1 fetch, ce qui est une heresie), etc.
 
Et pis merde, j'en ai marre de me justifier devant toi.
 
Si t'es pas content lis pas.
 
Au moins certains auront compris, et je ressortirai moins con la prochaine fois, grace a bjone, et pas grace a vous.
 

Le Iench il met dehors tous ceux qui apportent des arguments concrets
 
de la façon dont il parle ça manque bcp de politesse

Sly Angel a écrit a écrit :     Bah la prochaine fois demandes lui de faire le topic à ta place ( ça sera surement beaucoup mieux )

 
Parce que tu crois que bcp de mondea compris son truc ?
 
heureusement que je connais un peu d;assembleur, sinon laisse beton.

d'ailleurs, faudrait apprendre a lire une ligne sly : J'ai dit dans le premier post ( sisi, lis pour une fois, survole pas), que le lapsus Windows / compilo windows etait VOULU pour pas simplifier les choses pour un truc dont TLM se fout a part les puristes.
 
C'est + comprehensible ainsi.

 
Vu que c'est un forum informatique, la plupart des visiteurs en savent déjà assez sur le sujet.  
 
La généralisation avec le tiroir est excessive. Tout le monde qui a suivi des cours d'info savent déjà que le tiroir n'est nul autre qu'une case mémoire occupant une taille définie
 
 
 
 

Iench : Oui c'est drôle ça, tout le monde interprête mal ce que tu dis, ne serait ce pas plutôt toi qui ne sait pas t'exprimer ?
 
-> J'ai passé ma dernière heure à tout lire alors ta réflexion sur ma lecture du topic...
 
-> oui tu as dis que c'était le compilo, mais une phrase planquée dans un mont d'erreur tu m'excuseras mais c'ets du n'importe quoi.
 
-> Tu veux partager des connaissances à des gens ? C'est très bien, le forum est là pour ça, mais faire partager des connaissances c'est dire des choses exactes et définir un contexte, là où toi tu t'es surtout amusé à raccoler et à prendre un cas sur une fonction comme généralité.
 
-> Tu te focalises sur un point et ensuite tu développes n'importe quoi derrière quand on te fait remarquer que ton morceau n'est qu'une bribe du sujet
 
-> "Je suis sur que 90% des gens qui ont lu le truc ont compris les deux approches" -> Et 90% de ces mêmes gens en auront tiré les conclusions que tu sous entends et qui sont fausses. Hors ici ta conclusion se trouve dans le titre et je pense que j'ai pas besoin de dire le problème par rapport au titre. De plus tu arrives en messie pour dire "je vais apprendre des choses aux gens ici" alors que certainement d'autres personnes mieux renseignées auraient pu s'en charger bien mieux, lancer un sujet et faire sa leçon sont 2 choses différentes. Visiblement tu n'as pas trouvé la manière de lancer un sujet...
 
-> J'ai parlé de thèse pour ce qui est de la manière d'aborder les connaissance, il ne me semble pas avoir demandé que ce soit un thésard qui parle de ça...  
 
-> Djoh t'a énervé ? Mais tu croyais quoi en postant ça de cette manière ? Plaire à tout le monde à coup de rentre dedans ? Tu mets une connerie grosse comme toi et derrière tu t'attends à ce que les gens soient béas devant ton post ? ( surtout après avoir envoyé bouler tous les participants qui critiquent ton topic à raison ). Je pense qu'il a plus de raisons que toi d'être énervé de ce topic et que c'est bien toi qui cherche là.
 
-> Je t'ai pas demandé de te justifier, je dis ce que je pense, on est bien sur un forum non ? ( c'est toi même qui le dit hein )
 
-> Oui je lis, parce qu'heureusement il y a des gens qui prennent la peine d'écrire des choses intéressantes malgré tout ici. Je lis également parce que je me demande ce que tu vas raconter dans ce topic et malheureusement c'est encore plus infect dans la manière et la maitrise du sujet que je ne le pensais.  
 
-> certains auront profité d'autres personnes que toi pour apprendre oui, mais certains aussi n'auront pas pris la peine de lire le topic en entier vu justement comment tu as présenté la chose ( j'ai failli ne pas le lire après avoir vu le premier post moi même ). Si tu avais lancé le sujet sans balancer des affirmations à la con au départ, il aurait surement été beaucoup plus intéressant, alors il n'y a pas de quoi te satisfaire de ton oeuvre...
 
P.S. : Apprends à t'exprimer

les posts d'engueulades sont plus argumentés que le sujet  
 
si j'ai bien suivi un tiroir c'est une case et que le compère-latteur optimise tout le boxon en fonction de l'arche-à-Tecture.  D'ou la question qui découle fort logiquement de ce postulat : qui est Tecture ?

 
Qu'est ce qui te dit qu'il ne saurait pas vulgariser la chose si c'était un autre interlocuteur que toi ?  
 
Qu'est ce qui te dit que ça intéresse quelqu'un de savoir le temps que ça met un double pour circuler entre CPU/cache et RAM s'il ne connait même pas comment marche les bus & co ?
 
Tu ne vulgarises pas, tu prends des raccourcis dangereux et les gens qui ne connaissent pas justement sont dupés par tes explications, alors que derrière tu prétends que les gens pourront peser la valeur de ce que tu dis dans le contexte. C'est tout à fait paradoxal.
 
De plus je le redis, tu arrives en expliquant sur OSA qui est plutôt fréquenté par des gens ayant une certaine compétence les choses comme à un enfant. Si c'est à des gens qui n'ont pas de compétences que tu t'adresses, alors pourquoi mettre un titre qui trompe et s'adresse, tu l'as dit toi même, aux autres pour les provoquer ( et tu t'étonnes qu'ils répondent ? )

 
Simplifier ne veut pas dire erronner !!!!!!!
 
Pour le reste, je l'ai lue ta ligne, mais tu devrais plutôt faire publicitaire dans les journaux, tu sais ceux qui écrivent en énorme un truc et mettent une petite asterisque au bout avec une ligne à lire en bas.
 

Sans vouloir la ramener. On m'a a deja dit 2 fois que je me repetais, mais en ignorant l'info, cd page 1....
 
Le bus 64 bits c'est bien pour remplit le cache
 
Pour le prefered aligment versus le padding :
Plus de memoire utilise = acces alignes donc plus rapide mais risque  
de hors-cache plus important
 
Exemple : Utilisation du RGB24 comparé au RGB32
Le RGB32 est plus rapide que le RGB24 car tous les acces sont alignés sur 32 bits mais le surcout memoire du a la case memoire consommée en plus font que c'est plus lent.
 
L'alignement peut etre une option de compil et la ca pose probleme si tout ( y compris les libs ) n'est  pas compilé avec
Mais c'est aussi un attribut de declaration de structure
donc ca peut etre utilisé localement
Je l'ai plus en tete pour gcc
 
Enfin ca depend du bus memoire qu'il y a derrier.
Si c'est un bus lent (pas PC mais embarqué), type 16 bits asynchrones avec de nombreux wait-state on evite au maximum les caches miss car ceux ci sont tres tres couteux.
 
Enfin la possibilite les x86 sont les seuls CPU (a ma connaissance) a pouvoir faire des acces word/dword/quadword non alignés. Ca provoque un bus error sur les autres (motorola, sparc & arm)

 
ouai bah merci j'avais lu ... lui au moins il sait de quoi il parle

 
oula    
bon ben j'ai rien à rajouter    
t'as décrit tout ce que je pensais là  
 
- à retenir notamment : on est plusieurs à avoir soit disant "mal compris" ce que tu dis : exprime toi mieux
- ce post n'a rien à faire dans cette section (quand bien même il serait intéressant)

Alors là ça m'étonne! Ca fait longtemps(>10 ans) que je n'ai pas fait d'assembleur, mais il me semble qu'avec un 68030 ça ne posait pas de problèmes.  

Avec le 030 peut etre, mais avec les 00-010 et 020 c'etait le bus error a tout les coups.

Je ne vois pas l'interêt de ce topic: expliquer le fonctionnement bas niveau d'un ordinateur prendrait des jours, des semaines que dis-je des mois!
 
Donc à part troller je ne vois pas d'autres objectifs.

c bow l':love:

à quand la winram incompatible linux ?    
 
 
je sors ....

superX a écrit a écrit : à quand la winram incompatible linux ?         je sors ....

 
mdddrrrrr

superX a écrit a écrit : à quand la winram incompatible linux ?         je sors ....

 
 
bientot avec les pc palladiumé

 
et en plus c'est vrai !  
qu'est ce qu'ils vont pas nous inventer !  

Au moins mean rélève le niveau parce que sinon... (quand on ne sait pas on évite le ton péremptoire, cela évite de passer pour une andouille)
 
Je rajoute juste que comme il le signal, les acces non-alignées sont pénalisé en temps justement pour réaligner. Donc les perfs diminuent. Donc le padding fait perdre des perf sur des petites taille de donné, (char c; en C va prendre réellement 32 bits avec gcc, mais char tabc[1000]; va prendre 1000 octects de mémoire).  
 
Donc dans le cas général, gcc pond du code plus rapide (si ta version sur la manière de gérer la mémoire de vc++ de MS est vrai).
 
Donc tu t'es planté dans l'origine même de ton topic.