Dans certain papier, ils disent que la décompression LZ4, va plus vite qu'une copie en RAM. En multi-cpu, il arrive à saturer la bande passante mémoire. J'imagine qu'il est possible d'encore plus simplifier le schéma pour aller encore plus vite.
Est-ce que llvm propose un moyen de mélanger des langages et de faciliter l'usage de code déjà existant codé dans autre chose ?
En général, les conventions d'appels suivi sont celles du C, donc on oublie tout ce qui ressemble à de l'objet, ou un langage avec GC. Cela devient de plus en plus limitant.
"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.
[^] # 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é à 1.
Ta compression RLE compresse des lignes de pixels RGBA ?
"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é à 1.
Dans certain papier, ils disent que la décompression LZ4, va plus vite qu'une copie en RAM. En multi-cpu, il arrive à saturer la bande passante mémoire. J'imagine qu'il est possible d'encore plus simplifier le schéma pour aller encore plus vite.
"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é à 1.
"Ce n'est bien entendu pas le cas avec le SVG qui est tellement complexe qu'il te faut une VM Javascript pour couvrir tout le standard…"
Et un format vectoriel +simple, aurait du sens ?
"La première sécurité est la liberté"
[^] # Re: mélange de langage ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 1.
Je pensais au cas particuliers d'une gestion des EFL (écrites en C) avec ocaml qui a un GC. Le mélange des 2 n'a pas l'air simple du tout.
"La première sécurité est la liberté"
# mélange de langage ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 2.
Est-ce que llvm propose un moyen de mélanger des langages et de faciliter l'usage de code déjà existant codé dans autre chose ?
En général, les conventions d'appels suivi sont celles du C, donc on oublie tout ce qui ressemble à de l'objet, ou un langage avec GC. Cela devient de plus en plus limitant.
"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.
D'ailleurs, au lieu de faire du RLE, pourquoi ne pas utiliser les nouveau algo de compression ultra rapide comme LZO ou LZ4.
"La première sécurité est la liberté"
[^] # Re: SSII qui débauche ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Soutenez le libre ! pour un acte citoyen ! C'est rgent !. Évalué à 6.
Il faut surtout justifier l'absence d'augmentation de salaire.
"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. 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é"