COMPTOIR
  
register

Composé par ————— —— 25659 vues

Baisse de prix pour les Ryzen 7 1700X et 1700 ?

Fin avril, AMD nous faisait la bonne surprise de baisser le prix de son fleuron Ryzen, alias le Ryzen 7 1800X, qui voyait son tarif de vente conseillé passer de $499 à $469. On aurait pourtant pu croire que ça n'était pas à la base une initiative directe d'AMD, puisque seules quelques enseignes États-uniennes l'appliquaient, mais elle a eu un impact mondial et nous a permis de voir le tarif de l'engin baisser dans nos contrés.

 

C'est maintenant au tour des Ryzen 7 1700X et 1700 d'avoir le droit à une coupe tarifaire, pas égale, mais loin d'être inintéressante. Chez NewEgg (l'un des plus gros revendeurs de matos des États-Unis d'Amérique), le R7 1700X a vu son tarif passer de $399 à $349 et son petit frère R7 1700 a perdu $15, passant à $314 (Amazon.com le tombe même à $299). Serait-ce un choix fait par AMD pour maintenir la pression sur le Core i7-7700K d'Intel et prévoir les Kaby Lake-X à venir (Core i7-7740X et Core i5-7640X) ? Ou peut-être juste une offre venant de revendeurs qui peuvent se le permettre grâce à des réserves monstrueuses de puces ? Il va falloir attendre un peu pour le savoir, mais personne ne viendra se plaindre d'économiser autant sur un 1700X !

 

amd ryzen puce

Un poil avant ?

Ryzen vs Kaby vs Sandy en jeu : le bilan !

Un peu plus tard ...

La Radeon Vega Frontier vue sur CompuBench ?

Les 50 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Armand Raynal, le Lundi 05 Juin 2017 à 00h28  
par Un ragoteur inquiet d'Ile-de-France le Lundi 05 Juin 2017 à 00h13
Le problème est que ce n'est pas limité à gcc (relisez les forums: Prime95 et d'autres logiciels sont impactés) et que, pour l'instant, personne ne sait (même pas AMD) à quoi est dû ce bogue...

Bien sûr, tous les CPU ont des bogues: ils sont regroupés dans un "errata" (un document édité par le constructeur) et les auteurs de BIOS et d'OS font en sorte de contourner ces derniers (pas les compilateurs en général, car si vous savez évidemment sur quelle machine vous compilez un logiciel, la plupart du temps, vous ne savez pas sur quel autre CPU ses utilisateurs le feront tourner au final).
Si y'a un moyen pour gcc d'éviter le bug en tout cas y'en a sans aucun doute un pour prime95, reste aux devs à le trouver, que se soit dans le micro code du cpu, le logiciel lui même ou autre part.

Avec ce genre d'info, même si le bug est en effet bizarre, perso je suis pas inquiet. Dans le pire des cas j'imagine qu'un fixe fera très légèrement baisser les perf.

Sur ce, bonnet de nuit, plésiosaure du paléolithique
par Un ragoteur inquiet d'Ile-de-France, le Lundi 05 Juin 2017 à 00h13  
par Armand Raynal le Dimanche 04 Juin 2017 à 23h09
Si certains arrivent à résoudre le problème en prenant une version plus récente de gcc et en compilant sans option/sans certaines options, ca doit pas être bien grave de toute façon, non ?
Le problème est que ce n'est pas limité à gcc (relisez les forums: Prime95 et d'autres logiciels sont impactés) et que, pour l'instant, personne ne sait (même pas AMD) à quoi est dû ce bogue...

Bien sûr, tous les CPU ont des bogues: ils sont regroupés dans un "errata" (un document édité par le constructeur) et les auteurs de BIOS et d'OS font en sorte de contourner ces derniers (pas les compilateurs en général, car si vous savez évidemment sur quelle machine vous compilez un logiciel, la plupart du temps, vous ne savez pas sur quel autre CPU ses utilisateurs le feront tourner au final).

 
"Un ragoteur inquiet" le nom est bien choisit pour le coup C'est pas un de ces noms aléatoires donnés aux anonymes c'est ça, vous l'avez modifié ?

Oui, c'est l'avantage des ragots "anonymes": vous pouvez choisir le nom, et je ne m'en prive jamais, utilisant généralement un nom de circonstance.

 
Ca sonne tellement faux de vouvoyez ici, c'est sensé être un comptoir

Désolé, je suis un "vieux machin" (certains jeunes branleurs diraient même "vieux con" )...
par Armand Raynal, le Dimanche 04 Juin 2017 à 23h09  
Si certains arrivent à résoudre le problème en prenant une version plus récente de gcc et en compilant sans option/sans certaines options, ca doit pas être bien grave de toute façon, non ?

"Un ragoteur inquiet" le nom est bien choisit pour le coup C'est pas un de ces noms aléatoires donnés aux anonymes c'est ça, vous l'avez modifié ?

Ca sonne tellement faux de vouvoyez ici, c'est sensé être un comptoir
par Armand Raynal, le Dimanche 04 Juin 2017 à 23h00  
par Un ragoteur inquiet d'Ile-de-France le Dimanche 04 Juin 2017 à 22h24
...
je parle uniquement de compiler avec gcc, pas gcc lui même.

Le bug existe(je l'ai dit pourtant non, je l'ai pas nié ), c'est évident, à piori dans le cpu, mais ça semble bel et bien être un problème qui n'apparaît qu'en compilant avec des opti spécifiques sur gcc ou sur d'anciennes versions.

La 6.3 est sensée supporter ryzen et j'ai vu au moins 2 personnes qui disent ne plus avoir eu de problèmes après avoir compiler leur distros avec cette version sur reddit. Y'en a un qui dit avoir eu le problème en compilant avec l'option "-march=haswell" mais avec "-march=znver1", un autre qui confirme :
It's an issue with GCC and USE/CFLAGS.
I've done SEVERAL Gentoo installs (COMPILE ALL THE THINGS!) and had 0, that's right, ZERO segfaults.
I've had other issues (the result of me misconfiguring the kernel, borking merges, etc.), but absolutely no issues compiling.
The issue comes, from what I've seen, when people try to use the GCC optimizations, optimizations for other architectures (e.g. Haswell, Bulldozer, etc.), flags unsupported by their GCC version, etc.
par Un ragoteur inquiet d'Ile-de-France, le Dimanche 04 Juin 2017 à 22h24  
par Armand Raynal le Dimanche 04 Juin 2017 à 22h14
Ben justement si tu lis la suite les top comments disent que c'est bien un bug cpu mais que les versions récentes de gcc le contournent, c'est ça le support avant d'être des optimisations, car tous cpu(ou du moins tous nos gros x86 qu'on utilise) ont des bugs que les compilateurs doivent contourner.

Si c'était un bug cpu pas encore connu/pris en compte par gcc les gens auraient toujours le même problème que ce soit avec la version 4 ou 7.

Apparemment y'en a qui l'ont avec les versions récentes de gcc en tentant de compiler avec des optimisations spécifiques, mais sans opti particulières aucun problèmes.
Non, non, non et non !

C'est un programmeur qui vous le dit (presque 40 ans de programmation derrière moi, du langage machine sur 6800, 6502 et Z80 jusqu'aux langages les plus modernes, tel 'D'): gcc n'est que le révélateur d'un bogue de Ryzen. Et vous confondez optimisations dans le code généré par le compilateur avec les optimisations utilisées pour compiler gcc lui-même (vu que ce dernier doit tourner sur toutes les machines x86, les paquets gcc fourni pour les distro Linux sont compilés avec optimisations génériques).

Ce n'est pas parce qu'une version particulière de gcc ne déclenche pas le bogue que ce dernier n'existe pas !
par Cristallix, le Dimanche 04 Juin 2017 à 22h23  
par Armand Raynal le Dimanche 04 Juin 2017 à 22h14
Ben justement si tu lis la suite les top comments disent que c'est bien un bug cpu mais que les versions récentes de gcc le contournent, c'est ça le support avant d'être des optimisations, car tous cpu(ou du moins tous nos gros x86 qu'on utilise) ont des bugs que les compilateurs doivent contourner.

Si c'était un bug cpu pas encore connu/pris en compte par gcc les gens auraient toujours le même problème que ce soit avec la version 4 ou 7.

Apparemment y'en a qui l'ont avec les versions récentes de gcc en tentant de compiler avec des optimisations spécifiques, mais sans opti particulières et l'os compilé correctement aussi aucun problèmes.
Ce bug est quand même bien bizarre car tout le monde y va de sa sauce. AMD est sur le problème et ils investiguent.Je préfère attendre leur retour pour être sûr.
par Armand Raynal, le Dimanche 04 Juin 2017 à 22h14  
par Un ragoteur inquiet d'Ile-de-France le Dimanche 04 Juin 2017 à 21h56

Ne dites pas n'importe quoi, SVP... Le compilateur n'est pas en faute ici (le bogue se produit aussi avec Prime95 sous Windows). Quant au "support Zen", il s'agit juste d'optimisations propres au Zen, qui ont été ajoutées pour les programmes compilés par gcc, mais l'optimisation standard produit un code qui tourne sur tous les CPU x86, et gcc est lui-même compilé avec ce niveau de code "générique".

Plutôt que de vous contenter de lire le premier message du thread cité, vous devriez lire les derniers...
Ben justement si tu lis la suite les top comments disent que c'est bien un bug cpu mais que les versions récentes de gcc le contournent, c'est ça le support avant d'être des optimisations, car tous cpu(ou du moins tous nos gros x86 qu'on utilise) ont des bugs que les compilateurs doivent contourner.

Si c'était un bug cpu pas encore connu/pris en compte par gcc les gens auraient toujours le même problème que ce soit avec la version 4 ou 7.

Apparemment y'en a qui l'ont avec les versions récentes de gcc en tentant de compiler avec des optimisations spécifiques, mais sans opti particulières et l'os compilé correctement aussi aucun problèmes.
par Un ragoteur inquiet d'Ile-de-France, le Dimanche 04 Juin 2017 à 21h56  
par Armand Raynal le Dimanche 04 Juin 2017 à 17h38
https://www.reddit.com/r/Amd/comments/6f0qkq/compiling_with_ryzen_cpus_on_linux_causing_random/
(Le top comment)

Ca vient d'une ancienne version de GCC apparemment. Le problème existe sur la version 5, pas sur la 6.

C'est pas si étonnant vu que le support officiel de ryzen a été introduit à partir de la version 6.3.
par MaK le Dimanche 04 Juin 2017 à 19h44
Merci, c'est donc un bug logiciel des anciennes versions de GCC, la dernière version est optimisée Zen et a donc supprimé le problème.
Ne dites pas n'importe quoi, SVP... Le compilateur n'est pas en faute ici (le bogue se produit aussi avec Prime95 sous Windows). Quant au "support Zen", il s'agit juste d'optimisations propres au Zen, qui ont été ajoutées pour les programmes compilés par gcc, mais l'optimisation standard produit un code qui tourne sur tous les CPU x86, et gcc est lui-même compilé avec ce niveau de code "générique".

Plutôt que de vous contenter de lire le premier message du thread cité, vous devriez lire les derniers... Apparemment, mettre randomize_va_space (randomize address space layout) sur "off" semble permettre de ne pas déclencher le bogue en question, mais c'est bien un bogue, car cela devrait aussi marcher sur Ryzen !
par MaK, le Dimanche 04 Juin 2017 à 19h44  
par Armand Raynal le Dimanche 04 Juin 2017 à 17h38
https://www.reddit.com/r/Amd/comments/6f0qkq/compiling_with_ryzen_cpus_on_linux_causing_random/
(Le top comment)

Ca vient d'une ancienne version de GCC apparemment. Le problème existe sur la version 5, pas sur la 6.

C'est pas si étonnant vu que le support officiel de ryzen a été introduit à partir de la version 6.3.

Merci reddit
Merci, c'est donc un bug logiciel des anciennes versions de GCC, la dernière version est optimisée Zen et a donc supprimé le problème. Merci
par Armand Raynal, le Dimanche 04 Juin 2017 à 17h38  
par Un ragoteur inquiet d'Ile-de-France le Dimanche 04 Juin 2017 à 17h16
Justement non ! Cela se produit aux fréquence @ stock;: relisez les forums...

En plus, parler d'OC extrême pour 100MHz de mieux sur la fréquence turbo (car, c'est rappelons-le, la marge max d'OC d'un 1800X), c'est franchement exagéré...
https://www.reddit.com/r/Amd/comments/6f0qkq/compiling_with_ryzen_cpus_on_linux_causing_random/
(Le top comment)

Ca vient d'une ancienne version de GCC apparemment. Le problème existe sur la version 5, pas sur la 6.

C'est pas si étonnant vu que le support officiel de ryzen a été introduit à partir de la version 6.3.

Merci reddit
par Un ragoteur inquiet d'Ile-de-France, le Dimanche 04 Juin 2017 à 17h16  
par krakoO le Dimanche 04 Juin 2017 à 12h20
Et encore une fois c'est dans des situations très précise OC EXTREME.
Justement non ! Cela se produit aux fréquence @ stock;: relisez les forums...

En plus, parler d'OC extrême pour 100MHz de mieux sur la fréquence turbo (car, c'est rappelons-le, la marge max d'OC d'un 1800X), c'est franchement exagéré...
par Armand Raynal, le Dimanche 04 Juin 2017 à 12h38  
par krakoO le Dimanche 04 Juin 2017 à 12h20
OS performant pour toi peut-être
Juste un mot là dessus, les performances de GNU/Linux et en particulier du kernel Linux ne sont pas subjectives, ca n'a rien à voir avec le support qu'adobe ou n'importe quels devs de logiciels lui offrent (ou pas). C'est pas un hasard si 99% des 'supercomputer' l'utilisent ou encore plus d'un tier des serveurs. Et ça ne se limite pas à ces usages, c'est globale. Le temps de boot, les perf sur blender, en cryptominning, en compilation ou encore l'autonomie d'un thinkpad participent à le prouver parmis bon nombre d'exemples.

Pas la peine de faire toute une conversation HS là dessus, je veux pas lancer de débat juste faire une interjection momentanée