Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 3 sur 9 PremièrePremière 123456789 DernièreDernière
Affichage des résultats 61 à 90 sur 252
  1. #61
    Bah à mes souvenirs non.

    Mais bon sa me dérange pas hein !!

  2. #62
    Newbie06 > Nan, c'était juste pour dire que je suis breton, et que je faisait mon stage à grenoble... Faut que j'update mon profil, maintenant, c'est le nord de l'allemagne.

  3. #63
    Citation Envoyé par haven Voir le message
    Bah à mes souvenirs non.

    Mais bon sa me dérange pas hein !!
    Parfois, il y a de la promotion non réclamée... T'as peut être dit un truc particulièrement hardware advanced...
    Mes propos n'engagent personne, même pas moi.

  4. #64
    Dans le "tableau de bord utilisateur" option "groupe" j'ai une case à cocher pour la partie X86 adv, est-ce une invitation?
    Si c'est le cas, ça m'étonne un peu je suis un gros noob
    crève boulon

  5. #65
    Oui, c'est une option automatique qui permet à n'importe qui de faire la demande d'accés à la section x86 ADV.

  6. #66
    Aaaaaah okay , tout est clair à présent.
    crève boulon

  7. #67
    Mon oeuvre n'a plus de sens.
    Bon, je vais l'indiquer dans le 1er post, il servira au moins à ça...

  8. #68
    Bonsoir

    Je déterre un peu ce topic (tu vois Yasko, ton oeuvre n'est pas perdue) pour aborder un sujet qui me turlupine depuis quelques jours...
    Humble péon que je suis, je ne souhaite pas particulièrement obtenir l'accès aux escaliers du hard, mais j'ai pas trouvé d'autre sous-forum sans faire de HS.

    Je me demandais, donc, pourquoi il existe une différence troublante de performances quand on compare les processeurs de la plateforme core i7 face aux Phenom II X4 (high-end).

    Ce questionnement est apparu quand je me suis monté ma config à base de 955 BE. Je regardais plein de dossiers/comparatifs, puis je suis tombé sur 59hardware.

    Pour raccourcir, la plateforme i7 prend souvent une longueur d'avance dans les jeux, les benchmarks de compression ou encore les benchs dits "synthétiques" (je me demande à quoi ils servent d'ailleurs, 'fin bref).
    En revanche, pour 2 des 3 benchs de calcul, et l'intégralité des benchs linux, la plateforme Phenom2 X4 prend une avance surprenante. Je ne comprends pas.

    Est-ce que tout est histoire d'optimisation du côté logiciel ? Pourtant, mes quelques neurones sains m'informent qu'un benchmark linux bdd mysql fait des tests concrets, applicables directement dans la réalité. Est-ce possible d'optimiser ce genre de calculs autrement que par les instructions (trucs qu'on voit dans cpu-z...).

    Si vous pouviez m'éclairer, je vous en serais reconnaissant
    (y'a pas de piège)


  9. #69
    Ce que je vois, c'est que ces tests mettent particulièrement en lumière la force d'AMD (ou la faiblesse du i7 920) dans le domaine de l'encryption AES (comme ici ou la).

    Pour le reste, (un test MySQL, un sur les entiers et un autre sur la mémoire sous Linux), deux pistes :
    - les Phenoms en question ont une fréquence de fonctionnement plus élevée
    - le tout premier test PCMarkVantage font apparaitre que la plate-forme i7 est en léger retrait du point de vue HDD. Pourquoi, mystère, mais cela joue peut-être.

  10. #70
    Citation Envoyé par Grosnours Voir le message
    Ce que je vois, c'est que ces tests mettent particulièrement en lumière la force d'AMD (ou la faiblesse du i7 920) dans le domaine de l'encryption AES (comme ici ou la).
    Autrement dit, AMD va avoir chaud aux fesses quand Westmere sera là avec les instructions d'accélération AES hardware... (c'était peut-être fait pour, d'ailleurs)

  11. #71
    Via a un AES hard qui marche fort et majoritairement, j'ai l'impression que les gens s'en branle.
    Mes propos n'engagent personne, même pas moi.

  12. #72
    Je trouve bizarre dans cet article de 59hw qu'ils ne donnent que les latences de leurs mémoires. Doit-on en déduire qu'elles fonctionnent à la vitesse standard des bus/liens mémoire ?

    Sinon j'ai en gros les mêmes résultats qu'eux pour nbench 64 sur i7, donc pas de grosse cagouille flagrante à ce niveau

  13. #73
    Tiens puisqu'on a un utilisateur de cet OS du malin (CQFD : il aime moins l'i7 que Windows ), est-ce que le fait de faire un OC même léger (genre passer a 3 ou 3,3Ghz) change drastiquement (comprendre proportionnellement) les résultats du tests sur les entiers ?
    Je cherche a comprendre le test 59hw....

  14. #74
    Citation Envoyé par Møgluglu Voir le message
    Autrement dit, AMD va avoir chaud aux fesses quand Westmere sera là avec les instructions d'accélération AES hardware... (c'était peut-être fait pour, d'ailleurs)
    J'ai effectivement vraiment l'impression que les i5 seront des Phenom-killer, qui ne risquent de garder pour eux (mais c'est déjà beaucoup) que leur prix et leur compatibilité AM2.
    Ceci dit je ne suis pas sur que l'AES passionne les foules, comme le dit Neo_13

  15. #75
    Compte pas sur moi pour OC quoi que ce soit avec les températures qu'on a en ce moment
    D'ailleurs l'OS du malin se débrouille mieux que Vista pour scheduler des process, et encore plus sur des processeurs SMT...

  16. #76
    Citation Envoyé par Grosnours Voir le message
    Tiens puisqu'on a un utilisateur de cet OS du malin...

    Tu ne crois pas si bien dire...
    http://ubuntusatanic.org/news/
    Citation Envoyé par pseudoridicule Voir le message
    Bah ouais, tu malaxes et t’avale.

  17. #77
    Merci pour vos réponses,

    J'ai trouvé une update du comparatif incluant entre autres le X4 965 BE (3,4GHz) et le i7 950 (3,06GHz).

    Les écarts de performances dans les benchs où AMD était en tête se réduisent, donc ca doit bien venir de la fréquence.


  18. #78
    Bon puisqu'on peut se servir de ce topic pour poser des questions aux X86ADV, et que je ne suis qu'un simple et humble forumeur moyen (), j'aimerais qu'on m'explique ce que vous pensez de ceci :
    http://www.geoffchappell.com/viewer....nse/memory.htm

    En gros, selon l'auteur les OS 32 bits Microsoft (enfin Vista ici) sont parfaitement capables de gérer au delà de 4Go de mémoire et qu'ils ne le font pas pour une question de "licence".
    Et il a bricolé une version débloquée, qui donne ceci :


    J'en étais resté bêtement à la notion (mes cours d'archi sont loin ne me jetez pas trop de pierres) que 32bits = 4Go d'adressable.

    Encore un énième complot de Redmond découvert ?

  19. #79
    En 32 bits, le système ne peut gérer que 4Go de ram du fait de 2^32. C'est une limite physique. La version débloquée "voit" peut être les 8Go mais ne les utilise surement pas.

    Si en plus la carte vidéo installée embarque 1Go de ram, le système sera limite à 3Go ...

  20. #80
    Citation Envoyé par Madri Voir le message
    En 32 bits, le système ne peut gérer que 4Go de ram du fait de 2^32. C'est une limite physique. La version débloquée "voit" peut être les 8Go mais ne les utilise surement pas.

    Ça c'est vrai. D'ailleurs, une MAJ d'XP et/ou de Vista permettait déjà de voir 4Go (très utile pour vendre son Packard Poubelle à tata Jeanine).

    Si en plus la carte vidéo installée embarque 1Go de ram, le système sera limite à 3Go ...

    Ca c'est faux, ça ne dépend pas de la taille de la mémoire vidéo. A priori c'est 256Mo par CG.
    http://forum.canardpc.com/showthread.php?t=25772

  21. #81
    Citation Envoyé par Madri Voir le message
    En 32 bits, le système ne peut gérer que 4Go de ram du fait de 2^32. C'est une limite physique. La version débloquée "voit" peut être les 8Go mais ne les utilise surement pas.

    Si en plus la carte vidéo installée embarque 1Go de ram, le système sera limite à 3Go ...
    Tu n'as pas lu l'article que j'ai mis en lien....
    Surtout ce screen :


    Quand a ce que tu dis sur la carte graphique de 1Go, c'est en fait faux. Mogluglu avait fait des mesures avec diverses CG (il suffit de regarder dans le gestionnaire de périph la plage mémoire utilisée) et la quantité de mémoire utilisée par une CG ne dépend PAS de sa quantité de mémoire graphique. C'est plus compliqué que cela. La discussion est dans la partie X86ADV, mais j'ai la flemme de chercher ou exactement....

    EDIT : ah ben en fait Frypolar a mis le lien.

    ---------- Post ajouté à 14h53 ----------

    Citation Envoyé par Frypolar Voir le message
    En 32 bits, le système ne peut gérer que 4Go de ram du fait de 2^32. C'est une limite physique. La version débloquée "voit" peut être les 8Go mais ne les utilise surement pas.

    Ça c'est vrai. D'ailleurs, une MAJ d'XP et/ou de Vista permettait déjà de voir 4Go (très utile pour vendre son Packard Poubelle à tata Jeanine).
    Oui et non.
    C'est vrai mais physiquement, autrement dit pour un Pentium II.
    Or ici on parle d'un OS (c'est une entité logique) et tout le matériel actuel est 64 bits (donc capable de traiter au delà de 4Go).

    D'où ma confusion et ma question.

  22. #82
    Il me semble que les noyaux linux serveur peuvent gérer plus de 3gio de ram, et ce en 32bits, me trompe-je ?

  23. #83

  24. #84
    Est-ce quelqu'un a lu l'article au moins ?

    Parce que le PAE il en parle évidemment :

    Physical Address Extension

    Old hands may already have groaned at the preceding heading. The means for a 32-bit operating system to use physical addresses above 4GB was built into Intel’s 32-bit processors well over a decade ago1 and has been supported by Microsoft since Windows 2000. If you haven’t heard of it, or haven’t thought that it applies to Windows Vista, then one reason may be that Microsoft advertises it only as a feature of the server editions such as Windows 2000 Server and Windows Server 2003, and only then for the more expensive levels with names like Enterprise and Datacenter. However, even Windows 2000 Professional can be configured, without contrivance, to access memory above 4GB by using Physical Address Extension (PAE). This is old technology. It’s also widely and deeply misunderstood technology, arguably more than any other in the history of personal computing.

    The essence of PAE is that the 32-bit registers used by 32-bit instructions in a 32-bit operating system do not in practice address physical memory. This is because of very old technology called paging. The 32-bit register holds what is called a linear address.2 The processor translates linear addresses to physical addresses by looking through page tables, which are configured by the operating system. For the 80386 in 1985, each page table entry (PTE) was 32 bits and allowed for a 32-bit physical address. However, there is nothing fundamental to that. What’s fundamental is only that every linear address must either map to a physical address or be not-present. There is no reason at all that the linear and physical address spaces must be the same size. With a suitably different translation algorithm, the physical address space can be as big as Intel wants to allow. This theoretical point, which I expect was appreciated at Intel at least as early as 1985, got its real-world implementation in the P6 family of processors, beginning with the Pentium Pro in 1995. Since then, with only very few exceptions, Intel’s processors that are suitable for running 32-bit Windows all have enough address lines for accessing 64GB of memory and all support a translation algorithm for using all that memory in 32-bit code. PAE is this alternative translation algorithm.

    The practical outcome for 32-bit operating systems in general is that although any one instruction can form addresses for only 4GB of linear address space, those 4GB can be drawn from anywhere in any size of physical address space. For Windows in particular, the design is that the linear address space changes for each process. In 32-bit Windows, a process’s user-mode code is allowed between 2GB and 3GB of linear address space (depending on the increaseuserva boot option), with the remainder of the 4GB being reserved for system-level code. Both 32-bit and 64-bit Windows can use all of physical memory, including above 4GB, but 32-bit Windows can give no more than 3GB to each application.

    The difference between that and the “fully utiltise” in Dell’s fine print seems very fine to me, especially while I don’t have any real-world applications that need (or even use) as much as half a GB for each running instance. Until such software becomes common for ordinary use outside of specialised contexts, this difference from full utility does not of itself justify a rush to 64-bit operating systems—and certainly not of disturbing a working, trusted installation of 32-bit Windows Vista. If you have a program that uses memory by the gigabyte, then upgrading to a 64-bit version of that program to run on a 64-bit operating system is your only path ahead. If your concern is only that the system and all your applications may together use all your 4GB or more, then keeping your 32-bit operating system is at least an option for you—or would be, if Microsoft would provide you with license data to let you use the PAE support that Microsoft has already coded into the product.

    PAE Is An Ugly Hack

    Some commentators seem to have trouble grasping the naturalness of a physical address space that is larger than the linear address space. Perhaps they have been distracted by paging’s historical role as technology for dealing with a shortage of physical memory. Perhaps they have in mind the history of MS-DOS, which was kept alive for many years with ever more ways that programmers might write new code to access ever more memory than the basic 640KB.

    PAE is nothing like that. It is no more a concern to any software than is paging. After all, it is nothing but a variant algorithm for paging. Just as hardly any software is concerned that linear addresses are translated to physical addresses, even less software is affected by how linear addresses are translated to physical addresses. Application-level code and even most system-level code is entirely unconcerned and unaffected. Except for the operating system’s memory manager and for the relatively few drivers that work directly with physical memory, e.g., for such things as Direct Memory Access (DMA), no 32-bit software needs any recoding to benefit from a more-than-32-bit physical address space.

    Even kernel-mode drivers don’t need to know anything specific to PAE, much less be written specially to support it. All that’s required is a general awareness that physical memory addresses may be wider than 32 bits and that accommodation of this comes naturally from following the documentation. Far from being an ugly hack, PAE requires pretty much nothing of anyone. Indeed, to write a driver whose faults will be exposed by PAE, you actually have to work at it.

    When working with physical memory addresses, device drivers need to do 64-bit arithmetic. This should be natural to them since Microsoft’s development kit for device driver programming has recommended it for well over a decade, including to define a 64-bit PHYSICAL_ADDRESS type for all functions that receive or return physical memory addresses.

    For the particular matter of working with DMA, device drivers need to conform to the long-documented functional requirements for setting up and managing their DMA transfers. In particular, they need to be aware that the DMA functions may succeed only partially, and need to be called again to complete the request. The most significant, but not the only, reason for partial success is that the necessary double buffers could not all be set up. Double buffering is a technology for when a device cannot handle the full range of possible physical memory addresses. For instance, an old type of device (such as a floppy disk drive controller) may be limited to 24-bit physical addresses. To get data from the controller to physical memory above 16MB, the driver must use the DMA functions properly, so that the controller actually reads to a double buffer below 16MB and the DMA functions then copy the data to where it was wanted. Of course, most devices can handle 32-bit physical addresses and increasingly many can handle 64-bit addresses. Some drivers for 32-bit Windows assume that since all physical addresses fit 32 bits, their 32-bit device needs no double buffering. They then take shortcuts with their use of the DMA functions, especially to skimp on handling failures or partial successes. If these drivers are not fixed, then the use of physical memory above 4GB will expose the liberty that they have taken with the documented coding model. Note that if the device can handle 32-bit physical memory addresses but not 64-bit, then its driver needs to be fixed for 64-bit Windows, too.
    PAE and Performance

    Some commentators say that PAE comes with some hideous cost in performance. Compared with the original algorithm that maps 32-bit linear addresses to 32-bit physical addresses, PAE is slower. It has one extra level to its page tables. Each PTE is twice as big. The operating system therefore has more work to do when preparing and maintaining the page tables, and since the Translation Lookaside Buffer (TLB ) has only half the capacity, memory references are more likely to miss the TLB and require additional bus cycles. The reduction in performance is surely measurable. If you have no need to access memory above 4GB and are concerned enough, then you would not enable PAE. Note however that Microsoft itself does not regard this performance cost as worth troubling over (as will be clear shortly, under the heading Data Execution Prevention).

    Anyway, for access to memory above 4GB, the appropriate comparison is not between using PAE and not, but between using PAE and using the native 64-bit algorithm. For this comparison, not only are the PTEs the same size but the algorithms are very similar. To the processor, it’s PAE that is slightly simpler and plausibly quicker, but the memory manager in a 64-bit operating system can benefit from using 64-bit registers when working with the PTEs. These are very fine trade-offs relative to the enormous overheads that embellish some of the wilder misunderstandings of PAE on the Internet.

    For a rough-and-ready assessment of these trade-offs, consider Microsoft’s own performance measurement, as given by the Windows Experience Index. Surely this is meant to have some objectivity, even if comparison of ratings for 32-bit and 64-bit Windows may not be strictly fair. On this article’s test machine, the “Memory (RAM)” component of the Windows Experience Index is consistently 5.0 in 64-bit Windows Vista and is just as consistently 5.1 in 32-bit Windows Vista, even with PAE and the use of memory above 4GB.
    Choosing PAE

    Whether the memory manager in the Windows kernel uses PAE is configurable through the pae boot option. Indeed, 32-bit Windows Vista is supplied with two kernels:

    * an ordinary kernel which uses 32-bit PTEs without PAE, and has no code for working with physical addresses above 4GB;
    * a PAE kernel which uses 64-bit PTEs with PAE, and does have code for working with physical addresses above 4GB.

    The two kernels are respectively NTOSKRNL.EXE and NTKRNLPA.EXE, both in the Windows System directory. The loader (WINLOAD.EXE) knows how to set up the linear address space for mapping to physical addresses with or without PAE, but each kernel is specialised to one algorithm for the mapping. The pae option tells the loader which kernel to load.
    Data Execution Prevention

    If you have a modern machine of the sort that manufacturers are fitting with 4GB of RAM, then you very likely are running the PAE kernel already. This is not so that you can benefit from PAE and use physical memory above 4GB, else this article would not exist. It is instead to give you what Microsoft calls Data Execution Prevention (DEP). This protects you from programs that try to execute data, whether in error or from (suspected) malice. The connection with PAE is that DEP depends on the Execute Disable bit that Intel has defined in 64-bit PTEs, such that DEP can only be enabled if PAE is also enabled. Because Microsoft wants you to benefit from DEP, the typical practice of Windows Vista is to select the PAE kernel if you haven’t specified that you want it and even if you have specified that you don’t want it. (If your machine supports DEP, then a necessary condition for disabling PAE is that you also disable DEP by setting nx to AlwaysOff.)

  25. #85
    Je ne comprends pas ta question alors. Le PAE te permet d'avoir 36-bit d'adresse. Si ton OS supporte le PAE, alors il pourra utiliser ces 36 bits. En revanche comme les adresses des processus restent sur 32 bits, un seul processus ne pourra jamais accéder plus de 4 Go (moins ce qui est réservé par l'OS). Ca explique ce qu'on voit sur le Task Manager (8 processes de 1 Go) et devrait expliquer pourquoi ce que tu disais :
    J'en étais resté bêtement à la notion (mes cours d'archi sont loin ne me jetez pas trop de pierres) que 32bits = 4Go d'adressable.
    N'est pas tout à fait juste, ni tout à fait faux

  26. #86
    La question n'est pas vraiment sur la technique (comme tu le dit le PAE s'en charge), mais plutôt sur le fait que Vista 32 est tout a fait nativement capable de supporter plus de 4Go de RAM, et que c'est une fonction qui est désactivée par Microsoft pour une question de licence. Pour moi c'est une nouvelle.

    Ce qui signifie que l'équation RAM>=4Go -> OS 64bits est complètement fausse pour Vista32.

  27. #87
    Ha OK, tu t'étonnes juste que MS bride ses OS pour refourguer des versions plus chères

  28. #88
    Certes on peut adresser plus de 4Go avec le PAE, mais les processus sont toujours limités à 2Go de mémoire (3 en trifouillant). Avec un OS 64bits, ça passe à 4Go.
    D'ailleurs, quel est l'intrêt de se poser la question quand la version de Vista 64bits coute le même prix que la version 32bits et que Seven sera fourni avec les DVD des 2 versions ?

    Il faut passer en 64bits. On se traine le 32bits depuis trop longtemps.

    Donc le PAE du 32bits est déjà obsolète.

    Mes Lego - Tof : Canon EOS 40D + Tamron 17-50mm F/2.8 + Canon Seepdlite 430 EX II | VDS MadCatz Arcade Fight Stick TE

  29. #89
    Citation Envoyé par PrinceGITS Voir le message
    Avec un OS 64bits, ça passe à 4Go.
    Hu ? Tu veux dire que Vista 64 et/ou Seven 64 ne peuvent avoir des processus de plus de 4 Go

  30. #90
    Citation Envoyé par newbie06 Voir le message
    Ha OK, tu t'étonnes juste que MS bride ses OS pour refourguer des versions plus chères
    Citation Envoyé par PrinceGITS Voir le message
    Certes on peut adresser plus de 4Go avec le PAE, mais les processus sont toujours limités à 2Go de mémoire (3 en trifouillant). Avec un OS 64bits, ça passe à 4Go.
    D'ailleurs, quel est l'intrêt de se poser la question quand la version de Vista 64bits coute le même prix que la version 32bits et que Seven sera fourni avec les DVD des 2 versions ?

    Il faut passer en 64bits. On se traine le 32bits depuis trop longtemps.

    Donc le PAE du 32bits est déjà obsolète.
    Non.
    Ce que tu racontes est inexact.
    Et c'est bien la tout le problème, tout le monde, moi compris pensait que c'était exact.

    Je m'explique.
    D'après cet article, Vista 32 est capable de reconnaitre bien plus que 4Go de RAM et d'utiliser 3Go/process.
    Or qu'apporterait passer a Vista 64 ?
    Uniquement être capable d'utiliser 4Go/process, soit 1Go de plus utilisable par thread, et c'est tout.

    Un gain bien peu important pour la plupart des applis, il n'y a guère que les softs de montage ou de retouche (et les jeux avec un memory leak ) qui peuvent utiliser autant de mémoire par thread.

    Conclusion : est-ce que cela vaut le coup pour le particulier moyen (possédant 4Go ou plus) de passer a Vista64 ?
    Non, absolument pas, en tout cas dans un monde ou Microsoft n'aurait pas bridé volontairement son OS.

    Citation Envoyé par newbie06 Voir le message
    Hu ? Tu veux dire que Vista 64 et/ou Seven 64 ne peuvent avoir des processus de plus de 4 Go
    Oui, en effet, mais pour des process 32 bits.
    Source:http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

    Pour les process 64 bits, c'est bien 8 To.


    Bon sinon je vous trouve bien indiffèrent envers cet article qui bat en brèche deux vérités fort communément admises et qu'on ne cesse de rappeler ici même a tout vent :
    - les OS 32bits (ici le cas particulier de Vista32) ne peuvent "voir" plus de 4Go de RAM
    Bullshit

    - Il faut absolument passer a un OS 64b pour profiter de plus de 4Go de RAM
    Bullshit encore

    Bien sur tout cela reste théorique car dans la pratique ces deux phrases sont bien exactes, mais quand même découvrir que je raconte des conneries depuis un certain temps, cela me fait son petit effet,au moins je ne me coucherais pas idiot ce soir....

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •