"Le problème des instructions dédiés, c'est qu'il faut coder pour. Soit le compilo est capable de le gérer, soit le dev de la lib/logiciel doit le gérer."
Oui, mais c'est bien plus facile qu'un bloc externe qui demande un drivers en plus.
"Dans tous les cas, pour le code qui sera finalement exécuté et du point de vue du fondeur de CPU "généraliste", un déséquilibre entre les différentes unités d'exécution du CPU signifiera soit des performances moindres pour certains types de calculs purs, soit un investissement inutile dans l'optimisation d'une partie du CPU."
Si on reste sur ARM, une instruction "zip" serait utile pour tous les navigateurs gérant mod_gzip, cela doit représenter du monde. Une iDCT permettrait d'ouvrir des JPEG ultra-rapidement (sans utiliser de bloc externe, c'est utiliser tout le temps avec la photo et le navigateur), etc…
"En gros, en faisant tourner le 4 eme core (qui est problement necessaire pour payer l'overhead du multithread), tu arrives a obtenir le meme resultat en temps d'execution. Mais du fait que tu tournes a 1/3 de la frequence, tu reussis a consommer moins d'energie."
Je ne vois pas comment c'est possible. Pour moi, c'est toujours plus rapide, et moins consommateur d'énergie globalement, de tourner à 100% d'un seul cpu.
En gros, tu as chaque cpu consomme 100 et ton cache 100. Si tu as besoin de 1000 cycles de calcul, tu as une conso sur un seul cpu de 200 000 d'énergie (nb cycle * puissance : (100 + 100) * 1000). Si tu tournes à 1/3 de la fréquence, on va dire que tu consommes 25 par cycle. Donc, tes 1000 cycles de coute (25+100)*3000= 375 000 (cpu 3x plus lent). Si tu dis que tes 4 cpus permet de garder le boulot en 1000 cycle, tu as (4*25+100)*1000= 200 000.
En gros, tu y gagnes, si tu baisses franchement la consommation d'un multicoeur unitaire. Mais bon, on ne tient compte que de la consommation dynamique, normalement tu as de la consommation statique, et ton monocoeur devrait moins consommer si tu rajoutes encore une part de consommation fixe.
"La dessus : générer un certificat de révocation devrait pouvoir résoudre le problème, mais je suis d'accord avec toi : on en est pas encore à faire comprendre tout ça à Mme Michu."
Tu peux appeler cela "fermer son compte".
Contre le vol d'identité, je pensais aussi à la création d'une paire de clef supplémentaire qui signe la clef réellement utilisé. Cette clef maitre peut être oublié sur une clef usb (ou un format imprimé sur papier ?). En cas de perte ou de vol de la clef d'usage, cette clef permet de recréer une nouvelle clef d'usage.
Concernant le stockage du mot de passe, j'avais pensé à l'usage de ssss (s?) qui permet de découper une donnée en n parties. Ensuite, il suffit d'avoir m partie parmi les n pour reconstituer le message. Le mot de passe pourrait donc être donné à "des amis" qui donnerait leur morceau de donnéees sss, en cas de besoin. Par exemple, 3 amis parmi 5.
Pour le nameskating peut être que tu peux imposer une longueur de chaine, ou quelques choses qui empêche d'avoir des login ressemblant à des choses connues. Peut être une hiérarchie de nom ?
Je ne sais pas si tu as lu les longues interview du créateur de la PS4, mais Sony a été obsédé par la simplicité du point de vue du développeur pour sa ps4.
C'est amusant de voir que Xbox a fait les choix inverse : plus de perf hard au détriment de la simplicité (eDRAM + DDR128 bits vs 256 bits GDDR5, gestion des shaders simplifiés, mémoire unifé pour éviter les copies, etc…)
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.
[^] # 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.
"Le problème des instructions dédiés, c'est qu'il faut coder pour. Soit le compilo est capable de le gérer, soit le dev de la lib/logiciel doit le gérer."
Oui, mais c'est bien plus facile qu'un bloc externe qui demande un drivers en plus.
"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.
"Dans tous les cas, pour le code qui sera finalement exécuté et du point de vue du fondeur de CPU "généraliste", un déséquilibre entre les différentes unités d'exécution du CPU signifiera soit des performances moindres pour certains types de calculs purs, soit un investissement inutile dans l'optimisation d'une partie du CPU."
Si on reste sur ARM, une instruction "zip" serait utile pour tous les navigateurs gérant mod_gzip, cela doit représenter du monde. Une iDCT permettrait d'ouvrir des JPEG ultra-rapidement (sans utiliser de bloc externe, c'est utiliser tout le temps avec la photo et le navigateur), etc…
"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.
"En gros, en faisant tourner le 4 eme core (qui est problement necessaire pour payer l'overhead du multithread), tu arrives a obtenir le meme resultat en temps d'execution. Mais du fait que tu tournes a 1/3 de la frequence, tu reussis a consommer moins d'energie."
Je ne vois pas comment c'est possible. Pour moi, c'est toujours plus rapide, et moins consommateur d'énergie globalement, de tourner à 100% d'un seul cpu.
En gros, tu as chaque cpu consomme 100 et ton cache 100. Si tu as besoin de 1000 cycles de calcul, tu as une conso sur un seul cpu de 200 000 d'énergie (nb cycle * puissance : (100 + 100) * 1000). Si tu tournes à 1/3 de la fréquence, on va dire que tu consommes 25 par cycle. Donc, tes 1000 cycles de coute (25+100)*3000= 375 000 (cpu 3x plus lent). Si tu dis que tes 4 cpus permet de garder le boulot en 1000 cycle, tu as (4*25+100)*1000= 200 000.
En gros, tu y gagnes, si tu baisses franchement la consommation d'un multicoeur unitaire. Mais bon, on ne tient compte que de la consommation dynamique, normalement tu as de la consommation statique, et ton monocoeur devrait moins consommer si tu rajoutes encore une part de consommation fixe.
"La première sécurité est la liberté"
[^] # Re: Petit compte-rendu du papier blanc
Posté par Nicolas Boulay (site web personnel) . En réponse au journal twister un microblog opensource P2P. Évalué à 3.
"La dessus : générer un certificat de révocation devrait pouvoir résoudre le problème, mais je suis d'accord avec toi : on en est pas encore à faire comprendre tout ça à Mme Michu."
Tu peux appeler cela "fermer son compte".
Contre le vol d'identité, je pensais aussi à la création d'une paire de clef supplémentaire qui signe la clef réellement utilisé. Cette clef maitre peut être oublié sur une clef usb (ou un format imprimé sur papier ?). En cas de perte ou de vol de la clef d'usage, cette clef permet de recréer une nouvelle clef d'usage.
Concernant le stockage du mot de passe, j'avais pensé à l'usage de ssss (s?) qui permet de découper une donnée en n parties. Ensuite, il suffit d'avoir m partie parmi les n pour reconstituer le message. Le mot de passe pourrait donc être donné à "des amis" qui donnerait leur morceau de donnéees sss, en cas de besoin. Par exemple, 3 amis parmi 5.
"La première sécurité est la liberté"
[^] # Re: Petit compte-rendu du papier blanc
Posté par Nicolas Boulay (site web personnel) . En réponse au journal twister un microblog opensource P2P. Évalué à 2.
Pour le nameskating peut être que tu peux imposer une longueur de chaine, ou quelques choses qui empêche d'avoir des login ressemblant à des choses connues. Peut être une hiérarchie de nom ?
Comment tu gères la cloture de compte ?
"La première sécurité est la liberté"
[^] # 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é à 2.
http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php
"La première sécurité est la liberté"
[^] # 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é à 3.
Je ne sais pas si tu as lu les longues interview du créateur de la PS4, mais Sony a été obsédé par la simplicité du point de vue du développeur pour sa ps4.
C'est amusant de voir que Xbox a fait les choix inverse : plus de perf hard au détriment de la simplicité (eDRAM + DDR128 bits vs 256 bits GDDR5, gestion des shaders simplifiés, mémoire unifé pour éviter les copies, etc…)
"La première sécurité est la liberté"
[^] # 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é"