Articles précédents : Presse
- [17] Hors-Série Login n°15 - Spécial PHP
- [3] Présentation de Wi-Fi et de sa sécurité dans le Figaro Magazine
- [31] Les logiciels libres dans le Figaro
- [2] On cause logiciels libres dans la Gazette des Communes
- [13] MISC 4 : Internet, un chateau construit sur du sable ?
- [15] Un nouveau format pour les CD-ROMs ?
- [47] Sortie de Login n°100 Novembre
- [15] Linux Magazine France 44
- [38] Linuxfr 2ème site le plus populaire après Slashdot
- [16] Netbug n°1 gratuit
AMD has demonstrated the power of their Athlon 64 using the GeForce FX graphics card by running the Unreal Tournament 2003 64-bit Edition on the 64-bit Linux OS.
L'auteur de la dépêche fait remarquer que cela signifie qu'il existe un port sous Linux de la version 64bits de UT2003, ainsi que l'existence de drivers GeForce FX pour Linux ( surement propriétaires, mais c'est déjà ça ), et que tout ceci doit surement être assez performant pour justifier d'une démonstration ( un peu pas comme la X-Box qui plantait pendant les démos à la FNAC ou Carrefour ).
Cela dit, question jeux 64bits, c'est pas encore la panacée : d'ailleurs, ne pourrait-on pas dire que Linux serait le premier OS à avoir vu des vrais jeux 64bits? Et sinon, avouez que c'est quand même sympa de passer en premier par rapport à d'autres OS, non ? ;o)
Virtual Zone Hardware (1298 hits)
> Lire les commentaires (45 commentaires, moyenne: 1,8).
Re: UT2003 64 bits porté sous Linux
cool. et sinon ca marche tjrs pas grace au super brevet de mes **** , donc je repars avec mon ati.
[ X ] -1
-
[^]Re: UT2003 64 bits porté sous Linux
Posté par rictus (page perso, ) le 21/11/2002 à 14:00. (lien). Évalué à 0.Mise à part "bien", "pas bien", "c'est mal" (c) TM
On peut faire le point précis et honnête, au jour d'aujourd'hui et sans considération philosophique, sur ce que permet chaque driver que plateforme x86 ?
- version de Xfree86 supporté (oui sous debian on est encore en 4.1)
- support OpenGL, antialiasing et autres fonctions spéciales d'une carte graphique moderne;
- DRI, extensions XV
- bi-écran, sortie TV accélérée ou non, activée qu'au boot ou quand on veut...
- disponibilité en packages debian, redhat, gentoo... ;-)
- "bidouilles" à faire avec mplayer...
oui si quelqu'un à une URL pour tout ça...
Perso, j'ai une vieille ATI rage pro. Sur http://gatos.sourceforge.net/ati.2.php(...) , j'ai trouvé des modules Xfree 4 pour activer les extensions XV qui me permettent d'avoir avec mplayer des videos de qualité et qui bouffent pas trop de CPU. En revanche étant en Xfree 4.1 (debian oblige, pas de troll svp), je suis obligé d'utiliser une version datant de près d'un an et qui visiblement n'évoluera plus, mais sur lequel j'observe des fuites de mémoire (génant, je ne reboote ou ne me délogue presque jamais). La sortie video n'est activable que si l'on branche à une télé au boot (pas pratique, surtout que dans ce cas, on n'est limité au 800x600).-
[^]Re: UT2003 64 bits porté sous Linux
Posté par _Tof_ () le 21/11/2002 à 14:52. (lien). Évalué à 3.debian oblige, pas de troll svp
Tant pis, je marche dedans : J'ai une debian, une ATI et un xfree 4.2.1 installé à partir de paquets debian pris sur les ftp debian, et les drivers GATOS qui vont bien.... Donc, je cherche encore le sens du mot 'oblige'....-
[^]Re: UT2003 64 bits porté sous Linux
Posté par rictus (page perso, ) le 21/11/2002 à 16:35. (lien). Évalué à 0.ok, ok... faut vraiment faire attention à ce qu'on dit ici... (!)
bon, j'avais pas vu qu'il y avait un package de xfree 4.2.1 apparu en testing... merci pour l'info. Je vais voir si ça s'installe sans remettre à jour 3 millions de packages ;-)
Mais ça ne répond pas à ma question. Dans ton cas, c'est quoi ton ATI ? une Radeon ? "les drivers GATOS qui vont bien", ça donne quoi ? la sortie télé fonctionne ? avec les extensions XV ? Tuxracer qui rox ?
Merci de partager ton expérience.-
[^]Re: UT2003 64 bits porté sous Linux
Posté par _Tof_ () le 22/11/2002 à 15:22. (lien). Évalué à 1.Mon expérience est très limitée, puisque dans mon cas, il s"aigissait surtout de fair marcher XawTv (j'ai une all-in-wonder Radeon, donc avec un tuner TV...).
En tout cas, d'après glxinfo, le DRI a l'air de fonctionner, mais comme je joue pas sous linux (Aïe, je vais me faire flammer, la je le sens...), je peux pas te dire si Tuxracer Rox ou pas.
Sinon, pour ce qui est de la télé, grace au drivers GATOS, mon tuner fonctionne (et donx XawTV aussi :o) ), mais j'ai jamais essayé de faire fonctionner la sortie télé (si je veux faire fonctionner Xawtv, c'est parce que j'ai pas de tv....).
-
-
-
[^]Re: UT2003 64 bits porté sous Linux
Posté par boba () le 23/11/2002 à 16:39. (lien). Évalué à 1.La sortie video n'est activable que si l'on branche à une télé au boot
Avec mon ATI All-in-Wonder 128 Pro, le problème est le même...
Lennart Poettering développe un utilitaire pour pallier à cela visiblement, mais je n'ai pas essayé : http://www.stud.uni-hamburg.de/users/lennart/projects/atitvout/(...)
(pas pratique, surtout que dans ce cas, on n'est limité au 800x600)
Là je suis pas sûr, la résolution d'une télé est inférieure (720x576 je crois en PAL/SECAM).
Enfin j'ai peux-être pas bien compris ce que tu voulais dire.-
[^]Re: UT2003 64 bits porté sous Linux
Posté par rictus (page perso, ) le 25/11/2002 à 10:55. (lien). Évalué à 1.oui, la résolution d'une télé est théoriquement 720x576...
En pratique, les sorties TV des cartes vidéo vont jusqu'au 800x600... je ne sais pas si ça joue sur la tolérance des télés pour afficher un peu plus de lignes que la normale... ou alors si on perd un peu des bouts sur les cotés...-
[^]Re: UT2003 64 bits porté sous Linux
Posté par boba () le 25/11/2002 à 11:31. (lien). Évalué à 1.En fait quand je branche la télé sur le PC, il y a le double affichage sur l'écran du PC et la télé. Et la résolution sur l'écran s'adapte à celle de la télé, c'est-à-dire que j'ai une résolution de 720x576 sur l'écran du PC (ça fait bizarre, ya des bandes noires en haut et en bas, et l'image est déformée, car ce n'est pas proportionnel à du 800x600).
-
-
-
Re: UT2003 64 bits porté sous Linux
Curieux ça. Les drivers NVidia ne sont pas encore sorti pour x86-64 (le 64 bits de chez AMD) mais seulement pour IA 64 (le 64 bits de chez Intel).
Donc soit NVidia a ça sous le coude (ça ne m'étonnerait pas non plus), soit ils utilisent des drivers 32 bits vu que le x86-64 reste compatible x86 classique et ils ont juste enfumé les journalistes pour la démo (TRES probable).
C'est vrai que NVidia n'a pas non plus de raisons de mettre d'éventuels drivers x86-64 sur son site que que le CPU n'est pas encore sur le marché.
-
[^]Re: UT2003 64 bits porté sous Linux
Posté par rictus (page perso, ) le 21/11/2002 à 13:25. (lien). Évalué à 4.Est-ce que c'est une bêtise de penser que dans la mesure où le x86-64 est justement très proche de l'i386, y a juste à recompiler bêtement les sources du pilotes i386 pour obtenir un drivers x86-64 ? (certes pas trop optimisé, mais un peu quand même)
Si il existe déjà des compilox x86-64 bien sûr ?
NB : Je cherche pas à défendre NVidia, c'est une vraie question pour me coucher moins bête ce soir ! ;-)-
[^]Re: UT2003 64 bits porté sous Linux
Posté par Serge Rossi (page perso, ) le 21/11/2002 à 15:53. (lien). Évalué à 3.Bon, un bon compilateur x86-64, ça se trouve :-)
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html(...)
gcc -m64 !
Pour ce qui est du driver 3D 64 bits ou non, c'est tellement complexe que je ne m'avancerai pas trop là dessus. Je me demande d'ailleurs si ça va faire gagner quoi que ce soit...
-
-
[^]Re: UT2003 64 bits porté sous Linux
Posté par Gwenole Beauchesne (page perso, ) le 21/11/2002 à 19:09. (lien). Évalué à 2.Exact Serge, les drivers Nvidia existent vraiment pour x86-64. Il est logique qu'ils n'apparaissent pas encore sur le site de Nvidia. Encore heureux qu'ils ne commencent pas à développer que quand le processeur sort. Enfin, j'espère pour eux. ;-)
-
[^]Re: UT2003 64 bits porté sous Linux
Posté par Moby-Dik () le 21/11/2002 à 19:56. (lien). Évalué à 1.D'autant plus que NVidia a intérêt à ce qu'AMD réussisse, vu que sa plateforme nForce est dédiée aux CPU AMD et non Intel....
-
[^]Re: UT2003 64 bits porté sous Linux
Posté par rictus (page perso, ) le 22/11/2002 à 09:30. (lien). Évalué à 2.c'est drôle d'ailleurs que le nForce soit décliné en version exclusivement AMD... il y a pourtant bien une version qui a été développée pour la xbox et qui gère un cpu intel...
Enfin, c'est juste une remarque comme ça, en passant... AMD rulez !
-
-
[^]Re: UT2003 64 bits porté sous Linux
Posté par Sylvain Rampacek (Jabber id, page perso, ) le 21/11/2002 à 20:59. (lien). Évalué à 1.Ils existent et des versions linux 64 bits pour itanium (http://www.nvidia.com/view.asp?IO=linux_ia64_display_archive(...) ) et windows XP 64 bits (http://www.nvidia.fr/view.asp?PAGE=windowsxp_64(...) ) sont téléchargeables sur leur site !
Donc effectivement, ils ont sûrement dans leurs poches les versions X86-64 pour linux... (sûrement de grande ressemblance avec l'itanium).
-
un jeu 64 bits...
Super !
Il utilise plus de 4 Go de RAM ? Non ?
Bref, on se fout que cela soit 64 bits. L'important dans l'opteron/Athlon 64, c'est surtout un doublement du nombre de tous les registres.
-
[^]Re: un jeu 64 bits...
Posté par Jean-Yves B. () le 21/11/2002 à 12:25. (lien). Évalué à 3.L'important dans l'opteron/Athlon 64, c'est surtout un doublement du nombre de tous les registres.
Ouais, on la lance quand la pétition/collecte de fonds pour libérer le source du compilo C/C++ de DEC sur Alpha ? Parce que gcc, la soupe aux registres ...
[-1, appel au troll]-
[^]Re: un jeu 64 bits...
Posté par cedric () le 21/11/2002 à 12:40. (lien). Évalué à 9.Sauf que depuis le 3.2 tu as le droit a un nouvel allocateur de registre (qui faisait l'objet d'un brevet, mais dont gcc a ete exempte il y a peu) qui permet justement de resoudre les petits problemes qu'il y avait sur les archis ayant de nombreux registres.
De tete c'est l'option -fnew-ra.-
[^]Re: un jeu 64 bits...
Posté par Gwenole Beauchesne (page perso, ) le 21/11/2002 à 19:16. (lien). Évalué à 1.Non, le nouvel allocateur de registres n'est inclu que dans gcc3.3 comme test. Il se trouve juste que SuSE dispose d'une version avec le backport nécessaire pour gcc3.2.
IBM et l'université de RICE (enfin l'université qui hébergeait Briggs) ont concédé une exemption de royalties sur les technologies utilisées. En pratique, la variante implémentée diffère de ce qui était initialement prévu. Note aussi que l'actuel allocateur n'est pas si mauvais sur des merdes comme les x86. Perso, j'avais été surpris par le très faible gain actuel du nouvel allocateur de registres sur x86. Mais cela est amené à changer, la version dans gcc3.3 n'est qu'une expérimentation.
-
-
[^]Re: un jeu 64 bits...
Posté par Troy McClure (page perso, ) le 21/11/2002 à 12:47. (lien). Évalué à 1.SGI avait passé son compilo pour MIPS en open-source il y a un an ou deux, dans le but de faire un portage IA-64. Le truc a l'air d'avoir disparu (manque d'intérêt ?) de http://oss.sgi.com/projects/(...) :-( C'est dommage car ce compilateur n'a à mon avis absolument rien a envier à celui de DEC
-
[^]Re: un jeu 64 bits...
Posté par Troy McClure (page perso, ) le 21/11/2002 à 12:54. (lien). Évalué à 3.Bon ben j'ai dit une connerie le truc est loin d'être mort, http://open64.sourceforge.net/(...)
-
-
-
[^]Re: un jeu 64 bits...
-
[^]Re: un jeu 64 bits...
Posté par cedric () le 21/11/2002 à 12:38. (lien). Évalué à 2.NicO tu abuses, l'opteron/Athlon 64 est une horreur, je veux meme pas imaginer la gueule de leur decodeur. Ils ont fait comme pour le 32 bits : ajouts d'un nouveau mode avec prefixe...
Le doublement de leur registre c'est sympa, mais c'est pas assez et ils ne sont pas generique (il ne serve qu'aux entiers). Peu d'applications vont vraiment en beneficier au final...-
[+] [^]Re: un jeu 64 bits...
Posté par Jean-Yves B. () le 21/11/2002 à 12:48. (lien). Évalué à -1.Tant qu'on est dans le cambouis, Intel et AMD font toujours le concours idiot du plus long pipeline ? Qui est-ce qui pisseurine le plus loin pour l'instant ? (en bousillant la latence)
-
[^]Re: un jeu 64 bits...
Posté par Moby-Dik () le 21/11/2002 à 12:54. (lien). Évalué à 2.Tu a des stats sur les pertes moyennes liées aux longs pipelines (pertes compensées par divers mécanismes) ? Ou c'est juste histoire de lancer un troll sans envergure...
Je te signale qu'il y a peu de processeurs modernes qui se contentent encore de 4 ou 5 niveaux de pipelines. Cf. le futur processeur "desktop" qu'IBM va filer à Apple (16 étages de pipeline, voir http://arstechnica.com/cpu/02q2/ppc970/ppc970-1.html(...)).-
[^]Re: un jeu 64 bits...
Posté par Jar Jar Binks (page perso, ) le 21/11/2002 à 21:15. (lien). Évalué à 0.Boarf, chez Cray ça fait longtemps qu'ils ont dépassé les 100 niveaux de pipelines. Ça c'est du superscalaire.
-
[^]Re: un jeu 64 bits...
Posté par Nicolas Boulay () le 22/11/2002 à 09:56. (lien). Évalué à 1.Nan, c'est du super pipeline.
Le superscalar c'est quand tu mets 2 pipelines cote à cotes (genre 5 dans les cpu actuels).
-
-
-
-
[^]Re: un jeu 64 bits...
Posté par Moby-Dik () le 21/11/2002 à 12:51. (lien). Évalué à 3.(il ne serve qu'aux entiers). Peu d'applications vont vraiment en beneficier au final
Mouarf :) La majorité des applis manipulent à 99% des entiers et des pointeurs (qui sont aussi stockés dans les dits registres).
Et pour la virgule flottante, il me semble que 3DNow et SSE2 résolvent déjà le problème, non ?-
[^]Re: un jeu 64 bits...
Posté par Mickaël L () le 21/11/2002 à 14:17. (lien). Évalué à 1.Il me semble que c'est la partie arithmétique qui s'occupe des flottants (donc dès le 486DX, mais plus ou moins bien intégré). Les MMX/3dnow/SSE* concernent juste la parallélisation des calculs flottants, non?
C'est une question. Je vais pas me battre là-dessus. Je suis juste un matheux, moi.-
[^]Re: un jeu 64 bits...
Posté par Serge Rossi (page perso, ) le 21/11/2002 à 16:01. (lien). Évalué à 2.(je viens de le voir à l'instant dans la doc de gcc) Il suffit de compiler avec -msse ou -msse2 pour faire executer un maximum de calculs flottants sur ces unités.
Par contre, c'est simple précision seulement pour SSE. SSE2 n'est encore que sur le P4 et pas sur l'XP. Faut attendre l'Oteron pour avoir le SSE2 sur un CPU AMD.
Dans la doc, y'a même marqué qu'on peut essayer -mfpmath=sse,387 pour utiliser à la fois SSE et les unités flotantes classiques x86 pour réaliser les calculs mais c'est marqué comme expérimental.
Faudrait bencher tout ça...
-
[^]Re: un jeu 64 bits...
Posté par frecillia8 () le 21/11/2002 à 16:10. (lien). Évalué à 1.Oui tu as raison c'est le coprocesseur qui est sensé gérer les flottants, maintenant comme le jeu d'instruction est vieux (il date du x87), il utilise une pile de registre comme sur les calculettes HP.
Le problème des calculs sous forme de pile, c'est que ça rends le code impossible (enfin très difficile) à parallèliser, vu que toutes les instructions utilisent un même registre le sommet de la pile (d'ou les multiples dépendance entre instructions).
Résultats les perfs du code x87 sont exécrable, et même des processeurs RISC à 200Mhz arrivent à battre des Pentium relativement récents (j'ai pas le courage de retrouver les chiffres).
Au départ le SSE est conçu pour manipuler des vecteurs de flottants, mais comme il ne souffre pas de cette erreur de conception, la tendance future est de l'utiliser même pour les scalaires et de garder le support x87 uniquement par compatibilité avec les vielles applis.-
[^]Re: un jeu 64 bits...
Posté par Alberto () le 22/11/2002 à 09:17. (lien). Évalué à 2.C'est vrai et faux ce que tu dis.
Certes c'est une pile mais le renommage des registres permet de faire des miracles. C'est lie principalement a l'instruction fxchg qui permet de changer de sommet de pile (elle est "gratuite" sur p2).
Un Athlon est capable de faire 2 operations flottantes par cycle sur c e jeu d'instruction.
Pour info, SSE c'etait que des flottants simple precision, il a fallu attendre SSE2 pour les double...-
[^]Re: un jeu 64 bits...
Posté par frecillia8 () le 22/11/2002 à 11:08. (lien). Évalué à 2.le renommage des registres permet de faire des miracles. C'est lie principalement a l'instruction fxchg qui permet de changer de sommet de pile (elle est "gratuite" sur p2).
Oui je connais FXCHG, mais c'est surtout valable pour un compilateur, j'ai déja essayé de faire ça avec une routine de multiplication de matrices dans du code assembleur à la main, et ça donne sacré mal à la tête
-
-
-
[^]Re: un jeu 64 bits...
Posté par Moby-Dik () le 21/11/2002 à 19:53. (lien). Évalué à 1.Non, l'ALU (Arithmetical and Logical Unit) ne s'occupe que des entiers (et pointeurs, considérés comme des entiers). Les flottants sont traités par la FPU (Floating-point Processing Unit), et aussi récemment par les unités SIMD flottantes (SSE et SSE2).
La FPU a la particularité sur le x86 d'être architecturée de façon particulièrement pourrie : les registres sont organisés en pile et seul le haut de la pile est accessible directement. Les compilateurs doivent donc se faire chier à ordonnancer au mieux les opérations afin de minimiser le nombre de PUSH et POP sur cette pile, ce qui donne des résultats peu glorieux en termes de performances.
-
-
-
[^]Re: un jeu 64 bits...
Posté par Gwenole Beauchesne (page perso, ) le 21/11/2002 à 19:22. (lien). Évalué à 2.Comment ça pas assez génériques? Tous les 16 registres peuvent être adressés indiféremment en 8, 16, 32 ou 64-bit de valeur. e.g. t'es plus limité à %al, %bl et al. pour du 8-bit.
Par ailleurs, l'ABI spécifie que toutes les opérations en virgule flottante passent par l'unité SSE2 pour une précision single et double. Pour une précision de 80-bit, la vieille et pourrie stack FPU x87 est toujours dispo.
Le bénéfice est réel notament car l'ABI est mieux fouttue, et le nombre accru de registres disponibles.
-
-
[^]Re: un jeu 64 bits...
Posté par Gaël Le Mignot (page perso, ) le 21/11/2002 à 13:09. (lien). Évalué à 5.Avoir un porcesseur 64 bits ça ne concerne pas que les histoires d'espace d'addressage (bien que posséder un espace d'addressage virtuel très grand peut permettre des gains de performances, même si la mémoire physique reste inférieure à 4Go, via l'utilisation de techniques de "map"page de fichiers par exemple (man mmap)).
Combiné à des techniques comme le SIMD, les registres permettent d'accélérer à peu près tous les traitements (même si je ne sais pas si le jeu d'instruction de l'Athlon64 permet de faire cela).
Ça peut aussi servir pour faire des calculs en virgule fixe (plus rapide que de la virgule flottante) avec une haute précision. Je ne sais pas si UT2003 utilise ce genre d'astuces, mais ça me semble possible.
Ça permet aussi d'accélérer les copies de zone mémoire (vu qu'avec une seule instruction on passe de 32-bits transférés à 64-bits); bien sûr en temps normal la vitesse du bus est le facteur limitant, mais si les données manipulées sont dans le cache L1, la différence doit devenir visible.-
[^]Re: un jeu 64 bits...
Posté par Moby-Dik () le 21/11/2002 à 13:17. (lien). Évalué à 2.SIMD et transferts de mémoire 64 bits existaient déjà avant sur les Athlon et Intel 32 bits, grâce aux extensions MMX (SIMD entier sur registres de 64 bits) et SSE1/2 (SIMD flottant sur registres de 128 bits).
Par contre comme le dit Nico l'Athlon 64 (ou Hammer) ajoute 8 registres entiers supplémentaires aux 8 existants (qui sont par ailleurs étendus à 64 bits), ce qui n'est pas du luxe ;-))-
[^]Re: un jeu 64 bits...
Posté par Nicolas Boulay () le 21/11/2002 à 13:47. (lien). Évalué à 1.Y'a pas que pour les entiers, cela double aussi pour le SSE2.
-
-
[^]Re: un jeu 64 bits...
Posté par Nicolas Boulay () le 21/11/2002 à 13:56. (lien). Évalué à 2.Le 64 bits d'amd n'a rien à avoir avec le SIMD mais rien du tout. Les registres SSE2 sont déjà de 128 bits et rien ne change de ce coté là.
Le x86-64 ajoute qq petites instructions et un mode d'adressage pour rendre un peu plus carré le jeux d'instructions.
Sinon, l'accélération de copie de zone mémoire ce fait déjà avec l'utilisation de QMOVE qui bouge des paquets de 64 bits (instruction MMX)
La deuxième avancé de l'opteron et la plus important avec les registres mais qui concerne aussi le mode pure 32 bits est l'inclusion du north bridge dans le cpu.
Ainsi la latence d'accés au mémoire diminue. L'opteron gagnerait 20 % en perf pure juste grace à cela. L'accés à la mémoire est ainsi aussi inclue dans le pipeline de la bète.
Je plaisante sur les 64 bits, mais la barrière des 4 Go va devenir vite un handicapte pour le PC, dans le domaine de la CAO beaucoup de station on plus de 4 Go de RAM.
Dans 2 ans, beaucoup seront à 4 Go. Aujourd'hui, les barrettes de 1 Go de RAM sont disponnible à ~600eur, ce qui n'est pas si délirant (il y a un an, la barrette de 512 Mo de mémoire EDO 113 Mhz de SUN pour ultra 5/10 coutait 2400 eur...).-
[^]Prix SUN
Posté par Nicolas Boulay () le 21/11/2002 à 13:59. (lien). Évalué à 1.Petit jeu:
Le dernier monstre de SUN l'ultra Blade 1000 à base de processeurs UltraSparc III peut adresser 8 Go de RAM. Quel était le prix de l'extention de 4Go pour cette machine, il y a un an ? (mais je doute que le prix est beaucoup changé depuis...)-
[^]Re: Prix SUN
Posté par Serge Rossi (page perso, ) le 21/11/2002 à 16:09. (lien). Évalué à 1.Au boulot, on a une station SGI Onyx 2 (enfin station, c'est plutôt la taille armoire) qui a presque 2 ans mais qui a 4 Go de Ram. Pour l'instant ça va encore pour remonter un véhicule complet mais le moment ou on aura besoin de plus est très proche...
Mais bon, la SGI c'est du 64 bits depuis longtemps donc ça roule :-)
-
[^]Re: Prix SUN
Posté par rictus (page perso, ) le 21/11/2002 à 17:27. (lien). Évalué à 2.Arf... t'as raison, SUN pousse quand même un peu loin le bouchon...
quand on aime^H^H^H^H a besoin, on ne compte pas... dans la boite où je suis, pour les stations CAO SUN, on se contente depuis 2 ans d'1 Go de RAM et les stations coûtent environ 15 KE...
Les applis CAO (Pro-engeneer pour ne pas le citer) sont tellement bien écrites qu'on est presque vraiment à l'étroit avec 1 Go de RAM... Bon, en fait, n'y connaissant pas grand chose, je ne sais pas s'il serait possible au niveau de l'appli d'économiser la mémoire...
Enfin tout cela pour dire que jusqu'alors, pour nous, le coût d'une station CAO SUN, c'est 15 KE... et qu'on serait déja plus que content de faire une écomie de 50% en migrant vers de la plateforme PC... et donc avec un budget de 7,5 KE pour un PC, on peut largement se payer 4 Go de RAM (même en RDRAM !)... cela montre bien que 4 Go peuvent vite devenir une limite (dans la mesure où, si la RAM coûte pas cher, alors on n'optimise pas l'appli pour l'économiser)...
Le plus chiant actuellement, c'est d'arriver à continuer à justifier l'achat de stations SUN à 15 KE pour faire tourner ProE, alors qu'il tourne aussi sur PC sous win... (le seul argument qui reste commence à être win, c'est mal, et ça fait pas très crédible devant un gestionnaire...)
Allez messieurs de PTC, on active le portage de ProE pour linux !
-
[^]Re: Prix SUN
Posté par Matafan () le 21/11/2002 à 18:13. (lien). Évalué à 2.Détrompte toi, il n'est pas rare de trouver des machines à plus de 4Go de RAM chez les clients. Sur un pSeries 690 (d'IBM), c'est même 4Go minimum, et jusqu'a... 256Go de RAM. L'intéret de telles machines n'est pas de faire tourner une grosse appli, c'est surtout de faire du partitioning : tu fais tourner plusieurs "instances" de ton OS (AIX ou Linux ou les deux mélangés), comme si tu avais plusieurs machines physiques. Avec l'avantage de la souplesse : en cas de besoin ponctuel, tu peux "éteindre" une partition et en agrandir une nouvelle (plus de CPU, plus de RAM...).
Par contre c'est sûr que c'est pas donné : $33,177.60 le module de 4Go, d'après le site d'IBM.
-
[^]Re: Prix SUN
Posté par thedidouille () le 21/11/2002 à 22:53. (lien). Évalué à 1.J'ai une SunBlade 2000 au taffe, mais y a seulement 2 gigas de ram.
-
[^]Re: Prix SUN
Posté par Nicolas Boulay () le 22/11/2002 à 10:01. (lien). Évalué à 2.Vous n'êtes pas drole vous ne jouer pas à mon petit jeu.
Le prix de l'extention 4Go était de 50_000$...
-
-
-




Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.