Marrant j'ai passé mon DEA en 2001, qui parlait déjà de co-design. Puis, j'ai été dans l'industrie, et j'ai vu que souvent le point commun entre les gars du soft, et les gars du hard est le PDG.
Si tu as de la chance, la boite a un département système qui fait une synthèse et reste au niveau. Si tu n'en a pas, l'équipe hardware peut être moteur, et le soft rame derrière pour tenter de suivre.
J'ai bossé sur l'écriture de la lib bas niveau de gestion d'énergie d'un truc équivalent à l'omap3. Le cpu avait 4 points de fonctionnement, chaque point bas était plus efficace par cycles. Donc ajuster la fréquence aurait un sens pour baisser la consommation. Sauf que cela ne tient pas compte de la consommation des caches, qui avait 3 modes de fonctionnement : on, freeze, off. Les caches allumés faisaient perdre tout gain d'une baisse de fréquence.
A l'époque, la mode était de passer de "race to idle" à "spread to deadline". Mais ce n'était pas vraiment applicable. Il valait mieux aller le plus vite possible, puis flusher et couper les caches.
Les vliw ne sont pas nouveaux. L'itanium n'est pas nouveau, ni le dsp de TI, ni les gpus. Les gpu était des liv de 4 instructions qui sont passé à 2 voir moins.
Un itanium coutait 12k€ pour battre un x86 en vitesse pure, le prix est évidement en rapport avec la taille de la puce.
"Si demain un intel ou AMD, ou nvidia sort un CPU patator, s'il en vend… alors oui, bien sûr que les distro feront l'effort."
Les versions autre que x86 sont limités.
"Considérant une toute nouvelle architecture, il faut la considérer dans son ensemble."
C'est pour ça que je parle des caches.
"(des registres à gogo avec avec les instructions qui arrivent 15 par 15 ça comptent pas ?)."
L'ipc moyen d'un code est de 3. Le nombre de load par instruction est pas loin de 1 pour 5 instructions, un load, cela peut prendre 100 cycles. Donc, un pipeline fixe de 15 instructions sera vide la plus part du temps.
"la conception du CPU est faite de sorte à équilibrer les différentes parties"
Je ne sais pas si tu bosses dans le secteur (voir carrément pour ARM à Sophia), mais je ne comprends pas trop pourquoi, les concepteurs de CPU essayent seulement d'accélérer les codes existant de façon homogènes (sauf pour AES).
On sait que peu de taches nécessitent vraiment de la puissance de calcul brute (crypto, compression, iDCT, 3D…). Un core dédié impose un driver, et une latence de communication, qu'une instruction spécialisée n'a pas. On devrait voir fleurir des trucs pour la compression et tout ce qui est lent. Mais cela reste très classique. La PS4 a fait un choix radicale : moins de cache interne, contre une bande passante mémoire de folie. Cela ne serait pas une possibilité ?
On sait que la bande passante mémoire est limité, donc une unité de calcul qui éviterait des aller/retour serait assez précieuse.
Sais-tu pourquoi la conception de cpu ARM reste si classique ? (peu d'instructions spécialisés, pas d'intégration du contrôleur mémoire dans le cpu, pas de multithread "massif" genre Buldozer AMD qui est presque la fusion de 2 cpus, ce qui donne beaucoup d'unité de calcul (théorique) à une application monothread).
De mémoire, un bloc de calcul de Fermi avait 132 000 registres. Chaque thread en utilise une partie, il n'y a pas de copie au switch, comme pour les cpu multithread mais en plus souple.
"Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur."
Et tu crois franchement qu'une seul des ses distributions va décider de faire un port pour ton cpu tout beau tout neuf ?! Quand au C hyper portable, je rappelle qu'il peut y avoir des problèmes rien qu'entre les versions 32 et 64 bits sous x86.
"- compilateur : des perfs pour quoi faire ?"
Pour rien. Personne ne se plaind du temps de compilation de C++, et personne n'a créé go pour aider se coté là.
"- navigateur internet… le truc qui doit juste télécharger quelques kilos et les afficher ? S'il est lent c'est qu'il a un problème d'architecture logicielle. Un meilleur compilo n'y changerait pas grand chose. Et pour afficher les images, ce sont des algo « scientifiques hyper réguliers » super parallelisables."
Juste mdr. Regarde la taille du code source de Mozilla ! C'est plus gros que Linux.
"Pour l'histoire du cache, ce n'est pas un argument, juste un fait."
Tu n'as à alors rien compris au supposer avantage du vliw sur le superscalaire. Le but était de sauver du silicium pour mettre plus d'unité de calcul dans le même espace (ou budget de portes logiques). Si tu perds encore plus de place pour mettre du cache, c'est juste un gros failed.
"Apres il y a probablement une possibilite, si tu arrives a faire tourner 4 coeurs a moins d'un tiers de la frequence d'un seul pour le meme resultat, peut etre que tu consommeras moins d'energie (du fait que la consomation est une loi en puissance cubique de la frequence)."
Si tu baisses la fréquence, tu augmentes le temps pour une tache, alors tu peux baisser l'énergie par instruction pour le cpu, mais c'est rarement le cas pour le reste de la puce (cache et contrôleur mémoire). Ainsi une tache souvent plus vite faite à fond, qu'avec une fréquence de moitier. J'ai même lu une étude, ou il baissait la fréquence cpu ou celle du bus mémoire en fonction de la charge qui était cpu bound ou memory bound, il gagnait 10% de consommation.
"Je me demande comment Servo/Rust va s'en sortir de ce cote la."
Le plus simple de mon point de vue est de fournir un Mapreduce multicore efficace. Dans un langage fonctionnelle, on utilise tout les temps les map et fold, c'est donc un usage naturel. Le plus complexe sera de tenir compte de l'organisation mémoire des données pour éviter tout les problèmes de faux partage et de cohérence de cache.
"Ça c'est un problème du logiciel privateur, pas libre."
Tu plaisantes ? Tu connais beaucoup de distribution linux qui supporte "plein" de version de cpu ?
"Avec quel genre de code « normal » on a besoin de performances ?"
compilateur, base de donné, serveur, interface graphique, navigateur internet….
"Aujourd'hui, les processeurs sont obligés d'extraire le parallélisme entre les instructions, dynamiquement alors que ça pourrait mieux être fait de manière statique. "
Le compilo d'Itanium prouve que c'est faux. De plus, pour avoir de bonnes perf, l'itanium a besoin d'un cache code énorme au contraire du x86.
"On peut toujours le faire dans les architectures modernes, mais, je ne sais pas pourquoi, ce genre de technique a très mauvaise presse (MDR). Sans doute, mais c'est une mauvaise raison, parce que cela rend un programme incompréhensible, particulièrement tordu et totalement illisible, dont la maintenance est impossible que par un autre que celui qui l'a écrit (et encore) ?"
Les caches data et code étant séparé, ce genre de bidouille est très peu performante. Pour des raisons de sécurité, on déteste que des données deviennent du code exécutable.
"Les processeurs multicoeurs d'aujourd'hui ont beaucoup de mal à dépasser les 8 cœurs car la complexité de l'unité de ré-ordonnancement des instructions croit avec le carré du nombre de cœurs gérés."
Joli mélange entre superscalaire et multicore. Pour info, le seul cout d'un multi coeur par rapport au mono coeur est la gestion de la cohérence de cache. Le cout du réordonnancement c'est pour un cpu avec plein d'unité de calcul comme l'i7.
", très adapté à la programmation parallèle, les meilleurs Itanium ne dépassent cependant pas 8 cœurs."
Oui, ils sont VLIW, qui gère des paquets de 3 instructions. Selon les générations d'itaniuim, le cpu gère 1 packets de 3, 2 ou 3 packets de 3, donc 9 instructions à la volé.
"La distance occupée entre les éléments composant le supercalculateur : l'information ne peut se déplacer plus vite que la lumière. Aussi, si la distance entre les éléments dépasse plusieurs mètres, des temps de latence de l'ordre de la dizaine de nanoseconde peuvent apparaître et atténuer les performances."
Oui, mais non. Les pertes dans la bufferisation ou dans la transmission (sérialisation, encodage, code correcteur) sont bien plus importante que ce problème là.
"Concernant le second point, si l'on caricature la puissance d'un superordinateur à son nombre de cœurs, avec 256 cœurs sur une même puce, à nombre de cœurs égaux, une seule puce MPPA suffit là où il faudrait 32 processeurs 8 cœurs. On diminue donc la taille du système par 32 et d'autant les risques de latence. Enfin, cela reste une caricature, mais c'est un facteur qui a une réelle importance."
C'est une caricature, car tu oublies complètement la bande passante mémoire.
"la loi de Moore implique une multiplication par 2 tous les 2 ans de la performance et donc de la consommation électrique. "
La loi de Moore stipule un doublement du nombre de transistor pour le même prix, tous les 12 18 ou 24 mois, selon les versions. Il n'est pas question de consommation. Mais ce doublement a été fait en baissant la taille des transistors qui mécaniquement consomme moins.
"Parce que l’efficacité énergétique de ce nouveau processeur amène une réelle rupture technologique qui trouvera un double écho dans le monde des grands centres de données qui sont dans le mur énergétique aujourd'hui et dans le monde de l'embarqué car il rend des applications réalisables aujourd'hui qui étaient impossibles auparavant, demandant une forte puissance de calcul pour un budget consommation restreint."
Oui, mais il ne faudrait pas non plus prendre Intel pour des cons. Toutes les techniques employé par ce cpu sont disponible pour Intel. C'était le projet Larrabee, qui a raté car les GPU sont beaucoup plus puissant. Un GPU propose une nouvelle façon de programmer, sans cohérence mémoire, mais toujours plus facile. Les itanium étaient aussi VLIW dans le but de récupérer le silicium de l’ordonnanceur pour mettre des unités de calcul. Mais le code a tellement enfler, qu'il fallait ajouter des mega octets de cache, là, où le x86 demandait 10x moins. Gagner sur les ordonnanceurs pour y perdre sur le cache n'a pas d’intérêt.
"Les processeurs MPPA 256 sont aussi et avant tout une alternative aux solutions FPGA et ASICS actuellement utilisées dans les projets industriels ayant besoin d'une grande puissance de calcul. Ils diminuent la complexité de programmation de ce type de puces qui demandent plusieurs mois de développement en ramenant ce délai à quelques semaines : « Time is money ! » "
J'ai rarement vu ce genre d'application. Si un standard est bien établis comme celle de la vidéo (h264), un asic sera toujours imbattable en terme de prix et de consommation. Ce genre d'ip est dans tous les téléphones portables. Concernant les FPGA, ils servent souvent pour de la communication ou du traitement où la latence est primordiale. Latence impossible à tenir avec un truc avec un OS. Si le besoin est de la grosse puissance de calcul, les DSP était beaucoup employé.
"Les processeurs Kalray tiennent apparemment clairement leurs engagements et aucun autre processeur du marché ne rivalise aujourd'hui avec leur rendement en terme de puissance/consommation électrique. "
Les coeurs ARM ? Il y a un tas de projet de cpu multicoeur ARM pour aller dans le cloud. L'avantage est que la pile de logiciel est mature sous ARM. Le besoin du cloud est rarement autour de la puissance de calcul, mais plutôt de serveur de donné (web, db, …).
"Bien sur ces ordinateurs seront entièrement personnalisables sur le principe du Phonebloks."
Non, cela n'arrivera jamais. Les connecteurs nécessaires couteraient plus chère que les puces.
"Ils seront équipés de détecteurs en tout genre comme la radioactivité, le cancer, microscope, laser…"
Je parie sur les détecteurs de CO2, Nox, CO,… Bref, la pollution atmosphérique.
Le load balancing ne te fait une tolérance aux pannes en écriture.
"Tu penses qu'il suffit d'un claquement de doigts et, hop, les problèmes de parallélisme sont résolus ?"
Il faut utiliser les outils mis à disposition (mapreduce+bigtable), mais ce n'est pas sorcier non plus. C'est beaucoup moins complexe que de faire du mpi.
N'empèche avant google, personne ne savait faire des applis tournant sur des clusters de 1000 machines, les doigts dans le nez.
Qui est capable de faire une application insensible à un plantage d'un ordinateur complet ? Aujourd'hui cela se démocratise avec les VM, mais c'est encore loin des applis déployés par google.
Les GPU des ARM sont encore simples. Il y a une énorme culture du secret à casser, ce qui n'est pas évident. Mais les acteurs sont aussi peu nombreux (2 ?).
Il suffirait que ARM ouvre les specs de ses gpu, comme ils le font pour leur, cpu et le problème serait réglé.
Il y a d'autre service comme cela, d'utilité public ? Je pense à des miroirs de distribution, au moins sous forme de serveur bittorent. Il doit y en avoir d'autre.
Cela serait utile d'avoir une sorte de distribution linux, sous forme d'image d'OS, à monter dans une machine virtuelle, pour ceux qui loue un PC dans le cloud. Cela pourrait rendre service à beaucoup de gens à un cout minime.
La programmation par flux ressemble beaucoup, à la technique de transformation d'arbre successive. Cela peut souvent paraitre une perte, de recopier les données sont une autre forme. Mais cela permet d'éliminer toute une classe de bug lorsqu'il existe un tas de configuration fautive en lecture. C'est toujours plus facile d'écrire les données sous une forme pratique avant.
"ce qui peut avoir des conséquences sur les performances"
Et pas qu'un peu. Pour une application de copie qui fonctionne par bloc de 15Mo, avec une mise à jour d'un pourcentage de complétion à chaque fin de copie d'un bloc, avec une bande passante de 100 Mo/s, le flush() faisait chuter la vitesse de 20 % !
"Le soucis de l'i18n me pousse aussi à employer des formats de chaîne."
Tu peux développer ? Je n'ai jamais eu à faire à du i18n.
Est-ce que la poste a un service qui définit les API pour faciliter la vie de ses utilisateurs de données, et pour qu'elles soit aussi, un peu stable dans le temps ?
J'ai l'impression que le format des données et la manière de la réutiliser, peut être un sacré frein . ex: que faire d'un scan de document papier en format pdf, fichier .csv mal définit, etc…
[^] # Re: Sceptique…
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 6.
Marrant j'ai passé mon DEA en 2001, qui parlait déjà de co-design. Puis, j'ai été dans l'industrie, et j'ai vu que souvent le point commun entre les gars du soft, et les gars du hard est le PDG.
Si tu as de la chance, la boite a un département système qui fait une synthèse et reste au niveau. Si tu n'en a pas, l'équipe hardware peut être moteur, et le soft rame derrière pour tenter de suivre.
"La première sécurité est la liberté"
[^] # Re: Mouais
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 4.
J'ai bossé sur l'écriture de la lib bas niveau de gestion d'énergie d'un truc équivalent à l'omap3. Le cpu avait 4 points de fonctionnement, chaque point bas était plus efficace par cycles. Donc ajuster la fréquence aurait un sens pour baisser la consommation. Sauf que cela ne tient pas compte de la consommation des caches, qui avait 3 modes de fonctionnement : on, freeze, off. Les caches allumés faisaient perdre tout gain d'une baisse de fréquence.
A l'époque, la mode était de passer de "race to idle" à "spread to deadline". Mais ce n'était pas vraiment applicable. Il valait mieux aller le plus vite possible, puis flusher et couper les caches.
"La première sécurité est la liberté"
[^] # Re: Et les compilateurs?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 3.
Les vliw ne sont pas nouveaux. L'itanium n'est pas nouveau, ni le dsp de TI, ni les gpus. Les gpu était des liv de 4 instructions qui sont passé à 2 voir moins.
Un itanium coutait 12k€ pour battre un x86 en vitesse pure, le prix est évidement en rapport avec la taille de la puce.
"Si demain un intel ou AMD, ou nvidia sort un CPU patator, s'il en vend… alors oui, bien sûr que les distro feront l'effort."
Les versions autre que x86 sont limités.
"Considérant une toute nouvelle architecture, il faut la considérer dans son ensemble."
C'est pour ça que je parle des caches.
"(des registres à gogo avec avec les instructions qui arrivent 15 par 15 ça comptent pas ?)."
L'ipc moyen d'un code est de 3. Le nombre de load par instruction est pas loin de 1 pour 5 instructions, un load, cela peut prendre 100 cycles. Donc, un pipeline fixe de 15 instructions sera vide la plus part du temps.
"La première sécurité est la liberté"
[^] # Re: Et les compilateurs?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
"la conception du CPU est faite de sorte à équilibrer les différentes parties"
Je ne sais pas si tu bosses dans le secteur (voir carrément pour ARM à Sophia), mais je ne comprends pas trop pourquoi, les concepteurs de CPU essayent seulement d'accélérer les codes existant de façon homogènes (sauf pour AES).
On sait que peu de taches nécessitent vraiment de la puissance de calcul brute (crypto, compression, iDCT, 3D…). Un core dédié impose un driver, et une latence de communication, qu'une instruction spécialisée n'a pas. On devrait voir fleurir des trucs pour la compression et tout ce qui est lent. Mais cela reste très classique. La PS4 a fait un choix radicale : moins de cache interne, contre une bande passante mémoire de folie. Cela ne serait pas une possibilité ?
On sait que la bande passante mémoire est limité, donc une unité de calcul qui éviterait des aller/retour serait assez précieuse.
Sais-tu pourquoi la conception de cpu ARM reste si classique ? (peu d'instructions spécialisés, pas d'intégration du contrôleur mémoire dans le cpu, pas de multithread "massif" genre Buldozer AMD qui est presque la fusion de 2 cpus, ce qui donne beaucoup d'unité de calcul (théorique) à une application monothread).
"La première sécurité est la liberté"
[^] # Re: Et les cartes graphiques ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 3.
De mémoire, un bloc de calcul de Fermi avait 132 000 registres. Chaque thread en utilise une partie, il n'y a pas de copie au switch, comme pour les cpu multithread mais en plus souple.
"La première sécurité est la liberté"
[^] # Re: Merci pour cet article!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Tu parles de ce projet : https://fr.wikipedia.org/wiki/Larrabee
http://www.tomshardware.fr/articles/Xeon-Phi,1-43948.html
Il existe des cartes pour faire du HPC, mais cela ne va pas plus loin, les perfs étant trop basse pour concurrencer les GPU.
"La première sécurité est la liberté"
[^] # Re: Et les compilateurs?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 4.
"Une grande partie de ce boulot pourrait être fait en statique, une fois pour toute."
C'est juste faux, complètement faux. Une grosse partie de l'information est situé dans les données, dynamiquement donc.
"Parce que faire dynamiquement un truc qui peut l'être avant, c'est stupide."
Tu crois que les compilo optimisant ne font rien ?!
"La première sécurité est la liberté"
[^] # Re: Et les compilateurs?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 1.
"Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur."
Et tu crois franchement qu'une seul des ses distributions va décider de faire un port pour ton cpu tout beau tout neuf ?! Quand au C hyper portable, je rappelle qu'il peut y avoir des problèmes rien qu'entre les versions 32 et 64 bits sous x86.
"- compilateur : des perfs pour quoi faire ?"
Pour rien. Personne ne se plaind du temps de compilation de C++, et personne n'a créé go pour aider se coté là.
"- navigateur internet… le truc qui doit juste télécharger quelques kilos et les afficher ? S'il est lent c'est qu'il a un problème d'architecture logicielle. Un meilleur compilo n'y changerait pas grand chose. Et pour afficher les images, ce sont des algo « scientifiques hyper réguliers » super parallelisables."
Juste mdr. Regarde la taille du code source de Mozilla ! C'est plus gros que Linux.
"Pour l'histoire du cache, ce n'est pas un argument, juste un fait."
Tu n'as à alors rien compris au supposer avantage du vliw sur le superscalaire. Le but était de sauver du silicium pour mettre plus d'unité de calcul dans le même espace (ou budget de portes logiques). Si tu perds encore plus de place pour mettre du cache, c'est juste un gros failed.
"La première sécurité est la liberté"
[^] # Re: Mouais
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
"Apres il y a probablement une possibilite, si tu arrives a faire tourner 4 coeurs a moins d'un tiers de la frequence d'un seul pour le meme resultat, peut etre que tu consommeras moins d'energie (du fait que la consomation est une loi en puissance cubique de la frequence)."
Si tu baisses la fréquence, tu augmentes le temps pour une tache, alors tu peux baisser l'énergie par instruction pour le cpu, mais c'est rarement le cas pour le reste de la puce (cache et contrôleur mémoire). Ainsi une tache souvent plus vite faite à fond, qu'avec une fréquence de moitier. J'ai même lu une étude, ou il baissait la fréquence cpu ou celle du bus mémoire en fonction de la charge qui était cpu bound ou memory bound, il gagnait 10% de consommation.
"Je me demande comment Servo/Rust va s'en sortir de ce cote la."
Le plus simple de mon point de vue est de fournir un Mapreduce multicore efficace. Dans un langage fonctionnelle, on utilise tout les temps les map et fold, c'est donc un usage naturel. Le plus complexe sera de tenir compte de l'organisation mémoire des données pour éviter tout les problèmes de faux partage et de cohérence de cache.
"La première sécurité est la liberté"
[^] # Re: Et les compilateurs?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 3.
"Ça c'est un problème du logiciel privateur, pas libre."
Tu plaisantes ? Tu connais beaucoup de distribution linux qui supporte "plein" de version de cpu ?
"Avec quel genre de code « normal » on a besoin de performances ?"
compilateur, base de donné, serveur, interface graphique, navigateur internet….
"Aujourd'hui, les processeurs sont obligés d'extraire le parallélisme entre les instructions, dynamiquement alors que ça pourrait mieux être fait de manière statique. "
Le compilo d'Itanium prouve que c'est faux. De plus, pour avoir de bonnes perf, l'itanium a besoin d'un cache code énorme au contraire du x86.
"La première sécurité est la liberté"
[^] # Re: Pour comparer les performances
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 6.
"On peut toujours le faire dans les architectures modernes, mais, je ne sais pas pourquoi, ce genre de technique a très mauvaise presse (MDR). Sans doute, mais c'est une mauvaise raison, parce que cela rend un programme incompréhensible, particulièrement tordu et totalement illisible, dont la maintenance est impossible que par un autre que celui qui l'a écrit (et encore) ?"
Les caches data et code étant séparé, ce genre de bidouille est très peu performante. Pour des raisons de sécurité, on déteste que des données deviennent du code exécutable.
"La première sécurité est la liberté"
# arm ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 10.
"Les processeurs multicoeurs d'aujourd'hui ont beaucoup de mal à dépasser les 8 cœurs car la complexité de l'unité de ré-ordonnancement des instructions croit avec le carré du nombre de cœurs gérés."
Joli mélange entre superscalaire et multicore. Pour info, le seul cout d'un multi coeur par rapport au mono coeur est la gestion de la cohérence de cache. Le cout du réordonnancement c'est pour un cpu avec plein d'unité de calcul comme l'i7.
", très adapté à la programmation parallèle, les meilleurs Itanium ne dépassent cependant pas 8 cœurs."
Oui, ils sont VLIW, qui gère des paquets de 3 instructions. Selon les générations d'itaniuim, le cpu gère 1 packets de 3, 2 ou 3 packets de 3, donc 9 instructions à la volé.
"La distance occupée entre les éléments composant le supercalculateur : l'information ne peut se déplacer plus vite que la lumière. Aussi, si la distance entre les éléments dépasse plusieurs mètres, des temps de latence de l'ordre de la dizaine de nanoseconde peuvent apparaître et atténuer les performances."
Oui, mais non. Les pertes dans la bufferisation ou dans la transmission (sérialisation, encodage, code correcteur) sont bien plus importante que ce problème là.
"Concernant le second point, si l'on caricature la puissance d'un superordinateur à son nombre de cœurs, avec 256 cœurs sur une même puce, à nombre de cœurs égaux, une seule puce MPPA suffit là où il faudrait 32 processeurs 8 cœurs. On diminue donc la taille du système par 32 et d'autant les risques de latence. Enfin, cela reste une caricature, mais c'est un facteur qui a une réelle importance."
C'est une caricature, car tu oublies complètement la bande passante mémoire.
"la loi de Moore implique une multiplication par 2 tous les 2 ans de la performance et donc de la consommation électrique. "
La loi de Moore stipule un doublement du nombre de transistor pour le même prix, tous les 12 18 ou 24 mois, selon les versions. Il n'est pas question de consommation. Mais ce doublement a été fait en baissant la taille des transistors qui mécaniquement consomme moins.
"Parce que l’efficacité énergétique de ce nouveau processeur amène une réelle rupture technologique qui trouvera un double écho dans le monde des grands centres de données qui sont dans le mur énergétique aujourd'hui et dans le monde de l'embarqué car il rend des applications réalisables aujourd'hui qui étaient impossibles auparavant, demandant une forte puissance de calcul pour un budget consommation restreint."
Oui, mais il ne faudrait pas non plus prendre Intel pour des cons. Toutes les techniques employé par ce cpu sont disponible pour Intel. C'était le projet Larrabee, qui a raté car les GPU sont beaucoup plus puissant. Un GPU propose une nouvelle façon de programmer, sans cohérence mémoire, mais toujours plus facile. Les itanium étaient aussi VLIW dans le but de récupérer le silicium de l’ordonnanceur pour mettre des unités de calcul. Mais le code a tellement enfler, qu'il fallait ajouter des mega octets de cache, là, où le x86 demandait 10x moins. Gagner sur les ordonnanceurs pour y perdre sur le cache n'a pas d’intérêt.
"Les processeurs MPPA 256 sont aussi et avant tout une alternative aux solutions FPGA et ASICS actuellement utilisées dans les projets industriels ayant besoin d'une grande puissance de calcul. Ils diminuent la complexité de programmation de ce type de puces qui demandent plusieurs mois de développement en ramenant ce délai à quelques semaines : « Time is money ! » "
J'ai rarement vu ce genre d'application. Si un standard est bien établis comme celle de la vidéo (h264), un asic sera toujours imbattable en terme de prix et de consommation. Ce genre d'ip est dans tous les téléphones portables. Concernant les FPGA, ils servent souvent pour de la communication ou du traitement où la latence est primordiale. Latence impossible à tenir avec un truc avec un OS. Si le besoin est de la grosse puissance de calcul, les DSP était beaucoup employé.
"Les processeurs Kalray tiennent apparemment clairement leurs engagements et aucun autre processeur du marché ne rivalise aujourd'hui avec leur rendement en terme de puissance/consommation électrique. "
Les coeurs ARM ? Il y a un tas de projet de cpu multicoeur ARM pour aller dans le cloud. L'avantage est que la pile de logiciel est mature sous ARM. Le besoin du cloud est rarement autour de la puissance de calcul, mais plutôt de serveur de donné (web, db, …).
"Bien sur ces ordinateurs seront entièrement personnalisables sur le principe du Phonebloks."
Non, cela n'arrivera jamais. Les connecteurs nécessaires couteraient plus chère que les puces.
"Ils seront équipés de détecteurs en tout genre comme la radioactivité, le cancer, microscope, laser…"
Je parie sur les détecteurs de CO2, Nox, CO,… Bref, la pollution atmosphérique.
"La première sécurité est la liberté"
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 1. Dernière modification le 08 janvier 2014 à 15:51.
Le load balancing ne te fait une tolérance aux pannes en écriture.
"Tu penses qu'il suffit d'un claquement de doigts et, hop, les problèmes de parallélisme sont résolus ?"
Il faut utiliser les outils mis à disposition (mapreduce+bigtable), mais ce n'est pas sorcier non plus. C'est beaucoup moins complexe que de faire du mpi.
"La première sécurité est la liberté"
[^] # Re: au sujet du Vinyle vs CD vs MP3
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche NwAvGuy O2 : l’amplificateur casque sous licence Creative Common. Évalué à 3.
Le problème est surtout qu'il n'existe pas de format pour ça.
"La première sécurité est la liberté"
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 3.
'soupir'
"un module ne ralenti pas les autres"
Comment 2 trucs pourrait aller aussi vite qu'un seul ?
Pour mettre tes 2 modules ensembles, tu décris bien la connexion entre eux par un fichier XML, il y a donc bien un 3ième truc qui fait la liaison.
"La première sécurité est la liberté"
[^] # Re: L'escroquerie audiophile
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche NwAvGuy O2 : l’amplificateur casque sous licence Creative Common. Évalué à 2.
D'ailleurs, toutes les enceintes devraient être amplifié. Cela permet ainsi de faire des filtres actifs et d'avoir un bien meilleur rendement.
"La première sécurité est la liberté"
[^] # Re: L'histoire se repette !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
Dommage que opengraphics n'est rien donné. Il aurait pu attaquer le marcher des IP par le bas avec un super driver opensource.
"La première sécurité est la liberté"
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 3.
N'empèche avant google, personne ne savait faire des applis tournant sur des clusters de 1000 machines, les doigts dans le nez.
Qui est capable de faire une application insensible à un plantage d'un ordinateur complet ? Aujourd'hui cela se démocratise avec les VM, mais c'est encore loin des applis déployés par google.
"La première sécurité est la liberté"
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 2.
C'est la programmation modulaire, n'importe quel langage permet de le faire.
"La première sécurité est la liberté"
[^] # Re: L'histoire se repette !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 1.
Mais par rapport au part de marché de ARM et de imgtec, le reste ne représente pas grand chose non ?
"La première sécurité est la liberté"
[^] # Re: L'histoire se repette !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 1. Dernière modification le 08 janvier 2014 à 11:25.
Les GPU des ARM sont encore simples. Il y a une énorme culture du secret à casser, ce qui n'est pas évident. Mais les acteurs sont aussi peu nombreux (2 ?).
Il suffirait que ARM ouvre les specs de ses gpu, comme ils le font pour leur, cpu et le problème serait réglé.
"La première sécurité est la liberté"
# serveur d'utilité public ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Blague : Plouf le serveur. Évalué à 3.
Il y a d'autre service comme cela, d'utilité public ? Je pense à des miroirs de distribution, au moins sous forme de serveur bittorent. Il doit y en avoir d'autre.
Cela serait utile d'avoir une sorte de distribution linux, sous forme d'image d'OS, à monter dans une machine virtuelle, pour ceux qui loue un PC dans le cloud. Cela pourrait rendre service à beaucoup de gens à un cout minime.
"La première sécurité est la liberté"
[^] # Re: Conférence
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 3.
La programmation par flux ressemble beaucoup, à la technique de transformation d'arbre successive. Cela peut souvent paraitre une perte, de recopier les données sont une autre forme. Mais cela permet d'éliminer toute une classe de bug lorsqu'il existe un tas de configuration fautive en lecture. C'est toujours plus facile d'écrire les données sous une forme pratique avant.
"La première sécurité est la liberté"
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 2.
"ce qui peut avoir des conséquences sur les performances"
Et pas qu'un peu. Pour une application de copie qui fonctionne par bloc de 15Mo, avec une mise à jour d'un pourcentage de complétion à chaque fin de copie d'un bloc, avec une bande passante de 100 Mo/s, le flush() faisait chuter la vitesse de 20 % !
"Le soucis de l'i18n me pousse aussi à employer des formats de chaîne."
Tu peux développer ? Je n'ai jamais eu à faire à du i18n.
"La première sécurité est la liberté"
# api ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche DataPoste, le programme OpenData du groupe La Poste. Évalué à 9.
Est-ce que la poste a un service qui définit les API pour faciliter la vie de ses utilisateurs de données, et pour qu'elles soit aussi, un peu stable dans le temps ?
J'ai l'impression que le format des données et la manière de la réutiliser, peut être un sacré frein . ex: que faire d'un scan de document papier en format pdf, fichier .csv mal définit, etc…
"La première sécurité est la liberté"