Bonjour
 
J'envisage l'achat d'une nouvelle machine qui servirait :
-70% à du développement (où il faut un peu de proc mais surtout des temps d’accès disque court puisque on compile pleins de petits fichiers) => SSD NVME à priori
-10% à du calcul numérique pas super exigeant, les 16Go de RAM que j'ai aujourd'hui font très bien le job.
-10% à de la CAO pas très exigeante (une 650 TI fait depuis 2014 plus que très bien le job), de ce que j'ai compris me faut du OpenGl surtout. Mais je n'arrive pas à voir si les video intégrées seraient capables de faire ce que faisaient une 650 TI de 2014.
-10% de la bureautique qui évidement sera peu critique au regard du reste
 
Outre le NVME pour le SSD qui me parait un point justifiant le changement de machine je cherche une machine au bon rapport qualité prix, pas premier prix donc et pas non plus à la recherche de la dernière nouveauté qui permet de gagner 0.001%
 
J'ai besoin de pouvoir ajouter  
-Une carte mère capable de faire respirer tout ça efficacement.
-De la rame stable, toujours au bon rapport qualité prix.
-un lecteur DVD (sata),  
-un DD supplémentaire (1 second sata)
-une bonne alim (l'énergie c'est important pour moi)
-du réseau sans exigences particulières
-wifi pas nécessaire
-Bluetooth ça peut être bien en >5 depuis que je suis fan des oreillettes mais ce n'est pas indispensable car fonctionne très bien avec les dongle.
-de l'usb à gogo
-un boitier minitour tel que le Zalman T6 (mais je ne suis pas marié à celui là)
 
Auriez vous des choses à me recommander ?
 
Je m’étais fait une sélection fin d'année dernière que je n'avais pas acheté faute de temps pour finir de m'en occuper. Je ne vous souffle pas ici ce que j'avais repéré pour ne pas vous influencer...
 
Un budget de 500-600€ HT (sans écran, clavier souris) correspond à ce que j'ai en tête comme "bon rapport qualité prix", mais je peux me tromper.
 
Merci par avance pour vos conseils et suggestions

 
Etant donné ton utilisation principale (compilation de projets), j'ai un gros doute. A mon avis, la différence de temps de compil entre un NVME et un vulgaire SSD SATA 2.5 ne sera pas significative.
 
Globalement, tu sembles satisfait de ta machine actuelle, et les nouvelles générations CPU/GPU arrivent bientôt. De plus, les prix sont loin d'être revenus au niveau d'il y a 3 ans. A ta place, j'attendrais pour changer de config. As-tu déjà un SSD sur ta machine actuelle? A la limite, si tu veux vraiment tester le NVME, utilise une interface PCie > NVME M.2. Cela dit, il faut vérifier si tu as un port PCIe libre, puis ses specs.

 
Globalement en accord avec cette réponse.
 
Ceci dis je doute de la réelle utilité d'un M.2 NVME personnellement dans ce cas d'utilisation. Je pense qu'un sata III classique pourrait nettement faire le job.
Pour profiter pleinement de la bande passante supérieur d'un NVME, il faut avoir de gros fichier à transférer. Et je parle pas de plusieurs petits fichiers qui font un gros poid hin, ça, ça compte pas.

Bonjour et merci pour la réponse
 
J'ai une machine de 2014 achetée avec la même recherche de bon rapport qualité prix  
i5-4460
CM AsRock H97 Anniversary
16Go de DDR3 (qui me servent vraiment rarement , quand je fais du calcul)
et une 650 Ti qui me sert pour quelques outils de CAO  
Le tout sous W10 comme mes 6 portables Thinkpad génération X30 (2012) eux aussi sur SSD.
 
Je suis en ce moment fortement désappointé par le mur de 2025 imposé par Windows avec la fin du support de W10 et l'obligation de changer toutes mes machines pour passer à W11.
 
Sur les portables qui vont très bien, je vais faire l'effort de migrer sous Linux
Sur ce PC fixe je ne peux pas à cause de plusieurs logiciels.
Et comme je passe beaucoup de temps en développement dessus je peux prétendre à un gain de productivité avec une machine plus puissante donc je regardais pour sauter le pas.

 
Ce n'est absolument pas un mur. Windows 10 cessera de recevoir des nouveautés et correctifs, c'est tout. Mais les mises à jour de sécurité continueront encore un moment.

Je ne trouve pas cette information chez MS. Je ne vois qu'une fin de support en octobre 2025.

Il y a bande passante en débit max mais il y a aussi les temps d’accès.  
Avec des projets de dev qui ont beaucoup de petits fichiers je le vois au quotidien, sur les transferts réseaux, sur clé USB, sur disque ou SSD ; un transfert de gros fichiers se fera au débit maxi officiel du support, le transfert du même volume de petits fichiers prend infiniment plus de temps, temps quelquefois dramatiquement lent quand les supports ne sont pas performants (un clé usb par exemple).
Pour preuve il suffit d'essayer de transférer une montagne de petits fichiers puis de transférer la même chose zippé (1 seul fichier), on gagne infiniment plus que le rapport de poids total.

Bonjour,
 
Augmenter la RAM pour faire un RAMDISK ?
Et copier les sources sur celui-ci pendant le "travail" et n'utiliser que lui pendant la compilation.
 
La, en temps d'accès, ça va décoiffer.
 
Le seul inconvénient, préparer les données sur ce ramdisk avant et faire une sauvegarde après. Et voir si la taille des sources + compilés ne sont pas trop volumineuses vs taille ramdisk.  
 
Tu peux par ex, utiliser le logiciel gratuit de gestion de conf Git et créer un repository sur un SSD local, voire depuis internet (Github par ex). Tu mets tes sources dessus. Ensuite quand tu es prêt à travailler, tu fais un Git pull sur ton ramdisk pour récupérer toutes tes sources. Et quand tu as fini ou quand tu estimes que c'est nécessaire, un Git push pour les envoyer sur ton repo Git distant (SSD local ou Github). Tu as ainsi en plus un historique de tes modifications grâce à tous tes Git commit que tu fais pendant ton dev. Et toutes tes compilations sont faites depuis le RAMDISK. Y a pas plus rapide.
 
C'est un peu moins secure aussi en cas de crash du PC.  
Mais si tu envoies les modifications de temps en temps sur ton repo Git distant, tu diminues le risque de perdre tes modifications.
 
En revanche, il faut voir comment créer un ramdisk sous Windows (jamais fait, seulement sous Linux, désolé).
 
Pour installer Git sur Windows, c'est très simple en revanche. https://git-scm.com/downloads

CPU : Intel Core i3-12100 : https://www.ldlc.com/fiche/PB00473446.html : 170 €
RAM : 16 Go DDR4 : https://www.amazon.fr/Crucial-CT32G [...] 08C53LL9J/ : 70 €
CM : ASUS PRO H610M-C D4-CSM : https://www.ldlc.com/fiche/PB00499280.html : 123 €
SSD : Crucial MX500 500 Mo : https://www.amazon.fr/Crucial-CT200 [...] 0786QNS9B/ : 50 €
Alim : Seasonic SSR-550GB3 : https://www.amazon.fr/Seasonic-S12I [...] ZT5N/?th=1 : 64 €

Avec ta mobo actuelle (H97), les ports PCIe dispos sont des gen 2.0 x1... donc ils vont brider un SSD NVME. L'interface n'est pas intéressante ici.
 
Le temps d'accès est important, mais ton utilisation ne permettra pas de constater la différence entre SSD SATA et NVME. Ce n'est pas assez intensif.

Dans quel genre d'usage les vitesses d’accès du MVME se voient elle ?

Super merci je regarde ca ce I3 sort meilleur que le 5600x dans les 2 premiers comparatifs que j'ai regardé en plus, pour moins de conso et beaucoup moins cher  
 

A froid comme ça, dans des applications avec des débits élevés genre logiciel vidéo (haute définition), ou des applications serveurs avec un nombre violent de requêtes qui exploitent les IOPS élevés.
 
edit : perso, je tourne avec un MX500 (SATA 2.5" ) de 250 Go.
Là je pense qu'entre ta config actuelle, et une nouvelle, pour une compil donnée, ton chrono va passer de 2m30s à 2m15s... Je dis ça au doigt mouillé, mais c'est pour donner l'idée.

Je pense qu'il gagnerait plus à garder sa configuration actuelle et utiliser un RAMDISK (qui utilise donc une partie de la RAM).
 
Une idée de la taille des sources (+ les fichiers compilés) ?
 
Histoire de voir si c'est possible de travailler qu'avec de la RAM.
 
Comme tu précises qu'en plus avec 16 Go tu es large, possible que tu ne sois même pas obligé d'en ajouter.
 
Si toutes tes sources (+ fichiers compilés) prennent par exemple, 1 Go, tu crées un RAMDISK de 2 Go pour être large. Les applications n'auront donc plus que 14 Go mais qui pourrait toujours être suffisant.
 
Si c'est le logiciel Git qui te fait peur (c'est pourtant très pratique quand on fait du dev), alors tu peux simplement passer par des fichiers ZIP.
 
Tu sauvegardes tes sources au format ZIP sur un disque quelconque (SSD ou pas). Tu extrais ton ZIP sur le RAMDISK. Tu compiles ensuite les sources qui ont été dézippées sur ce RAMDISK autant de fois que tu veux. Tu ne pourras pas faire plus rapide car TOUT est en RAM. (pas d'accès disque).
 
Et quand tu as fini, tu refais un ZIP pour le recopier sur le disque (SSD ou pas).
 
Tu perds donc juste du temps dans les transferts du fichier ZIP pour sauvegarder ou restaurer car le RAMDISK s'efface bien sur quand tu arrêtes le PC.
 
Grâce à cela, je pense que tu peux améliorer significativement tes durées de compilation, le tout gratuitement (si pas besoin d'augmenter la RAM).

Je suis en train de regarder pour faire du RAMDisk
 
Non seulement je pratique Git mais en plus apparemment les outils proposés pour faire ça offrent une synchro avec le RAMdisk.
C'est au pire quelques centaines de Mo à compiler et avec pleins de trucs ouverts je me suis rarement vu atteindre les 8G

Personnellement, je testerais d'abord cette solution de RAMDisk avant de vouloir changer de PC.
 
A toi de voir.
 
C'est peut-être ton CPU qui ne suivra plus après ...  
Quoiqu'un i5-4460, ça doit encore bien dépoter.
 
La bande passante de la DDR3 pourrait "un peu" te limiter aussi, surtout face à de la DDR4 ou 5 d'une nouvelle config si tu venais à utiliser un RAMDisk sur la nouvelle.
Mais bon ...

Si on peut allouer logiciellement une partie de la RAM système au RAMdisk, cela pourrait servir de test de perf de référence. Ca vaut le coup d'essayer, surtout que c'est gratuit. Mais à la longue, c'est pas un peu fastidieux? On peut scripter les tâches mais enfin... Je crains aussi que le CPU ne devienne limitant, mais le test pourrait servir de repère.

je teste RAMdisk pour finir de me déprimer car au fond il n'y a que ce maudit 2025 qui pose vraiment soucis
pendant que ça compile au pire je bois un café, au mieux je réfléchis à mon code à venir.... c'est pas vraiment un problème tout ça en fait
 
Sur les bench le I5-4460 semble bien à la masse par rapport au i3-12100. Étonnant d'ailleurs j'aurais pensé les i3 tout mous, sans turbo ni rien comme dans l'ancien temps.

Je suis en train de tester RamDisk mais je crois que je suis déjà nul dans mon diag initial car test de compilation sans rien changer (sur SSD) => les 4 cœurs de mon i5 sont à 100%...

Pas vraiment en fait, surtout si tu utilises Git.
 
Car il est quand même préférable d'utiliser un logiciel de conf quand on fait du dev, même si on est le seul développeur.
C'est un outil tellement pratique.
 
Du coup, on perd juste du temps lors des push/pull avec le repo Git.
 
Mais même en utilisation courante (avec un disque donc), on a aussi tendance à faire les mêmes opérations.
 
Le plus gros point noir, en revanche, c'est en cas de crash du PC. Cela peut arriver si le binaire qu'on génère fait une opération qui déstabilise l'OS.
Car la, tu perds tout. Donc pour des dev un peu "touchy", cela peut être risqué. Mais on minimise ce souci si on utilise justement un repo Git en parallèle car il y a une sauvegarde externe (sur l'autre disque ou sur internet).

La, c'est embettant.
 
Comme quoi, mon hypothèse que ton CPU soit limitant (je parlais dans le cas d'un RAMdisk) est finalement plausible car tu as déjà le problème avec un SSD. Donc finalement un RAMDisk ne devrait pas beaucoup aider...
 
Attention, possible que ton CPU prenne plus de % à cause des accès disque. Chose qui pourrait diminuer avec l'utilisation de la RAM et donc plus de puissance CPU dédiée à la compilation. Mais le gain, s'il y a gain, ne devrait pas être transcendant.
 
J'ai bien peur que finalement ton CPU va te limiter...  

Le bus mémoire a été quand même pas mal amélioré entre ces 2 générations.
Ne serait-ce la RAM (DDR3 vs DDR4/5).

arf test de compilation négatif (tout pareil à pas grand chose prés) mais en fait j'ai copié qu'une partie du code sur le ramdisk (le mien), j'ai des tonnes de trucs qui sont liée à l'IDE, là c'est une misère à mettre dans le ramdisk, faut que je reparamètre pleins de trucs.
 
Bon mais du coup que le NVME fasse ou pas gagner des choses le CPU a beaucoup à gagner
Faut que je remonte les exigences dessus

 
D'où le fastidieux, et lors de certaines màj de ton IDE, ces sources sont parfois mises également à jour. Donc il faudra penser à maintenir.
 
Par contre, pour le compilo, je suis surpris que tes 4 coeurs soient busy. Ton IDE est quand même efficace. J'ai souvent vu un core qui travaille, et les autres qui foutaient rien. Ou alors les éditeurs progressent simplement.

C'est quoi ton IDE ?
 
Visual Studio ?
Eclipse ?

Là je testais un projet sous Eclipse transformé par STMicroelectronics.
Toutes les libs de la couche HAL, de loin le plus gros, est je ne sais pas où, configurée je ne sais pas comment.
Vu le château de carte qu'est Eclipse (ici parfaitement stabilisé par ST) je préfère ne pas tenter de bricolage.

L'upgrade est donc justifié du coup.
Ne serait-ce pour le CPU.

Ca je confirme ...  

bon
 
Il ne me reste qu'à changer mon cahier des charges pour un proc de compétition "bon rapport qualité prix   "
et/ ou continuer de me plaindre de cette ahurissant obligation de changer de machine imposée par MS

 
Ouais mais je pense pas que c'est worth le coût, honnêtement.  
Les randoms write et latence vont pas vraiment être notable pour ton utilisation, à mon avis. C'est une différence minim entre un 2.5"/ Sata III et un nvme d'un point de vue humain.  
Plus, à prix égale, les SSD 2.5"/ Sata III ont plus de place. ( Même si pour être honnête, ça commence à se tasser petit à petit. )
 
Quand on parle de montage vidéos, là je suis plus en accord, étant donné que les fichiers vidéos sont typiquement des gros fichiers, et ceux pas nécessairement à cause de leurs nombres. Ils sont juste gros individuellement.
 
Après n'étant pas développeur, peut être simplement que je ne me rend pas compte, fort possible.

Je viens de faire un essai
680Mo de projets de dev avec en tout 14000 fichiers  
 
Copie de ça du SSD vers le SSD un peu plus de 1 minutes avec une vitesse de transfert très irrégulière allant de 40Mo/s à 500 ou 600ko.
 
Copie du ZIP de tout ça sans compression (700Mo de ZIp), copier coller du SSD vers le SSD instantané (sans doute une optimisation par windows)
Copie d'un autre disque dur bien vieux et bien lent vers le SSD, je vois a peine la fenêtre de transfert s'ouvrir, ça prend 1 ou 2 secondes.
 
Faire cet exercice sur une clé usb fait peur.
 
Je zip toujours les projets sur lesquels je ne bosse pas parce que pour les sauvegardes notamment ça change tout.

j'ai pas tout suivi, mais ca me semble normal niveau copie
 
un seul fichier de 700Mo ca ira tjs plus vite que 14000 fichiers de tailles differentes (bcp d'input/output vs 1 seul)
 

Çà illustre bien qu'il n'y a pas qu'une histoire de débit de transfert quand on parle de petits fichiers, les temps d’accès sont aussi super importants.
 
Le fait qu'un OS soit 500x plus rapide sur SSD que sur disque dur ne viendrait il pas  tout simplement de ces temps de latence aussi, le débit on s'en moque un peu dans ce cas aussi

Attends. Pourquoi tu te réfères à l'USB ?  
A aucun moment on y fait mention hin.
 
Idem, pourquoi tu nous sort des HDD pour référence ?
On en a jamais parler à aucun moment.

comme caricature du problème des temps d'accès qui sont d'autant plus impactants que les fichiers sont petits et qui sont présents aussi pour les trucs plus rapides

et je ne parle pas de DD, je dis juste que j'ai été obligé de copier depuis un DD tellement ça allait trop vite de SSD à SSD, peut être à cause d'une optimisation.

Ouais mais du coup ça n'a pas grand rapport avec un SATA III / 2.5" en interne, et ça disproportionne une comparaison qui n'a pas lieu d'être.  
Tu vires juste au hors propos en faisant ça, et tu rends la chose confuse.

Oublions l'usb qui n'était là que pour illustrer le même phénomène
 
Ben retenons juste que le temps de transfert c'est une chose mais que les temps d’accès sont hautement importants et certainement l'intéret principal aux SSD parce que des petits fichiers il n'y a surtout ça à l'usage d'un ordinateur.
 
On arrive à transformer un vieux clou en une machine tout à fait correcte en remplaçant son DD par un SSD.
 

 
Il y a sans doute moins d'ecart entre SSD sur MVME et SSD sur SATA  qu'il y en a entre DD et SSD sur SATA mais je m’étonne que le NVME n'apporterait rien alors qu'il présentent à priori des temps d’accès de l'ordre de 10x plus courts que ce que l'on peut avoir au mieux avec le SATA, sans compter la parallélisation incomparablement plus profonde.  

D'une part entre HDD et SDD, on passe grossièrement de 15ms à 15µs, le facteur est de 1000 d'où la "révolution".
 
D'autre part, qu'entre SSD SATA et NVME, il y ait un facteur 10, je demande à voir. Perso de ce que j'ai vu, le temps d'accès moyen synthétique est souvent comparable. Le NVME apporte plus de IOPS/commandes, et l'intérêt est plus difficilement mesurable dans les tâches habituelles.
 
Il y a aussi un autre phénomène : une latence de 15µs c'est rien du tout. Alors 10 fois plus rapide que rien du tout, c'est fait toujours rien du tout (à l'échelle humaine bien sûr). Dit autrement, les latences d'accès deviennent négligeables par rapport à d'autres temps. Par exemple, pour la compilation, tu as toi-même mis en évidence que les temps de traitement CPU étaient bien supérieurs. Cela masque complètement le gain en temps d'accès.
 
Dit encore autrement, peu de gens exploite réellement le NVME...

+1
Rien à rajouter pour le coup. Exactement ce que je pensais. A la différence que je n'ai pas les épaules pour le dire moi même, puisque je ne suis pas trop sûr de moi, ne maitrisant pas tout à fait tout ce qui est mémoire etc...
Je me sens pas assez à l'aise pour faire un argument plus "offensif" à ce sujet.

En tout cas, il devra quand même changer de CPU (et donc de config) s'il veut avoir un gain "visible", NVME ou pas, non ?