Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ce n'est plus à ce moment une application personnelle. On est tous d'accord pour dire qu'une application professionnelle peut avoir besoin de cette mémoire supplémentaire, mais pas forcément les applications personnelles. Et les exemples donnés sont des applications professionnelles...
Salut,
Si, de fait, on peut difficilement estimer qu'il s'agit d'applications personnelles, je ne crois pas forcément qu'il faille les taxer d'application professionnelles...Envoyé par Miles
Les jeux MMOG, bien que *souvent* développés en équipe, entrent difficilement dans la plupart des acceptions du sens donné à "application professionnelle".
Tu trouveras meme plusieurs projet de MMOG qui n'entrent pas dans l'acception ayant sens de "application créée (et gérée) par des professionnels
A méditer: La solution la plus simple est toujours la moins compliquée
Je ne vois aucun livre ainsi nommé dans la liste de ses livres.
Ils sont normalisé en C et décrit dans la norme C. Et être normalisé n'est pas une condition nécessaire pour être documenté.1) Ils ne sont pas standards donc documenté nulle part.Il est vraissemblable que la prochaine version du C++ aura les types de taille fixe introduits en C99
Le fait qu'ils seront vraissemblablement introduit en C++0X est déduisible des documents publiquement accessibles du commité.2) Où est-ce donc dit ?
La normalisation est par essence un processus lent.3) Il serais temps que se soit fais !
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
Je ne me suis pas retapé toute la discussion en profondeur, j'ai rien vu la dessus, alors pour en revenir au sujet initial:
il peut y avoir un sérieux problème avec size_t qui lui, contrairement à int restant à 32, passe à 64 bits non?
Sachant que les size_type sont implementés en tant que size_t.
Et pour les comparaisons avec std::string::npos aussi qui est implementé en tant que static_cast<size_t>(-1) .
( désolé si cela a déjà été mentionné )
C'est dans ce genre de cas que lire les warnings devient encore plus primordial
Je viens de lire une bonne partie de ce post.
Y a pas mal de bêtises.
Sous XP x64 c'est 128 GB de mémoire géré au max comme pour Vista à partir de la version Business.
Ensuite pour les programmes comme sous les sytèmes Windows x86 c'est 2GB adressable par un processus 32 bits et 4GB si on déclare IMAGE_FILE_LARGE_ADDRESS_AWARE pareil pour un processus x64 sauf que c'est 8TB avec IMAGE_FILE_LARGE_ADDRESS_AWARE.
Ensuite y a l'arrivé de nouveau registres généraux qui commencent par la lettre R codé sur 64 bits.
Le nombre de registre généraux double ainsi que le nombre de registre SSE.
x64 c'est que du bénef pour les perfs...
Dernière modification par NairodDorian ; 06/08/2008 à 19h03.
Pas forcément. Tu travailles avec des pointeurs deux fois plus gros, donc tu peux avoir un ralentissement.
Pour le reste, c'est presque juste ce que tu racontes. C'est le nombre de registres généraux ainsi que les XMM qui est doublé. Il n'y a jamais vraiment eu de registres pour la FPU, c'est une pile qui est utilisée en réalité. Et cette partie a entièrement été remplacée par les instructions SSE2 si j'ai bien compris
Oui utilisé comme une pile mais ce sont bien des registresc'est une pile qui est utilisée en réalité
Non ça n'a pas disparu.Et cette partie a entièrement été remplacée par les instructions SSE2 si j'ai bien compris
Dernière modification par NairodDorian ; 06/08/2008 à 18h29. Motif: vérification sur doc intel quand aux registres FPU
Si tu tu stockes explicitement un pointeur en mémoire oui, sinon je ne vois pas pourquoi ça gonflerait forcément.
On appelle ça une pile à cause de la façon dont on y accède mais ce sont bien des registres casés à l'intérieur du CPU, pas une zone mémoire utilisée comme pile.
Non, par contre les drivers pour Windows 64 bits ne peuvent plus utiliser le FPU (au départ Microsoft disait que ce serait le cas pour les programmes utilisateur aussi).Et cette partie a entièrement été remplacée par les instructions SSE2 si j'ai bien compris
:wq
(De memoire) Il y a 8 registres qui sont utilisables comme une pile ou comme des registres independants. Je ne me souviens plus par contre si le jeu d'instructions est (etait des le debut) complet en ce qui concerne l'utilisation comme registres independants.
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
Exact, les registres sont nommés st.Il y a 8 registres qui sont utilisables comme une pile ou comme des registres independants.
Les registres MMX sont des alias des registres FPU et on peut y accéder normalement mais dès qu'on veut repasser en FPU il faut réinitialiser les registres. De mémoire on peut quand même accéder un peu au registre FPU qu'on veut avec FXCH (pour échanger un registre avec ST0).
:wq
Oui mais tu risques de ne plus rien récupéré de correct.De mémoire on peut quand même accéder un peu au registre FPU
C'est pour celà qu'on sauvegarde "l'état" avant d'utilisé les instructions MMX.
Pour "retravailler" avec les registres FPU après avoir bossé avec MMX on exécute d'abord EMMS et ensuite on restaure "l'état".
Mais ça n'a plus d'importance qui se sert encore de MMX qui va disparaitre de manière définitive?
C'est vrai qu'il y a un risque à utiliser une techno. destinée à disparaître. Mais j'imagine que quand on veut optimiser à fond une fonction, ça peut toujours être utile d'avoir un jeu de registres supplémentaire.Mais ça n'a plus d'importance qui se sert encore de MMX qui va disparaitre de manière définitive?
Avant de poster un message.
Quand vous avez la réponse à votre question, n'oubliez pas de cliquer sur.
Bah non, je parle d'utiliser FXCH pour changer le registre qui est au sommet de la pile.Oui mais tu risques de ne plus rien récupéré de correct.
Faut jamais dire ça avec Intel.
:wq
c'est pas plustôt 3Go ?
Ben... en fait...
Sous x86, il y a toujours 4Go d'addressable ! Mais sur ces 4Go, 1Go est reservé pour le système, voir 2Go si on a pas utilisé le bon flag. Donc il reste 2Go (ou 3Go) d'utilisable (mais toujours 4Go d'addressable).
Il n'y a plus cette limite en x64, qui peut ainsi mapper les 3Go de RAM des 3 cartes graphiques en SLI sans manger toute la partie addressable
N'oubliez pas de cliquer sursi un commentaire vous a été utile !
Et surtout
Oui sous un OS Windows x86.c'est pas plustôt 3Go ?
Avec un OS Windows x64 si ton process est 32 bits alors 4Go avec IMAGE_FILE_LARGE_ADDRESS_AWARE.
j'avais compris allouable
dsl
Avec des type list et tout et tout ?
[FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.
Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager