Je peux juste dire que les micro benchs ont rarement un intérêt, car ils sont encore plus difficile à interpréter que les benchs applicatifs.
J'imagine qu'un "make -j" d'un noyau Linux particuliers, donnera une bonne idée de la vitesse des CPU, et du système d'IO sur des données petites.
Des tests utilisant des compresseurs video (ffmpeg, mencoder) ou audio (lame) peuvent servir pour les calculs lourd (entiers ou flottant selon les options).
7zip/gzip peuvent servir pour le bench de calcul d'entier.
Je crois qu'il existe des clients pour exciter des serveurs web et mesurer les temps de réponse, il doit donc être possible d'installer des applications web commune, et comparer ses temps, avec un PC classique.
Utiliser des vrais applications permet aussi de mesurer le degré d'adaptation/d’adaptabilité des softs avec le nouveau cpu. Si le cpu a plein de particularités pour aller vite, mais qu'aucun soft ne les gère, un micro bench dira que le cpu est le plus rapide, mais il n'aura aucun intérêt pratique. A l'époque de l'arrivé 64 bit, les soft de compression vidéo n'utilisant pas de code assembleur était forcément plus lent que leur version 32 bit optimisé à la main.
Je serais curieux de voir les vrai cas d'usage. J'avoue que depuis que j'ai "dc -l" sous la main (ou même les calculs fait par google), j'ai du mal à voir l’intérêt d'une calculatrice.
Pour moi, le layout mémoire idéal d'un système à entité consiste à regrouper par composant.
L'entité est simplement un nombre, nombre qui sert de clef dans un conteneur à composants, pour retrouver les composants.
L'idée est que chaque système manipule un nombre réduit de composants sur un grand nombre d'entités, ainsi on bénéficie d'une meilleure localité d'accès pour les caches.
Après ma position ce n'est pas que les GPU sont inutiles, loin de là. C'est juste que parler d'un rapport 100, c'est n'importe quoi. Ni en théorie, ni en pratique, on atteint le rapport 100. Même en comparant un CPU d'il y a trois ans à GPU de cette année.
Ok. J'étais rester sur des GPU avec >1 TFlops de puissance, et des cpu qui tournait à 60 Gflops. (2 instructions fpu/cycles/cpu).
Excuse-moi pour l'agressivité, mais purée t'as pas peur de la contradiction !
Non, c'était mes souvenirs. Le MULSP c'est du simple précision, et c'est 4 multiplications seulement, qui prennent 2 cycles, et non un seul.
Actuellement, tu prends 16 ops en un seul cycle. L'avx date de quand ? 2 ans max.
Je me repète mais à un instant donné, on a des groupes de 32 cœurs qui exécutent la même intruction sur un GPU.
La grosse différence, c'est que tu n'es pas obligé d'avoir les adresses mémoires contigües contrairement au SIMD. Un vecteur load/store pourrait exister, mais ce n'est pas encore fait, sauf erreur. La différence est que cela revient à pouvoir exécuter la même fonction sur 32 éléments totalement différent, contrairement au SIMD classique.
un ordre total sans le surcoût d'un protocole de cohérence.
Quel est l'intérêt de ça, si tu fonctionnes avec des threads pas franchement synchronisé ? Je comprends l’intérêt de l'ordre pour un cpu localement, mais pas pour l'ensemble des cpus. Un retard d'écriture venant d'un write buffer ou d'un retard de thread, quelle différence ?
un protocole de constance mémoire beaucoup plus faible que la cohérence de cache classique.
Il y a tout de même plus de contraintes d'utiliser du SIMD large par rapport à des GPU (un comble). Mais bon le SIMD 512 bits, efficace c'est récent, avant tu avais une seul multiplication même en SSE.
Plutôt que d'avoir une FPU de plus, what about une FPU qui sait faire 8 opérations en même temps ? ;)
Parce que personne ne code naturellement avec des gros tableau alignés pour faire une addition.( En plus ce genre de code se fait étrangler par la mémoire.)
Prends une simple image 2D, avec la gestion des canaux de couleur, il y a peu de cas qui peut se faire accélérer sans changer le code (surtout avec la gestion des bords).
Sur un serveur, la charge de travail se distribue quand même assez naturellement sur un certains nombre de cœurs,
Oui, mais c'est spécifique. En plus, J'imagine que l'augmentation de la vitesse décroit avec le nombre de cœur. Est-ce que 8 cœurs est vraiment 2x plus rapide que 4 ? La bande passante mémoire n'augmente pas aussi vite, idem pour les IO.
l'auto-vectorisation dans les compilateurs (gcc, icc) commence à très bien marcher, donc une recompilation permet déjà d'obtenir un gain en performance.
Vu que le code C impose le layout mémoire, sans le changer, j'ai de gros doute sur les accélérations possibles.
monter en fréquence c'est devenu physiquement impossible (la puissance dissipée augmente de manières quadratique par rapport à la fréquence) et c'est sur que ça devient plus difficile de gagner en performance.
L'équation complète inclus la capacité parasite et la tension, qui peuvent toutes les 2 baisser. De plus, il pourrait rajouter des unités de calcul, j'imagine qu'une application bien écrit devrait tirer facilement des performances d'une unité de FPU de plus.
# simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rust en version 0.12. Évalué à -5.
Pourquoi faire aussi complexe ?
```
fn twice(x: int, f: |int| -> int) -> int {
f(x) + f(x)
}
fn main() {
let square = |x: int| { x * x };
}
```En ocaml, on peut l'écrire :
let twice x f = (f x) + (f x)
let _ =
let square x = x *x in
twice 5 square
Pourquoi créer un nouveau langage pour faire aussi verbeux et compliquer qu'avant ?
"La première sécurité est la liberté"
[^] # Re: Power8 chez OVH
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 4.
Je peux juste dire que les micro benchs ont rarement un intérêt, car ils sont encore plus difficile à interpréter que les benchs applicatifs.
J'imagine qu'un "make -j" d'un noyau Linux particuliers, donnera une bonne idée de la vitesse des CPU, et du système d'IO sur des données petites.
Des tests utilisant des compresseurs video (ffmpeg, mencoder) ou audio (lame) peuvent servir pour les calculs lourd (entiers ou flottant selon les options).
7zip/gzip peuvent servir pour le bench de calcul d'entier.
Je crois qu'il existe des clients pour exciter des serveurs web et mesurer les temps de réponse, il doit donc être possible d'installer des applications web commune, et comparer ses temps, avec un PC classique.
Utiliser des vrais applications permet aussi de mesurer le degré d'adaptation/d’adaptabilité des softs avec le nouveau cpu. Si le cpu a plein de particularités pour aller vite, mais qu'aucun soft ne les gère, un micro bench dira que le cpu est le plus rapide, mais il n'aura aucun intérêt pratique. A l'époque de l'arrivé 64 bit, les soft de compression vidéo n'utilisant pas de code assembleur était forcément plus lent que leur version 32 bit optimisé à la main.
"La première sécurité est la liberté"
[^] # Re: super soft !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Une calculatrice scientifique libre sous Linux (materiel). Évalué à 2.
Je serais curieux de voir les vrai cas d'usage. J'avoue que depuis que j'ai "dc -l" sous la main (ou même les calculs fait par google), j'ai du mal à voir l’intérêt d'une calculatrice.
"La première sécurité est la liberté"
[^] # Re: super soft !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Une calculatrice scientifique libre sous Linux (materiel). Évalué à 2.
Une liseuse avec un bon système tactile devrait faire une calculatrice efficace.
"La première sécurité est la liberté"
[^] # Re: Benchmark
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à -1.
Cela évite d'utiliser des pointeurs :)
"La première sécurité est la liberté"
[^] # Re: super soft !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Une calculatrice scientifique libre sous Linux (materiel). Évalué à 3.
Une liseuse, cela peut être un ARM9 à 200Mhz. Il n'y a pas de fpu, mais c'est toujours plus rapide que les cpu dédiés à 20Mhz.
"La première sécurité est la liberté"
[^] # Re: Benchmark
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à 2.
Ou alors tu le code toi-même : un vector pour le stockage et un hashmap pour l'association composant <-> entity.
"La première sécurité est la liberté"
[^] # Re: Benchmark
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à 2.
Pour chaque entité tu alloues tous les composants ? Pourquoi pas seulement, les composants utiles ?
"La première sécurité est la liberté"
[^] # Re: bizarre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à 2.
Les indirections sont bien plus local que dans un système classique.
"La première sécurité est la liberté"
[^] # Re: En heures !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Logiciel libre de gestion des congés. Évalué à 1.
Une personne en 4/5ième (80%), à 5 semaines de congé de 4 jours.
"La première sécurité est la liberté"
# bizarre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à 6. Dernière modification le 09 octobre 2014 à 18:04.
Pour moi, le layout mémoire idéal d'un système à entité consiste à regrouper par composant.
L'entité est simplement un nombre, nombre qui sert de clef dans un conteneur à composants, pour retrouver les composants.
L'idée est que chaque système manipule un nombre réduit de composants sur un grand nombre d'entités, ainsi on bénéficie d'une meilleure localité d'accès pour les caches.
Le conteneur peut être une hashmap ou un arbre.
"La première sécurité est la liberté"
[^] # Re: super soft !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Une calculatrice scientifique libre sous Linux (materiel). Évalué à 1.
Dans ce cas, il pourrait trouver une tablette chinoise, sans wifi ni bluethout de 5 à 7", cela fera bien mieux l'affaire.
"La première sécurité est la liberté"
# super soft !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Une calculatrice scientifique libre sous Linux (materiel). Évalué à 4.
J'aurais fais les mêmes choix de soft, mais pourquoi ne pas en faire une application libre pour smartphone ?
J'imagine que le hard est fun à faire, mais cela limite pas mal la diffusion du projet.
"La première sécurité est la liberté"
# Le sénat dernier espoir ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le sénat dernier espoir ?. Évalué à 4.
C'est pas Obiwan Kenobi, le dernier espoir ?
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 2.
Ok. J'étais rester sur des GPU avec >1 TFlops de puissance, et des cpu qui tournait à 60 Gflops. (2 instructions fpu/cycles/cpu).
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à -3.
Non, c'était mes souvenirs. Le MULSP c'est du simple précision, et c'est 4 multiplications seulement, qui prennent 2 cycles, et non un seul.
Actuellement, tu prends 16 ops en un seul cycle. L'avx date de quand ? 2 ans max.
La grosse différence, c'est que tu n'es pas obligé d'avoir les adresses mémoires contigües contrairement au SIMD. Un vecteur load/store pourrait exister, mais ce n'est pas encore fait, sauf erreur. La différence est que cela revient à pouvoir exécuter la même fonction sur 32 éléments totalement différent, contrairement au SIMD classique.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 2.
Quel est l'intérêt de ça, si tu fonctionnes avec des threads pas franchement synchronisé ? Je comprends l’intérêt de l'ordre pour un cpu localement, mais pas pour l'ensemble des cpus. Un retard d'écriture venant d'un write buffer ou d'un retard de thread, quelle différence ?
Lequel ?
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 1.
Cela m'étonnerait beaucoup. Même dans la DDR, il y a un mode de transfert qui demande la data qui intéresse en premier.
"La première sécurité est la liberté"
[^] # Re: Non !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 4.
J'imagine que depuis que Intel fait de l'AVX en 64 bits, cela n'a plus trop d'intérêt.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 2.
Regarder le monothread pour du HPC, c'est pas sérieux.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 2.
Y'a ARM aussi.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 1.
Il y a tout de même plus de contraintes d'utiliser du SIMD large par rapport à des GPU (un comble). Mais bon le SIMD 512 bits, efficace c'est récent, avant tu avais une seul multiplication même en SSE.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 2.
Parce que personne ne code naturellement avec des gros tableau alignés pour faire une addition.( En plus ce genre de code se fait étrangler par la mémoire.)
Prends une simple image 2D, avec la gestion des canaux de couleur, il y a peu de cas qui peut se faire accélérer sans changer le code (surtout avec la gestion des bords).
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 1.
Je parlais de puissance disponible (max) pas de performance réelle.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 2.
Oui, mais c'est spécifique. En plus, J'imagine que l'augmentation de la vitesse décroit avec le nombre de cœur. Est-ce que 8 cœurs est vraiment 2x plus rapide que 4 ? La bande passante mémoire n'augmente pas aussi vite, idem pour les IO.
Vu que le code C impose le layout mémoire, sans le changer, j'ai de gros doute sur les accélérations possibles.
L'équation complète inclus la capacité parasite et la tension, qui peuvent toutes les 2 baisser. De plus, il pourrait rajouter des unités de calcul, j'imagine qu'une application bien écrit devrait tirer facilement des performances d'une unité de FPU de plus.
"La première sécurité est la liberté"