"Vu qu'on fait varier la fréquence et le voltage a la baisse dans le cas de la conso dynamique, on n'est pas loin d'avoir un f3 pour la consomation en premiere approximation."
Pour la puissance instantané, pas pour la consommation d'une tache, qui est multiplié par le temps pour l’exécuter. Ce temps augmente avec la baisse de la fréquence. Si on baisse une fréquence sans baisser la tension, cela ne sert à rien. Les OMAP sont équipé d'un système de retroaction qui mesure la vitesse de la puce (vitesse d'un anneau d'inverseur) et adapte la tension en fonction.
"Sur un terminal mobile qui passe son temps en veille, oui, la consomation statique est le probleme important."
Non pas du tout. En veille, 99% de la puce est coupé. Il reste juste le domaine de réveil(wakeup domain), qui est alimenté avec une horloge à 32khz. Quand je parle de conso statique, je parle de fuite de courant de bloc allumé (power domain). Ces fuites sont proportionnelles à la surface de la zone et à la tension, indépendamment de la fréquence de l'horloge.
" Pour ca, il est certain qu'il faut baisser la conso statique, mais ca le soft n'y peut rien. C'est du a la techno utilise et tu n'as pas d'optimisation pour."
Si tu peux, avec le "race to idle", et la gestion correct des latences de réveil (cf les arrondis des compteurs de Linux pour grouper les réveils). Il y a aussi la gestion correct des états des périphériques, souvent si un driver est utilisé, son bloc n'est jamais complètement coupé de peur de perdre son état. Le fait d'adapter la fréquence entre bus mémoire et cpu, permet aussi de baisser la tension qui a un effet sur la consommation statique.
Souvent la combinaison des systèmes de gestion d'énergie est tellement compliqué (on parle de >100 blocs dans des power domain différent, avec des clock domain différent, et des dépendances gérés plus ou moins automatiquement), que le plus simple est encore de gérer des "modes" d'usage, pour passer de l'un à l'autre, et optimiser à mort leur configuration. C'est beaucoup plus simple que d'essayer de faire du code intelligent qui s'adapte à tous les cas (en plus un code qui tourne, c'est un cpu allumé, un bus mémoire, une mémoire, etc…).
"Dans le cas des architectes, je peux te dire qu'au moins sur le projet auquel je participe, à chaque fois qu'on demandait une instruction en matériel, la réponse qu'on obtenait était en gros « Why do you need it? Show me the data ». Pour être honnête, l'architecture est pensée pour être extrêmement efficace énergétiquement parlant, donc si tu demandes un mécanisme de prédicat pour les conditionnelles, forcément, le monsieur,"
Un système de prédicat n'est pas une simple instruction. En plus un concepteur de cpu se met rarement à niveau système. Il faut voir la tronche d'un SoC de téléphonie, c'est plein de bloc hyper complexe (plusieurs cpus, plusieurs type de cpus, une centaine de bloc). Il ne voit pas que rajouter une instruction de cryptage, qui lui bouffe son budget de surface de consommation, évite d'ajouter un bloc externe sur Soc qui rajoute un driver, de la latence.
J'ai connu des monstres du codage de compilateur, qui finalement, ne connaissait pas grand chose sur les architectures cpu moderne. Les algo retenus par les informaticiens, prennent en compte, en général un temps d'accès mémoire uniforme. Ce qui n'a aucun sens : on se prend un facteur 100, si on ne fait pas attention.
A l'inverse, j'ai vu des codeurs hardwares, que cela ne dérange pas de mettre des bits de contrôles de 2 périphériques différents sur un même octet mémoire, ce qui rend l'écriture de drivers "amusant", surtout si 2 cpus différents sont censé y accédé avec des Os différents.
J'ai vu aussi des modes automatique de mise en sommeil qui peuvent perdre des données, mais consomme moins, sans interruption pour gérer la sauvegarde de contexte. Le logiciel doit alors simuler le comportement du hardware, super simple !
multicore : plusieurs cpu se partage la même mémoire : le goulot d'étranglement est sur la cohérence de cache
superscalaire : un cpu et plusieurs unité de calcul fonctionnant en parallèle : le goulot d'étranglement est l’ordonnanceur pour faire comme si les instructions étaient exécutées dans l'ordre.
"D'ailleurs, dans le silicium, quelqu'un connaît-il sa vitesse ?"
10cm par ns, quand on faisait des pcb.
"Quelqu'un connaît-il un processeur ou GPU ou autre puce qui fasse mieux ?"
La puce d'IBM pour le hpc basé sur plusieurs powerpc.
"Il faudrait que quelqu'un de Kalray ou plus calé que moi te réponde, mais sa force concernant les solutions FPGA et ASICS c'est son temps de développement réduit de plusieurs mois voire années à quelques semaines. Programmer un système FPGA/ASICS c'est compliqué et fastidieux. Avec Kalray tu programmes dans ton langage préféré "comme un cpu classique" pour ce que j'ai saisi. "
Dans ce cas, c'est la taille du marché qui compte. Si c'est pour faire du calcul pour l'armée, il s'agit de quelques unités. Si il s'agit de h264, il s'agit de millions d'unité. Si c'est pour un téléphone, c'est facile d'acheter une ip qui existe déjà.
"Il est admis que la consomation d'energie suit une loi en puissance de 3 de la frequence. Donc si tu as 25 a 1/3 de la frequence, tu passes a 25 * 25 * 25 a pleine frequence. Pas 100, mais 15625. Ca change un peu le calcul de depart a pleine frequence :-)"
Soit il y a du changement depuis 2008, soit il y a un gros soucis. La consommation est en f*V² (conso dynamique) + conso statique qui est proportionnel à la surface et à le tension (fuite). La conso dynamique était devenu inférieur à la conso statique. Le but était de baisser la tension à tout prix.
" Il y a clairement une consomation statique, mais bon, sur le materiel dont on parle, c'est la partie dynamique qui est le plus genant (Sans compter l'ecran et la radio)."
Pour moi, c'était plus vrai depuis le 65nm.Encore avant, couper l'arbre d'horloge pouvait faire tomber 70% de la consommation.
Sur omap, tu avais plusieurs modes sur plusieurs zone : couper le courant; couper le courant, sauf celui de certains registres, passer en veille (mise en série d'une diode qui basse la tension de 0.6V, ce qui permet de sauver les registres horloge coupé), ensuite il y a les modes sans horloges.
La différence entre ses modes, c'est le niveau de consommation, mais surtout le temps de réveille : allumer une PLL était très long, idem pour un powerdomain (qq ms ?).
Si intel propose des coupures sur FMA, les changements de mode peuvent couté très cher.
"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.
[^] # Re: Par contre communiquer via des ultrasons est définitivement une réalité.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Communiquer via les ultrasons. Évalué à 4.
Faire moins consommateur que le Bluetooth en emission, cela parait difficile.
"La première sécurité est la liberté"
[^] # Re: environnement... blabla
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.
Je pensais que tu parlais d'un petit nouveau. Les serveurs ARM sont déjà annoncés.
"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.
"Vu qu'on fait varier la fréquence et le voltage a la baisse dans le cas de la conso dynamique, on n'est pas loin d'avoir un f3 pour la consomation en premiere approximation."
Pour la puissance instantané, pas pour la consommation d'une tache, qui est multiplié par le temps pour l’exécuter. Ce temps augmente avec la baisse de la fréquence. Si on baisse une fréquence sans baisser la tension, cela ne sert à rien. Les OMAP sont équipé d'un système de retroaction qui mesure la vitesse de la puce (vitesse d'un anneau d'inverseur) et adapte la tension en fonction.
"Sur un terminal mobile qui passe son temps en veille, oui, la consomation statique est le probleme important."
Non pas du tout. En veille, 99% de la puce est coupé. Il reste juste le domaine de réveil(wakeup domain), qui est alimenté avec une horloge à 32khz. Quand je parle de conso statique, je parle de fuite de courant de bloc allumé (power domain). Ces fuites sont proportionnelles à la surface de la zone et à la tension, indépendamment de la fréquence de l'horloge.
" Pour ca, il est certain qu'il faut baisser la conso statique, mais ca le soft n'y peut rien. C'est du a la techno utilise et tu n'as pas d'optimisation pour."
Si tu peux, avec le "race to idle", et la gestion correct des latences de réveil (cf les arrondis des compteurs de Linux pour grouper les réveils). Il y a aussi la gestion correct des états des périphériques, souvent si un driver est utilisé, son bloc n'est jamais complètement coupé de peur de perdre son état. Le fait d'adapter la fréquence entre bus mémoire et cpu, permet aussi de baisser la tension qui a un effet sur la consommation statique.
Souvent la combinaison des systèmes de gestion d'énergie est tellement compliqué (on parle de >100 blocs dans des power domain différent, avec des clock domain différent, et des dépendances gérés plus ou moins automatiquement), que le plus simple est encore de gérer des "modes" d'usage, pour passer de l'un à l'autre, et optimiser à mort leur configuration. C'est beaucoup plus simple que d'essayer de faire du code intelligent qui s'adapte à tous les cas (en plus un code qui tourne, c'est un cpu allumé, un bus mémoire, une mémoire, etc…).
"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.
C'est pour gérer la perte du mot de passe local.
"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.
"Dans le cas des architectes, je peux te dire qu'au moins sur le projet auquel je participe, à chaque fois qu'on demandait une instruction en matériel, la réponse qu'on obtenait était en gros « Why do you need it? Show me the data ». Pour être honnête, l'architecture est pensée pour être extrêmement efficace énergétiquement parlant, donc si tu demandes un mécanisme de prédicat pour les conditionnelles, forcément, le monsieur,"
Un système de prédicat n'est pas une simple instruction. En plus un concepteur de cpu se met rarement à niveau système. Il faut voir la tronche d'un SoC de téléphonie, c'est plein de bloc hyper complexe (plusieurs cpus, plusieurs type de cpus, une centaine de bloc). Il ne voit pas que rajouter une instruction de cryptage, qui lui bouffe son budget de surface de consommation, évite d'ajouter un bloc externe sur Soc qui rajoute un driver, de la latence.
"La première sécurité est la liberté"
[^] # Re: environnement... blabla
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.
Pour concurrencer intel, il faut déjà pouvoir vendre qq dizaines millions de pièce.
"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é à 5.
J'ai connu des monstres du codage de compilateur, qui finalement, ne connaissait pas grand chose sur les architectures cpu moderne. Les algo retenus par les informaticiens, prennent en compte, en général un temps d'accès mémoire uniforme. Ce qui n'a aucun sens : on se prend un facteur 100, si on ne fait pas attention.
A l'inverse, j'ai vu des codeurs hardwares, que cela ne dérange pas de mettre des bits de contrôles de 2 périphériques différents sur un même octet mémoire, ce qui rend l'écriture de drivers "amusant", surtout si 2 cpus différents sont censé y accédé avec des Os différents.
J'ai vu aussi des modes automatique de mise en sommeil qui peuvent perdre des données, mais consomme moins, sans interruption pour gérer la sauvegarde de contexte. Le logiciel doit alors simuler le comportement du hardware, super simple !
"La première sécurité est la liberté"
[^] # Re: 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é à 4.
" superscalaire et multicore."
multicore : plusieurs cpu se partage la même mémoire : le goulot d'étranglement est sur la cohérence de cache
superscalaire : un cpu et plusieurs unité de calcul fonctionnant en parallèle : le goulot d'étranglement est l’ordonnanceur pour faire comme si les instructions étaient exécutées dans l'ordre.
"D'ailleurs, dans le silicium, quelqu'un connaît-il sa vitesse ?"
10cm par ns, quand on faisait des pcb.
"Quelqu'un connaît-il un processeur ou GPU ou autre puce qui fasse mieux ?"
La puce d'IBM pour le hpc basé sur plusieurs powerpc.
"Il faudrait que quelqu'un de Kalray ou plus calé que moi te réponde, mais sa force concernant les solutions FPGA et ASICS c'est son temps de développement réduit de plusieurs mois voire années à quelques semaines. Programmer un système FPGA/ASICS c'est compliqué et fastidieux. Avec Kalray tu programmes dans ton langage préféré "comme un cpu classique" pour ce que j'ai saisi. "
Dans ce cas, c'est la taille du marché qui compte. Si c'est pour faire du calcul pour l'armée, il s'agit de quelques unités. Si il s'agit de h264, il s'agit de millions d'unité. Si c'est pour un téléphone, c'est facile d'acheter une ip qui existe déjà.
"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é à 3.
"Il est admis que la consomation d'energie suit une loi en puissance de 3 de la frequence. Donc si tu as 25 a 1/3 de la frequence, tu passes a 25 * 25 * 25 a pleine frequence. Pas 100, mais 15625. Ca change un peu le calcul de depart a pleine frequence :-)"
Soit il y a du changement depuis 2008, soit il y a un gros soucis. La consommation est en f*V² (conso dynamique) + conso statique qui est proportionnel à la surface et à le tension (fuite). La conso dynamique était devenu inférieur à la conso statique. Le but était de baisser la tension à tout prix.
" Il y a clairement une consomation statique, mais bon, sur le materiel dont on parle, c'est la partie dynamique qui est le plus genant (Sans compter l'ecran et la radio)."
Pour moi, c'était plus vrai depuis le 65nm.Encore avant, couper l'arbre d'horloge pouvait faire tomber 70% de la consommation.
"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é à 3.
Sur omap, tu avais plusieurs modes sur plusieurs zone : couper le courant; couper le courant, sauf celui de certains registres, passer en veille (mise en série d'une diode qui basse la tension de 0.6V, ce qui permet de sauver les registres horloge coupé), ensuite il y a les modes sans horloges.
La différence entre ses modes, c'est le niveau de consommation, mais surtout le temps de réveille : allumer une PLL était très long, idem pour un powerdomain (qq ms ?).
Si intel propose des coupures sur FMA, les changements de mode peuvent couté très cher.
"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.
"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é"