"De maniere generale, on arrive a rendre du code vectorise avec NEON plus rapide qu'en C. "
Oui, mais sur quel CPU ? Sur A8, je n'en doute pas, sur A9, c'est moins évident.
" Globalement, le seul moyen d'ameliorer les performances que nous voyons maintenant, c'est de trouver ce que l'on peut encore dedupliquer et ce que l'on peut compresser."
Vous triez déjà les champs des structures de données par ordre décroissant de taille pour éviter le padding ?
Vous pouvez aussi mettre en place du tiling, c'est à dire de changer l'ordre des opérations pour que les données utiles restent dans le cache le plus longtemps possible (travailler par texture et non par coordonnés d'écran par exemple, etc…). Sur la multiplication de matrice pleine, cela fait gagner un facteur 10.
Sur x86, tu as aussi des instructions pour ne pas mettre certaine données en cache. Cela peut être utile, si il s'agit de faire une simple copie de données, dont tu n'as plus besoin du tout ensuite, cela évite de "trasher" le cache.
Sinon, je croyais qu'un des avantages des images vectorielles étaient justement la faible empreinte mémoire, remplacé par du temps cpu.
Oui quand tu coupes un powerdomain, il faut un temps de mise en place de la tension qui est de l'ordre de la milliseconde au moins, et tu perds au moins les registres et les caches, sauf si il y a une tension spécifique de rétention pour ces registres. Dans ce dernier cas, cela peut être vue comme la coupe d'une horloge, mais avec plus de temps de mise en route. Le plus long a redémarrer sont les pll qui génèrent les horloge, de mémoire, c'était ~250ms.
". Il faut encore qu'on fasse le port NEON. Oui, l'implementation C d'un blit de glyph en RLE est plus performante qu'un blit vectorise en assembleur…"
Je ne sais pas si cela a changé mais la balance de performance entre cpu normal et NEON a complètement changer entre CortexA8 et CortexA9, ce sont 2 équipes différentes qui ont créé les 2 cpus, l'une ne croyant pas à l'intérêt du NEON (de mémoire, c'est la française). De mémoire encore, le A8 issue 2 instructions à la fois, le A9 une seul, ce qui fait que parfois le cpu est plus rapide que le copro NEON sur A9.
"On les coupe litteralement completement si ils ne sont pas necessaire."
C'est nouveau comme technique ? Cela fait un moment que l'on peut coupé les cpu. J'imagine que c'est nouveau de n'avoir qu'un seul cpu allumé au lieu de 2 ou 4 habituellement.
"Ton point etant que quitte a avoir 4 coeurs qui tournent, autant les faire aller le plus vite possible. "
Ok, c'est ça que je ne comprenais pas : dans l'archi en question, tu ne peux pas couper les cpus individuellement. Maintenant, avec les archi big/little, ARM met 2 cpus cote à cote, et il y a un transfert de registres pour les mode les moins rapide, cela permet d'utiliser un processeur plus petit.
Je ne pense pas, surtout dans la version "lowpower". Ils peuvent faire des télécommandes HF qui utilisent juste l'énergie mécanique que l'on met pour presser une touche.
"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…)
[^] # 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. Dernière modification le 14 janvier 2014 à 09:48.
"De maniere generale, on arrive a rendre du code vectorise avec NEON plus rapide qu'en C. "
Oui, mais sur quel CPU ? Sur A8, je n'en doute pas, sur A9, c'est moins évident.
" Globalement, le seul moyen d'ameliorer les performances que nous voyons maintenant, c'est de trouver ce que l'on peut encore dedupliquer et ce que l'on peut compresser."
Vous triez déjà les champs des structures de données par ordre décroissant de taille pour éviter le padding ?
Vous pouvez aussi mettre en place du tiling, c'est à dire de changer l'ordre des opérations pour que les données utiles restent dans le cache le plus longtemps possible (travailler par texture et non par coordonnés d'écran par exemple, etc…). Sur la multiplication de matrice pleine, cela fait gagner un facteur 10.
Sur x86, tu as aussi des instructions pour ne pas mettre certaine données en cache. Cela peut être utile, si il s'agit de faire une simple copie de données, dont tu n'as plus besoin du tout ensuite, cela évite de "trasher" le cache.
Sinon, je croyais qu'un des avantages des images vectorielles étaient justement la faible empreinte mémoire, remplacé par du temps cpu.
"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.
Oui quand tu coupes un powerdomain, il faut un temps de mise en place de la tension qui est de l'ordre de la milliseconde au moins, et tu perds au moins les registres et les caches, sauf si il y a une tension spécifique de rétention pour ces registres. Dans ce dernier cas, cela peut être vue comme la coupe d'une horloge, mais avec plus de temps de mise en route. Le plus long a redémarrer sont les pll qui génèrent les horloge, de mémoire, c'était ~250ms.
"La première sécurité est la liberté"
[^] # 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é à 3.
oui mais pas à plus de 10 ko/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é à 3.
". Il faut encore qu'on fasse le port NEON. Oui, l'implementation C d'un blit de glyph en RLE est plus performante qu'un blit vectorise en assembleur…"
Je ne sais pas si cela a changé mais la balance de performance entre cpu normal et NEON a complètement changer entre CortexA8 et CortexA9, ce sont 2 équipes différentes qui ont créé les 2 cpus, l'une ne croyant pas à l'intérêt du NEON (de mémoire, c'est la française). De mémoire encore, le A8 issue 2 instructions à la fois, le A9 une seul, ce qui fait que parfois le cpu est plus rapide que le copro NEON sur A9.
"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.
"On les coupe litteralement completement si ils ne sont pas necessaire."
C'est nouveau comme technique ? Cela fait un moment que l'on peut coupé les cpu. J'imagine que c'est nouveau de n'avoir qu'un seul cpu allumé au lieu de 2 ou 4 habituellement.
"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.
"Ton point etant que quitte a avoir 4 coeurs qui tournent, autant les faire aller le plus vite possible. "
Ok, c'est ça que je ne comprenais pas : dans l'archi en question, tu ne peux pas couper les cpus individuellement. Maintenant, avec les archi big/little, ARM met 2 cpus cote à cote, et il y a un transfert de registres pour les mode les moins rapide, cela permet d'utiliser un processeur plus petit.
"La première sécurité est la liberté"
[^] # 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é à 2.
Je ne pense pas, surtout dans la version "lowpower". Ils peuvent faire des télécommandes HF qui utilisent juste l'énergie mécanique que l'on met pour presser une touche.
"La première sécurité est la liberté"
[^] # 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.
Je n'était pas ironique.
"La première sécurité est la liberté"
[^] # 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é"