Cela me rappelle certain concours de photos, qui disent d'un coté que toutes les photos continuent de nous appartenir, et de l'autre qu'ils ont tous les droits pour s'en servir pour faire leur publicité, sans contre parti.
Le droit moral est très théorique. Il ne peut pas se vendre, mais par exemple, changer d'avis sur l'usage d'une œuvre impose un dédommagement à l’usager, cela limite donc énormément les effets du droit moral.
"Créer un droit de courte citation et de remix audiovisuel" en gros, si le morceau d'origine est à peine reconnaissable, il ne devrait pas y avoir de droit associé.
Est-ce qu'un jour la lib principal serait remplacé par battery ou un équivalent ?
Est-ce que le support de windows sera un peu plus "sympa" ? (sys.rename qui rale si le fichier destination existe mais pas sous linux, le module "Unix", installeur pas forcément à jour, …)
Est-ce qu'il existe une library graphique digne de ce nom ? Le binding gtk est connu mais bon gtk… :/
Sans doute. Mais il faut aussi faire attention au restrict, cela doit pouvoir introduire des bugs subtiles, si on veut utiliser un autre pointeur pour se balader à l'intérieur d'un tableau par exemple.
La dépendance est sur r1. Avec un immédiat tu as : r2 = [r1+imm]
// après c'est de la manip de registre
C'est souvent complexe à faire en C malheureusement, il faut que cela soit explicit. "restrict" n'est pas encore utilisé partout. J'ai surtout l'impression que c'est utilisé dans gcc, mais c'est encore loin d'avoir atteint les compilo pour l'embarqué.
Le 1er FPGA qui était conçu pour ça était équipé d'un véritable bus, sa configuration était simplement vu comme de la mémoire. Les fpga actuelles utilisent des liens série plus lents. J'imagine que ces nouveau FPGA change de configuration pour des grosses parties, cela peut aussi vouloir dire que c'est lent.
Le problème est que tu auras toujours un gros avantage de fréquence sur un ASIC par rapport à un FPGA. Et programmer un FPGA, c'est du hardware pas du soft. Coder en VHDL, n'a rien à voir avec du C ou du C++.
Les FPGA reconfigurables à la voler ont existé, mais personne ne leur trouver d'utilité. La reconfiguraiton demande toujours un peu de temps.
"beaucoup de codes ne le seront peut-être jamais parce que la mémoire des GPU est insignifiante."
Est-ce que le problème de rassembler la mémoire des GPU, n'est pas du même genre que le partage mémoire interne des shaders ?
Après, il y a des intermédiaires entre FPGA et CPU, comme le MIC. J'ai vu un array de risc, encore plus simple que MIC, tournant à 1 GHz avec un paquet de cpu dedans.
D'ailleurs, un CPU comme celui de la futur PS4, doit être intéressant : 8 coeurs x86 et ~300 shader dans le même package avec 176 GB/s de bande passante mémoire sur 8Go.
Cray avait créé un ordinateur ou les sockets pouvaient être un gros Xillinx ou un cpu. C'était il y a presque 10 ans. Un GPU doit être bien plus simple à programmer en comparaison.
Le plus gros Vertex 7, dispose de ~10 Mo de ram interne, 3200 multiplieurs qui offrent 5300 Gmac/s en entier 16 bits, à comparer au teraflop des cartes graphiques.
A moins de faire des opérations trés bizarres, très spécifique comme de la crypto à la pelle, j'ai du mal à croire que la techno FPGA puisse faire mieux que les GPU.
Le add représente bien plus d'un cycle, car il y a une dépendance read-after-write. C'est évidement une amélioration du loop unrolling, mais bon, c'est la base, même gcc le fait tout seul (ou presque).
"via un, à la louche, load R16, PTR [R15 + CST]."
C'est bien ce que je reproche, il passe par la mémoire au lieu d'utiliser un registre (en cas de réutilisation du str->foo bien sûr). Cela doit être dû à la gestion des alias mémoire par le compilo C (2 pointeurs du même type dans le même scope et tout passe par la mémoire, car l'un peu aliaser l'autre).
D'ailleurs, cela me rappelle aussi une personne qui pensait que parce que la donné se trouvait dans les write buffer, cela n'était pas la peine d'essayer de passer par un registre. Pourtant, la bande passante, même entre un registre, et un write buffer n'a rien à avoir. Il y a souvent qu'un ou 2 bus (1read/ 1write) pour gérer la mémoire, or un x86 gère 5 instructions à la volé soit 10 read et 5 write. Et encore, il n'est pas question du surcout de la mémoire à cause de la gestion de la pagination et de sa cohérence (lecture retardé juste après un write pour vérifier que l'on ne relit pas la même donné).
Il faudrait que je le relise, mais quand il était sorti, il y avait des trucs qui m'avait fait tiquer, (mais j'ai oublié quoi :).
Il faut connaitre aussi un peu le genre de truc que sortent les compilo C, surtout avec la vectorisation automatique, en changeant un peu son code, le compilo peut faire plus de chose.
De plus, laisser faire le compilo marche bien pour les monstres comme les Intel core. Mais pour des trucs plus simple comme les PPC 603 (et donc les ARM des smartphone), tu te prends tous les problèmes des CPU les plus simple : prédiction de branchement statique, pas de prédiction de saut dynamique (vtable), très peu de write buffer (donc mélanger lecture et écriture est pénalisant), l'alignement mémoire est primordial, etc…
La doc d'AMD parle d'assembleur mais aussi de code C.
Par exemple, un code que l'on trouve dans le kernel linux, n'est pas intuitif :
for (i=0;i<N;tab+=4,i+=4){
tab[0] = tab[0] + n…
tab[1] = tab[1] + n…
tab[2] = tab[2] + n…
tab[3] = tab[3] + n…
}
C'est plus rapide car l'indexation d'un tableau par une constante, génère une seul instruction contrairement à "tab[i]" qui nécessite une addition.
Le cout d’usage des pointeurs est souvent négligé. Tous les codes utilisant des "str->foo" passe très souvent par la mémoire, plutôt que par un registre.
Je l'avais lu à une époque :) dans mon souvenir, il y avait 3 pdf. Concernant les perfs pour le codage en C, AMD avait sorti quelques choses de très lisible.
oula non. La meilleur distance de prefetch dépend de l'architecture. A la limite, le preload est mieux : tu coupes ta boucle en 3, pour qu'en simultané tu ais la lecture des données n+1, le traitement des données n, et l'écriture des données n-1. Si le parcours suit un pattern pas trop complexe, les prefetch automatiques pourront s'en sortir.
A l'époque où j'avais lu sur le sujet, il y avait les Cray qui avait un mode non-coherent (nc). C'était le seul moyen d'avoir toute la puissance disponible. Les codeurs s'arrachaient tellement les cheveux, qu'ils ont renoncer à ce genre de mode dans les machines suivantes. J'imagine que cela devait ressembler à un gros GPU mais avec des vecteurs de plusieurs centaines de flottant.
Tu veux dire que le mécanisme de cohérence mémoire n'entre pas en compte lorsque la donnée est en write buffer, mais pas encore en cache. Donc, pris en compte par le cpu ayant écrit mais pas les autres ? J'avais lu qu'il relachait sans cesse la cohérence mémoire, et l'itanium allait assez loin, mais je ne pensais pas à ce point-là.
volatile est un mot clef pour dire que la donnée mémoire déclarée ensuite, à le contenu qui bouge tout seul. C'est la base pour accéder à des registres hardware.
Dans le cas contraire, un compilo considère que seul le programme C en cours de compilation peut y toucher, d'où la génération possible de boucle infinie, de lecture unique puis un usage de registre.
La mémoire de PC est cohérente de partout normalement. Une fois une données écrite quelques part, elle est visible par tous de la même façon. Il y a logiquement un mécanisme de synchronisation qui détecte ce genre de cas.
Et une fois tu as expliqué clairement un problème, tu trouves la solution. J'adore aller ennuyer un collègue avec un problème, je fais mon monologue, puis je trouve la solution tout seul :)
Les téchniques disponibles par processeurs, ne sont pas pléthoriques. Je ne connais pas ton équipe, mais toutes les universitaires que j'ai vu bosser dans le domaine des compilateurs avaient une vision très vague de la façon de fonctionner d'un cpu.
Genre cela peut les défriser quand on leur dit :
- que plus d'instructions peut permettre d'aller plus vite que moins
- que l'instruction la plus lente est souvent un load
- que le temps d'accès à la mémoire, n'est absolument pas uniforme, avec un rapport environ de 100 entre le plus lent et le plus rapide.
- qu'une multiplication est une instruction très rapide de nos jours, mais pas du tout une division
tu peux t'en sortir, si il s'agit d'un pointeur dans B et des données dans A.
Le pointeur B peut être invalide (en dehors du fichier tel que vu actuellement), ou B pointe vers une vielle donné : si le nom est présent, on peut détecter l'erreur.
[^] # Re: Concours et vie privée
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours de programmation CodinGame le 28 mai 2013. Évalué à 1.
Cela me rappelle certain concours de photos, qui disent d'un coté que toutes les photos continuent de nous appartenir, et de l'autre qu'ils ont tous les droits pour s'en servir pour faire leur publicité, sans contre parti.
"La première sécurité est la liberté"
# remarques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Politiques publiques et droit d'auteur, quels points de réforme essentiels ?. Évalué à 2.
Le droit moral est très théorique. Il ne peut pas se vendre, mais par exemple, changer d'avis sur l'usage d'une œuvre impose un dédommagement à l’usager, cela limite donc énormément les effets du droit moral.
"Créer un droit de courte citation et de remix audiovisuel" en gros, si le morceau d'origine est à peine reconnaissable, il ne devrait pas y avoir de droit associé.
"La première sécurité est la liberté"
[^] # Re: exemples
Posté par Nicolas Boulay (site web personnel) . En réponse à l’entrée du suivi Générer des courbes (fonctionnalité de tableur). Évalué à 2 (+0/-0).
http://glsl.heroku.com propose aussi des exemples de shaders qui pourraient servir.
"La première sécurité est la liberté"
[^] # Re: La suite pour ocaml ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Présentation OCaml le 21 mai 2013 à Paris. Évalué à 3.
Est-ce qu'un jour la lib principal serait remplacé par battery ou un équivalent ?
Est-ce que le support de windows sera un peu plus "sympa" ? (sys.rename qui rale si le fichier destination existe mais pas sous linux, le module "Unix", installeur pas forcément à jour, …)
Est-ce qu'il existe une library graphique digne de ce nom ? Le binding gtk est connu mais bon gtk… :/
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 1.
"Dans 99% des cas. Sans pointeur, tu auras très très souvent :"
Non, dans 80% des cas, il s'agit d'un paramètre de ta fonction, qui est dans un registre.
"(C'est généralement juste l'affaire d'un changement de paramètre et c'est tout)…"
bah non :)
Les compilo sont souvent uniquement à la génération d'avant.
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 1.
Sans doute. Mais il faut aussi faire attention au restrict, cela doit pouvoir introduire des bugs subtiles, si on veut utiliser un autre pointeur pour se balader à l'intérieur d'un tableau par exemple.
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 1.
La dépendance est sur r1. Avec un immédiat tu as : r2 = [r1+imm]
// après c'est de la manip de registre
C'est souvent complexe à faire en C malheureusement, il faut que cela soit explicit. "restrict" n'est pas encore utilisé partout. J'ai surtout l'impression que c'est utilisé dans gcc, mais c'est encore loin d'avoir atteint les compilo pour l'embarqué.
"La première sécurité est la liberté"
[^] # Re: "Un monde de FPGA (portes logiques) est présenté"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HPC Magazine : Le média de référence du HPC et du Big Data.. Évalué à 2.
Le 1er FPGA qui était conçu pour ça était équipé d'un véritable bus, sa configuration était simplement vu comme de la mémoire. Les fpga actuelles utilisent des liens série plus lents. J'imagine que ces nouveau FPGA change de configuration pour des grosses parties, cela peut aussi vouloir dire que c'est lent.
"La première sécurité est la liberté"
[^] # Re: "Un monde de FPGA (portes logiques) est présenté"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HPC Magazine : Le média de référence du HPC et du Big Data.. Évalué à 2.
C'est possible aussi que AMD sorte une version spécial HPC avec quelques liens gigabyte ethernet en prime.
"La première sécurité est la liberté"
[^] # Re: "Un monde de FPGA (portes logiques) est présenté"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HPC Magazine : Le média de référence du HPC et du Big Data.. Évalué à 4.
Le problème est que tu auras toujours un gros avantage de fréquence sur un ASIC par rapport à un FPGA. Et programmer un FPGA, c'est du hardware pas du soft. Coder en VHDL, n'a rien à voir avec du C ou du C++.
Les FPGA reconfigurables à la voler ont existé, mais personne ne leur trouver d'utilité. La reconfiguraiton demande toujours un peu de temps.
"beaucoup de codes ne le seront peut-être jamais parce que la mémoire des GPU est insignifiante."
Est-ce que le problème de rassembler la mémoire des GPU, n'est pas du même genre que le partage mémoire interne des shaders ?
Après, il y a des intermédiaires entre FPGA et CPU, comme le MIC. J'ai vu un array de risc, encore plus simple que MIC, tournant à 1 GHz avec un paquet de cpu dedans.
D'ailleurs, un CPU comme celui de la futur PS4, doit être intéressant : 8 coeurs x86 et ~300 shader dans le même package avec 176 GB/s de bande passante mémoire sur 8Go.
"La première sécurité est la liberté"
# "Un monde de FPGA (portes logiques) est présenté"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HPC Magazine : Le média de référence du HPC et du Big Data.. Évalué à 2. Dernière modification le 16 mai 2013 à 15:54.
Cray avait créé un ordinateur ou les sockets pouvaient être un gros Xillinx ou un cpu. C'était il y a presque 10 ans. Un GPU doit être bien plus simple à programmer en comparaison.
Le plus gros Vertex 7, dispose de ~10 Mo de ram interne, 3200 multiplieurs qui offrent 5300 Gmac/s en entier 16 bits, à comparer au teraflop des cartes graphiques.
A moins de faire des opérations trés bizarres, très spécifique comme de la crypto à la pelle, j'ai du mal à croire que la techno FPGA puisse faire mieux que les GPU.
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
"le add supprimé c'est 1 cycle"
Le add représente bien plus d'un cycle, car il y a une dépendance read-after-write. C'est évidement une amélioration du loop unrolling, mais bon, c'est la base, même gcc le fait tout seul (ou presque).
"via un, à la louche, load R16, PTR [R15 + CST]."
C'est bien ce que je reproche, il passe par la mémoire au lieu d'utiliser un registre (en cas de réutilisation du str->foo bien sûr). Cela doit être dû à la gestion des alias mémoire par le compilo C (2 pointeurs du même type dans le même scope et tout passe par la mémoire, car l'un peu aliaser l'autre).
D'ailleurs, cela me rappelle aussi une personne qui pensait que parce que la donné se trouvait dans les write buffer, cela n'était pas la peine d'essayer de passer par un registre. Pourtant, la bande passante, même entre un registre, et un write buffer n'a rien à avoir. Il y a souvent qu'un ou 2 bus (1read/ 1write) pour gérer la mémoire, or un x86 gère 5 instructions à la volé soit 10 read et 5 write. Et encore, il n'est pas question du surcout de la mémoire à cause de la gestion de la pagination et de sa cohérence (lecture retardé juste après un write pour vérifier que l'on ne relit pas la même donné).
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 4.
Il faudrait que je le relise, mais quand il était sorti, il y avait des trucs qui m'avait fait tiquer, (mais j'ai oublié quoi :).
Il faut connaitre aussi un peu le genre de truc que sortent les compilo C, surtout avec la vectorisation automatique, en changeant un peu son code, le compilo peut faire plus de chose.
De plus, laisser faire le compilo marche bien pour les monstres comme les Intel core. Mais pour des trucs plus simple comme les PPC 603 (et donc les ARM des smartphone), tu te prends tous les problèmes des CPU les plus simple : prédiction de branchement statique, pas de prédiction de saut dynamique (vtable), très peu de write buffer (donc mélanger lecture et écriture est pénalisant), l'alignement mémoire est primordial, etc…
La doc d'AMD parle d'assembleur mais aussi de code C.
Par exemple, un code que l'on trouve dans le kernel linux, n'est pas intuitif :
for (i=0;i<N;tab+=4,i+=4){
tab[0] = tab[0] + n…
tab[1] = tab[1] + n…
tab[2] = tab[2] + n…
tab[3] = tab[3] + n…
}
C'est plus rapide car l'indexation d'un tableau par une constante, génère une seul instruction contrairement à "tab[i]" qui nécessite une addition.
Le cout d’usage des pointeurs est souvent négligé. Tous les codes utilisant des "str->foo" passe très souvent par la mémoire, plutôt que par un registre.
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Je l'avais lu à une époque :) dans mon souvenir, il y avait 3 pdf. Concernant les perfs pour le codage en C, AMD avait sorti quelques choses de très lisible.
Sans doute ce truc : http://support.amd.com/us/Processor_TechDocs/22007.pdf
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
oula non. La meilleur distance de prefetch dépend de l'architecture. A la limite, le preload est mieux : tu coupes ta boucle en 3, pour qu'en simultané tu ais la lecture des données n+1, le traitement des données n, et l'écriture des données n-1. Si le parcours suit un pattern pas trop complexe, les prefetch automatiques pourront s'en sortir.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2. Dernière modification le 16 mai 2013 à 10:29.
A l'époque où j'avais lu sur le sujet, il y avait les Cray qui avait un mode non-coherent (nc). C'était le seul moyen d'avoir toute la puissance disponible. Les codeurs s'arrachaient tellement les cheveux, qu'ils ont renoncer à ce genre de mode dans les machines suivantes. J'imagine que cela devait ressembler à un gros GPU mais avec des vecteurs de plusieurs centaines de flottant.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Tu veux dire que le mécanisme de cohérence mémoire n'entre pas en compte lorsque la donnée est en write buffer, mais pas encore en cache. Donc, pris en compte par le cpu ayant écrit mais pas les autres ? J'avais lu qu'il relachait sans cesse la cohérence mémoire, et l'itanium allait assez loin, mais je ne pensais pas à ce point-là.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 1.
acid est rarement nécessaire comme le montre le succès du no-sql.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
volatile est un mot clef pour dire que la donnée mémoire déclarée ensuite, à le contenu qui bouge tout seul. C'est la base pour accéder à des registres hardware.
Dans le cas contraire, un compilo considère que seul le programme C en cours de compilation peut y toucher, d'où la génération possible de boucle infinie, de lecture unique puis un usage de registre.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
La mémoire de PC est cohérente de partout normalement. Une fois une données écrite quelques part, elle est visible par tous de la même façon. Il y a logiquement un mécanisme de synchronisation qui détecte ce genre de cas.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 8.
Et une fois tu as expliqué clairement un problème, tu trouves la solution. J'adore aller ennuyer un collègue avec un problème, je fais mon monologue, puis je trouve la solution tout seul :)
"La première sécurité est la liberté"
[^] # Re: C'est trop limité ;)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Galeries de shaders GLSL et fond d'écran animé pour Android. Évalué à 2. Dernière modification le 15 mai 2013 à 17:13.
"Pas que je sache, mais en même temps, vu que la variable est globale et constante, quel serait l'intérêt de la limiter à une fonction ?"
Faire des calculs genre lui faire calculer 1/ srqt(5) une fois pour toutes sans avoir à faire confiance au compilo du drivers opengl.
"a" pour faire de la transparence, dans une fenêtre web ?
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 3.
:)
Les téchniques disponibles par processeurs, ne sont pas pléthoriques. Je ne connais pas ton équipe, mais toutes les universitaires que j'ai vu bosser dans le domaine des compilateurs avaient une vision très vague de la façon de fonctionner d'un cpu.
Genre cela peut les défriser quand on leur dit :
- que plus d'instructions peut permettre d'aller plus vite que moins
- que l'instruction la plus lente est souvent un load
- que le temps d'accès à la mémoire, n'est absolument pas uniforme, avec un rapport environ de 100 entre le plus lent et le plus rapide.
- qu'une multiplication est une instruction très rapide de nos jours, mais pas du tout une division
"La première sécurité est la liberté"
# La suite pour ocaml ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Présentation OCaml le 21 mai 2013 à Paris. Évalué à 3.
Est-ce que quelqu'un sait ce qui est prévu pour la prochaine version d'ocaml ?
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
tu peux t'en sortir, si il s'agit d'un pointeur dans B et des données dans A.
Le pointeur B peut être invalide (en dehors du fichier tel que vu actuellement), ou B pointe vers une vielle donné : si le nom est présent, on peut détecter l'erreur.
"La première sécurité est la liberté"