Quad 2.93GHz ou Octo 2.26GHz

[Vaolo]

Bonjour,

2 jours que je suis sur le store, que je m'applique à lire les tests, labos, les reponses sur les forums, je n'arrive toujours pas à me décider, je n'ai plus acheté de machine depuis 3 ans, mon dernier est un macbook 2Ghz.

j'ai regardé, les resultats benchmarks des 2 configs, ils sont proches, mais je me méfie de ces résultats de calculs brut.

Pour le meme budget, je peux prendre un OCTO 2.26 ou un QUAD 2.93 (8 Go RAM sur les 2).

Mon métier : développeur d'application, j'ai toujours d'ouvert en meme temps :

• Eclipse (lourd)
• Textmate
• Firefox
• Serveur WEB + serveur d'application + serveur base de donnée
• 2 ou 3 machines virtuelles de démarrée sous windows, ou linux.

J'ai toujours 2 écrans de branchées sur la machine.

Mon problème aujourd'hui c'est que tout cela RAME a mort :sleep: et je suis obligé de travailler avec 2 machines (macbook et linux Pentium4...). j'ai besoin de reactivité !

Aussi, au vue de l'investissement, je compte garder la machine 4/5 ans, en me donnant la possibilité d'upgrader la machine mais pas en racheter une autre...


Je me rends pas bien compte des puissances, reactivités disponibles, vue que la vitesse sur proc n'est plus le critere de selection maintenant...

A votre avis ?

Merci d'avance pour vos retours, je compte un peu sur vos réponses pour prendre une decision.

 

[fgero]

Avec Eclipse, c'est du Java que tu fais, non ?
Java : de ce que j'en subis (!) en tant qu'ingé système sur de très gros serveurs au boulot, c'est à la fois très inefficace (comprendre gourmand en CPU pure, par exemple le GC), et souvent très exigeant en Go de RAM (-xmx énormes sur Websphere).
Les SGBD comme Oracle, c'est souvent très exigeant en RAM (car il faut souvent paramétrer d'énormes buffers pools pour cacher les I/O, en tout cas sur les serveurs que je fréquente).
Plusieurs VMWare = de la RAM verrouillée, évidemment, ça c'est vite calculé.
Java et les SGBD profitent bien des multiprocesseurs, il sont bien parallélisables (quand l'applicaiton est bien écrite) donc plus il y a de cores mieux c'est en environnement serveur.

Maintenant, est-ce que tu développes et fait tourner de gros codes et SGBD en environnement serveurs ? si c'est le cas, pars sur un Octo 2,26 car tes JVM serveur et tes SGBD les exploiteront pour peu qu'ils soient sollicités par de nombreux clients.

Si non, c'est à dire si tu sollicites ta machine plutôt en tant que workstation (que serveur), tu peux te poser la question du Quad 2,93, il faudrait en fait que tu mesures ton activité courante (en terme de CPU, nombre de threads très actifs, et RAM).
Pour la RAM c'est assez facile de savoir regarde la mémoire virtuelle totale que tu références.

J'ai choisi le 2,93 car sa puissance brute est supérieure et des opérations interactives et répétitives de Final Cut (les rendus) n'utilisent pas vraiment les 4 cores (plutot 2) et sont sans doute plus rapides en 2,93 (donc interactivité supérieure, c'est particulier).
Par contre, Compressor utilise tous les cores d'un Octo mais c'est du batch, ça me dérange moins.
Mais c'est chez moi, environnement type workstation, rien à voir avec le boulot (serveurs).
Si ton activité courante est faite de "bursts" de CPU, censés être interactifs (courts), peut-être que le 2,93 est adapté ?
Si ta machines est à fond (>90% CPU) pendant de longues périodes, et que tu as plus de 4 threads qui travaillent régulièrement, alors le 8core est peut-être adapté ?
Enfin, l'utilisation courante (mail, navigation, office) ne justifie en aucune manière 8 cores, évidemment, Snow Leopard ou pas...c'est le reste de l'activité qui est concernée.

Le Quad, contrairement à ce que dit Apple, est parfaitement upgradable à 16Go, les barrettes de 4Go fonctionnent (ça c'est prouvé, confer OWC, Bare Feats), elles ont déjà bien baissé (confer OWC) et baisseront encore à terme. Pour l'instant les 8Go sont très peu chers, pour passer à 16Go peut-être faut-il attendre un peu...

Bref, c'est fonction des typologies de sollicitations (actuelles et futures) que tu fais subir à ta machine.

 

[Vaolo]

Salut fgero,

j'utilise bien cette machine comme poste de travail.

Je crois que je vais partir sur le QUAD 2.93, mon principal blocage était sur le fait que la RAM serait bloquée à 8go, mais tu me donnes une information importante la, elle n'est plus bloquée !


Merci beaucoup pour les infos.

++

 

[fgero]

http://eshop.macsales.com/shop/memory/Mac-Pro-Memory


Mais mesure quand même ton nombre de threads en activité simultanée ET significative quand tu sollicites la machine. Cela peut être un argument pour le 8 core, même si ce dernier à une vitesse d'horloge nettement plus faible à prix égal que le Quad, évidemment.

Si tu peux attendre la rentrée, il pourrait éventuellement y avoir un refresh sur les Mac Pro (nouveaux Nehalem > 3Ghz ?)

 

[Vaolo]

:mouais: .... avec Apple il y a tous les 6 mois des nouveaux ceci et cela.... avant j'attendais, maintenant je n'attends plus !

A force d'attendre, je rame...

c'est décidé je prends le QUAD 2.93.

 

[ntx]

A mon avis, pas de mise à jour de la gamme avant début 2010 ou le renouvellement des architectures des processeurs Intel. Cela fait quelques années que la gamme de MP n'est renouvelée qu'une fois par an. Si des > 3 Ghz sortent, le prix risque d'être très salé pour un gain de performances faible.

 

[Vaolo]

Bonsoir,

Derniere question, pour mes 2 écrans 22 pouces,

pour avoir sur mes 2 écrans une résolution native 1680 x 1050,

Est ce que j'ai besoin de 2 carte GT120 pour ca ? ou une seule suffit ?

Merci d'avance.

 

[ntx]

Une seule suffit.

 

[thecrow]

Et un adaptateur en plus car il n'y a qu'un DVI et un mini display port

 

[Vaolo]

Merci pour vos retours

 

[iota]

Salut.

Java : de ce que j'en subis (!) en tant qu'ingé système sur de très gros serveurs au boulot, c'est à la fois très inefficace (comprendre gourmand en CPU pure, par exemple le GC), et souvent très exigeant en Go de RAM (-xmx énormes sur Websphere).

Très inefficace et très gourmand en RAM par rapport à quoi ?

@+
iota

PS : désolé pour le HS, mais je suis juste curieux

 

[fgero]

Bonjour,

"Par rapport" à un programme écrit dans un langage dont l'environnement n'implique pas de passer une bonne part de son temps CPU à faire des choses inutiles (du point de vue de la finalité du programme : l'application). Je ne suis pas développeur, mais pour "profiler" régulièrement d'un point de vue système beaucoup de programmes Java sous Websphere livrés par les développeurs avant qu'ils ne partent en production, je trouve toujours une part ahurissante de la CPU consommée pour autre chose que du code "utile". Par exemple, lors des benchs, le GC consomme souvent une part prépondérante de CPU, ce qui est un comble !. Tout ça parce que le programmeur ne se préoccupe pas vraiment du devenir ou du nombre des objets qu'il manipule, "la machine suivra".

"Par rapport" à des usages de programmation (liés au langage mais surtout à son 'environnement) qui ne génèrent que rarement des fuites mémoires, alors que beaucoup de ce que livrent les développeurs Java accumule à la longue des pages non libérées, ce qui inévitablement finit mal. Combien de JVM paramétrées avec un -Xmx de 1Go, tout ça pour héberger quelques petites applis mal écrites et qui fuient...pour tenir une semaine sans avoir à recycler la JVM...

"Par rapport" à des environnements d'exécution comme les moniteurs transactionnels, par exemple sur Mainframe type IMS/CICS (c'est un exemple) qui sont autrement plus efficaces que les Websphere et consors, et qui hébergent des transactions écrites avec à l'esprit la résistance dans le temps, l'économie mémoire et CPU. Oui, c'est du Cobol ou de l'assembleur...mais ça tient des millions de transactions par jour.

Il en va du langage, mais surtout de la manière de travailler qui va avec.
Et ce que je vois passer sur les environnements Java va dans le sens du relâchement et du gâchis de ressources serveur.

Bien sûr, je parle ici de programmes Java destinés à tourner sur un gros serveur et donc à être appelé des milliers de fois par jour par de nombreux utilisateurs, et ce dans une JVM qui reste des semaines ou des mois sans être arrêtée...faut que ça soit PROPRE.

Je ne parlais pas des programmes Java qui tournent unitairement sur les postes utilisateurs. Là, l'éventuelle pauvre qualité de programmation et tous les machins genre GC ne se verront pas, car le programme à une vie courte et ne sera pas appelé sans cesse dans le même environnement.

My 2 cents.

A part ça, je vois bien qu'une fois bien écrite, avec certaines choses à l'esprit dès le départ, une "transaction" Java sous Websphere peut très bien marcher et être efficace...

 

[jnj]

Salut

perso je ne suis pas encore sur Mac. Justement j'y songe très fort à force de rencontrer des pb sous Win (je suis développeur d'appli web moi aussi)
mais cela fera l'objet d'autres posts

venons en à ta problématique : au vu de ta manière de bosser tu optes pour un quad : ok, j'ai vu les conseils donnés par ailleurs, ils tiennent la route je suis un ancien benchmarkeur sous unix d'appli Oracle.

là où je coince : "tu veux garder ta bécane 4 ou 5 ans" Pour un simple usager en bureautique + Internet c'est parfait. J'ai encore un PC Pentium 4 1.6 Ghz en usage à la maison : il ne fait que du Word/ Excel + firefox + jeux pour les moins de 10 ans;
il a 7 ans révolus. Il va plutôt vite pour ce type de boulot.

Si tu es comme moi un codeur indépendant, ben je pense que tu fais fausse route
En effet, comptabilises le temps perdu à cause d'une bécane trop lente, trop chargée sans compter le stress négatif lié. Tu perds de l'argent. Mieux vaut changer de bécane tous les 3 ans. L'idéal est de préparer cela dès l'achat de la machine : données stockées à part, disque externe ou disque réseau un max de périph en USB et non pas en interne.

Perso je prépare ma migration depuis un Dell double coeur de 2 ans vers un Mac duo ou quad (je ne fais pas de java donc j'ai moins de consommation de ressources) Dans 3 ans, je le revands d'occaze ou je le recycle dans la famille gratuitement et je prend une nouvelle bécane. Le temps passé à poireauter devant une bécane, PC ou Mac, n'est pas facturable au client !

à +