A64 socket 939 : Impressions ?

[cpulloverclock]

ya Microsoft Windows XP PRO AMD64 Build 1184 -WinBeta qui est en beta test, jai la version precedente que jai compare au windows 2003 64bits SP1 et comme en version 32bits il lui est superieur




windows 2003 avec SP1 1184 (le Sp1 pour beta testeurs), par defaut c le 1069


ca marche pas mal, par contre pas mal de progs incompatibles avec le 64bit mais c normal, ct courru davance, c clair quen encodage ya une grosse diff quand le prog est optimise 64bits

[Doc TB]

Oui c'est trés bien, mais ca reste une version beta inutilisable parceque

1/ C'est une beta et tu ne peut pas etre sur des résultats
2/ Les warez de winbeta, c'est bien, mais si microsoft vient me demander des comptes ?
3/ Microsoft est actuellement en train de modifier Windows 64 pour l'adapter aux CPUs Intel et, a voir les résultats, j'en connais qui vont halluciner.

[The_ED]

3/ Microsoft est actuellement en train de modifier Windows 64 pour l'adapter aux CPUs Intel et, a voir les résultats, j'en connais qui vont halluciner.

Tu pourrais nous en dire plus ?? :D

[PeGGaaSuSS]

Oui c'est trés bien, mais ca reste une version beta inutilisable parceque

1/ C'est une beta et tu ne peut pas etre sur des résultats
2/ Les warez de winbeta, c'est bien, mais si microsoft vient me demander des comptes ?
3/ Microsoft est actuellement en train de modifier Windows 64 pour l'adapter aux CPUs Intel et, a voir les résultats, j'en connais qui vont halluciner.

Pfutt warez warez sa reste a prouvé, Microsoft a jamais attaqué WinBeta...
Pis de toute façon, y'a une version parfaitement légale qui existe.

[johnnyholzeisen]

3/ Microsoft est actuellement en train de modifier Windows 64 pour l'adapter aux CPUs Intel et, a voir les résultats, j'en connais qui vont halluciner.

Tu pourrais nous en dire plus ?? :D

Si mes souvenirs sont bons, je crois que l'EM64T possède une instruction de plus que l'AMD64 (je ne retrouve plus l'endroit où je l'ai lu ), sans compter tout ce que MS et Intel savent, mais que nous ne connaissons pas encore...

Autrement, je me pose une question, est-ce que la haute fréquence du Pentium n'est pas "bridée" par le faible nombre de registres ??
L'Hyperthreading serait plus performant, non ?

[Wanou]

Pas sur, dans mon cours de système d'exploitation (qui date un peu) on expliquait que porter NT4 (vous voyez que ca date) sur une autre architecture ne demandait pas bcp de travail, parce que seul le HAL était a réécrire, le reste du sytème pouvait être recompilé pratiquement sans modifs (faible, en tout cas). La preuve : y avait NT PPC, MIPS, Alpha, X86

Ben justement, c'est le défaut des cours un peu vieux: ca a beaucoup evolué.
L'avantage (ou le défaut cela dépend du coté d'ou on se place) de NT4, c'était sa HAL (Hardware Abstraction Layer) qui 'cachait' au système le matos et qui permettait donc, en recompilant dans le bon langage machine, de transposer facilement une application, un driver etc... vers un autre CPU.
Le défaut (justement), c'est qu'il n'y avait AUCUN accès direct au périphérique. Ce qui faisait que pour les périphériques "gourmands" (carte graphique, carte d'acquisition, carte son etc...) on avait des latences épouvantables et des vitesses à peine meilleures.
C'est pourquoi à partir de NT5 (windows2000), la HAL n'est plus vraiment une HAL. De nombreux périphériques peuvent avoir (après avoir demandé la permission poliment au système ou plus ou moins en bourrinant) accès au matériel directement. Le défaut, c'est qu'il devient TRES DIFFICILE de proposer des versions pour d'autres CPUs.
Résultat des courses, il serait suicidaire pour M$ de tenter de mettre son OS sur un cpu non X86.
Après, réussir à "l'adapter" pour une architecture plus ou moins proche (Itanium et X86-64), c'est plus facile. Pas facile, mais plus facile.
Reste le problème de tous les drivers qui devront passer au 64 bits, car, heureusement, et à la différence de Windows 95 (qui acceptait les drivers 16 bits de Windows 3) à son époque, M$ n'a pour le moment pas prévu de systeme "batard" pour faire passer du code 32 bits sur son os 64 bits hors de la machine WOW.
Et là, on risque de pleurer pour les scanners, les imprimantes, bref tous les périphériques qui n'auront pas de driver en X86-64, car les constructeurs ne se feront pas suer à sortir un driver pour un matos qui n'est pas neuf.

Enfin, bon, à part ca, PERSONNE IL A LES TARIFS A LA LOUCHE DE L'A64-3500 nom de Dieu !!!

[Oxygen3]

2/ Les warez de winbeta, c'est bien, mais si microsoft vient me demander des comptes ?

c marrant, t'as plus peur de microsoft que de amd :whistle:

[Neo_13]

Dans un cas, c'est illégal, dans l'autre pas

[PeGGaaSuSS]

Dans un cas, c'est illégal, dans l'autre pas

Ah ouais ?
Une version non vendue n'a aucune valeur...
Donc dans les deux cas c'est pareil.
Le seul risque, c'est pour celui qu'a fait sortir le leak de se faire virer de la boite.

[lechenejb]

c'est pas parce que çà a pas de valeur que sa vaut rien, il y'a une propriété intellecteuelle ... le jour où microsoft fera un beta test ouvert à tous, ok, sinon ba on a pas le droit ...

[SiX-P4cK]

2/ Les warez de winbeta, c'est bien, mais si microsoft vient me demander des comptes ?

c marrant, t'as plus peur de microsoft que de amd :whistle:

ou des 0 a gauche de la virgule... :P

pk ya pas d'article comme sa sur les prochain cpu intel :evil: (les Dothan 90nm c bien mais ya pas que les portable dans la vie )

[Oxygen3]

euh, le celeron D, tu crois que c'est quoi ?

[Minuteman]

Les prix de nouveaux Athlon64 sont apparus chez mon revendeur, mais je ne sais pas si c'est réellement les A64 Socket939 (c'est référencé n'importe comment).
http://www.stegpc.com/browse.asp?cat=121

[eponge]

Les prix de nouveaux Athlon64 sont apparus chez mon revendeur, mais je ne sais pas si c'est réellement les A64 Socket939 (c'est référencé n'importe comment).
http://www.stegpc.com/browse.asp?cat=121

tu m'étonnes :

AMD Athlon 64 3800+, Box, Fan (2.2GHz),1MB Cache,PGA754

freqs pas bonne, cache pas bon , socket pas bon.... et le prix !!!! pas bon du tout, a 1080?...c est des DeutschMark ?

quand on voit le 3400+ en general a un peu plus de 400?... meme un FX53 serait moins cher...

[Minuteman]

C'est des francs suisses, mais cliques sur le produit et tu as le prix en euros.
En résumé:
3200+: 286 Euros (lui il doit pas être S939)
3500+: 506 Euros
3800+: 719 Euros

[fun__key]

Steg les adores

Meme si c le boxons dns le liste d article :P

[Minuteman]

Ils viennent à l'instant (genre il y a 10 min à tout casser) d'ajouter un A64 2800+ S754 au même prix que les 3000+...je sais pas ce qu'ils tiennent pour un bordel mais c'est n'importe quoi lol.

[joseph_31]

Les prix de nouveaux Athlon64 sont apparus chez mon revendeur, mais je ne sais pas si c'est réellement les A64 Socket939 (c'est référencé n'importe comment).
http://www.stegpc.com/browse.asp?cat=121

En tout cas sur l'article on peut lire :

AMD Athlon 64 3800+, Box, Fan
(2.4GHz),512MB Cache,PGA754

Alors moi je veux bien l'acheter avec 512 Moctets de cache L2 !!!!!

Sinon 719€ c'est quand même trop cher encore .....

[paulez]

C'est ptet des Mbits et pas des Mbytes :D

[psy31]

Oui c'est trés bien, mais ca reste une version beta inutilisable parceque

1/ C'est une beta et tu ne peut pas etre sur des résultats
2/ Les warez de winbeta, c'est bien, mais si microsoft vient me demander des comptes ?
3/ Microsoft est actuellement en train de modifier Windows 64 pour l'adapter aux CPUs Intel et, a voir les résultats, j'en connais qui vont halluciner.

mmm, certains ne vont pas du tut apprécier celà =>

· Software IOTLB — Intel® EM64T does not support an IOMMU in hardware while AMD64 processors do. This means that physical addresses above 4GB (32 bits) cannot reliably be the source or destination of DMA operations. Therefore, the Red Hat Enterprise Linux 3 Update 2 kernel "bounces" all DMA operations to or from physical addresses above 4GB to buffers that the kernel pre-allocated below 4GB at boot time. This is likely to result in lower performance for IO-intensive workloads for Intel® EM64T as compared to AMD64 processors.



http://www.redhat.com/docs/manuals/e...x86_64-en.html

[deltaden]

> C'est gratiut et n'apporte rien, alors que ma remarque etait plus dans
> l'interet general pour enrichir les prochains articles ....

Elle était bidon. Si c'etait faisable, on l'aurait fait.

je suis pas d'accord:

Faire le test entre une version 32bits et 64bits permet d'avoir le gain/la perte apporté par le 64bits. Même si le test est fait sous Linux, ça permet d'avoir un aperçu du genre de gain qu'on pourrait avoir sous Windows. Evidement, ce ne sera pas le même. Mais un encodeur, c'est un encodeur, qu'il soit sous Linux ou sous Windows, ça doit être le même genre d'opérations effectuées.

Enfin, bon, perso je m'en fou des résultats d'encodage, mais bon, c'est juste que je pensais sa remarque pas si dénuée d'intérêt que ça pour d'autres personnes.

[deltaden]

Le 64bits, aujourd'hui, c'est Apache, c'est la compression zip et c'est les beses de données. Le reste ca viendra... plus tard.

et la crypto, surtout la crypto !!

émulé en plus... sans faire de benchs j'annonce -10% facile à cause de la double émulation... (wine-> linux32->linux64), plus le problème de l'occupation mémoire des variables en 64bits (dont 32 ne servent pas)

- il n'y a quasiment pas de pertes "linux32->linux64" et il s'agit parfois d'un gain. Mais ça reste limité du genre entre -3 et 3%...

- un appli 64bits utilise toujours des variables 32bits par défaut, il y a juste les pointeurs en 64bits.

Résultat des courses, il serait suicidaire pour M$ de tenter de mettre son OS sur un cpu non X86.
Après, réussir à "l'adapter" pour une architecture plus ou moins proche (Itanium et X86-64), c'est plus facile. Pas facile, mais plus facile.

:heink:

Tu considères l'IA64 plus ou moins proche du x86 ???

Alors franchement, je vois vraiment pas quel CPU peut être considéré comme éloigné du x86, parce que là.....

[Doc TB]

- un appli 64bits utilise toujours des variables 32bits par défaut, il y a juste les pointeurs en 64bits.

C'est nouveau ca ?

[deltaden]

C'est nouveau ca ?

vraiment pas

Au niveau assembleur, la taille par défaut reste 32bits.
Au niveau languages de programmation, les int sont toujours en 32bits en C/C++. En tout cas dans GCC et le compilo de MS.

C'est normal, vu que 99.9% des applis n'ont pas besoin d'entier 64bits autrement que pour faire des calculs sur les pointeurs. Ce serait un gaspillage de mémoire ridicule.
D'ailleurs, un programmeur qui veut optimiser un minimum son code n'utilise pas des int à tout bout de champ. Il a aussi à sa disposition des short et des char.

PS: je parle bien de l'architecture AMD64, les autres j'en sais rien.

[Doc TB]

D'accord.... :sarcastic:

Pour ton info, un int, c'est toujours 32 bits, que tu soit en IA32 ou en x86-64. Qd tu passe en x86-64, c'est le *LONG* qui est en 64 bits, et pas que les pointers. Donc il n'y a pas *QUE* les pointers qui sont 64 bits puisque les LONG sont bien en 64 bits. Quand à leurs utilisations, tu n'a qu'a regarder les codes sources des rares applications portées x86-64 comme le client Seti@Home, tu verra qu'elles sont trés utilisées.

Et vu que le probleme de depart, c'etait le portage et bien oui, ca ralentis en 64 bits. Puisque les mecs qui codent en i386 utilisent autant des int que des long (qui font alors tout les deux 32 bits), lorsque tu compile en x86-64, tu te retrouve avec des long de 64 bits alors qu'ils ont été pensé dans une optique 32 bits.

[Franck@x86]

deltaden> tu confonds peut-être variables et opérandes.

La taille d'une variable est définie par sa déclaration, et en effet long c'est 32 bits en x86 et 64 bits en AMD64. Donc si tu définis un tableau de long, il sera donc deux fois plus gros en x86-64, et donc prendra deux fois plus de mémoire.

En revanche, si tu définis un long et tu y colles la valeur 1, le code généré en x86-64 ne sera pas deux fois plus gros qu'en x86. Parce que, comme tu le signales, les opérandes x86-64 font 32 bits par défault.

En somme, par rapport à l'x86, l'x86-64 bouffe plus de cache de données mais pas plus de cache code.

[deltaden]

En fait j'ai répondu en vitesse et me suis un peu embrouillé.
En effet, Franck, c'est bien des opérandes que je parlais en disant que "Au niveau assembleur, la taille par défaut reste 32bits. "

Par contre pour le code, je parlais bien des int qui restaient en 32bits.
Un programme qui n'a pas besoin d'entiers 32bits, s'il est bien codé n'utilise pas des long, mais des ints. Evidement, il y en a une multitude de mal codés...

Mais sous Windows, avec les compilateurs MS, les long sont en réalités toujours 32bits... Eh oui, pour avoir des entiers 64bits, il faut faire des "__int64" si je me souviens bien:

Si tu me crois pas:
http://www.microsoft.com/whdc/winhec.../64bitAMD.mspx
"For example, int and long remain 32 bits, but pointers become 64 bits."

Sous GCC par contre, il me semble bien que les long sont 64bits.
C'est sans doute par compatibilité avec toutes les autres architectures supportées par GCC, ce qui permet de faire les choses proprement et d'avoir des codes source très portables.

D'ailleurs, ça devrait moins poser de problème en open-source, vu que Linux tourne depuis longtemps sur des archis 64bits et un grande partie des programmes existants sont "64bits clean". D'ailleurs il suffit de voir le nombre d'applis déjà disponibles en Linux x86-64...

[ririck]

Parceque tu crois que Windows 64 n'est pas prés depuis des mois déjà ? Ils n'attendent que le bon vouloir d'Intel pour sortir.

Commercialement, Microsoft ne peut pas se permettre de se facher avec Intel, ce n'est pas plus compliqué que ça.

L'argument fonctionne aussi dans l'autre sens : Microsoft a pas besoin de l'accord d'Intel : si Xp-64 sortait maintenant, Intel couperai ses liens avec Microsoft ? Et laisserait de coté les 95 à 98 % d'utilisateur de PC tournant sous Windows. Les acheteurs, préfèreraient surement acheter du AMD, plutôt que d'utiliser Linux ou un mac.

Donc si il y a eu un accord, Intel a surement aligné un joli petit chèque.

[Neo_13]

Parceque tu crois que Windows 64 n'est pas prés depuis des mois déjà ? Ils n'attendent que le bon vouloir d'Intel pour sortir.

Commercialement, Microsoft ne peut pas se permettre de se facher avec Intel, ce n'est pas plus compliqué que ça.

L'argument fonctionne aussi dans l'autre sens : Microsoft a pas besoin de l'accord d'Intel : si Xp-64 sortait maintenant, Intel couperai ses liens avec Microsoft ? Et laisserait de coté les 95 à 98 % d'utilisateur de PC tournant sous Windows. Les acheteurs, préfèreraient surement acheter du AMD, plutôt que d'utiliser Linux ou un mac.

Donc si il y a eu un accord, Intel a surement aligné un joli petit chèque.

Et si Intel fournit une version "spéciale" de linux bien opti et simple à install comme il faut avec chacun de ses CPU ?
Ca m'étonnerais qu'il y ait eu cheque.... Un échange de bon procédé !

[ririck]

Parceque tu crois que Windows 64 n'est pas prés depuis des mois déjà ? Ils n'attendent que le bon vouloir d'Intel pour sortir.

Commercialement, Microsoft ne peut pas se permettre de se facher avec Intel, ce n'est pas plus compliqué que ça.

L'argument fonctionne aussi dans l'autre sens : Microsoft a pas besoin de l'accord d'Intel : si Xp-64 sortait maintenant, Intel couperai ses liens avec Microsoft ? Et laisserait de coté les 95 à 98 % d'utilisateur de PC tournant sous Windows. Les acheteurs, préfèreraient surement acheter du AMD, plutôt que d'utiliser Linux ou un mac.

Donc si il y a eu un accord, Intel a surement aligné un joli petit chèque.

Et si Intel fournit une version "spéciale" de linux bien opti et simple à install comme il faut avec chacun de ses CPU ?
Ca m'étonnerais qu'il y ait eu cheque.... Un échange de bon procédé !

Oui, mais je vois pas trop ce qu'Intel peut proposer à Microsoft en échange.