Position d'Intel sur les processeurs 64 bits grand public

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes : aucune
0
22
fév.
2003
Matériel
"Comme vous le savez déjà (peut-être), AMD devrait être en septembre prochain le premier fabricant à proposer un processeur 32 / 64 bits grand public avec l'Athlon 64.
[...]"

NdM : j'ai coupé le message, car c'est une recopie d'une news de Clubic.com Clubic.com : "Intel et le 64 bits grand public" Publié le 21/02/2003 par Vincent

Cette news était une recopie avec quelques changements mineurs d'une news publiée sur Clubic. Nous n'acceptons pas ce type de news d'habitude, mais il nous est difficile de tout vérifier. Toutes nos excuses à Clubic.

Message aux rédacteurs de news : rédigez un minimum vos dépêches, évitez à tout prix la recopie, et même fouillez un peu plus loin, pour enrichir la brève, c'est assez facile.

Merci Berretta_Vexee

Aller plus loin

  • # Re: Position d'Intel sur les processeurs 64 bits grand public

    Posté par  . Évalué à 10.

    C'est quoi ce copier/coller de la bréve de Clubic.com ?

    http://www.clubic.com/n/n7984.html(...)
  • # Re: Position d'Intel sur les processeurs 64 bits grand public

    Posté par  . Évalué à 2.

    Hum, je me souviens qu'il y a 5 ans je discutais avec un représentant Intel, je lui avais demandé quand Intel passerait sur des technologies RISC. Sa réponse : Jamais le RISC c'est dépssé le CISC est bien plus performant etc....

    Le fait qu'il ne souhaite pas faire des processeurs 64 bits ne m'étonne qu'a moitié, ils doivent amortir leur derniers processeurs.

    AMD a une maintenant une opportunité de gagné des parts de marché. Mais le soucis restera toujours les logiciels qui ne sont pas à recompiler comme les antivirus pour les serveurs de messagerie. Cela restera du 32 bits malgré la pseudo compatibilité j'attend de voir.

    Sinon il y a les futur PowerPC G5 ainsi que les Sparc et HPPA-RISC.

    wait and see.

    Je me souviendrait toujours du PII porté par un escargot dans la pub Apple.
    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

      Posté par  . Évalué à 10.

      Parlant du G5, d'après les rumeurs, il devrait être annoncé en juin/juillet.
      Ca ne parait pas important comme ça, mais si c'est le cas, cela empecherait de dire qu'AMD est le premier à proposer un 64Bits grand public, et enleverait une part de "prestige" dont AMD à bien besoin pour contrer Intel, coté grand public justement.
      De plus, je vous rappel cette news sur Hardware.fr :
      http://www.hardware.fr/html/news/?date=26-01-2002#4454(...)
      qui à été suivi d'autres news confirmant le fait que l'architecture 32bits devrait être utilisé jusqu'en 2008, soit jusqu'au fameux p8
      http://www.hardware.fr/html/news/?date=04-10-2002#5207(...)
      ce qui pourrait confirmé un tel projet.
      Encore une pour la route :
      http://www.hardware.fr/html/news/?date=15-11-2002#5337(...)

      Comme quoi, Intel n'est pas aussi stupide qu'il le laisse penser. Il laisse juste les autres prendre la température du marché.
    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

      Posté par  (site web personnel) . Évalué à 8.

      AMD a une maintenant une opportunité de gagné des parts de marché.

      Tout a fait d'accord !!
      Mais à mon avis, aussi bien pour Intel que AMD, le 64 bits pose des gros problèmes :
      - au niveau technologique (comment faire le moins cher, le plus performant et compatible avec le 32 bits)
      - au niveau commercial (est-ce que ça va plaire au grand public ?)

      Car bon, ça fait longtemps que AMD nous promet un 64 bits quand même...
      Et oui : http://linuxfr.org/2002/05/13/8232.html(...) , en mai 2002, il était annoncé pour octobre 2002 !!... (on prend les mêmes et on recommence ?)
    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

      Posté par  . Évalué à 1.

      AMD a une maintenant une opportunité de gagné des parts de marché. "une occasion de gagner des parts de marché" (sinon c'est un anglicisme) Mais le souci restera toujours les logiciels qui ne sont pas à recompiler comme les antivirus pour les serveurs de messagerie Je n'ai pas compris ta phrase, en quoi c'est un souci s'il n'y a pas à recompiler ?
      • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

        Posté par  . Évalué à 5.

        les performances, le fait de garder une compatibilité avec le 32 bits ne permet pas d'obtenir des performances identiques à du 64 bits natifs. Le fait d'avoir une compatibilité entre le 32 et le 64 permet pendant un temps de combler le manque de logiciel optimisés pour le 64 bits. Dans le cas de Linux, le problème sera vite oublié, mais je pense plutôt au logiciel un peu plus propriétaire comme oracle, db2, les antivirus. Apple a connu le problème il y a 5 ans avec la transition du 68040 vers les Power PC (CISC vers RISC) ou pas mal d'utilisateur se plaignait du manque de logiciels optimisés. Apple a du faire pas mal de refonte dans son OS pour que cela marche. Le soucis va rester qu'il n'y a pas que GNU/Linux ou les LL comme utilisation sur cette plateforme. Donc je me demande comment va faire AMD pour réussir à vendre sa plateforme et avoir suffisament de logiciels pour valoriser son architecture.
        • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

          Posté par  . Évalué à 4.

          Apple a connu le problème il y a 5 ans avec la transition du 68040 vers les Power PC (CISC vers RISC) ou pas mal d'utilisateur se plaignait du manque de logiciels optimisés.

          Ce n'est pas le problème. Le code 68000 était émulé par le PowerPC. Le 32 bits tourne en natif sur le futur CPU AMD (et il est censé tourner aussi vite que sur un Athlon actuel).

          Dans le cas de Linux, le problème sera vite oublié, mais je pense plutôt au logiciel un peu plus propriétaire comme oracle, db2, les antivirus.

          C'est une obsession, les antivirus ? :-))
        • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

          Posté par  . Évalué à 0.

          Dans le cas de Linux, le problème sera vite oublié, mais je pense plutôt au logiciel un peu plus propriétaire comme oracle, db2, les antivirus.

          Décidément, tu y tiens à ton anti-virus. Dans ton commentaire précédent, je croyais que c'était une taquinerie, vu le peu d'utilité des anti-virus (à part enrichir quelques sociétés qui ne vivent que de ça). Surtout que je ne pense pas qu'un anti-virus soit limité par le CPU.

          Je suis souvent sous Windows NT au boulot, et j'ai désactivé l'anti-virus (contrairement à la politique de ma boîte) car il prend de la mémoire et ralentit aussi la machine. Je ne fais aucune manipulation qui me permettrait de récolter un virus (je n'ouvre pas d'exe et je n'ai pas Outlook), et je n'en ai jamais eu.

          Par contre, concernant une base de données, la recompiler pour de meilleurs performances me semble beaucoup plus utile et nécessaire.
          • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

            Posté par  . Évalué à 0.

            vu le peu d'utilité des anti-virus (à part enrichir quelques sociétés qui ne vivent que de ça). Surtout que je ne pense pas qu'un anti-virus soit limité par le CPU.

            Travaillant chez un herbergeur et FAI, je me vois mal dire à mes clients : désolé l'antivirus cela ne sert à rien sauf à engraisser les sociétés éditrices. Nimda, klez c'est vrai moi ça m'a fait rire mais pas ceux qui se sont fait infectés.
            Soit un antivirus n'est pas limité par la cpu, mais analyse plusieurs centaines de mails par secondes avec les pièces jointes volumineuses on en rediscutera après de ta cpu.

            Et non ce n'est pas une obsession les antivirus, mais j'avais proposé à un responsable de passer sur des power pc pour les performances. Car nous manquions cruellement de puissance sur les traitements de mails avec l'antispam et l'antivirus.

            L'un des motif de refus fut le manque de binaires natifs. En effet GNU/Linux est disponible sur une quantité d'architecture mais certains logiciels commerciaux disponible pour GNU/Linux ne le sont et seront que pour IA32 du moins pour le moment.

            A ceci on peut rajouter aussi dans les softs propriétaires :
            - SGBDR : ORACLE, DB2...
            - Sauvegarde : Arkeia, TINA
            - Serveur Web : websphere, weblogic

            Donc à mon avis, le fait d'avoir l'AMD en 64 bits c'est bien mais avoir des binaires optimisés pour cette architecture cela sera au poil. Un cluster de 64 bits ou du SMP donnerait des performances sympathique. Mais avant de s'avancer sur des hypothétique performance j'attend de voir la bête pour me faire une opinion.

            En attendant je n'acheterais pas cette architecture si cela ne me sert qu'a faire tourner des softs en 32 bits.
            • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

              Posté par  . Évalué à 1.

              Et non ce n'est pas une obsession les antivirus, mais j'avais proposé à un responsable de passer sur des power pc pour les performances. Car nous manquions cruellement de puissance sur les traitements de mails avec l'antispam et l'antivirus.

              L'un des motif de refus fut le manque de binaires natifs.


              T'as eu de la chance qu'ils aient refusé, parce qu'un PowerPC se fait torcher par les processeurs IA32 actuels...
            • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

              Posté par  . Évalué à 2.

              Travaillant chez un herbergeur et FAI, je me vois mal dire à mes clients : désolé l'antivirus cela ne sert à rien sauf à engraisser les sociétés éditrices. Nimda, klez c'est vrai moi ça m'a fait rire mais pas ceux qui se sont fait infectés.

              Tes clients veulent avoir un anti-virus chez leur hébergeur, et pas chez eux sur leurs PC ? Ou au moins ils pourraient mettre cet anti-virus sur la passerelle entre leur réseau interne et le reste du Net. Et je dirais à mes clients qu'en évitant certaines pratiques, on n'a pas de problème de virus. Je sais bien que le client est roi mais rien n'interdit de lui donner des conseils de bon sens, surtout si on lui fait faire des économies.

              Cela dit, je ne vois pas en quoi un anti-virus agit contre Nimda vu que Nimda est surtout un vers. Nimda infecte les serveurs Web en les attaquant directement, et génère un gros trafic Web (mes serveurs Linux ont pas mal loggué de tentatives).

              Et pour finir, je pense qu'un anti-virus ne sert souvent à rien car ce qui est dangereux ce sont les nouveaux virus, et ceux-là par définition ton anti-virus ne les connaît pas.

              Soit un antivirus n'est pas limité par la cpu, mais analyse plusieurs centaines de mails par secondes avec les pièces jointes volumineuses on en rediscutera après de ta cpu.

              Dans ce cas, je te l'accorde.
              • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                Posté par  (site web personnel) . Évalué à 2.

                Cela dit, je ne vois pas en quoi un anti-virus agit contre Nimda vu que Nimda est surtout un vers. Nimda infecte les serveurs Web en les attaquant directement, et génère un gros trafic Web (mes serveurs Linux ont pas mal loggué de tentatives).

                si si...
                l'anti-virus sert !

                car en fait, nimda utilise effectivement une faille de sécurité (corrigée) de IIS.
                mais dès qu'il commence à rentrer sur le serveur, il se met sur le disque dur...

                donc l'anti-virus l'analyse (comme tous les fichiers ajouter/modifier) et hop, il le supprime !
                (c'est pas du bidon, c'est du vécu)

                après, si tu veux le bloquer avant même l'infection, c'est au rôle du firewall de faire ça !
            • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

              Posté par  (site web personnel) . Évalué à 4.

              Oracle et DB2 sont de mauvais exemples d'applis 32 bits. Ca fait longtemps que ces applis tournent en 64 bits sur Alpha, Sparc, MIPS et IBM Power.

              Donc, si le CPU AMD devenait vraiment disponible sur des machines d'entreprise, je pense que Oracle ne mettrait pas longtemps à apparaitre pour cette plateforme.

              A noter que le problème d'AMD en entreprise avec ses gammes actuelles, ça n'est pas tellement un problème de CPU mais plutôt de cartes mères.

              Regardez les gammes de serveurs x86 rackables chez Compaq/HP, Dell ou IBM. Vous en voyez beaucoup avec de l'AMD ? Non. On ne trouve quasiment que les cartes mères sur chipset Intel ou Serverworks.

              Si AMD ne corrige pas ce problème, les AMD 64 bits ne décolleront pas en entreprise.
    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

      Posté par  (site web personnel) . Évalué à 1.

      > Je me souviendrait toujours du PII porté par un escargot dans la pub Apple. URL !!! URL !!! URL !!!
    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

      Posté par  . Évalué à 0.

      Attention, Intel fait du RISC! c'est la puce I960 (je crois ) sur une bonne partie des cartes RAID ...

      quand au 64 bit, j' y crois pas encore, lorsqu'on aura plutot une architexture plus sioux (avec des bus et des perifs vraiement performant), , la, on pourrait exploiter les performance du 64 bits .
      • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

        Posté par  . Évalué à 0.

        Bien sur qu'Intel a fait du RISC... dans l'embarqué, comme le i960 que tu cites, et un des predecesseurs, mort-né, de l'itanium. Sauf qu'ils n'ont jamais fait d'étincelles avec, comme quoi ça doit être une question de culture...
        • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

          Posté par  . Évalué à 1.

          Ce sont de trés bonnes cartes RAID quand meme..
          Je crois que l'histoire c'est que INTEL voulais changer d'architecture mais que MICROSOFT ne voulais pas car trop compliqué à développer dessus.....

          J'aime les réflections disant que l'architecture PC c'est de la m...e mais les meme qui font cette réflection l'utilise (je suis dans le meme cas)...
          Dites moi pourquoi l'ALPHA est elle morte alors que c'était théoriquement la meilleur du marché à l'époque (RISC 64 bits!!!)..
  • # Re: Position d'Intel sur les processeurs 64 bits grand public

    Posté par  (site web personnel) . Évalué à 10.

    640 Kb should be enough for anyone
    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

      Posté par  (site web personnel) . Évalué à 5.

      ... et puis internet ça marchera jamais, pas la peine d'investir la-dedans
    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

      Posté par  . Évalué à -2.

      Intel dit que le 64 bits c'est pour 2008 au plustôt. Intel ne dit pas jamais.
      • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

        Posté par  (site web personnel) . Évalué à 2.

        Le rachat des ingénieurs Alpha (DEC) de Compaq leur aura permis de l'annoncer pour 2008 et non 2015 ou quoi?
        Je me demande vraiment si Intel se moque de nous ou pas. Les processeurs 64 bits existent depuis près de 10 ans pour les grandes machines. On ne va pas m'expliquer qu'en dix ans où on est passé de maigre 386 au puissant de la mort qui tue la vie P4 on n'a pas été foutu de réduire les coûts de production des 64bits pour le rendre grand public, qui n'est autre chose que "à prix abordable".
        Bon c'est vrai que l'Itanium 1 c'était un véritable escargot et qu'ils ont dû vraiment l'améliorer pour qu'un puisse l'utiliser à d'autres fins que de dépense inutilement de l'argent.
        Entre nous, avec les logiciels libres, puisqu'on a accès au code source, on se fout un peu de la compatibilité binaire qu'Intel nous revend depuis le i386. Si j'avais besoin d'une platteforme 64 bits, c'est avec plaisir que je tournerais vers sparc ou alpha. Le x86 y'en a vraiment plus besoin.
        • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

          Posté par  . Évalué à 4.

          Faut replacer le contexte. Intel estime que le 64 bits n'est pas une priorité pour le grand public. Il n'a pas vraiment tort. Qui ici a besoin d'un système 64 bits ? Qui utilise pour son PC perso plus de 4 Go de mémoire vive ? Passer de 32 à 64 bits, çà bouffe plus de mémoire et plus de place disque. Je ne suis pas convaincu que le marché grand public a envie d'avoir des pc plus cher uniquement car le CPU est passé de 32 à 64 bits et que çà lui (le grand public) sert à rien. Et 2008 ce n'est pas loin ...
          • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

            Posté par  (site web personnel) . Évalué à 0.


            "Passer de 32 à 64 bits, çà bouffe plus de mémoire et plus de place disque."

            Tu pourrais préciser s'il te plait ? Parce que là, avec mes connaissances actuelles de l'architecture des PC et de Linux, je ne suis pas d'accord. Mais peut-être ai-je manquer un wagon ?
            • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

              Posté par  . Évalué à 5.

              bas le monsieur par du principe que:
              Sur une architecture 32Bits classique le plus petit block mémoire fait 32Bits et que donc sur une architecture 64Bit celui-ci fera 32Bits.
              Et que donc un simple int prendra la méme place en mémoire qu'un quad word ( 2 Double ).
              Hors rien n'est moin sur vue que c'est un processeur 16/32/64 au quel on aura affaire, le passage du bus de 16 a 32Bit avec le 386DX, n'a pas fait exploser la consomation mémoire, je ne vois pas pourquoi cela serait le cas avec le passage de 32 a 64bit, dans le cas d'un processeur purement 64Bit cela aurait été different.

              Pour l'espace disque je comprends pas trop moi méme, mais peut étre par t'il du principe que les cluster seront de 64Bits aussi, ce qui est un peut ridicule vue que sur n'importe quel systéme avec de gros capacité les cluster font déjà souvent plus de 64Bits mais bon ...

              Apres pour ce qui dise que le 64Bit est sans interet sortit de l'addressage mémoire qui passe la barre des 4Go, c'est un peut reducteur, la bande passente mémoire va sacrement augmenté et ce méme pour les applications 32bit si le processeur gére bien le tout, de plus le domaine de la video, de la 3D et du multimedia en general font déjà largement usage du MMX et SSE, ce qui prouve bien qu'il y a bien une utilité a des operations sur 64 voir 128bits.

              Je pence d'aillieur qu'on peut tout affait rapprocher le x86-64 du MMX et du SSE, tout le monde reniait leur utilisé au debut et maintenant ils sont trés largement addopté, de plus le x86-64 apporte des inovations nettement plus importante que le MMX et SSE
              • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                Posté par  . Évalué à 1.

                > le passage du bus de 16 a 32Bit avec le 386DX, n'a pas fait exploser la consomation mémoire Car c'est le bus. Il y avais des 68000 avec un bus de 8 bits :-) et ça ne diminuait pas le mémoire utilisée. Par contre, c'est moins rapide (4 opérations pour lire ou écrite un int). > Pour l'espace disque je comprends pas trop moi méme Simple. Prend un librairie partagé. Par exemple, dans la librarie, les adresses des fonctions seront stockées sur 64 bits et non 32 bits (sinon c'est du 32 bits). Enfin, il ne faut pas confondre les adressess utilisées par les programmes (Linux sous i86 c'est 32 bits) et les adresses utilisé par le noyau. Linux sous i86 peut géré 64 Go et chaque programme prend au plus 4 Go (ou 2?). > la bande passente mémoire va sacrement augmenté et ce méme pour les applications 32bit Le bus mémoire des pendium II, athlon etc... est déjà de 64 bits.
                • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                  Posté par  . Évalué à 2.

                  En fait les cartes nForce sont déjà en 128Bits et normalement l'Hypertransport devrait étre a 256Bits, donc oui c'est pas en relation directe avec les 64Bits ( quoi que le controleur mémoire est en partie integré au CPU avec l'Opteron et l'Athlon 64 ), mais il y a bien gain de Bande passante mémoire. Quand a l'espace mémoire je crois que nos pauvre disque de plusieurs dizaine de giga pourront supporter le surcout de quelque octets des libraries partagés. P.S. 386SX 16->32Bits 386DX 32->32Bits méme chose avec les 486SX
                  • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                    Posté par  . Évalué à 1.

                    > En fait les cartes nForce sont déjà en 128Bits On ne parle pas de la même chose ici. une nForce dite 128Bits, c'est la taille du mot du cpu. Mais pas les capacités d'adressage. En 32 bits il y a déjà 4 Go! C'est beaucoup pour une carte graphique. Donc 128Bits d'adressage c'est totalement inutil. Pour un OS, on parle de capacité d'adressage en général. D'ailleur on peut avoir un OS 64 bits avec un int à 32 bits (C'est le cas avec Alpha, OSF1 et DEC UNIX 3 et 4 (pas testé true64)). C'est-à-dire que l'adressage à 64 bits et que la taille naturel d'un mot est de 32 bits. > mais il y a bien gain de Bande passante mémoire. C'est à cause du bus de donnée. Les bus de données des PIII, athlon etc... sont déjà en 64 bits. Le bus de donnée est indépendant de l'adressage et de la taille d'un mot. Le passage de 32 à 64 bits de l'adressage des cpu ne va pas améliorer sa bande passage. Car on peut avoir un bus de donnée de 8 bits avec un bus d'adressage de 64 bits et un mot (le int) à 64 bits. C'est le bus de données qui compte pour la bande passante. Enfin, avoir un mot (le int) à 32 bits (et même un os et un adressage de 32 bits) ne veut pas dire que le cpu ne peut pas traiter efficacement du 64 bits. D'ailleur sous GNU/Linux i86 avec gcc on a des entiers de 64 bits (long long) et des flottants de 96 bits (long double) mais toujours les pointeurs à 32 bits. Le gros intéret d'os Linux 64 bits, c'est l'adressage mémoire. Quelqu'un qui possède un itanium (ia64) peut nous dire quelle est la taille d'un int sous Linux. Je ne serait pas étonnée qu'elle soit toujours de 32 bits.
                    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                      Posté par  . Évalué à 1.

                      1) le nForce est un chipset de type north gate, c'est a dire un controleur mémoire assez courant sur les cartes méres pour athlon XP et non une carte graphique ( http://www.nvidia.com/view.asp?PAGE=nforce(...) ). Je fesais reference a son bus de donnée qui est sur 128Bits et non a son bus d'addressage.
                      Le fait est que l'Opteron et l'Athon 64, ne sont pas qu'un simple extention du x86 avec un bus et des registres sur 64Bits, mais integres aussi pas mal d'inovation comme le controleur hypertransport qui permet des echanges sur 256Bits.

                      2) un traitement 64Bits sur un processeur 32Bit prendra toujours 2 fois plus de cycle que sur un processeur 64Bits, que ce soit bien supporté ou pas.

                      3)Le gros intéret d'os Linux 64 bits, c'est l'adressage mémoire.
                      Oui mais la on parle de processeur, et l'Opteron et Athlon 64 apporte un peut plus que l'addressage 64Bits, et je pence que GCC ne crachera pas sur quelques registre en plus et un cache plus large et plus rapide.
                      De plus je suis percuadé qu'il y bon nombre d'applications qui peuvent beneficier d'un traitement sur 64Bit, que ce soit en matiére de graphisme, de video ou de la 3D, ( 3 domaine ou de plus l'assembleur a encore sa place et son mot a dire, des filtres on l'on pourrait traiter 2 pixel a la fois etc etc ...), sans parler des applications qui manipules de grands nombres comme le cryptage ou les calculs scientifiques, ( méme si le gain est pas de l'ordre de 100% il est tout de méme enorme ).

                      De plus des algos sur 64Bits existe mais faute d'architecture populaire en 64bits ils sont sous exploités, je pence par exemple au Tiger Hash, qui déjà plus rapide que le SHA1 et MD5 sur un cpu 32Bit ecrase tous sur un 64Bits.
                      • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                        Posté par  . Évalué à -1.

                        > le nForce est un chipset de type north gate

                        Ooops. J'ai pris ça pour la "nouvelle GForce"... des divagations.

                        > 2) un traitement 64Bits sur un processeur 32Bit prendra toujours 2 fois plus de cycle que sur un processeur 64Bits, que ce soit bien supporté ou pas.

                        Pour un cpu avec des registres de 32 bits ok. Si tu as des registres de 64 bits c'est différent. Un IA-32 moderne qui bosse sur des 'double float' n'est pas plus lent qu'un cpu dit 64 bits (sinon il y aurait pléthore de bench le montrant). D'ailleur un athlon a un bus de 64 bits et quelques registres de 64 bits.

                        Je ne dis pas que tu as tord mais je trouve que ce n'est pas évident.
                      • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                        Posté par  . Évalué à 0.

                        des filtres on l'on pourrait traiter 2 pixel a la fois

                        Suffit d'utiliser le MMX.
              • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                Posté par  (site web personnel) . Évalué à 1.

                c est clair que un proc 128 pourrait manipuler en une seule operation un pixel RGB 32 bits ... vu que l on fait souvent le meme traitement aux 3 couleurs, ca pourrait sacrement booster :=) (si le proc est cpable de faire le meme traitement en meme temps sur 4 champs du meme registre ... ) Enfin c est ce que j apperceois avec mes faibles conaissnces en la matiere ... ( C, HP48, 68000 ... )
                • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                  Posté par  . Évalué à 5.

                  c est clair que un proc 128 pourrait manipuler en une seule operation un pixel RGB 32 bits

                  Le RGB 32 bits, c'est 8 bits par composante plus éventuellement 8 bits pour l'alpha, donc 32 bits en tout (et non 32 bits par composante). C'est à ça que sert le MMX (avec les cosmonautes qui dansent le funk en tapant sur des tambours).
              • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                Posté par  . Évalué à 0.

                he ho !

                j'en suis encore à 192Mo de mem et 256 de swap sur un PII :))

                doucement les amis, je suis d'accord avec Intel là, faut pas se presser. On sera obligé de passer au 64bits uniquement pour la course à la puissance, et ça c'est quand on ne pourra plus ou difficiliement monter en vitesse pure et miniaturisation.

                Moi aussi au cpu 64bits ça me botterai juste pour le côté techno ( j'ai toujours rêvé d'avoir un Alpha ou un Sparc à la maison :)),
                mais sinon l'utilité est restreinte pour le moment. Je n'ose même pas imaginer ce qu'on peut faire avec un Athlon XP ou un PIV, alors au proc 64bits .... :-/
            • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

              Posté par  . Évalué à 6.

              Et bien c'est simple si tu genere ton application en mode 64 bit sans qu'elle en ait vraiment besoin, la place mémoire/disque utilisé par ton application va grossir légerement: il faut plus de place pour stocker une adresse mémoire sur 64 bit que sur 32 bit (oui je sais c'est une lapalissade).

              Plus de place --> occupation disque et mémoire supérieure, mais surtout efficacité des caches diminuée.

              De plus, si tu utilise des mots sur 64 bits sans que cela soit nécéssaire tu perds en performance aussi car les calculs prenne plus de temps.

              Certes si tu besoin de faire des calculs avec des valeur sur 64bit alors la tu gagnes beaucoup, mais a l'heure actuelle le besoin n'est pas énorme.

              AMD est malin: dans leur mode 64 bit, ils ajoutent 8 autres registres ce qui peut aider grandement les 80x86 avec leur nombre ridiculement faible de registres autrement le mode 64 bit par lui-meme tant que tu n'as pas plus de 4 Go de RAM, bof!
              • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                Posté par  . Évalué à 0.

                Exellente réponse.
                Ajoutont à celà les possibles (j'ai pas vérifié) problèmes d'alignement s'il sont fait sur 8 octets contrairement à 4 comme actuellement. Au pire on peut avoir :
                char titi ; // 7 octets de perdu
                int toto ;

                contre :
                char titi ; // 3 octets de perdu
                long toto ;
                • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                  Posté par  (site web personnel) . Évalué à 1.

                  > lus de place --> occupation disque et mémoire supérieure, mais surtout efficacité des caches diminuée. A mon avis dans un CPU hybride 32/64 c est justement ca qui doit etre bien etudie : ne pas laisser une apli 32 utiliser les 64 bits du registre, ou alors au moins rendre les 32 bits inutilises non-signifatifs, et ne pas les transferer lors des ecritures memoires, sinon , par ce que si un CPU hybride 32/64 se contente de supporter les opcodes 32 bits, je vois vraiment pas l interret ... donc question pertes de memoire, je doute un peu ... idem pour le spb d alignements ... Féliciano tu parles des caches en tant que "convertisseur" ( transformation d un format vers un autre ) , ou comme "memoire tampon" ? Dans le premier cas, un convertisseur prendra justement soin d economiser la memoire, et de ne transfere que les bits significatifs ! Dans le second, ben je me tais et je pris pour qu il y ait quand meme un convertisseur :=) -- doublehp apt-get remove ispell
                  • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                    Posté par  . Évalué à 1.

                    Il n'y aura pas une appli qui tourne parfois en 32 bits et parfois en 64 bits. C'est soit tout l'un ou tout l'autre pour des raisons évidente d'édition de lien. On ne peut pas faire l'édition de lien d'un .o avec sizeof(void *) = 4 et d'un autre avec sizeof(void *) = 8. Image "titi = toto ;" avec titi (void *) d'un .o 32 bits et toto (void *) d'un .o 64 bits. Notes que ça implique d'avoir une libc 32 bits et une 64 bits pour faire tournée des programmes 32 bits ou 64 bits. > et de ne transfere que les bits significatifs ! Ça ne change rien. imagenons en 0x1000 qu'il y a : 0x 00 00 00 00 00 00 00 01 Le cache pour s'avoir qu'il y a cette valeur doit allé lire les 8 octets. Il ne peut pas préssuposer qu'il y a 7 octets à 0. Si le bus fait 8 octets, c'est aussi rapide de lire 1 octet que 8 (du moins s'ils sont alignés, sinon il faut au plus deux opérations de lecture). Enfin, dans un programme toute les valeurs possibles d'un short int, int, long, etc peuvent être utilisées. Donc ça ne laisse pas la possibilité au cache de faire une convention du type : 0x 07 01 => 7 octets à 0 puis 7 car 0x 07 01 c'est aussi un short int ou 2 caractères. A moins que le cache ajoute un octet pour indiquer le type. Or le cache n'est pas sencé connaitre le type des données qu'il lit. C'est comme les caches des disques dure. Ils ne savent pas le type de données lues/écrites.
                    • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                      Posté par  . Évalué à 5.

                      On ne peut pas faire l'édition de lien d'un .o avec sizeof(void *) = 4 et d'un autre avec sizeof(void *) = 8. Image "titi = toto ;" avec titi (void *) d'un .o 32 bits et toto (void *) d'un .o 64 bits.

                      Je te rappelle qu'un programme peut être compilé avec uniquement des offsets relatifs sur 32 bits. On peut d'ailleurs imaginer qqch sur le modèle de ce qui faisait sur PC avant (mode NEAR pour < 4 Go et FAR pour > 4 Go).

                      <i>> et de ne transfere que les bits significatifs !

                      Ça ne change rien. [...] A moins que le cache ajoute un octet pour indiquer le type.

                      Originaux tes exemples, j'ai l'impression que tu n'as jamais vu d'assembleur et les modes d'adressage d'un CPU. Tu oublies les modes d'adressages qui précisent la taille des données à transférer. Sur 68000 un "move" peut être écrit "move.b", "move.w" ou "move.l" , correspondant à 8, 16 ou 32 bits. Quand dans ton code C tu manipules des char ou des long, c'est compilé en instructions qui ne transfèrent que les tailles utiles (en l'occurence 8 bits pour char et 32 bits pour long).
                      • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                        Posté par  (site web personnel) . Évalué à 2.

                        Enfin quelqu un qui sait de quoi il parle :=)
                        ( meme mieux que moi :o )
                      • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                        Posté par  . Évalué à -1.

                        > Je te rappelle qu'un programme peut être compilé avec uniquement des offsets relatifs sur 32 bits.

                        Et sous ms-dos et windows il y a quelques années on pouvais faire du 16 bits en relatif aussi (les fichier .com :-) ).

                        Si ton programme n'utilise que du relative 32 bits sur un os 64 bits (par exemple) alors tu ne peux pas utiliser de librairie (comme expliqué plus haut). Dans ce cas, je vois pas où il est le gain de place.

                        > Originaux tes exemples, j'ai l'impression que tu n'as jamais vu d'assembleur et les modes d'adressage d'un CPU.

                        Tu n'as pas compris le problème. On parlait de cache. La question était de savoir s'il était possible d'économiser le cache en ne copiant que les octets "significatifs". J'ai répondu que non en prenant comme exemple un int de 8 octets. Il est évident que pratiquement tout les cpu savent récupérér 1, 2, 4 ... octets (le z80 le fesait). Quoiqu'il en soit (puisse que l'on parle de cache ! ) je me demande si le cache a ce niveau de "finesse".
                        • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                          Posté par  (site web personnel) . Évalué à 2.

                          la réponse est non, l'unité de base d'un cache, c'est la "ligne de cache", c'est 32 octets sur les x86 actuels il me semble. En tout cas, c'est toujours de l'ordre de 16,32 ou 64 octets pour les caches L1 et L2.
                        • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                          Posté par  . Évalué à 1.

                          Si ton programme n'utilise que du relative 32 bits sur un os 64 bits (par exemple) alors tu ne peux pas utiliser de librairie (comme expliqué plus haut).

                          Je ne vois pas le rapport entre le fait qu'un OS soit 64 bits, qu'on utilise des adressages relatifs en 16 ou 32 bits, et qu'on ne puisse pas utiliser de librairie. A l'heure actuelle, la librairie C (tu parles bien de ça je suppose) est en 32 bits sous Linux x86, mais ça n'empêche pas d'avoir des programmes qui ne contiendraient que des offset relatifs sur 16 bits. Sur Amiga tu pouvais bien avoir des programmes qui n'utilisaient que des sauts relatifs, alors que l'OS était 32 bits.

                          La question était de savoir s'il était possible d'économiser le cache en ne copiant que les octets "significatifs". J'ai répondu que non en prenant comme exemple un int de 8 octets.

                          Tu te poses de drôles de questions. Remarque, si tu utilises un int pour une variable, c'est que tu comptes utiliser un bonne partie des valeurs possibles, tu ne vas pas prendre un int si tes valeurs vont de 1 à 100 par exemple. Ta question "d'optimiser le cache" n'a même pas de sens à mon avis. Si tu manipule un int (sur 32 bits ou 64 bits) et que tu modifies sa valeur dans le CPU, une fois que tu sauvegarde en mémoire, tu es obligé d'aller écrire tous les bits, qu'ils soient à zéro ou à un ! Le CPU ne sait pas ce qu'il y avait en mémoire avant.

                          Et dans le cas d'un cache, la granularité du cache est bien supérieure à la taille d'un mot mémoire.
                          • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                            Posté par  . Évalué à 1.

                            Je n'ai pas dit que l'on ne peut pas utiliser un adressage relatif. Je dis que l'adressage relatif ne peut pas être utilisé lorsqu'un programme appel une fonction ou un variable dans une librairie partagée, ou une librairie partagée vers une librairie partagée (et surement d'autres combinaisons). Je ne dis pas qu'un programme qui utilise une librairie partagée ne peut pas utiliser les adressages relatif ! Je dis aussi que les adresses d'un objet (j'ai pris l'exemple d'une fonction static mais c'est aussi vrai pour une variable) externe qui est stocké dans une variable est forcément l'adresse absolue. C'est principalement dans le contexte d'une fonction (if, while, etc...) que les adresses relatives sont utilisées, que le programme soit statique ou dynamique !

                            > qu'on utilise des adressages relatifs en 16 ou 32 bits, et qu'on ne puisse pas utiliser de librairie.

                            Car le compilateur ne sait pas à la compilation où va être chargée la librairie partagée (d'où l'édition de lien à l'exécution pour les librairies partagée). Et donc, il ne peut supposer que la fonction appelée (ou la variable) est à une distance tenant dans un mot inférieur à sizeof(void *) (sous un système 32 bits, sizeof(void *) = 32 et pour un système 64 bits, sizeof(void *) = 64). Donc l'appel de la fonction (ou de la variable) est codé en utilisant une adresse absolue sur 64 bits (si c'est un OS 64 bits). Notes que je n'est pas dit que c'était impossible pour une librairie static (d'édition de lien étant faite à la compilation). Je ne parle que de l'utilisation d'un objet dans une autre librairie partagée !

                            > Sur Amiga tu pouvais bien avoir des programmes qui n'utilisaient que des sauts relatifs, alors que l'OS était 32 bits.

                            Sous DOS aussi c'est possible (fichier .com comme je l'ai dit précédament). Car il n'y a pas d'utilisation de librairie partagée.

                            > Tu te poses de drôles de questions.

                            C'est pas moi qui ait posé la question (relis le thread).

                            > Ta question "d'optimiser le cache" n'a même pas de sens à mon avis.

                            J'ai répondu à une question et dis que l'on ne pouvait optimiser le cache comme c'était proposé. Et je n'ai fait aucune proposition d'optimisation de cache (relis le thread).

                            > Et dans le cas d'un cache, la granularité du cache est bien supérieure à la taille d'un mot mémoire.

                            Merci de le confirmer.
          • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

            Posté par  (site web personnel) . Évalué à 4.

            Je pense qu'à grands coups de marketing les proc 64 bits ont toutes leurs chances vis à vis du public. Il suffit de voir le marché des consoles : le public n'achète pas une console à X Mhz, ou avec X Mo de mémoire, il achète une 32bits, une 64bits, unz 128bits (oui je sais ce ne sont pas des "vrais" 128bits). Mais dans l'esprit populaire, 64 bits = 2x32bits, donc deux fois mieux! :)
          • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

            Posté par  . Évalué à 3.

            Intel estime que le 64 bits n'est pas une priorité pour le grand public. Il n'a pas vraiment tort. Qui ici a besoin d'un système 64 bits ? Qui utilise pour son PC perso plus de 4 Go de mémoire vive ? Vu le rythme de croissance de la taille mémoire dans les PC grand public, on arrivera à 4 Go à peu près en 2008. C'est dire si les PC un peu plus costauds vont vite se casser les dents sur la limite d'adressage, avant cette date. C'est vrai que ça paraît délirant qu'un jour le PC de base soit doté de 4 Go, mais comme ça n'a jamais cessé de croître... Passer de 32 à 64 bits, çà bouffe plus de mémoire et plus de place disque. ( Pas d'accent sur le "a" de "ça" (car ton "ça" = "cela") ) Le fait de passer du 32 bits au 64 bits ne fait pas forcément grossir le code car les architectures CISC à la Intel permettent d'utiliser plusieurs modes d'adressage, en particulier relatifs, avec des "offsets" sur 16, 32 ou 64 bits. A priori, sur la plupart des programmes (qui sont < 4 Go), il n'y aura pas besoin de stocker les sauts et autres pointeurs sur plus de 32 bits. Ceux qui ont fait de l'assembleur 68000 me comprendront aisément, à l'époque on pouvait le plus souvent utiliser de l'adressage relatif sur 16 bits, même pour des programmes plus gros que 64 Ko.
            • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

              Posté par  . Évalué à 0.

              > C'est dire si les PC un peu plus costauds vont vite se casser les dents sur la limite d'adressage, avant cette date. C'est probable. Ça (sans 'à', merci pour l'info car j'ai déjà fait mille fois cette faute) explique aussi le positionnement de Intel. Beaucoup seront "forcé" de passé à 64 bits autour de 2008 s'il ne sont pas déjà passés en 64 bits. > les architectures CISC à la Intel permettent d'utiliser plusieurs modes d'adressage, en particulier relatifs Comme pratiquement tout les cpu il me semble. L'adressage relative étant utilisé dans les fonctions pour les sauts (if, while, etc...) mais pas entre fonction. Une fonction peut-être appelé n'importe où. Il faut aussi pensé aux pointeurs de fonction qui peut-être utilisé. Donc même l'adresse d'une fonction static doit être codé sur 64 bits. Exemple (j'ai surement fait des erreurs de typage car j'ai oublié comment déclarer des pointeurs de fonction...): toto.c void*(void) titi(void) { return toto ; } static void toto(void) { print("toto\n") ; } main.c main() { void* (*func)(void) ; func = titi() ; func() ; // affiche "toto" }
              • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                Posté par  . Évalué à 1.

                L'adressage relative étant utilisé dans les fonctions pour les sauts (if, while, etc...) mais pas entre fonction. Une fonction peut-être appelé n'importe où. Il faut aussi pensé aux pointeurs de fonction qui peut-être utilisé.

                Tu as sans doute raison pour les pointeurs de fonction, mais tu te trompes pour l'adressage relatif qui ne serait pas utilisable entre fonctions.

                Dans le cas des pointeurs de fonctions, en effet je ne vois pas trop comment on ferait sans stocker le pointeur complet. Un offset relatif ne marcherait pas pour la ligne "func = titi() ;" puisque cet offset devrait être modifié entre le moment de l'affectation et la ligne où on y fait référence ( "func();" ).
                Quoique finalement ça ne devrait pas être très difficile de faire un compilateur qui serait capable de suivre les offset des pointeurs de fonction...

                Par contre, n'importe quel appel de fonction "normal" marche très bien avec des offset relatifs, c'est ce qu'il se passe quand tu génères du code "PIC" (position independant code"). Sur 68000 ça se code avec un "jsr offset(PC)" si ma mémoire est bonne. Un appel de fonction ou un saut de boucle, ce n'est jamais qu'un saut (avec dans le cas d'une fonction une sauvegarde sur pile de l'adresse de départ, et un "ret" au bout).
                • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                  Posté par  . Évalué à 1.

                  > mais tu te trompes pour l'adressage relatif qui ne serait pas utilisable entre fonctions.

                  Pour tout les appels de fonction de librarie partagé, le relatif ne peut pas marché.

                  > Quoique finalement ça ne devrait pas être très difficile de faire un compilateur qui serait capable de suivre les offset des pointeurs de fonction...

                  Faut ajouter beaucoup de code pour ça => perte de place. C'est comme les gens qui veulent économiser de l'espace en utilisant des champs bits. Faut tellement de code, que généralement ça bouffe plus de place que d'utiliser un int pour stocker un booleen. Et c'est aussi plus lent.

                  > Par contre, n'importe quel appel de fonction "normal" marche très bien avec des offset relatifs, c'est ce qu'il se passe quand tu génères du code "PIC"

                  En fait, lorsque la librairie partagée est chargée, le loader change toute les adresses relatives en absolu (depuis la table des symbols). Car ce sont des adresses relatives (donc de 64 bits sur un OS 64 bits) et non des offsets. Les librairies partagées sont faites en considérant qu'elle commence à l'adresse 0 (la résolution d'adresse sera faite à l'excécution). Il est claire que si plusieurs librairie sont utilisées, ça ne peut pas marché. Le loader va modifier les adresses relatives pour en faire des adresses absolus.
                  • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

                    Posté par  . Évalué à 1.

                    Pour tout les appels de fonction de librarie partagée, le relatif ne peut pas marcher.

                    Oui, c'est un cas où on est obligé d'avoir des adresses absolues. Mais à l'intérieur de ton programme, ou de ta bibliothèque de fonctions, tu peux n'avoir que du relatif.

                    Encore que, sous Amiga on récupérait une adresse de début de bibliothèque (avec OpenLibrary() ), et ensuite on appelait une des fonctions de la bibliothèque en utilisant un offset relatif si je me souviens bien (en asm : "jsr OpenWindow(a6)", a6 étant le registre d'adresse pris par convention pour les appels de biblio), la bibliothèque comprenant en son début une table de fonction . Que les ex-amigaïstes me confirment la chose...

                    Tout ceci pour dire que passer en 64 bits ne devrait avoir qu'une influence tout à fait réduite sur l'occupation mémoire ou disque, en particulier aucun risque de doublement de taille.
            • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

              Posté par  . Évalué à 4.

              Intel a déja une norme d'adressage supérieur à 4Go pour ses 32 bits. Elle est utilisé par windows Serveur par exemple, et ca permet d'avoir 64Go, mais avec des limitations. Ca existe pour Linux aussi. Sinon, l'interet de l'Itanium, c'était surtout pour intel. Si le développement a était si long, c'est que chaque transistor est breveté, contrairement au x86. Le but à l'époque était de se débarasser des cloneurs. Depuis AMD a révolutionné le marché, et Intel en prend plein le tronche pour pas un rond. Donc même pour le grand public, l'interet n'est pas évident. S'il veut vraimment un 64bit, il prendra un AMD64 et basta. Surtout si Intel ne sort son 64bit grand public qu'en 2008-2009. D'ici là AMD aura développé de nouvelles armes secretes qui lui permetront de gagner la guerre. En fait, AMD à peut être ici l'opportunité en or de passer devant Intel. Et Intel l'a bien compris, puisque cette compagnie prepare aussi un 64bit compatible.. AMD64, au cas ou...
          • [^] # Re: Position d'Intel sur les processeurs 64 bits grand public

            Posté par  . Évalué à 3.

            Interressant comme argument...
            Mais ça ne m'explique pas pourquoi on en est pas resté aux 8 bits alors que 16 ça bouffe plus de mémoire ! quand aux 32 bits houla comme c'est trop cher ! les 4 bits c'est pas mal aussi comme rapport qualité/prix.

            On pourrait pas faire du 48 bits ? c'est un bon compromisentre 32 et 64, pour couper la poire en deux...

            Plus sérieusement, j'ai une barrette de 1 Go sur ma liste de courses, maintenant là en 2003, et je ne suis qu'un rigolo, même pas pour du serveur, alors la barrière des 4 Go toujours pas cassée en 2008, hum hum c'est aussi mal vu que le 640kb is enough for everybody de l'autre escroc.
  • # et pour le 64 bits pas grand public ?

    Posté par  (site web personnel) . Évalué à 3.

    y a-t-il des gens par ici qui ont eu l'occasion de faire joujou avec des itaniums2 ? est-ce que ce genre de machine apporte vraiment un gain en puissance brute par rapport à un xeon ou athlon top-moumoutte (mis à part les 32 bits supplémentaires) qui justifie des écart des prix aussi grands ? (à ce que j'ai vu, une machine itanium2-900MHz mono-proc, ça va direct chercher dans les 50000 F)
    • [^] # Re: et pour le 64 bits pas grand public ?

      Posté par  (site web personnel) . Évalué à 4.

      Une moule(je sais pas si je peux citer son nick vu que c'est a son boulot) a sous la main un bi proc, la compilation d'une application de décideur prend plus d'une minute alors que sur mon athlon 2000+, ça prend dans les 30s.

      D'apres lui, ça devait surtout venir de gcc qui est pourri sur les non x86. Ça sert pas a grand chose si y a rien de correct pour l'exploiter.
      • [^] # Re: et pour le 64 bits pas grand public ?

        Posté par  (site web personnel) . Évalué à 3.

        oui, je vois de qui tu parles :) mais quelque chose me dit que le genre d'applis qu'il fait tourner dessus est assez différent de ce que j'envisage. Et c'est vrai que la comparaison des temps de compile n'est sans doute pas très pertinente entre deux archis complètement différentes, d'autant que les itaniums sont censés demander au compilateur d'être un peu plus finaud que sur x86. Et puis il y a des alternatives à gcc, comme icc et
        http://sourceforge.net/projects/open64/(...)
      • [^] # Re: et pour le 64 bits pas grand public ?

        Posté par  . Évalué à 2.

        ... la compilation d'une application de décideur prend plus d'une minute alors que sur mon athlon 2000+, ça prend dans les 30s.

        Je voudrais pas dire de bêtises, mais j'ai l'impression que s'offrir une archi 64 bits, c'est un peu comme monter un cluster ou faire du traitement en parallèle en général. Si l'architecture logicielle n'est pas adaptée, on ne risque pas de gagner en performance de façon fulgurante.

        D'autre part, je suis en train de me demander dans quelles conditions le 64Bits peut-être réellement utile. Si l'on considère en simplifiant à l'extrême que le 64 bits agit sur la taille des entiers manipulés par le processeur en une opération et sur la largeur du bus, on peut comprendre qu'un entier compris entre -32768 et +38767 soit un peu étroit pour la plupart des opérations courantes et que passer du 16 au 32 bits ait apporté un réel gain en ramenant à une seule étape les opérations qui étaient découpées en deux phases voire plus.

        Par contre, atteindre les limites de -2147483648 à 2147483647, c'est pas courant. Connaissez vous beaucoup d'applications actuelles qui fassent un usage intensif des quad words ? Ah si, peut-être les "double" très utilisés par les compilateurs.

        En dehors de ces cas précis, 0001 et 00000001 représentent la même chose, et s'il faut autant de temps pour accéder à la mémoire, je comprend que le gain en performance ne soit pas évident.
        • [^] # Re: et pour le 64 bits pas grand public ?

          Posté par  . Évalué à 4.

          Le principal intérêt du 64 bits, et à peu près le seul, c'est de s'affranchir de la limite des 4 Go de mémoire par application. Certains serveurs atteignent déjà cette limite.

          Certaines applications peuvent également bénéficier d'un gain de performance en effectuant certains calculs par blocs de 64 bits, plutôt que 32 bits, mais MMX et SSE existent déjà pour ce type d'opérations et sont plus performants.
          • [^] # Re: et pour le 64 bits pas grand public ?

            Posté par  (site web personnel) . Évalué à 2.

            Ben quand t'as besoin d'une machine qui gère lus de 4 Go de RAM (typiquement une bonne petite base de données, par exemple un datamart), tu prends une machine sérieuse, du Sun ou IBM ou HP...
            • [^] # Re: et pour le 64 bits pas grand public ?

              Posté par  . Évalué à 3.

              Il faut aussi prendre en compte le prix. Les serveurs que tu cites ne doivent pas être donnés. A l'heure actuelle, ce n'est pas non plus le cas des processeurs 64 bits, mais si un constructeur comme AMD arrive à rendre "grand public" un tel processeur, cela signifie qu'il sera possible d'avoir un gros serveur performant à peu de frais.
            • [^] # Re: et pour le 64 bits pas grand public ?

              Posté par  (site web personnel) . Évalué à 1.

              j'avais lu qq part que la taille moyenne mémoire augmentait de .8 bits (bus d'adresse) par an soit 80%. Si 512 Mo est courant sur une machine de bureau neuve, il faut 3 ans pour dépasser 4Go à ce rythme.

              "La première sécurité est la liberté"

              • [^] # Re: et pour le 64 bits pas grand public ?

                Posté par  . Évalué à 2.

                j'avais lu qq part que la taille moyenne mémoire augmentait de .8 bits (bus d'adresse) par an soit 80%. Si 512 Mo est courant sur une machine de bureau neuve, il faut 3 ans pour dépasser 4Go à ce rythme. J'avais fait le calcul en 2002, à l'époque la taille standard de la mémoire était de 256 Mo. Sachant que la taille mémoire double tous les 18 mois, elle quadruple tous les 3 ans. Ca donne ceci comme progression : Année : 2002 2005 2008 Mo : 256 1024 4096
                • [^] # Re: et pour le 64 bits pas grand public ?

                  Posté par  (site web personnel) . Évalué à 2.

                  2005 1go ? Ah non ! La plus part des power user ont déjà 512-1go de ram !

                  "La première sécurité est la liberté"

                  • [^] # Re: et pour le 64 bits pas grand public ?

                    Posté par  (site web personnel) . Évalué à 2.

                    La tendance actuelle est que le prix de la ramme baisse moins vite qu avant ... donc t inquiete pas, la progression va ralentire ... on est passe rapidement de 256 a 1Go, mais vu le prix de la RDRAM, on va rester un petit bout de temps a 1Go ... de toute facon les usines de RAM tournent a fond, et ils n arrivent pas a baisser les couts de production ...
                    • [^] # Re: et pour le 64 bits pas grand public ?

                      Posté par  . Évalué à 3.

                      euh souvent le prix de la RAM n'a pas de rapport direct avec la capacité de prod, tel que dans le cas du tremblement terre en Asie qui avait permis un envolement durable des prix alors que les usines n'avait pas été touchés :p
              • [^] # Re: et pour le 64 bits pas grand public ?

                Posté par  (site web personnel) . Évalué à 8.

                > j'avais lu qq part que la taille moyenne mémoire augmentait de .8 bits Quand est ce que les numerso d IRQ sur les PC passe a 8 bits ? par ce que 4 bits ca devient la bousculade, meme avec le IRQ-sharing .... ils sont pas capables de trouver "4 bits de libres" quelque part ???? je demande meme pas un segment de 64Kb complet ... juste 4 autres bits ... allez soyez sympa :/
                • [^] # Re: et pour le 64 bits pas grand public ?

                  Posté par  . Évalué à 1.

                  exact. sur PC entre les IRQ et les limites du DMA, y a du boulot avant de passer a 64bit le biniou !!
                • [^] # Re: et pour le 64 bits pas grand public ?

                  Posté par  . Évalué à 1.

                  Quand est-ce que les numeros d'IRQ sur les PC passe à 8 bits ? par ce que 4 bits ca devient la bousculade, meme avec le IRQ-sharing

                  Déjà, ajouter un bit ça serait pas mal, ça doublerait le nombre. Avec 5 bits ça comblerait les besoins de beaucoup de gens (32 possibilités, il y a de quoi en mettre des cartes d'extensions).
                  8 bits, ça me paraît énorme et inutile, ça fait 256 IRQ différentes.
                  • [^] # Re: et pour le 64 bits pas grand public ?

                    Posté par  (site web personnel) . Évalué à 2.

                    Quand on vois la vitesse a laquelle ca evolue, vo mieux prevoire large ... regarde a quoi on en est reduis juste parce que justement ils n ont pas prevu assez large ...
                    Meme Aple s est offert 8 bits pour les IRQ ... j ai jamais entendu dire que c'etait "trop" :=)
                • [^] # Re: et pour le 64 bits pas grand public ?

                  Posté par  . Évalué à 1.

                  Héhé. Je ne crois pas que le fait qu'il y ait 15 IRQ signifie qu'elles sont stockées sur 4 bits.
                  Les IRQ sont cascadables : on a un premier niveau de 8 IRQ dont une sert à accéder au deuxième niveau => total de 15 IRQ. Je suppose que rien ne s'oppose à ce qu'il y ait un niveau supplémentaire... Sauf que ça sert pas à grand chose et il faudrait que l'OS le supporte.
        • [^] # Re: et pour le 64 bits pas grand public ?

          Posté par  (site web personnel) . Évalué à 4.

          Les manipulations mémoires : SGBD, grand fichiers, espace mémoire > 4Go, double ! c'est pour ça que le x87 était souvent à la traine des machines "risc", y'a aussi les flags "champs de bits" qui sont 2 fois plus larges. C'est déjà pas mal.

          Coté Athlon64, l'avantage est l'ajout d'un mode d'adressage qui faisait default et le doublement du nombre de registre adressable.

          "La première sécurité est la liberté"

        • [^] # Re: et pour le 64 bits pas grand public ?

          Posté par  (site web personnel) . Évalué à 4.

          Je vois déja un intéret: que Konqueror ne me dise pas qu'un répertoire fait 2go quand il en fait 14 (il compte sur des DWORD).
      • [^] # Re: et pour le 64 bits pas grand public ?

        Posté par  (site web personnel) . Évalué à 2.

        Je viens de tester moi aussi :) bon y'a que gcc-2.96 de dispo sur l'itanium, donc il n'est pas super à son avantage ;)
        cat /proc/cpuinfo
        processor : 0
        vendor : GenuineIntel
        arch : IA-64
        family : Itanium 2
        model : 0
        revision : 7
        archrev : 0
        features : branchlong
        cpu number : 0
        cpu regs : 4
        cpu MHz : 995.819000
        itc MHz : 995.819000
        BogoMIPS : 1488.97


        je relance le bench de http://linuxfr.org/comments_reply,10578,155866,1.html(...)
        ** **
        ** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
        ** for details. (Results can be submitted to pozo@nist.gov) **
        ** **
        Using 2.00 seconds min time per kenel.
        Composite Score: 120.72
        FFT Mflops: 65.99 (N=1024)
        SOR Mflops: 229.90 (100 x 100)
        MonteCarlo: Mflops: 51.47
        Sparse matmult Mflops: 147.90 (N=1000, nz=5000)
        LU Mflops: 108.34 (M=100, N=100)



        ben voilà, pour la factorisation LU c'est le score de mon celeron@450 MHz :))
  • # Re: Position d'Intel sur les processeurs 64 bits grand public

    Posté par  (site web personnel) . Évalué à -1.

    bonjour, je penche plutot sur le fait que le win64 de chez krosoft
    n'est pas pret et comme intel et bill travaillent toujours ensenble,
    ca va de soit, intel doit attendre que win64 fonctionne !?
    m'enfin avec du 32 bits j'en ai assez pour le moment.

    Amd avec un 32/64 ca permet de fair tourner des anciens os,
    et aussi les GNU/linus qui sont deja pret.
    a+
    cveyoda
  • # Re: Position d'Intel sur les processeurs 64 bits grand public

    Posté par  (site web personnel) . Évalué à -2.

    bonjour, je penche plutot sur le fait que le win64 de chez krosoft
    n'est pas pret et comme intel et bill travaillent toujours ensenble,
    ca va de soit, intel doit attendre que win64 fonctionne !?
    m'enfin avec du 32 bits j'en ai assez pour le moment.

    Amd avec un 32/64 ca permet de fair tourner des anciens os,
    et aussi les GNU/linux qui sont deja pret.
    a+
    cveyoda
  • # Re: Position d'Intel sur les processeurs 64 bits grand public

    Posté par  (site web personnel) . Évalué à 2.

    Une interview de linus a propos de l'ia64: http://www.theinquirer.net/?article=7966(...)

    Astute observers will have wondered how a 32bit processor can address more than 4GB of memory. PAE is the answer. It allows 36bit addressing using 'pages' of memory. According to Torvalds, the Pentium 4 is crippled "because Intel refuses to do a 64-bit version (because they know it would totally kill ia-64)."

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.