C'est vrai pour le calcul généraliste mais pas pour le calcul bourrin. D'ailleurs ton (1), marche si on accepte de ne jamais faire de modification en place. On lit une grande quantité de donné, pour créer une autre quantité de donné réutilisé dans la passe suivante. Chaque passe n'a pas le droit d'utiliser, les donnés générées par la passe, à un autre moment.
Concernant les PPC, tu parles des quicklogic ? Il me semble qu'il utilise des coeurs ppc classique, genre 603e ou e300.
On peut faire le parallèle avec le matériel, en lequel les militaires veulent avoir confiance. C'est le cas pour tout matériel utilisé pour la crypto.
La puce développée en France, est aussi produite en France (Atmel à Nante de mémoire).
Et ensuite, il envoie le résultat, dans un laboratoire de reverse engenering de l'armée, pour vérifier qu'aucune fonctionnalité n'a été ajouté. Il démonte la puce et compare chaque porte avec la netliste originale.
J'avais lu une fois que sur le choix "du moins pire" (quand aucun candidat se détache nettement) la méthode Condorcet était moins efficace que le scrutin majoritaire à 2 tours, qui permet de "voter contre".
Mais je ne sais pas si c'est le programmeur, le compilateur glsl/cuda/open cl > langage machine ou directement le matériel (probablement pas le matériel d’ailleurs) qui se charge de garder son pipeline bien remplit.
Pour moi, c'est le problème principal. On a vraiment l'habotude d'avoir le même genre de performance entre un modèle amd et un modèle Intel. C'est rare d'avoir un bench 50% plus rapide pour un processeur et 50% plus lent sur un autre bench.
Le compilateur opencl fait au mieux, mais selon les contraintes internes par rapport au code, les performances ne seront pas du tout les mêmes, ce qui demande un gros boulot d'optimisation pour les jeux. De mémoire, ati gère les flottant 16 bits et pas nvidia, sur un code qui n'a pas besoin de mieux, il sera 2x plus rapide qu'un code utilisant du 32 bits classique. C'est pareil, si le hardware interne gère des vecteurs de taille 2, sur une machine ayant une telle largeur, l'efficacité sera plus grande que sur un gpu scalaire.
Je sais qu'augmenter de manière énorme le nombre de registre augmente le temps de changement de tâche. Mais si il s'agit d'un banc de registres spécial, peut être que l'ancienne astuce, de sauver/restaurer le registre uniquement sur demande peut être appliqué.
Il faudrait un banc de registre par exemple 1 000 registres 256 bits. On pourrait faire des lecture mémoire de 256 à 8 bits, et ensuite faire des transferts de la taille que l'on veut vers les registres classiques. Si le core "out of order" est bien fait, il pourrait détecter ces transferts entre registres et seulement faire un "alias".
Avoir autant de registre peut permettre d'éviter un gros besoin de transfert vers la mémoire forcément plus lent que le cpu.
Un cell est simplement un dsp flottant qui exécutent 2 instructions en même temps, sur des registres SIMD. La particularité est de ne pas avoir de cache mais d'utiliser uniquement de la mémoire locale. C'est très rapide, mais très chiant à utiliser. Il faut utiliser un gros DMA pour transférer la mémoire depuis et vers la DRAM externe. Il serait sans doute possible d'automatiser tout cela avec un compilo opencl, mais je ne crois pas que cela existe.
Par rapport au GPU, il n'y a pas d'absence de cohérence de mémoire, il n'y a pas d'accès mémoires complexe, ni de lecture de type de données compliqué (genre éclater un vecteur RGB, ou une texture compressé).
Concernant la cohérence de cache, je ne pense pas que cela soit gros, mais cela fait perdre des cyclee d'horloge sur les accès.
Pour le problème de la mise de départ, ou pour le temps entre le paiement terminé et la fourniture de la feature, il est peut être possible de fonctionnement par roulement.
Le cash est réellement disponible, pour le développement de la fonctionnalité n, provient de la fonctionnalité n-1.
Une différence qui semble perdurer c'est quand même que les shaders sont mauvais sur tous ce qui n'est pas du calcul vectoriel.
Cest un peu passé; C'est fini les shader complètement vectoriels. Il me semble que ATI ne gère que 2 éléments à la fois, et nvidia est scalaire. Les codes des shaders utilisent des vecteurs de taille 1 à 4. Avec du simd, les taux d'utilisation des fpu seraient trop faibles.
Peut-être qu'il faudrait un indicateur d'entropie d'un article : plus celui-ci est issue d'un nombre d'ip différent et d'ip de nature différente,plus l'article peut être vu de manière plus neutre (ou remplit de troll).
Peut-être aussi qu'un "mode plan" serait utile pour refondre un article plus simplement.
Peut-être qu'un concept de "branche" (avec merge à 3 voies comme Git) pourrait permettre de mettre à plat les conflits d’édition tout en facilitant le refactoring d'article (et faciliter la remise en forme souvent simplifié par un revert...).
Peut-être aussi qu'une "augmentation" (y mettre une forme de forum/commentaires hiérarchique avec des [+] ?) de la page de discussion pourrait être un atout pour contourner les propriétaires de pages sauvage. Cela pourrait servir, pour y mettre des infos "informes" remis en forme par les propriétaires des pages.
L'idée, c'est quand même qu'une info moche est toujours mieux que pas d'infos du tout ! Mais certains semblent l'oublier...
Est-ce que tu sais pourquoi il est à ce point recommander d'avoir des matériaux qui stock la chaleur (mur de brique) ?
Je vois bien le principe de stockage d'énergie un peu comme une capa de découplage. Mais il y a plein de cas, où c'est gênant : aération des chambres, monté en température très lente, voir sensation de mur froid.
Il manque pas tant de chose que cela au cpu pour jouer au gpu en fait. Il faut créer des load/store un peu plus complexe pour faire de l'adressage multidimensionnel en un seul cycle, qui peut avoir une absence de cohérence, les barrières devenant explicites. Ensuite, il faut une série d'alu lié pourquoi pas à des instructions haut niveau (manipulation de matrice vecteur) et surtout il faut un énorme paquet de registres ( 128 000 de mémoires dans un bloc nvidia). Ces registres peuvent être lié au load/store special (genre load de la taille du registre mais lecture partiel possible si les registres sont SIMD).
Je pense à l'exemple donné par les EFL sous un chip Samsung dont le code était plus rapide en pure SW qu'en utilisant le GPU, la bande passante mémoire était partagé. La différence était que le code était plus "fin" en cpu, et cela économisait des accès. Mais je suis d'accord l'exemple est un peu spécial (bus partagé) et les shaders deviennent de plus en plus des cpu, il ne restera plus que la quasi-absence de cohérence mémoire.
Cela changera peut-être avec AVX d'intel ? Je crois qu'il veulent enfin vectoriser les load.
Pour avoir voulu vectoriser un pauvre filtre 2D d'image, je me suis rendu compte que la nécessité d'avoir les accès mémoires alignés, est une très très forte contrainte quand on traite des tableaux 2D. Je comprends pourquoi Altivec était tellement plus efficace, lui qui n'avait pas cette contrainte.
En gros, tu veux Larrabee, 80 x86 de type atom mais avec un jeu d'instruction SIMD de 512 bits. Je pense aussi que c'est l'avenir : les gpu sont trop complexes, ont trop de variation entre eux (il faut recoder pour chaque gpu ou presque). A moins qu'un des 2 constructeurs proposent un vrai compilo llvm pour leur shader et que du code shader complexe puisse vivre plusieurs années dans un logiciel.
[^] # Re: N'optimiser que si nécessaire
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le colonel Moutarde, sur la table (de hachage), avec un livre de maths. Évalué à 2.
c'est possible que cela soit le quicksort de la libc ?
"La première sécurité est la liberté"
[^] # Re: mouais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
C'est vrai pour le calcul généraliste mais pas pour le calcul bourrin. D'ailleurs ton (1), marche si on accepte de ne jamais faire de modification en place. On lit une grande quantité de donné, pour créer une autre quantité de donné réutilisé dans la passe suivante. Chaque passe n'a pas le droit d'utiliser, les donnés générées par la passe, à un autre moment.
Concernant les PPC, tu parles des quicklogic ? Il me semble qu'il utilise des coeurs ppc classique, genre 603e ou e300.
"La première sécurité est la liberté"
# Puces militaires
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Conférence « Vote électronique : en quoi le logiciel libre n'est pas la solution ». Évalué à 2.
On peut faire le parallèle avec le matériel, en lequel les militaires veulent avoir confiance. C'est le cas pour tout matériel utilisé pour la crypto.
La puce développée en France, est aussi produite en France (Atmel à Nante de mémoire).
Et ensuite, il envoie le résultat, dans un laboratoire de reverse engenering de l'armée, pour vérifier qu'aucune fonctionnalité n'a été ajouté. Il démonte la puce et compare chaque porte avec la netliste originale.
Pourquoi la démocratie serait moins protégée ?
"La première sécurité est la liberté"
[^] # Re: Le vote électronique avec le vote papier
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Conférence « Vote électronique : en quoi le logiciel libre n'est pas la solution ». Évalué à 2.
J'avais lu une fois que sur le choix "du moins pire" (quand aucun candidat se détache nettement) la méthode Condorcet était moins efficace que le scrutin majoritaire à 2 tours, qui permet de "voter contre".
"La première sécurité est la liberté"
[^] # Re: Pas sûr qu'il y ai un remplacement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
Mais je ne sais pas si c'est le programmeur, le compilateur glsl/cuda/open cl > langage machine ou directement le matériel (probablement pas le matériel d’ailleurs) qui se charge de garder son pipeline bien remplit.
Pour moi, c'est le problème principal. On a vraiment l'habotude d'avoir le même genre de performance entre un modèle amd et un modèle Intel. C'est rare d'avoir un bench 50% plus rapide pour un processeur et 50% plus lent sur un autre bench.
Le compilateur opencl fait au mieux, mais selon les contraintes internes par rapport au code, les performances ne seront pas du tout les mêmes, ce qui demande un gros boulot d'optimisation pour les jeux. De mémoire, ati gère les flottant 16 bits et pas nvidia, sur un code qui n'a pas besoin de mieux, il sera 2x plus rapide qu'un code utilisant du 32 bits classique. C'est pareil, si le hardware interne gère des vecteurs de taille 2, sur une machine ayant une telle largeur, l'efficacité sera plus grande que sur un gpu scalaire.
Je sais qu'augmenter de manière énorme le nombre de registre augmente le temps de changement de tâche. Mais si il s'agit d'un banc de registres spécial, peut être que l'ancienne astuce, de sauver/restaurer le registre uniquement sur demande peut être appliqué.
Il faudrait un banc de registre par exemple 1 000 registres 256 bits. On pourrait faire des lecture mémoire de 256 à 8 bits, et ensuite faire des transferts de la taille que l'on veut vers les registres classiques. Si le core "out of order" est bien fait, il pourrait détecter ces transferts entre registres et seulement faire un "alias".
Avoir autant de registre peut permettre d'éviter un gros besoin de transfert vers la mémoire forcément plus lent que le cpu.
"La première sécurité est la liberté"
[^] # Re: mouais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
Un cell est simplement un dsp flottant qui exécutent 2 instructions en même temps, sur des registres SIMD. La particularité est de ne pas avoir de cache mais d'utiliser uniquement de la mémoire locale. C'est très rapide, mais très chiant à utiliser. Il faut utiliser un gros DMA pour transférer la mémoire depuis et vers la DRAM externe. Il serait sans doute possible d'automatiser tout cela avec un compilo opencl, mais je ne crois pas que cela existe.
Par rapport au GPU, il n'y a pas d'absence de cohérence de mémoire, il n'y a pas d'accès mémoires complexe, ni de lecture de type de données compliqué (genre éclater un vecteur RGB, ou une texture compressé).
Concernant la cohérence de cache, je ne pense pas que cela soit gros, mais cela fait perdre des cyclee d'horloge sur les accès.
"La première sécurité est la liberté"
[^] # Re: Les jeux libres doivent faire leurs preuves
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Quel modèle économique pour le jeu vidéo libre?. Évalué à 2.
Pour le problème de la mise de départ, ou pour le temps entre le paiement terminé et la fourniture de la feature, il est peut être possible de fonctionnement par roulement.
Le cash est réellement disponible, pour le développement de la fonctionnalité n, provient de la fonctionnalité n-1.
"La première sécurité est la liberté"
[^] # Re: Domotique et énergie...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux fait même le café, en open-source et open-harware. Évalué à 3.
J'ai déjà vu ce genre de radiateur avec une surface en verre et un coeur de pierre :)
J'ai des radiateurs radiant, c'est le même principe sauf qu'il s'agit juste d'une tole fine, c'est beaucoup moins chère et très confortable.
"La première sécurité est la liberté"
[^] # Re: Fire in the hole.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quand vous achetez certains logiciels, vous avez le droit à... Rien. Évalué à 1.
Quand tu achètes un objet, il n'y a pas de contrat. C'est aussi ça qui est bien.
"La première sécurité est la liberté"
[^] # Re: Pas sûr qu'il y ai un remplacement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
Une différence qui semble perdurer c'est quand même que les shaders sont mauvais sur tous ce qui n'est pas du calcul vectoriel.
Cest un peu passé; C'est fini les shader complètement vectoriels. Il me semble que ATI ne gère que 2 éléments à la fois, et nvidia est scalaire. Les codes des shaders utilisent des vecteurs de taille 1 à 4. Avec du simd, les taux d'utilisation des fpu seraient trop faibles.
"La première sécurité est la liberté"
[^] # Re: Ouai enfin bon....
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche sslh 1.10, la bête noire des censeurs. Évalué à 2.
J'ai du mal à suivre, ce que tu veux dire par là.
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quand vous achetez certains logiciels, vous avez le droit à... Rien. Évalué à 6.
Un livre coute moins chère qu'une PS3. Et je ne crois pas que la personne qui avait pris un tas de note pour une thèse ai été dédommagé.
"La première sécurité est la liberté"
[^] # Re: Le problème, c’est aussi la neutralité
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Wikipedia passe à l'édition WYSIWYG. Évalué à 7.
Peut-être qu'il faudrait un indicateur d'entropie d'un article : plus celui-ci est issue d'un nombre d'ip différent et d'ip de nature différente,plus l'article peut être vu de manière plus neutre (ou remplit de troll).
"La première sécurité est la liberté"
# DRM
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quand vous achetez certains logiciels, vous avez le droit à... Rien. Évalué à 9.
Il me semble que media player a changé sa licence, il y a quelques années, pour s'arroger le droit d'effacer les médias détectés comme pirate.
Ou Amazon qui efface à distance des livres, dont il s'est rendu compte après coup qu'il n'avait pas le droit de les vendre.
C'est un peu la même idée.
"La première sécurité est la liberté"
# meilleur page de discussions ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Wikipedia passe à l'édition WYSIWYG. Évalué à 2.
Peut-être aussi qu'un "mode plan" serait utile pour refondre un article plus simplement.
Peut-être qu'un concept de "branche" (avec merge à 3 voies comme Git) pourrait permettre de mettre à plat les conflits d’édition tout en facilitant le refactoring d'article (et faciliter la remise en forme souvent simplifié par un revert...).
Peut-être aussi qu'une "augmentation" (y mettre une forme de forum/commentaires hiérarchique avec des [+] ?) de la page de discussion pourrait être un atout pour contourner les propriétaires de pages sauvage. Cela pourrait servir, pour y mettre des infos "informes" remis en forme par les propriétaires des pages.
L'idée, c'est quand même qu'une info moche est toujours mieux que pas d'infos du tout ! Mais certains semblent l'oublier...
"La première sécurité est la liberté"
[^] # Re: Domotique et énergie...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux fait même le café, en open-source et open-harware. Évalué à 2.
Est-ce que tu sais pourquoi il est à ce point recommander d'avoir des matériaux qui stock la chaleur (mur de brique) ?
Je vois bien le principe de stockage d'énergie un peu comme une capa de découplage. Mais il y a plein de cas, où c'est gênant : aération des chambres, monté en température très lente, voir sensation de mur froid.
"La première sécurité est la liberté"
[^] # Re: mouais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 3.
Il manque pas tant de chose que cela au cpu pour jouer au gpu en fait. Il faut créer des load/store un peu plus complexe pour faire de l'adressage multidimensionnel en un seul cycle, qui peut avoir une absence de cohérence, les barrières devenant explicites. Ensuite, il faut une série d'alu lié pourquoi pas à des instructions haut niveau (manipulation de matrice vecteur) et surtout il faut un énorme paquet de registres ( 128 000 de mémoires dans un bloc nvidia). Ces registres peuvent être lié au load/store special (genre load de la taille du registre mais lecture partiel possible si les registres sont SIMD).
"La première sécurité est la liberté"
[^] # Re: Pas sûr qu'il y ai un remplacement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
Je pense à l'exemple donné par les EFL sous un chip Samsung dont le code était plus rapide en pure SW qu'en utilisant le GPU, la bande passante mémoire était partagé. La différence était que le code était plus "fin" en cpu, et cela économisait des accès. Mais je suis d'accord l'exemple est un peu spécial (bus partagé) et les shaders deviennent de plus en plus des cpu, il ne restera plus que la quasi-absence de cohérence mémoire.
"La première sécurité est la liberté"
[^] # Re: Pas sûr qu'il y ai un remplacement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
Oui les caches de textures, mais c'est beaucoup plus rigide que ce qui est possible de faire avec un cpu.
"La première sécurité est la liberté"
[^] # Re: mouais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 3.
Cela n'est pourtant pas rare de voir du code shader avec une version pour ATI et une autre pour nvidia.
"La première sécurité est la liberté"
[^] # Re: mouais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
Cela changera peut-être avec AVX d'intel ? Je crois qu'il veulent enfin vectoriser les load.
Pour avoir voulu vectoriser un pauvre filtre 2D d'image, je me suis rendu compte que la nécessité d'avoir les accès mémoires alignés, est une très très forte contrainte quand on traite des tableaux 2D. Je comprends pourquoi Altivec était tellement plus efficace, lui qui n'avait pas cette contrainte.
"La première sécurité est la liberté"
[^] # Re: Domotique et énergie...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux fait même le café, en open-source et open-harware. Évalué à 2.
C'est écrit plus haut : le rendement change en fonction de la puissance demandée.
"La première sécurité est la liberté"
[^] # Re: Ouai enfin bon....
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche sslh 1.10, la bête noire des censeurs. Évalué à 3.
J'ai un peu de mal à comprendre comment un RSI peut être responsable du comportement d'un employé mais bon.
Ton 'petit' lien est un peu trop gros pour trouver rapidement l'info.
"La première sécurité est la liberté"
[^] # Re: Pas sûr qu'il y ai un remplacement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
tu oublis que les cpu ont des caches moins "statique" que les gpu. La bande passante manquante peut aussi se compenser de cette façon.
"La première sécurité est la liberté"
[^] # Re: mouais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rendu 3D logiciel. Évalué à 2.
En gros, tu veux Larrabee, 80 x86 de type atom mais avec un jeu d'instruction SIMD de 512 bits. Je pense aussi que c'est l'avenir : les gpu sont trop complexes, ont trop de variation entre eux (il faut recoder pour chaque gpu ou presque). A moins qu'un des 2 constructeurs proposent un vrai compilo llvm pour leur shader et que du code shader complexe puisse vivre plusieurs années dans un logiciel.
"La première sécurité est la liberté"