ce dernier etant plus econome
 
Des que l'on parle de variables comme les double faisant 8 octets, windows est plus rapide que linux, ce dernier etant plus econome.
 
Laissez moi detailler.
 
Vous savez que la memoire actuelle de notre PC est en 64 bits. Ca signifie que quand on lache une operation de lecture, on va lire 64 bits d'un coup. Donc 8 octets.
 
Maintenant, vous devez imaginer la memoire comme des tiroirs, tous cote a cote. Vous voulez le contenu d'un tiroir ? Vous l'ouvrez et le refermez.  
 
Simple jusque la non ?
 
Maintenant venons en au fait. Vous ne pouvez ouvrir qu'un tiroir a la fois. Donc vous ouvrez le tiroir, prenez les infos et refermez le tiroir pour aller voir a un autre.
 
Maintenant, imaginez que dans votre tiroir vous ayez mis une info prenant 4 octets, tout au debut.
 
OK, tout va bien, vous ouvrez le tiroir, vous le fermez, et zopla, vous avez votre info.
 
Maintenant, vous etes pas trop con. Vous remplissez votre espace memoire au fur et a mesure.
 
Donc imaginons que vous ayez besoin, apres avoir range cette info, de ranger une info prenant 8 octets.
 
Vous allez mettre la premiere moitie dans le tiroir...
 
Shit putain de bordel de fuck a dieu. y a pu de place. Bah vi, y a deja une variable a 4 octets dedans. Donc vous avez pu mettre "que" 4 octets dans le tiroir.
 
Ah bah zut alors.
 
Je fais quoi ?
 
Bah je mets le reste dans l'autre tiroir. celui a cote.
 
Mais merde, si je veux recuperer l'info, je vais devoir faire deux mouvement, je vais devoir ouvrir deux tiroirs, chaque fois pour recuperer une moitie d'info...
 
Shit
 
spagood.
 
Spagood du too.
 
Il aurait ete plus efficace d'aller direct dans le tiroir d'a cote et de mettre directement toute l'info dedans, de remplir le tiroir, et comme ca si j'ai besoin d'avoir l'info, j'ouvre juste ce tiroir, je prends tout le contenu et hop, un seul mouvement.
 
POWAAAAAAAAAAAAAAA.
 
C'est vachement plus efficace.
 
Seulement merde, y a un trou de 4 octets avant... pas good. Il aurai pu etre utilise pour autre chose.
 
Voila le principe.
 
Le premier cas c'est linux. Le second c'est windows.
 
Linux dit "pour mettre une variable de 8 octets, je doit commencer soit au debut d'un tiroir, soit au milieu d'un tiroir. Ainsi, je lirai l'info d'un coup, ou en deux coups.
 
Windows dit " Pour mettre une variable de 8 octets, je dois commencer au debut d'un tiroir. Ainsi, je lirai l'info d'un coup"
 
Forcement, la seconde approche est plus efficace, mais est plus susceptible de generer des espaces memoires non alloues, voire bordelliques.
 
Pour les autres variables, ils se mettent d'accord.
 
4 octets, ce sera soit au debut d'un tiroir soit au milieu. Ainsi j'aurai tout d'un coup.
 
2 octets, soit au debut, au premier quart, a la moitie ou au dernier quart. Pareil, tout en un coup.
 
1 octet ou je veux, de toute facon ca changera rien.
 
Voili, voilou, donc windows sera plus rapide que linux niveau memoire dans quasiment tous les cas, mais linux sera un peu plus "propre".
 
Attention, je fais deliberement un GROS lapsus. Quand je parle linux, je parle les compilateurs pour linux. Idem windows.
 
Maintenant, vu le prix de la memoire, quelle solution choisir ? Celle de windows me semble plus intelligente, car on est + limite par les performances de la memoire que par la taille de la memoire ( 512 Mo... )
 
Enfin, sachez que voila, c'est image, c;est batard, c'est pas rigoureux comme demo. M'en foo. Mon but est que le + de monde possible comprenne
 
Il est possible d'appliquer la methode de windows sous linux. Mais si vous utilisez d'autres libs, vous risquez d'avoir quelques ennuis
 
l'inverse est vrai.

j'ai besoin d'une précision : les processeurs pour pc actuels sont bien en 32 bits (4 octets) ? Les os aussi ?  donc dans quel cas on peut rencontrer ce que tu viens de décrire ?
si je vois juste, on tombe jamais sur des cas de variables avec plus de 4 octets. donc il faudrait au moins 3 variables à mettre dans un "tiroir" pour rencontrer le problème : donc lorsque windows utilise systématiquement 2 tiroirs pour 2 variables, linux en utilisera qu'un.
comme tu l'as dit, je pense qu'on est plus limité en performance qu'en place
il n'empeche que windows utilise dès le démarrage un gros paquet de mémoire virtuelle, et vaux mieux ouvrir 2 tiroirs en ram qu'un tiroir sur le disque dur.
enfin je pense qu'on peut épiloguer longtemps la dessus, mais rien ne vaut un test grandeur nature, et là ça dépend clairement des applications, mais ce que tu dis n'es pas vérifié (pas dans tous les cas, loin de là)

hum .... interessant tout ca ....  

 
Hey, pas con, je viens de mater la gueule des registres et effectivement les registres sont en 32 bits...
 
Mais il doit y avoir moyen de fetcher deux registres en meme temps ou d'utiliser les deux parties d'un coup.
 
Sinon, si on a un processeur 32 bits, ne pouvant recevoir que 32 bits d'un coup par la memoire, quoiqu'il arrive, a quoi sert'il d'avoir de la memoire 64 bits ?
 
32 bits sont suffisant, car selon toi quoiqu'il arrive tu as que 32 bits utiles dans les 64 bits que tu demandes a ta memoire.
 
Et comme on ne peux faire qu;un acces a chaque fois... on peux forcement ramener et utiliser 64 bits d'un coup. Par exemple, une instruction ramenant 64 bits , et les mettant dans 2 registres 32 bits, par exemple FF FF AA AA, %eax = AAAA et %ebx = FFFF
 
Se pose aussi le probleme du return vu que c;est le contenu de %eax (32 bits) qui est renvoye... hum interessant.
 
Bref, On les traitera peut etre en plusieurs fois dans le proco, mais neanmoins en les rapatriant en un coup.
 
D'ailleurs, un acces memoire est bcp plus couteux qu'un calcul lambda du proco, point de vue temps.

je confirme une machine 32 bits a des régistres et des instructions manipulants des mots de 32 bits, une machine 64 bits, des régistres 64 bits et des instructions manipulant des mots de 64 bits
 
désigner la mémoire "mémoire 32 bits" et ou "mémoire à 64 bits" je n'ai jamais vu ça ça n'existe pas.

 
Bah tiens.
 
Pourquoi tu as des interfaces memoires en 256 bits alors sur tes CG ? Pour rapatrier 2 pixels ou + suivant le nb de couleurs d'un coup ( ce qui prouve qu;on peux rapatrier plusieurs infos en meme temps).
 
D'ailleurs, un Double c'est 8 Bytes, et tu fais des calculs en 64 bits dessus : Comment une machine 32 bits les fait alors ?
 
Tu t'es plante la AlphaT...
 
En y reflechissant bien, en faisant le calcul en deux fois, et en separant les donnees arrivant dans deux registres different, c'est tout a fait possible de faire des calcul avec une rpecision de 64 bits.

AlphaT, va lire ca pour voir pourquoi on differencie memoire 32 bits et 64 bits plutot que de lacher des enormites.
 
http://www.hardware.fr/articles/231/page4.html
 
Bref.
 
Et comment tu expliques, alors, qu'on travaille sur des nombres avec une precision de 8 octets ( soit exactement 8*8 = 64 bits )
 
http://www.intap.net/~drw/cpp/cpp03_03.htm
 
En C++, mais aussi en VB, etc...

Je parie qu'on le verra plus poster dans ce topic a partir de maintenant AlphaT
 
Je suis en train de lire mon bouquin pour voir comment ca marche... j'avance petit a petit.
 

Ma première phrase est correcte mais ma deuxième est incorrecte merci de me rappeler cette notion trop antérieure.
 
C'est vrai qu'on peut faire des calculs avec une précision de 64 bits sur une machine 32 bits j'ai déjà lu un texte à ce sujet.
 
 
 
 

Mr iench est plus spécialisé "Hardware"  
 
mais moi je connais plus la programmation sous différents langages

tu n'es pas obliger d'être méprisant
toi même tu es en train d'apprendre, tu peux encore te tromper, tu devrais rester humble.
et même si tu connaissais ton sujet parfaitement, ça ne t'empeche pas de respecter ceux qui n'ont pas de livre traitant du sujet sous les yeux
 
pour en revenir au sujet, j'ai moi même fait une erreur en disant que windows utilisant un "tiroir" par variable. Si j'en crois ce que tu dis, windows essayera de remplir un "tiroir", tant qu'une variable n'est pas couper. donc windows met au moins 2 variables par "tiroir" (j'emploie volontairement le mot "tiroir", vu que le terme registre est inaproprié il me semble, et que je ne me rappelle plus le terme exact). Ce que je voulais souligner c'est que l'impact de ce que tu décris est minim puisque les deux os mettront au moins deux variables dans chaque tiroir.
 
pour comprendre l'interet dun mémoire 64 bits, je pense que ça risque d'être compliqué, vu que la frontière entre mémoire, controlleur mémoire, et processeur est de plus en plus flou (par exemple le prochain amd aura le controlleur mémoire directement dans le core, et non plus dans le chipset comme dans les processeur x86 actuel). Il me semble vraissemblable, par un quelconque moyen, que le controlleur peut écrire 2 variables en même temps dans la même mémoires ... sinon, il n'y aurait que peu d'interet ...
d'ailleur, le controlleur ne peut pas lire qu'une seule variable à la fois, si plusieurs sont présentes dans le "tiroir". Il est obligé de toutes les charger. Si les variables qui sont voisines sont aussi nécessaires, le controlleur fait d'1 pierre 2 coups en récupérant 2 variables (ou plus). Ceci a une forte probabilité si la mémoire est peu fragmenté.
 
Bref, ta conclusion était un peu attive. On ne peut affirmer que windows a une gestion de la mémoire plus rapide que linux en prenant en compte ce seul paramètre. Dans tout ce qui est accès mémoire, de nombreux calculs de probabilités sont menés par les ingénieurs développant les processeurs pour optimiser au mieux le système. Et on ne s'improvise pas expert en architecture CPU.

on sent ke demain c vendredi, les trolls s'impatientent

 
Mais le but c'est pas de parler de la gestion de la memoire en general, juste de ce point precis.
 
Quand au nombre de variable par tiroir, justement, ca depend.
 
Ca peut etre 2 int par tiroir.
 
Ca peut etre aussi 8 char.
 
Ca peut etre 4 Short int.
 
Ou ca peux etre 1 Double...
 

 
Sous windows quoiqu'il qrrive ton Double tu l'aura en 1 acces memoire. Sous linux t'as en gros 50% de chances de l'avoir en un, 50 % de chances d'en avoir 2.
 
En moyenne sous windows, pour ranger ton double, tu bousillera de 7 a 0 octets soit en gros 3.5 octets.
 
Sous linux, tu bousillera de 3 a 0 bits soit 1.5 octets
 
Pour AlphaT, c'est une vieille histoire entre nous deux, et ce n'est pas la premiere fois que je le vois debarquer en lachant une connerie pour faire le gars qui sait.
 
mais je reconnait vraiment mon erreur d'emportement ( comme d'hab d'ailleurs), et m'en excuse.
 
Et le titre racoleur c'est pour rameuter le peuple sur un sujet que j;ai trouve particulierement marrant.

à mon avis, rien que l'optimisation de la compilation du kernel contre cette éventuelle perte de temps. Ceci dit, je dis éventuelle car [troll] ça m'étonnerait que microsoft ait déjà réussi à coder quelque chose de rapide et fiable, surtout par rapport à linux, car tous les développeurs qui travaillent dessus essaye de l'optimiser sans arrêt... [/troll]

 
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

personnellement je peux pas trop me prononcer, je pense pas que le problème soit aussi simple que ça (comment linux choisi où mettre les données). De plus, même si c'est de cette façon que procède linux, il faut savoir où c'est géré et s'il y a moyen de modifier ça. Ce serait pas le premier paramètre de ce type que l'on pourrait modifiant en changeant juste une définition dans les sources du kernel, ou en passant une option à la compilation... chose que l'on ne peut choisir sous windows.
 
Enfin, avec un titre comme ça, tu rameutera peut-être du peuple, mais ça tournera inévitablement au troll dénué d'interet. Comme je l'ai dit dans mon premier post, à notre faible niveau (en architecture mémoire), la seule chose que nous serions susceptible de comprendre sur le sujet, c'est le résultat d'un comparatif (la méthode empirique) entre les deux OS. Laissons l'absrait et les grand calcul de probabilité (que tu as grossièrement tenté de présenter) aux ingénieurs dont je n'espère même pas connaitre un jour le sens de leur travaux

Bah c'est simple il peux savoir.
 
les tiroirs commencent a l'adresse 0, OK ?
 
Les 8 premiers octets sont le premier tiroir. Ils ont pour numero, 0, 1, 2, 3, 4, 5, 6, 7
 
Soit en binaire 0000, 0001, 0010, 0011, 0100, 0101, 0110, 0111
 
le second tiroir, 8,9,10,11,12,13,14,15
 
Soit en binaire 1000, 1001, 1010, 1011, 1100, 1101, 1110, 1111
 
etc...
 
Tu remarques rien ?
 
les adresses multiples de 2 se terminent par 0.
 
Celles multiples de 4 par 00.
 
celles de 8 par 000, etc ( facile a demontrer d'ailleurs).
 
Donc si tu veux bien ranger ton Double (8 octets), tu le mets a une adresse dont le numero finit par 000 en binaire.
 
Ton int dans une adresse finissant par 00 en binaire.
 
Ton short int dans une adresse finissant par 0 en binaire.
 
etc

Ca n'a rien a voir avec windows mais avec le compilateur (gcc vs
visual machin).Ca correspond a l'attribut packed de la plupart des compilateurs, qu'il fasse du padding ou pas pour optimiser l'alignement, ansi qu'a l'option peferred-align de memoire.
 
D'autre part le cache amoindri tres fortement le benefice de vitesse
Par contre la taille reste nettement plus grosse en fonction de l'organisation memoire et du type de structure.
 

Il parle de la largeur du bus mémoire.
Une barrette de mémoire transfère des données sur une largeur de 64 bits. Tu accèdes donc à des "blocs" de 8 octets.
C'est complètement indépendant de la taille des registres du processeur.

D'un autre cote en les compactant tu as plus de chance que ce soit dans le cache
La largeur 32/64 va juste jouer sur la vitesse de remplissage du cache

c'est bien on apprend pas mal de choses ici mais j'ai perdu 30000000 neurones rien qu'en lisant les deux premiers posts.

pour savoir komment ça marche l'architecture intel, tu vas sur leur site et tu commandes leurs bouquins, ils st gratuits...

en fr ou en US???
 
Parce que si c'est expliqué en francais je prend

désolé, c en US et il y a quelques milliers de pages...

bon ben sans moi fau que je garde des neuronnes pour lire ce tomic

   
c'est vrai qu'ils sont gratuits

mrbebert a écrit a écrit :       c'est vrai qu'ils sont gratuits

puisque je te le dis... Mâme les frais de ports... Pourtant, envoyé par fedex, avec 4 kg de bouquins... Quand je les ai reçus j'ai halluciné... En fait à l'origine je cherchais de la doc sur les processeurs intel pour faire mon système d'exploitation, et vraiment, ils st très bien fait...
J'ai ces 4 volumes :
volume 1 : basic architecture. C'est un petit bouquin ki explique en gros l'arichecture intel (environ 300 pages...)
volume 2 : instruction set reference. Toutes les fonctions de l'architecture intel, avec les op codes, les descriptions détaillées, etc etc... (+ de 1000 pages !!!). Très utile pour faire un assembleur.
volume 3 : system programming guide. Le plus intéressant pour moi. Ca explique comment fonctionnent le mode protégé, la mémoire, le multitaches, les interruptions, le multiprocessing, l'apic, etc etc... (+ de 800 pages...)
volume 4 : pentium 4 and xeon. Tout sur les particularités de ces processeurs. (+ de 200 pages)
Très très bien fait, vraiment, mais il faut un bon niveau en anglais...

J'ai trouvé de quoi occuper mes longues soirées d'hiver

mrbebert a écrit a écrit : J'ai trouvé de quoi occuper mes longues soirées d'hiver

t'as oublié "pendant 3 ans"  

[Le saviez vous ?] Windows plus rapide niveau plantages et freezes que nux...

troll repéré

ou ca ????

 
ca c'est pas du troll? ou alors moi je ne comprend pas ce que c'est alors

Je suis tjs curieux sur le coup du fetchage de 2 registres en meme temps avec 64 bits

C'est pas forcement plus rapide.
Tu fait certes 1 seul acces mais ca risque d'etre un acces cache-miss plutot que 2 cache hit

En tout cas c'est tellement moins rapide que les p'tits gars d'ILM et de Pixar ont décidé d'utiliser Linux pour faire leurs films...  

encore là le iench  
arrete de parler de chose que tu ne maitrises pas  
si c'est des infos que tu es venu chercher, y-a d'autres façons de posées les questions
tu as perpétuellement tord, t'es chiant et t'es un vrai boulay !
   
 
http://www.tusors.fr.st/

djoh a écrit a écrit : encore là le iench   arrete de parler de chose que tu ne maitrises pas   si c'est des infos que tu es venu chercher, y-a d'autres façons de posées les questions tu as perpétuellement tord, t'es chiant et t'es un vrai boulay !  http://balr0g.free.fr/hfr/img/boulet.jpg     http://www.tusors.fr.st/

 
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.

remark une reponse de se genre de la part de djoh ne peut qu ' augmenter le credibilité de iench !!!
 
 
m'enfin c mon pur avis !!!

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.

 
comme l'a dit tux, c'est loin d'être aussi simple que les caractéristiques superficielles dont tu parles  
y-a bien d'autre chose à prendre en considération, et tu ne peux pas dire que windows à une gestion de la mémoire plus performante que linux uniquement à cause de ça
 
et arrete de faire chier avec tes troll bidon