Au risque de choquer encore, en 2015, un processeur c'est plutôt du 64 bits et des performances qui permettent de faire des choses basiques confortablement.
le souci avec le logiciel est qu'il a tendance à absorber toute les ressources dont il dispose. Et les utilisateurs s'habituent au confort. C'est dur à changer, les habitudes :-D
Typiquement : affichage de pages HTML avec des mégas de javascript et décodage de vidéos H264, le tout sans mettre à genoux la machine.
Le JavaScript n'est pas un langage parallèle, même si les WebWorkers sont un pas en avant. Le (dé)codage vidéo par contre est fait pour être "accélérable" et donc utiliser des circuits parallèles et plus ou moins spécialisés. Sinon, mplayer fait du bon boulot.
Mais cela reste deux applications différentes, avec deux caractéristiques de données, d'exécution, d'algorithme, de structures, de comportements très différents. Donc les solutions idéales sont différentes. Et des types d'applications, il y en a des millions ! Comment un programme en JavaScript pourrait-il utiliser 50GFLOPS ? (nombre totalement aléatoire, pour montrer qu'il n'a pas été fait pour ça, on prendrait du FORTRAN sinon, et que chaque langage a son domaine plus ou moins précis)
Pour ce qui est de F-CPU, il y a deux choses intéressantes à retenir : c'est d'abord un "vrai" 64 bits, pas un bricolage... Une partie de l'inspiration venant du DEC Alpha. Donc c'est prêt pour des grosses applications. Pour les "plus modestes", je planche sur une version réduite à 32 bits parce que honnêtement, le 64 bits est souvent overkill pour plein de trucs. Et en plus, des chemins de données plus larges ralentissent la fréquence d'horloge (idem quand on passe de 16 à 32 bits, c'est mécanique) et ça consomme plus si on n'utilise pas les bits de poids fort, par exemple (plein de changements d'états des fils qui ne servent pas vraiment). En tout cas, FC0 (le cœur de base) est prévu pour une bonne performance single-thread, soit le cas d'utilisation "JavaScript".
D'un autre côté, le jeu d'instructions du F-CPU est capable de gérer des données arbitrairement larges. Donc il peut être fabriqué avec des registres 256 bits ou 1024 bits, comme ça vous chante. Normalement, le logiciel ne nécessite même pas d'être recompilé s'il est correctement codé. On se retrouve dans le cas qu'on appelle de nos jours "GPU" ou "GPGPU". Les registres SIMD hyperlarges peuvent être réalisés de façon brute ou vectorielle ou entre les deux, selon les contraintes. Et rien n'empêche d'implémenter autant de cœurs qu'on le désire (à vous de vous débrouiller pour qu'ils ne meurent pas de faim, parce que ça consomme de la bande passante, ces bêtes-là)
C'est pour cela que j'ai resorti F-CPU de l'armoire : il est un bon cœur single-tread pour exécuter des applications classiques, et peut être étendu pour des applications intensives plus spécifiques. Contrairement à ce qu'il se passe sur un PC, il n'y a même pas besoin de changer d'environnement de programmation ou même d'outil, le jeu d'instruction reste identique et ainsi un programme peut être baladé d'un cœur à un autre, en fonction des instructions ou ressources d'exécution qu'il demande.
Quel ordinateur actuel migre dynamiquement un programme dans la carte graphique lorsqu'il se met à accéder intensivement à la mémoire vidéo ?
Le NEC SX a l'air sympathique mais un peu hors budget
Il faut prendre les moyens de ses ambitions ;-)
Parce que ce n'est pas tout d'amonceler des unités de calcul sur une puce, il faut aussi ventiler toutes les données, et là, en dehors d'une utilisation purement vidéo, une carte vidéo ne donnera pas son plein rendement. La mémoire pose un problème énorme. Seymour Cray avait mis en place la règle que pour chaque FLOP, il fallait un mot de stockage et de bande passante... (un mot étant autour de 64 bits). Si on regarde l'exemple "(GT 970) dépassent les 3000 GFLOPS.", il y a juste 4GO de RAM, pas 3T mots... Pas étonnant que cela ne coûte "que" 400€.
D'un autre côté, un SX ne convient évidemment pas pour regarder une vidéo de youtube quand on est aux toilettes.
Pour rebondir sur les affichages géants à base de leds que vous pilotez de belle manière, est-ce que la solution de considérer les leds comme un écran et de créer l'interface HDMI aurait été viable?
Quel problème essayez-vous de résoudre, pour quelle circonstance, pour quel type de LED, quel prix, quel coût de développement, quelle réutilisabilité/flexibilité... pour quel client ?
Dans les méga-écrans, de nombreux paramètres non triviaux interviennent, comme par exemple la distance. Un hypothétique signal HDMI (plusieurs paires torsadées avec un encodage totalement dingue à ultra-haute fréquence) arrivera à un endroit, pas forcément au milieu de la surface (les architectes et artistes n'ont que faire des contingences électroniques). Puis, après un peu de "magie" (transformer le HDMI en signal intelligible par les LEDs) il faut transporter ces signaux sur des dizaines de mètres (quand ce n'est pas centaines).
C'est le transport et la conversion qui posent problème. Pour le transport, le plus fiable, économique et efficace c'est Ethernet 100BaseT et il existe des modules qui convertissent directement du RJ45 en un flux de données encapsulées par UDP. Donc directement utilisables par un FPGA.
Pour la video, l'idée serait qu'on doit transformer du HDMI en Ethernet, mais pourquoi se casser la tête alors que tout ordi qui se respecte dispose déjà d'un port Ethernet ? Un hub et c'est réglé, pas besoin de se prendre le chou à convertir. De plus, programmer une socket UDP est très facile.
La carte WizYasep est donc flexible, réutilisable, reconfigurable, indépendante du système d'exploitation ou du type d'ordinateur, la fréquence de rafraîchissement est réglable... et le coût total du système est inférieur à une version nécessitant une conversion HDMI vers Ethernet. J'allais oublier : en cas de BSOD/KP, les visiteurs ne sont pas accueillis avec des disgracieux messages systèmes ;-)
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 3.
le souci avec le logiciel est qu'il a tendance à absorber toute les ressources dont il dispose. Et les utilisateurs s'habituent au confort. C'est dur à changer, les habitudes :-D
Le JavaScript n'est pas un langage parallèle, même si les WebWorkers sont un pas en avant. Le (dé)codage vidéo par contre est fait pour être "accélérable" et donc utiliser des circuits parallèles et plus ou moins spécialisés. Sinon, mplayer fait du bon boulot.
Mais cela reste deux applications différentes, avec deux caractéristiques de données, d'exécution, d'algorithme, de structures, de comportements très différents. Donc les solutions idéales sont différentes. Et des types d'applications, il y en a des millions ! Comment un programme en JavaScript pourrait-il utiliser 50GFLOPS ? (nombre totalement aléatoire, pour montrer qu'il n'a pas été fait pour ça, on prendrait du FORTRAN sinon, et que chaque langage a son domaine plus ou moins précis)
Pour ce qui est de F-CPU, il y a deux choses intéressantes à retenir : c'est d'abord un "vrai" 64 bits, pas un bricolage... Une partie de l'inspiration venant du DEC Alpha. Donc c'est prêt pour des grosses applications. Pour les "plus modestes", je planche sur une version réduite à 32 bits parce que honnêtement, le 64 bits est souvent overkill pour plein de trucs. Et en plus, des chemins de données plus larges ralentissent la fréquence d'horloge (idem quand on passe de 16 à 32 bits, c'est mécanique) et ça consomme plus si on n'utilise pas les bits de poids fort, par exemple (plein de changements d'états des fils qui ne servent pas vraiment). En tout cas, FC0 (le cœur de base) est prévu pour une bonne performance single-thread, soit le cas d'utilisation "JavaScript".
D'un autre côté, le jeu d'instructions du F-CPU est capable de gérer des données arbitrairement larges. Donc il peut être fabriqué avec des registres 256 bits ou 1024 bits, comme ça vous chante. Normalement, le logiciel ne nécessite même pas d'être recompilé s'il est correctement codé. On se retrouve dans le cas qu'on appelle de nos jours "GPU" ou "GPGPU". Les registres SIMD hyperlarges peuvent être réalisés de façon brute ou vectorielle ou entre les deux, selon les contraintes. Et rien n'empêche d'implémenter autant de cœurs qu'on le désire (à vous de vous débrouiller pour qu'ils ne meurent pas de faim, parce que ça consomme de la bande passante, ces bêtes-là)
C'est pour cela que j'ai resorti F-CPU de l'armoire : il est un bon cœur single-tread pour exécuter des applications classiques, et peut être étendu pour des applications intensives plus spécifiques. Contrairement à ce qu'il se passe sur un PC, il n'y a même pas besoin de changer d'environnement de programmation ou même d'outil, le jeu d'instruction reste identique et ainsi un programme peut être baladé d'un cœur à un autre, en fonction des instructions ou ressources d'exécution qu'il demande.
Quel ordinateur actuel migre dynamiquement un programme dans la carte graphique lorsqu'il se met à accéder intensivement à la mémoire vidéo ?
Il faut prendre les moyens de ses ambitions ;-)
Parce que ce n'est pas tout d'amonceler des unités de calcul sur une puce, il faut aussi ventiler toutes les données, et là, en dehors d'une utilisation purement vidéo, une carte vidéo ne donnera pas son plein rendement. La mémoire pose un problème énorme. Seymour Cray avait mis en place la règle que pour chaque FLOP, il fallait un mot de stockage et de bande passante... (un mot étant autour de 64 bits). Si on regarde l'exemple "(GT 970) dépassent les 3000 GFLOPS.", il y a juste 4GO de RAM, pas 3T mots... Pas étonnant que cela ne coûte "que" 400€.
D'un autre côté, un SX ne convient évidemment pas pour regarder une vidéo de youtube quand on est aux toilettes.
Quel problème essayez-vous de résoudre, pour quelle circonstance, pour quel type de LED, quel prix, quel coût de développement, quelle réutilisabilité/flexibilité... pour quel client ?
Dans les méga-écrans, de nombreux paramètres non triviaux interviennent, comme par exemple la distance. Un hypothétique signal HDMI (plusieurs paires torsadées avec un encodage totalement dingue à ultra-haute fréquence) arrivera à un endroit, pas forcément au milieu de la surface (les architectes et artistes n'ont que faire des contingences électroniques). Puis, après un peu de "magie" (transformer le HDMI en signal intelligible par les LEDs) il faut transporter ces signaux sur des dizaines de mètres (quand ce n'est pas centaines).
C'est le transport et la conversion qui posent problème. Pour le transport, le plus fiable, économique et efficace c'est Ethernet 100BaseT et il existe des modules qui convertissent directement du RJ45 en un flux de données encapsulées par UDP. Donc directement utilisables par un FPGA.
Pour la video, l'idée serait qu'on doit transformer du HDMI en Ethernet, mais pourquoi se casser la tête alors que tout ordi qui se respecte dispose déjà d'un port Ethernet ? Un hub et c'est réglé, pas besoin de se prendre le chou à convertir. De plus, programmer une socket UDP est très facile.
La carte WizYasep est donc flexible, réutilisable, reconfigurable, indépendante du système d'exploitation ou du type d'ordinateur, la fréquence de rafraîchissement est réglable... et le coût total du système est inférieur à une version nécessitant une conversion HDMI vers Ethernet. J'allais oublier : en cas de BSOD/KP, les visiteurs ne sont pas accueillis avec des disgracieux messages systèmes ;-)