[Portable] Achat portable développeur

[Currahee]

Bonjour à tous,

Je cherche à m'acheter en cette fin de période de soldes un pc portable.

1) Budget : 700 - 900 Euros

2) Ecran : 17 ou 16 pouces

3) Utilisation : Pour faire prioritairement du développement + Internet + Lecture de Films

Entre espace mémoire et vitesse de disque, je choisis sans hésiter la vitesse du disque (un paramètre à priori important pour du dev).

Sinon niveau marques j'ai ciblé DELL et TOSHIBA. Chez DELL quelle série correspondrait le plus à mes besoins : Vostro ou Studio ? (ou XPS).

Merci d'avance pour vos conseils

[F.Saad]

Envoyé par Currahee

Bonjour à tous,

Je cherche à m'acheter en cette fin de période de soldes un pc portable.

1) Budget : 700 - 900 Euros

2) Ecran : 17 ou 16 pouces

3) Utilisation : Pour faire prioritairement du développement + Internet + Lecture de Films

Entre espace mémoire et vitesse de disque, je choisis sans hésiter la vitesse du disque (un paramètre à priori important pour du dev).

Sinon niveau marques j'ai ciblé DELL et TOSHIBA. Chez DELL quelle série correspondrait le plus à mes besoins : Vostro ou Studio ? (ou XPS).

Merci d'avance pour vos conseils

oublie XPS, ca vaut rien.

Maintenant Vostro v. Studio.
C'est une bonne question :
En terme de performance, disons qu'un Vostro Config Max vaudrea moins qu'un Studio.
Cependant, meme en Config Max, ca reste assez limité pour quequechose qui est censé dureé. mais ca ne vaudra jamais un S 1555
Sinon, Si comme tu l'as noté tu cherche une bonne vitesse de disque.
Le Studio a ce que tu veut. le HDD 320 est un 7200 rpm.
si tu peut acheter en italie, tu trouvera celui la, je crois que c'est le meilleur prix au monde pour le Studio 1555
http://compraonline.mediaworld.it/we...tegory_rn=1504
l'ecran est un 15'6 Cependant. Mais je te jure que 15 6 ou 16 c'est pas trés different :/

[nouknouk]

salut,

pour moi on se fout un peu de la marque, de la série, etc...
Les choses qui me semblent importantes sont (dans l'ordre du plus important au moins important):

1- une résolution maximum ! Programmer, c'est passer des heures et des heures devant son IDE préféré pour taper et relire du code. Plus ton écran aura une grosse résolution, moins tu perdras de temps à scroller, déscroller, etc...
Les IDE récents ont une forte tendance à remplir l'écran de plein de petites palettes (fichiers projet, navigateur de classe, debug output, ...) qui pompent sur la surface laissée à la fin à l'éditeur de code. Plus grosse sera ta résolution, plus tu verras d'un coup de code.

Bien entendu la résolution dépend de ta diagonale. Un 15 pouces en 1920x1200 me semble exagéré: tout sera écrit tout petit et tu te flingueras les yeux au bout d'une heure.
Perso, j'ai opté pour du 1680x1050 pour un 15,4 pouces. J'adore et je ne reviendrais pas en arrière. Par contre, j'ai testé le 1920x1200 sur du 17 pouces et là ça devient trop petit à mon goût.

L'idéal étant l'écran externe supplémentaire, genre 23 ou 24 pouces avec du 2048 x milleQuelqueChose. Idéal si tu bosses 90% du temps au même endroit (et si tu développes sur un bureau, par sur le canapé avec le portable sur les genoux ).

L'écran (enfin surtout la résolution), c'est la chose la plus primordiale à mes yeux. Le choix doit vraiment être réfléchi. A noter qu'on s'en tape un peu de la fidélité du rendu des couleurs, etc... Il faut juste que ton écran ne soit pas flou non plus


2- Un clavier bien agencé ! C'est tout con mais hyper important à l'usage et on n'y pense pas quand on achète.
Autant le pavé numérique n'est finalement pas indispensable (on s'y fait vite à son absence), autant certaines touches sont primordiales: page up/Down, home/End, Suppr/Del.
Attention à ce que ces touches ne soient pas uniquement accessibles au moyen d'un combo avec une touche fonction (Fn). C'est mon cas, et c'est vraiment relou.
Egalement à noter: certains claviers ont les touches [Fn] et [Ctrl] dans un sens (gauche/droite), d'autres c'est le contraire. A méditer car ça peut dérouter de ne plus avoir sa touche Fn (resp. sa touche Ctrl) tout en bas à gauche du clavier.


3- De la RAM, beaucoup de RAM. Tout dépend de l'environnement avec lequel tu développes, mais certains sont très gourmands en RAM (Eclipse notamment). 2Go ne me semblent pas superflus et de toute façon au prix du Go actuel, ça ne plombera pas ton budget.


4- un disque rapide, 7200trs/min minimum. Déjà dit. L'idéal étant le SSD même si perso j'ai pas non plus noté une immense différence avec mon ancien 7200trs/min (OCZ Vertex 128Go, 350€ environ) pour du dev. Java.


5- un processeur dual core. C'est pas indispensable mais non seulement c'est agréable et surtout ça permet de faire des tests qu'on ne pourra pas avec un simple core (l'inverse étant possible, qui peut le plus peut le moins). Les Core 2 Duo ayant ma préférence personnelle.
Il faut bien noter que désormais les processeurs sont bien assez puissant pour gérer un environnement de développement. Donc opter pour un processeur haut de gamme ne fera qu'augmenter la facture sans apporter aucun confort supplémentaire.

5- accessoirement un pavé tactile pour la souris qui puisse se désactiver quand on a une souris externe. Rien de plus énervant que commencer à taper du code puis de s'apercevoir que le curseur a bougé parce qu'en posant les mains ça a détecté un 'clic gauche' qui a bougé le curseur.

My 2 cents.

[F.Saad]

Ca merite une punaise !

[jabbounet]

si le(s) langages dans le(s)quels tu développe sont compilé pense prendre un bon processeurs et un disque avec un bon taux de transfert

un compilateur est très gourmand en CPU et en accès disque (lors de la génération des binaires/executables).

[nouknouk]

Envoyé par jabbounet

si le(s) langages dans le(s)quels tu développe sont compilé pense prendre un bon processeurs et un disque avec un bon taux de transfert

Autant pour moi le disque dur est effectivement relativement important (ie. bannir les 4200trs/min, et à prix égal privilégier le 7200trs/min plus petit), autant gaspiller de l'argent dans un processeur haut de gamme est amha inutile car 99% du temps, les compilations sont incrémentales. tout l'argent qui n'ira pas dans le processeur pourra être utilisé à meilleur escient ailleurs.

- en C++ le gros du boulot sera assuré par le linker ... qui passera grosso modo son temps à attendre que le disque dur (ou le cache mémoire) lui fournisse les fichiers dont il a besoin.

- en Java, Eclipse par exemple sait compiler en arrière plan pendant que tu codes. Tu n'as donc même pas de 'vraie' étape de compilation avant de pouvoir tester ton changement de code.

[jabbounet]

oui la compilation incrémentale est bien pratique,

mais parfois tu dois quand même tout recompiler. (checkout d'une nouvelle branche, build d'une release, ...) et la le cpu est en général sollicité a environ 100%

ensuite il faut voir si tu developpe tout sur le pc ou si tu accède a un serveur de dev via un vpn.

[nouknouk]

Envoyé par jabbounet

mais parfois tu dois quand même tout recompiler. (checkout d'une nouvelle branche, build d'une release, ...) et la le cpu est en général sollicité a environ 100%

Sauf que la compilation complète d'un projet c'est ce que tu fais 1 fois sur 100 ; les 99 autres fois c'est de l'incrémental.

Alors que ta compilation prenne même 50% de temps en plus, si au quotidien la différence n'est visible qu'une fois sur 100, on s'en balance un peu.

[jabbounet]

Ca dépend de la taille du projet. j'ai vu des softs qui mettaient 8 h a compiler sur des machines a 8 cpu sparc.

bon je ne crois pas que ce sera son usage. mais ce n'est pas a négliger je pense.

[nouknouk]

8 heures de compil ?! Vous compiliez sur un octo de Sparc V7 ou bien c'était la compilation de l'ensemble du soft embarqué dans les fusées Ariane ?

Le dernier gros projet en C++ sur lequel j'ai bossé pesait un million de lignes de code. Il était par ailleurs basé sur Qt qui ajoute un pré-processing des fichiers headers.

On compilait sur nos machines de bureau, qui embarquait des mono-processeurs moyens pour l'époque, des Pentium 4 si je me souviens bien. Et à l'époque, même si on avais certes le temps de prendre un café pour une recompil' complète, on ne dépassait jamais les 20 ou 30 minutes.

Comme dit précédemment, une recompilation intégrale n'arrive quasiment jamais dans les faits. Personnellement, sur le projet ci-dessus, on n'a jamais eu à se plaindre de la lenteur de compilation alors que comparé aux CPUs d'il y a 4 ans, le moindre CPU bas/moyen de gamme du moment les pulvérise.

Autre exemple: le noyau linux qui fait maintenant dans les 6 millions de lignes de codes, et qui compilait déjà en moins de 2h30 sur un P3 500 à l'époque.

[F.Saad]

Envoyé par nouknouk

8 heures de compil ?! Vous compiliez sur un octo de Sparc V7 ou bien c'était la compilation de l'ensemble du soft embarqué dans les fusées Ariane ?

Le dernier gros projet en C++ sur lequel j'ai bossé pesait un million de lignes de code. Il était par ailleurs basé sur Qt qui ajoute un pré-processing des fichiers headers.

On compilait sur nos machines de bureau, qui embarquait des mono-processeurs moyens pour l'époque, des Pentium 4 si je me souviens bien. Et à l'époque, même si on avais certes le temps de prendre un café pour une recompil' complète, on ne dépassait jamais les 20 ou 30 minutes.

Comme dit précédemment, une recompilation intégrale n'arrive quasiment jamais dans les faits. Personnellement, sur le projet ci-dessus, on n'a jamais eu à se plaindre de la lenteur de compilation alors que comparé aux CPUs d'il y a 4 ans, le moindre CPU bas/moyen de gamme du moment les pulvérise.

Autre exemple: le noyau linux qui fait maintenant dans les 6 millions de lignes de codes, et qui compilait déjà en moins de 2h30 sur un P3 500 à l'époque.

lol ? le serveur XEON de OVH me prend 1 h 40 en moyenne pour compiler la tarball SQL pour usage avec GCC avec le ./Configure en + q_q

[jabbounet]

Envoyé par nouknouk

8 heures de compil ?! Vous compiliez sur un octo de Sparc V7 ou bien c'était la compilation de l'ensemble du soft embarqué dans les fusées Ariane ?

Le dernier gros projet en C++ sur lequel j'ai bossé pesait un million de lignes de code. Il était par ailleurs basé sur Qt qui ajoute un pré-processing des fichiers headers.

On compilait sur nos machines de bureau, qui embarquait des mono-processeurs moyens pour l'époque, des Pentium 4 si je me souviens bien. Et à l'époque, même si on avais certes le temps de prendre un café pour une recompil' complète, on ne dépassait jamais les 20 ou 30 minutes.

Comme dit précédemment, une recompilation intégrale n'arrive quasiment jamais dans les faits. Personnellement, sur le projet ci-dessus, on n'a jamais eu à se plaindre de la lenteur de compilation alors que comparé aux CPUs d'il y a 4 ans, le moindre CPU bas/moyen de gamme du moment les pulvérise.

Autre exemple: le noyau linux qui fait maintenant dans les 6 millions de lignes de codes, et qui compilait déjà en moins de 2h30 sur un P3 500 à l'époque.

celui d'un train suffira mais c'etait il y'a quelqeus années.

[nouknouk]

Envoyé par jabbounet

celui d'un train suffira mais c'etait il y'a quelqeus années.

... ce qui confirme que dans le cadre d'un achat d'un portable pour travailler sur des projets persos et en prenant en compte que dans un projet solo ou en petite équipe, la recompilation complète d'un projet est d'autant plus rare, la puissance d'un processeur actuel de moyenne gamme est largement suffisante.

Evidemment, Currahee nous aurait demandé conseil pour acheter une grappe de serveurs de compilation pour son entreprise qui a 30 développeurs à plein temps sur un projet de 10 millions de lignes de code, le tout avec un budget de 30k€, la réponse n'aurait vraisemblablement pas été la même

Dans son cas à lui, mieux vaut donc investir dans un autre composant qui ne pourra lui être que plus utile.

[jabbounet]

quand tu fait du dev tu passe un temps non négligeable a

editer/compiler/tester

la phase compile (même incrémentale) sera non négligeable donc pour moi le proc n'est pas a négliger


apres il faut aussi regarder quelle seront ses autres taches sur son ordi, car le dev ne fait pas tout

après on regarde souvent ce qui se fait dans le monde open source quand on fait des dev perso, on récupère des source de libs/soft que l'on regarde et recompile pour voir comment ça marche.....

[nouknouk]

Envoyé par jabbounet

la phase compile (même incrémentale) sera non négligeable donc pour moi le proc n'est pas a négliger

Et comme dit auparavant, quand tu modifies 10 lignes de code dans 5 fichiers entre chaque compil, l'incrémental passera son temps à attendre que le linker soit alimenté en fichiers.

Je ne parle même pas des chaînes de compil classique qui ne tirent généralement pas partie des processeurs multicoeurs (une compil du kernel avec mon core 2 duo sous debian + gcc = un des deux coeurs du CPU part systématiquement au PMU du coin tellement on ne lui donne rien à faire).

Mais tu as certainement raison: avec un budget de 700-900€, il a tout intérêt à se payer un Quad Core Extreme-truc qui ne servira quasiment à rien plutôt qu'investir dans un meilleur écran qui lui fera gagner des dizaines de minutes par jour car il scrollera deux fois moins dans son code au cours de la journée

apres il faut aussi regarder quelle seront ses autres taches sur son ordi, car le dev ne fait pas tout

"développement + Internet + Lecture de Films" => j'ai pas vu de modélisation 3D, de Crysis 7, de montage/encodage de vidéo ou quoi que ce soit d'autre dans sa description qui laisse penser qu'un proc surdimensionné lui soit nécessaire.

après on regarde souvent ce qui se fait dans le monde open source quand on fait des dev perso, on récupère des source de libs/soft que l'on regarde et recompile pour voir comment ça marche.....

... et on compile ... une fois chaque lib et quand on fait sa ptite modif, on fait de ... l'incrémental.

Ce sera tout pour moi.

[jabbounet]

Code :

1
2
Mais tu as certainement raison, avec un budget de 600-700€, il a tout intérêt à se payer un Quad Core Extreme-truc qui ne servira quasiment à rien plutôt qu'investir dans un meilleur écran qui lui fera gagner des dizaines de minutes par jour car il scrollera deux fois moins dans son code au cours de la journée

je n'ai pas dit de tapper dans le quad core extreme, j'ai dit que cela n'étais pas a négliger tout comme les accès disques, c'est tout.

[jabbounet]

Je ne parle même pas des chaînes de compil classique qui ne tirent généralement pas partie des processeurs multicoeurs (une compil du kernel avec mon core 2 duo sous debian + gcc = un des deux coeurs du CPU part systématiquement au PMU du coin tellement on ne lui donne rien à faire).

tu peux demander a make de lancer plusieurs process de compile en parallèle

genre make -j 2 ou plus (si tu as plusieurs coeurs ça ira plus vite )

[Currahee]

Un immense merci pour vos réponses Je ne pensais pas que mon post allait lancer un tel débat, mais tant mieux, car au moins ça argumente sévère, et le sujet est constructif.

Merci Nouknouk pour les points essentiels de ton premier post. Si j'avais déjà en tête l'importance de la RAM, d'un proc dual core et l'intuition qu'il me fallait une vitesse de disque importante j'avais complètement zappé la résolution écran.

Sur le duo processeur - carte graphique, je précise que je ne suis qu'un faux nymphormaticien en devenir et que je n'ai pas le temps de m'adonner aux jeux 3D. Donc je ne vais pas vous départager sur le débat lancé. Et puis si je voulais le top du top du top, je mettrais plus d'oseille sur la table...

Je vais essayer de m'attaquer à la config de DELL Studio 17 et 15 sur le site, voir ce que ça donne.

Par contre, si vous voyez ce que vous considérez comme une affaire en cette fin de soldes sur les sites de vente quels qu'ils soient, n'hésitez pas à me le signaler Parce que moi quand je navigue sur ces sites, j'ai les fesses qui frétillent mais n'ai pas le recul nécessaire pour faire le bon choix rationnel.

PS : F.Saad, pourquoi bannir les XPS ???

[jabbounet]

dell perd un peu en qualité ces dernier temps. et c'est en général assez cher.

[F.Saad]

Comme il a dit, les XPS sont a banir parcequ'il n'apporte rien sur le plan performance au studio dont ils sont les successeurs.
je te conseil toujours le Studio 1555 (pas 153x), c'est la meilleure affaire de l'été