KaiXian KX-6000 : le nouveau CPU x86 chinois de Zhaoxin (8 cœurs, 3 GHz, 16 nm)

KaiXian KX-6000 : le nouveau CPU x86 chinois de Zhaoxin (8 cœurs, 3 GHz, 16 nm)

Par Sébastien Gavois

Le 25 Septembre 2018 à 09h46
Sciences et espace
1 min 18

KaiXian KX-6000 : le nouveau CPU x86 chinois de Zhaoxin (8 cœurs, 3 GHz, 16 nm)

La société s'est associée à VIA qui dispose d'une licence pour fabriquer de tels processeurs. Comme le relève Anandtech, il fait suite au KX-5000 annoncé plus tôt dans l'année.

Ses caractéristiques évoquent une architecture LuJiaZui (x86-64) et un cache L2 de 8 Mo, mais peu d'autres détails sont donnés. Notamment sur les différences avec la précédente architecture WuDaoKou.

Zhaoxin se contente ainsi d'annoncer qu'il peut faire face à des Core i5 de 7ème génération d'Intel. L'objectif de la société est de proposer une alternative chinoise aux puces x86, et de monter progressivement en puissance. Peut-être dans l'espoir de les vendre un jour à l'international ?

Il faudra alors rassurer sur la question de la sécurité et l'absence d'éventuelles portes dérobées. D'ici là, c'est la question des performances concrètes de ces nouveaux CPU à laquelle il faudra répondre.

Commentaires (18)


jb18v
Le 25/09/2018 à 09h15

VIA ! toujours vivants <img data-src=" />


Gilbert_Gosseyn Abonné
Le 25/09/2018 à 09h59







jb18v a écrit :



VIA ! toujours vivants <img data-src=" />





Cela ne nous rajeunit pas, hein ? ;).



zefling Abonné
Le 25/09/2018 à 11h18

J’ai connu les Cyrix, mais pas les VIA. Une autre époque.


grsbdl Abonné
Le 25/09/2018 à 11h21

Portes dérobées ? Cela ne peut pas être pire que chez ses concurrents américains :-p


Groupetto Abonné
Le 25/09/2018 à 11h31

J’en avais jamais entendu parler…c’est du 16nm produit par TSMC, pour ceux qui auraient la flemme de cliquer sur le lien ;)


raoudoudou
Le 25/09/2018 à 11h43







jb18v a écrit :



VIA ! toujours vivants <img data-src=" />





Ils étaient toujours présents sur le marché des serveurs low-cost y a pas si longtemps. Ptêtre encore d’ailleurs.



vampire7
Le 25/09/2018 à 11h50







grsbdl a écrit :



Portes dérobées ? Cela ne peut pas être pire que chez ses concurrents américains :-p





En effet, il est impossible de faire pire que le Intel Management Engine…



jb18v
Le 25/09/2018 à 11h55

<img data-src=" />


TheMyst Abonné
Le 25/09/2018 à 12h27

La première Dedibox avec son VIA C7, il y a 12 ans.


yvan Abonné
Le 25/09/2018 à 12h42

C’est en rachetant Cyrix que Via a eu une licence x86, sinon ils faisaient du chipset.

(Idem pour le graphisme, ils se sont mis à faire des CG via un rachat)



Sinon ben les chinois ont progressé tellement vite… <img data-src=" /> respect.



Un corei5 ça suffit à la plupart des usages dès aujourd’hui.


ArchangeBlandin Abonné
Le 25/09/2018 à 12h55

Et on fait fonctionner ça avec un chipset de chez eux aussi ? Un chipset VIA ?

Du coup, je suis super curieux d’avoir des détails, des benchmarks variés, parce que ça fait longtemps qu’on n’a que deux fabricants.


Obidoub
Le 25/09/2018 à 13h41

Reste plus qu’à tester, s’ils sont accessibles pour le grand public…


yl
Le 25/09/2018 à 15h52







vampire7 a écrit :



En effet, il est impossible de faire pire que le Intel Management Engine…





Il est toujours possible de faire pire… Maintenant, si la NSA était vraiment derrière ce superviseur de la partie application-processor (=x86), comme ils disent chez Intel, pourquoi ont-ils demandé (dans le cadre de leur plateformes HAP) à Intel que ce soit désactivable (via des soft-straps cachés) comme des recherches récentes l’ont illustré?



C’est tout le x86 qu’il faudrait enfin coller dans les poubelles de l’histoire et en ce sens bizarre de voir les chinois y aller. Tant de décennies à accumuler la mauvaise graisse pour assurer la compatibilité de binaire (et pareil côté soft pour Microsoft) font que cela devient vraiment inélégant.

&nbsp;



Gilbert_Gosseyn Abonné
Le 26/09/2018 à 08h36

Le x86 est très bon, c’est l’implémentation qui faut revoir/sécuriser. AMD est meilleur à ce petit jeu soit dit en passant …



Et puis, contrairement au x86 qui est un vrai standard, l’archi ARM est tout sauf standardisée. Et c’est très problématique …


yl
Le 26/09/2018 à 10h55







Gilbert_Gosseyn a écrit :



Le x86 est très bon, c’est l’implémentation qui faut revoir/sécuriser. AMD est meilleur à ce petit jeu soit dit en passant …



Et puis, contrairement au x86 qui est un vrai standard, l’archi ARM est tout sauf standardisée. Et c’est très problématique …





Le x86 est tout sauf un “bon” modèle. Franchement, même quand Intel fait un SoC ce n’est pas vraiment le cas: Certes le le PCH et quelques contrôleurs se retrouvent sous le même capot mais ils en font toujours en réalité le minimum. Au point d’en arriver a ce que des signaux qui sortaient vers un bloc autrefois externe doivent aller faire une boucle faisant le tour de la carte car si on n’a pas les délais de propagation de quand c’était dehors, ca ne marche pas! Et vu qu’ils ont paumé le VHDL depuis des plombes, plus personne ne sait visiblement retoucher le truc.

&nbsp;

Leur architecture de communication inter-core, on en revient à un token-ring dans chaque sens quand tout le monde fait des crossbar.



&nbsp;Tous les périphériques sont vus comme du PCI et énumérés en mode bonne vieilles IO avant d’être memory-mappés, ce qui est lent comme un jour sans pain au démarrage… enfin si ca démarre, parce que nul part ailleurs on voit une telle complexité dans le séquençage des alims/reset. Le controleur DDR, niveau j’en fais le moins possible, est quasiment totalement initialisé en soft (et pas un paramétrage, un enable/attente active et zou), c’est si complexe chez eux que sans le MRC (source donné aux seuls éditeurs de BIOS) ou le FSP (sa version binaire pour les autres/coreboot) c’est infaisable. Surtout avec une documentation proprement lamentable.



Non, pour dire que c’est “très bon” il ne faut pas avoir vu autre chose ces 2 dernières décennies!



Guinnness
Le 26/09/2018 à 18h05







yl a écrit :



C’est tout le x86 qu’il faudrait enfin coller dans les poubelles de l’histoire et en ce sens bizarre de voir les chinois y aller. Tant de décennies à accumuler la mauvaise graisse pour assurer la compatibilité de binaire (et pareil côté soft pour Microsoft) font que cela devient vraiment inélégant.





Il y en a eu un paquet de familles de procs non compatibles x86 qui ont plus ou moins finis dans les poubelles de l’histoire, faute d’être compatibles avec la logithèque colossale dispo sur les proc x86 (dans le désordre Itanium, Sparc, Mips, PowerPC, Alpha etc … ), pourtant la plupart étaient largement supérieures niveau perfs au X86.



Il n’y a que récemment grâce à l’émergence de nouveaux types de matériels et de nouveaux usages qu’on a vu des architectures non compatibles comme Arm exploser, cela dit des PC en Arm il n’y en a pas des masses



Gilbert_Gosseyn Abonné
Le 28/09/2018 à 08h39







yl a écrit :



Le x86 est tout sauf un “bon” modèle. Franchement, même quand Intel fait un SoC ce n’est pas vraiment le cas: Certes le le PCH et quelques contrôleurs se retrouvent sous le même capot mais ils en font toujours en réalité le minimum. Au point d’en arriver a ce que des signaux qui sortaient vers un bloc autrefois externe doivent aller faire une boucle faisant le tour de la carte car si on n’a pas les délais de propagation de quand c’était dehors, ca ne marche pas! Et vu qu’ils ont paumé le VHDL depuis des plombes, plus personne ne sait visiblement retoucher le truc.

 

Leur architecture de communication inter-core, on en revient à un token-ring dans chaque sens quand tout le monde fait des crossbar.



 Tous les périphériques sont vus comme du PCI et énumérés en mode bonne vieilles IO avant d’être memory-mappés, ce qui est lent comme un jour sans pain au démarrage… enfin si ca démarre, parce que nul part ailleurs on voit une telle complexité dans le séquençage des alims/reset. Le controleur DDR, niveau j’en fais le moins possible, est quasiment totalement initialisé en soft (et pas un paramétrage, un enable/attente active et zou), c’est si complexe chez eux que sans le MRC (source donné aux seuls éditeurs de BIOS) ou le FSP (sa version binaire pour les autres/coreboot) c’est infaisable. Surtout avec une documentation proprement lamentable.



Non, pour dire que c’est “très bon” il ne faut pas avoir vu autre chose ces 2 dernières décennies!





Tu dois ignorer que, dans le mode ARM, un processeur fait par Qualcomm, un autre par Samsung, un autre par Mediatek, ou encore un autre d’un autre fabricant/fondeur nécessitent tous un code recompilé pour leur archi propre ? Même à révision ARM identique. Tout ceci car il n’y a pas de vrai standard dans le monde ARM.



Niveau architecture x86, tu peux prendre n’importe quel sort compilé et l’exécuter sur n’importe quel processeur AMD, Intel, Cyrix, Via, …



Coté Android (je laisse à part l’iOS d’Apple) si les apps fonctionnent d’un smartphone à l’aute (enfin, normalement), c’est parce qu’elles tournent dans une sorte d’émulation. Tu ne peux pas prendre une image système Sony et la faire tourner telle quelle sur un smartphone LG (ou vice versa). Il n’y a aucune standardisation de pilotes pour commencer (ça part mal). Et puis bon, les fabricants de smartphone ne maitrisent aucunement l’architecture qu’ils utilisent et les mises à jour dépendent exclusivement des fondeurs. Quand un fondeur tel que Qualcomm (il n’est pas seul à agir de la sorte hein) décide de stopper les devs pour ses anciens processeurs, fini les mises à jour sur ces appareils. Les “ROM alternatives” ne sont qu’une panacée très peu heureuse.



Curieusement, Apple est revenu de leur propre architecture PowerPC (un dérivé de l’architecture RISC Power de IBM) pour reprendre du x86. Si ce dernier était si mauvais, pourquoi ? Et pourquoi les consoles de jeu de salon utilisent du x86 ? Car, malgré ses défauts, l’architecture x86 a de vraies qualités, à commencer par un standard solide appuyé par différents acteurs.



yl
Le 03/10/2018 à 08h47







Gilbert_Gosseyn a écrit :



Curieusement, Apple est revenu de leur propre architecture PowerPC (un dérivé de l’architecture RISC Power de IBM) pour reprendre du x86. Si ce dernier était si mauvais, pourquoi ? Et pourquoi les consoles de jeu de salon utilisent du x86 ? Car, malgré ses défauts, l’architecture x86 a de vraies qualités, à commencer par un standard solide appuyé par différents acteurs.





Je ne crois pas avoir défendu ARM: Mon avis est que c’est en effet une belle merde et au delà des variations infinies (plus encore niveau SoC que coeur), une archi se disant minimaliste et pétrie d’états indéfinis par souçi de simplification… qui traine désormais classiquement 3 jeux d’instruction car on n’a pas été&nbsp; fichu de spécifier un truc correct d’entrée, on se dit que c’est vraiment la frugalité d’un côté ruinée par la gabegie de l’autre!



En effet, on a maintenant le jeu 32 bits à taille d’instruction fixe, le Thumb à taille d’instruction variable (pour de moindres besoins en RAM sur les petits systèmes)… et le 64 bits arrivé sur le tard. Un minimum de compatibilité binaire imposant d’avoir les 3. Et cela aurait pu être 4, si Google avait voulu se lier pieds et poings à ARM en utilisant Jazelle… Ce qu’ils n’ont pas voulu, faisant leur propre JVM indépendante du matériel.



Le PowerPC n’était absolument pas le bébé d’Apple mais d’IBM. Un truc en comparaison bien mieux né (passer de 32 à 64 bits n’a pas changé le jeu d’instruction, très bien conçu dès le départ il n’a évolué qu’a la marge). Ils ont entrouvert la porte aux partenariats au milieu des années 90 avant hélas de la refermer. Motorola semi-conducteurs (devenu Freescale puis racheté par NXP) y était allé et a produit des processeurs utilisés pendant 20 ans dans le domaine telecom (et avionique).



La seule véritable force du x86, c’est les volumes de vente et les prix: Cela a tué le marché de la station de travail, commence à gangrener l’industrie télécom qui a de moins en moins besoin de processeurs spécialisés (network processor/DSP) pour faire le job… Mais il faut vraiment se boucher le nez pour toucher à cela venant du PowerPC crois moi! Et a tout point de vue, matériel comme logiciel (bas niveau).



Fermer