Discussion :

[Idrakis]

Oui, c'est vrai.
Sur l'exemple que tu viens de donner : http://www.developpez.net/forums/d60...x/#post4094777

Sur le 12 cores, on vois que le 1er core est surchargé par une seul fraction de job, mais en quoi l'utilisation d'AccLib va permettre l'étalement de cette fraction de job ? J'imagine que c'est le développeur qui va tout de même devoir se charger de scinder la tache en question, et pas AccLib ? Donc a quelle partie de la gestion de la répartition du job intervient cette library exactement ?

[Fraggy]

Je suis d'accord mais par quel formule magique avec AccLib j'aurais des gains de performances plus élevés ?

pour répondre à cette question il faut d'abord comprendre pourquoi ça bloque

Ce que Idrakis a de suite compris :

Oui, c'est vrai. Sur l'exemple que tu viens de donner :


Sur le 12 cores, on vois que le 1er core est surchargé par une seul fraction de job, mais en quoi l'utilisation d'AccLib va permettre l'étalement de cette fraction de job ? J'imagine que c'est le développeur qui va tout de même devoir se charger de scinder la tache en question, et pas AccLib ? Donc a quelle partie de la gestion de la répartition du job intervient cette library exactement ?

ACCLib ne scinde pas le job de 20ms en plus petit (ça serait vraiment de la magie pour le coup). ACCLib c'est pas de la magie, c'est juste logique : en 2001 on en était la dans la réflexion (lsong et moi) la suite est logique, n'importe qui peut arriver à voir le chemin à suivre. Ensuite pour avoir un truc qui tourne avec des performances, la c'est une autre paire de manches :p

Je vois deux raisons pour ne pas en dire plus :
- ça va rien expliquer du tout, genre la question d'après ça sera : "oui mais comment tu fais pour garder la cohérence du truc ?". Évidemment une fois qu'on commence à s'expliquer on est obligé de tout dire... ce qui m'amène au deuxième point...
- je veux conserver un avantage concurrentiel, si quelqu'un développe un produit concurrent sur les mêmes concepts que les miens, je peux pas faire valoir mon brevet si j'ai pas déjà des clients et du chiffre d'affaire.... et comme le brevet va être dispo publiquement dans 15 mois, j'ai à peine le temps de faire un vrais produit et de le vendre :p

D'un autre coté si ça vous intéresse vraiment, envoyez moi un mail : vincent.song@acclib.com

[Idrakis]

Je comprends tout a fait le besoin de garder une longueur d'avance sur la concurrence, mais sans rentrer à l'intérieur des mécanismes d'AccLib, d'un point de vue uniquement externe.

Si je me retrouve dans le cas précedement cité, comment moi, utilisateur d'AccLib, je procède pour répartir mes taches ? Je lui donne en vrac toutes les taches que je veux qu'il éxecute, et il va s'occuper tout seul de l'équilibrage homogène des charges sur chaque core ?

Mais d'après ce que j'imagine, ça ne résout toujours pas le problème exposé par le shéma ci-dessus ? Car je suppose qu'AccLib n'est pas capable de diviser l'éxécution d'une même tache sur plusieurs processeurs différents ? Je me trompe là justement ? Et si je ne me trompe pas, et bien, c'est que pour moi, le problème n'est toujours pas résolut, car la tache occupant le core 1 prendra toujours la même place, et donc toujours autant de temps CPU, et donc sera toujours aussi bloquante pour le job à éxecuter.

Tu vois ce que je veux dire ?
Je ne te demande pas de me dire comment AccLib résoudra le problème en interne, mais comment moi, je verrais le résultat de cette résolution, en externe ?

Sinon, je suis très interessé par cette library, quand est-ce que la première version publique sera-t-elle disponible environ ?
Une version .NET est-elle prévue ? ou pas du tout ?

[Fraggy]

Sinon, je suis très interessé par cette library, quand est-ce que la première version publique sera-t-elle disponible environ ?
Une version .NET est-elle prévue ? ou pas du tout ?

Pour le moment je fais une étude marketing, je cherche a voir qui est intéressé, à quel prix je peux le vendre, quels sont les prescripteurs...
La lib est prête mais pour le moment elle est pas publique, dsl.
Pour la version .Net, techniquement ça serait que de la "traduction" dont ça pose pas de pb. mais rien n'est prévu.

Si je me retrouve dans le cas précedement cité, comment moi, utilisateur d'AccLib, je procède pour répartir mes taches ? Je lui donne en vrac toutes les taches que je veux qu'il éxecute, et il va s'occuper tout seul de l'équilibrage homogène des charges sur chaque core ?

Pour comprendre la répartition des taches, il faut comprendre ce qu'elles sont : pour utiliser acclib, tu es obligé de te reposer sur du code source, celui du framework. Le travail de l'utilisateur est de remplir des fonctions de callback délivrés par le framework en question.

Tu as deux types de callback, "Detect" et "Solve".
Il y a autant de callback detect que de paire logique dans ton monde : si ton monde est composé de light source (L), de sphere (S) et de box (B), tu as genre 6 detect (LL,BB,SS,LS,LB,SB), pareil pour les solve.
Donc si tu écris 12 méthodes, tu me permet de répartir les jobs comme je veux. Par exemple
- DetectLL -> return false; // pas d'interaction
- DetectLS, DetectLB -> en fonction de la distance, on va dire que false sinon true ? // tu fais comme tu veux.
- DetectSB, DetectSS, DetectBB -> //c'est le detect classique d'un moteur de physique
- SolveLL ->return;//fait rien
- SolveLS, SolveLB ->//mise à jour de ta propre structure d'affichage
- SolveSB, SolveBB, SolveSS ->//voir solve d'un moteur de physique
C'est un poil plus compliqué quand même, puisque tu dois aussi hériter de la sphère/box/lightsource que je te donne et lui associer des données (liste de vertex, direction/intensité/couleur etc...), données qui vont évoluer (ou pas) en fonction des SolveLS ou SolveLB.

En résumé, je vais te demander de tout fractionner par pair. (y a des mécanismes plus compliqué pour donner des priorités à des entités pour forcer des couples, mais bon c'est pas le sujet.)

Au niveau des résultats (vue externe) le proc est à fond quand y a plein de boulot, sinon la répartition est uniforme. Tout mon travail en ce moment c'est de faire des démos pour montrer le gain de performance, vu que je veux/peux pas expliquer comment ça marche... en tous cas pas sans NDA.

Mais d'après ce que j'imagine, ça ne résout toujours pas le problème exposé par le shéma ci-dessus ? Car je suppose qu'AccLib n'est pas capable de diviser l'éxécution d'une même tache sur plusieurs processeurs différents ? Je me trompe là justement ? Et si je ne me trompe pas, et bien, c'est que pour moi, le problème n'est toujours pas résolut, car la tache occupant le core 1 prendra toujours la même place, et donc toujours autant de temps CPU, et donc sera toujours aussi bloquante pour le job à éxecuter.

- ACCLib ne divise pas une tache données sur plusieurs coeurs (sinon ca serait magique)
- le core 1 est tj à fond et prendra tj 20 ms avec ACCLib (on peut rien faire face à ça...)
Et pourtant, sur la démo l'affichage 3D prend 60/70ms (quand je suis à fond) et j'arrive a synchroniser plus de balles avec 8 threads que 7 (donc le gain monte tj pareil) :p

Vincent, au fait, A.C.C.Lib (ça se prononce comme un acronyme, pas comme Gotlib !!!). vais me coucher moi...

EDIT : voir le post d'IDrakis juste aprés (4 detect->6 detect)

[Idrakis]

Il y a autant de callback detect que de paire logique dans ton monde [...] tu as genre 4 detect (LL,LS,LB,SB)

Si j'ai bien suivis le raisonnement, il ne manque pas BB et SS ?

Et ce que dans ce cas, on ne pourrait pas simplifier, en imaginant que le moteur physique possède une méthode générique pour tester les collisions entre tous les types de géométries ( Box, Sphères, ... ), ce qui donnerait :
LL, MM, LM

Il ne restes plus que les relations Models-Models à géré ( c'est le moteur physique qui se préoccupe des calculs de collisions en fonction de la géométrie ) et les relations Models-Lumières.

Et donc le callback Detect renverra un boolean indiquant s'il est nécessaire de lancer le callback Solve ?
Dans le cas de la physique, Detect renverra tout bettement le resultat de l'intersection des bounding box / sphere, et Solve sera chargé d'appliquer le résultat de la collision, si elle existe ?

C'est bien ça si j'ai bien compris ?

[Alp]

Dans le cas de la physique, Detect renverra tout bettement le resultat de l'intersection des bounding box / sphere, et Solve sera chargé d'appliquer le résultat de la collision, si elle existe ?

C'est bien ça si j'ai bien compris ?

En gros, oui.

Mais ce qu'il est important de comprendre, c'est qu'ACCLib va bien au-delà.
Pour être plus précis, il "suffit" de donner à manger à ACClib des données sous une certaine forme pour qu'elle puisse tout te mettre à jour et te calculer avec une bonne répartition pour tirer profit de la puissance et du nombre de coeurs. Comme dit par Fraggy précédemment, les domaines d'applications sont "infinis" dans le sens ou pour peu que l'on modélise correctement les choses, ACCLib pourra se débrouiller pour répartir.

[Matthieu Brucher]

Je vais faire mon chieur, mais génial. Merci les brevets. Mais bon, comme c'est un brevet logiciel, rien n'empêchera un gars de se baser sur ce que tu as fait pour créer une autre bibliothèque.
Et je ne crois pas non plus que tu aies des idées qui n'aient pas déjà été publiées (donc remise en cause de la pertinence d'un brevet).

[Fraggy]

Je vais faire mon chieur, mais génial. Merci les brevets. Mais bon, comme c'est un brevet logiciel, rien n'empêchera un gars de se baser sur ce que tu as fait pour créer une autre bibliothèque.

Justement, dans 15 mois, j'aurais de quoi montrer l'antériorité via un produit vendu, des clients et un CA, je pourrais défendre le brevet en question.
C'est vrais que la gestion des brevets peut être à priori mal perçue. Mais dans ACCLib on est que 2 (plus ou moins 1/2...), la boite n'existe pas encore, on est au tout début et le brevet est ma seule barrière à l'entrée. Le but du brevet c'est de me défendre contre les gros (clients et partenaires potentiels), pas de faire chier les utilisateurs potentiels.

Et je ne crois pas non plus que tu aies des idées qui n'aient pas déjà été publiées (donc remise en cause de la pertinence d'un brevet).

Concernant la publication, j'ai rien trouvé d'antérieur à mon système, mais c'est une possiblité (comme tout brevet, logiciel ou pas), c'est pour ça que je suis pas chaud de faire de l'open source. J'aimerais garder une avance en R&D.
En fait j'aime pas particulièrement le système de brevet, mais j'ai pas vraiment le choix : brevet ou pas ? si j'en fais pas je risque de me faire copier, je risque de voir des portes se fermer (investisseurs, clients...). Le seul gain évident à ne pas en faire c'est de faire des économies...
Le choix est vite fait, au pire je le renouvellerais pas et voilà...

[Fraggy]

Si j'ai bien suivis le raisonnement, il ne manque pas BB et SS ?

J'ai corrigé dans le post en question :p

Et ce que dans ce cas, on ne pourrait pas simplifier, en imaginant que le moteur physique possède une méthode générique pour tester les collisions entre tous les types de géométries ( Box, Sphères, ... ), ce qui donnerait :
LL, MM, LM

Il ne restes plus que les relations Models-Models à géré ( c'est le moteur physique qui se préoccupe des calculs de collisions en fonction de la géométrie ) et les relations Models-Lumières.

Et donc le callback Detect renverra un boolean indiquant s'il est nécessaire de lancer le callback Solve ?
Dans le cas de la physique, Detect renverra tout bettement le resultat de l'intersection des bounding box / sphere, et Solve sera chargé d'appliquer le résultat de la collision, si elle existe ?

C'est bien ça si j'ai bien compris ?

Comme disais ALP, c'est ca, mais je pense pas que ça t'aide à comprendre comment je passe le pb du job le plus lent, celui qui fait 20ms...
Concernant la partie générique de la bibliothèque, on y pense (beaucoup), limite on y travaille (un peu), mais pour l'instant la priorité c'est de faire un moteur 3D/physique :p

[Matthieu Brucher]

Justement, dans 15 mois, j'aurais de quoi montrer l'antériorité via un produit vendu, des clients et un CA, je pourrais défendre le brevet en question.
C'est vrais que la gestion des brevets peut être à priori mal perçue. Mais dans ACCLib on est que 2 (plus ou moins 1/2...), la boite n'existe pas encore, on est au tout début et le brevet est ma seule barrière à l'entrée. Le but du brevet c'est de me défendre contre les gros (clients et partenaires potentiels), pas de faire chier les utilisateurs potentiels.

C'est un brevet logiciel. Tu vas en plus assembler des briques de bases existantes. OK, tu as travaillé longtemps sur ta bibliothèque, et si quelqu'un te fait de la concurrence, il va mettre longtemps avant de faire la même chose. Ca ne veut pas dire que ça mérite un brevet. Au contraire, tu n'as pas de nouveauté en terme de parallélisme (dis-moi si je me trompe, mais tu ne vas pas recréer un nouveau type de threads, tu vas te baser sur les outils qui existent).

Concernant la publication, j'ai rien trouvé d'antérieur à mon système, mais c'est une possiblité (comme tout brevet, logiciel ou pas), c'est pour ça que je suis pas chaud de faire de l'open source. J'aimerais garder une avance en R&D.
En fait j'aime pas particulièrement le système de brevet, mais j'ai pas vraiment le choix : brevet ou pas ? si j'en fais pas je risque de me faire copier, je risque de voir des portes se fermer (investisseurs, clients...). Le seul gain évident à ne pas en faire c'est de faire des économies...
Le choix est vite fait, au pire je le renouvellerais pas et voilà...

Parce que tu n'as pas de brevet sur ton système, tu aurais pas de client ?

En tout cas, j'espère que tu as vraiment une nouveauté, mais je doute que ton système n'ait pas déjà été mis en pratique dans un domaine. Comme tu le dis, il y a des gens qui font de la recherche dans ce domaine depuis plusieurs années.

[Mat.M]

pour répondre à cette question il faut d'abord comprendre pourquoi ça bloque

Ce que Idrakis a de suite compris :

Encore une fois cela me fait vraiment sourire même si je suis neuneu et que je n'ai pas compris mais je ne comprends pas comment tu puisses obtenir un graphique avec un microprocesseur de plus de 4 coeurs vu qu'un tel CPU n'est pas commercialisé à l'heure actuelle.
Même le plus récent d'Intel le Corei7 ne semble pas avoir cela et rien ne nous dit que Intel sortira un tel processeur avec 8 coeurs par exemple parce que technologiquement et physiquement c'est quasi impossible à réaliser ( à moins de passer par la mécanique quantique ou je ne sais quoi mais c'est un autre débat )

http://www.intel.com/products/proces...ifications.htm

[Mat.M]

En passant par des threads pools, par exemple.

hummm oui comme dans \bullet-2.74\bullet-2.74\src\BulletMultiThreaded du SDK de Bullet et qui a du inspirer Mr Fraggy

[screetch]

Encore une fois cela me fait vraiment sourire même si je suis neuneu et que je n'ai pas compris mais je ne comprends pas comment tu puisses obtenir un graphique avec un microprocesseur de plus de 4 coeurs vu qu'un tel CPU n'est pas commercialisé à l'heure actuelle.
Même le plus récent d'Intel le Corei7 ne semble pas avoir cela et rien ne nous dit que Intel sortira un tel processeur avec 8 coeurs par exemple parce que technologiquement et physiquement c'est quasi impossible à réaliser ( à moins de passer par la mécanique quantique ou je ne sais quoi mais c'est un autre débat )

http://www.intel.com/products/proces...ifications.htm

Je suis a l'heure actuelle sur un double CPU quatre coeurs (ce qui n'est PAS un octo core, c'est un double quad core)

[Idrakis]

je ne comprends pas comment tu puisses obtenir un graphique avec un microprocesseur de plus de 4 coeurs vu qu'un tel CPU n'est pas commercialisé à l'heure actuelle.

Je crois que rien n'indique que les cores sont tous sur le même processeurs, ça pourrait être 3 processeurs 4 coeurs.

[Fraggy]

C'est un brevet logiciel. Tu vas en plus assembler des briques de bases existantes. OK, tu as travaillé longtemps sur ta bibliothèque, et si quelqu'un te fait de la concurrence, il va mettre longtemps avant de faire la même chose. Ca ne veut pas dire que ça mérite un brevet. Au contraire, tu n'as pas de nouveauté en terme de parallélisme (dis-moi si je me trompe, mais tu ne vas pas recréer un nouveau type de threads, tu vas te baser sur les outils qui existent).
[...]
En tout cas, j'espère que tu as vraiment une nouveauté, mais je doute que ton système n'ait pas déjà été mis en pratique dans un domaine. Comme tu le dis, il y a des gens qui font de la recherche dans ce domaine depuis plusieurs années.

C'est tj possible, que ce que j'ai fais est été déjà employé qq part ailleurs et publié (auquelles cas, mon brevet devient caduc et je ne garde que l'avance R&D). Mais j'en doute fortement, j'utilise une combinaison d'algorithmes et de principes vraiment ... innovante.
Que le Brevet soit valable ou pas à terme, est une autre affaire, pour le moment ce brevet existe, par conséquent je me dois de m'organiser comme s'il est valable.

Parce que tu n'as pas de brevet sur ton système, tu aurais pas de client ?

Disons que ça pourrait rassurer les clients : ils se disent que s'ils investissent en temps et en argent dans ma solution, je ne vais pas fermer du jour au lendemain a cause d'une autre entreprise qui dépose le même algo avec un brevet logicielle.
Si je vais voir 3 boites, qu'est ce qui garantir aux 2 plus petite que la première va pas retrouver le principe et déposer un brevet ? Si ça arrive, les deux plus petites n'ont plus qu'a s'asseoir sur leur investissement et chercher une autre solution pour la parallélisation...

[Fraggy]

Encore une fois cela me fait vraiment sourire même si je suis neuneu et que je n'ai pas compris mais je ne comprends pas comment tu puisses obtenir un graphique avec un microprocesseur de plus de 4 coeurs vu qu'un tel CPU n'est pas commercialisé à l'heure actuelle.
Même le plus récent d'Intel le Corei7 ne semble pas avoir cela...

Tu parles de quel graphique ? Le truc avec les job sur 12 coeurs c'est un exemple pour montrer le pb du job le plus long...

Si tu parles du graphique de gain de performance :

C'est sur un corei7
En abscisse on a le nb de threads, Corei7 c'est 4 coeurs HT, donc 8 threads. pour windows ça fait comme un 8 coeurs. (la confusion est peut être là)

On constate juste que les 4 derniers se comporte pas comme les 4 premiers...
La courbe jaune c'est un test sur pov ray, la rouge c'est notre bibliothèque. les deux graphiques sont le résultat de tests reproductible sur corei7 2.66 Ghz

Vincent, qu'on ne me dise pas que je sors des graphiques sur des proc qui n'existent pas !!!


ps : au fait, le xeon 7400 est un proc 8 coeurs

[Fraggy]

Je crois que rien n'indique que les cores sont tous sur le même processeurs, ça pourrait être 3 processeurs 4 coeurs.

Le graphe sur 12 coeurs était là juste pour illustrer la problématique, j'aurais pu ensuite faire un graphe sur 32 et 64 coeurs pour montrer que le job le plus lent ralenti tous le monde !!! Si vous parlez de ce graphique la, effectivement je n'ai pas de 12 coeurs à la maison :p

J'ai eu l'opportunité de tester acclib sur un serveur 4 proc 4 coeur -> 16, j'ai pas fais de vidéo, j'ai pas garder de chiffres (et je peux plus reproduire vu que j'ai du rendre le serveur a Intel).
A l'époque le gain au dela de 4 coeur n'était pas vraiment évident (entre temps acclib a bien évolué, donc j'espère que ça sera mieux la prochaine fois)

Vincent, Juste pour dire que quand je fais un graphique de perf je précise le proc utilisé :p

[Fraggy]

hummm oui comme dans \bullet-2.74\bullet-2.74\src\BulletMultiThreaded du SDK de Bullet et qui a du inspirer Mr Fraggy

Jamais lu ce papier :p
j'ai codé mon premier thread pool à l'école je crois. Dans ACCLib il y a un thread pool avec autant de threads que de coeur/thread hardware. C'est un truc relativement simple.
Et le pool lui même ne peut pas résoudre le pb du job le plus lent...

[Matthieu Brucher]

Encore une fois cela me fait vraiment sourire même si je suis neuneu et que je n'ai pas compris mais je ne comprends pas comment tu puisses obtenir un graphique avec un microprocesseur de plus de 4 coeurs vu qu'un tel CPU n'est pas commercialisé à l'heure actuelle.
Même le plus récent d'Intel le Corei7 ne semble pas avoir cela et rien ne nous dit que Intel sortira un tel processeur avec 8 coeurs par exemple parce que technologiquement et physiquement c'est quasi impossible à réaliser ( à moins de passer par la mécanique quantique ou je ne sais quoi mais c'est un autre débat )

http://www.intel.com/products/proces...ifications.htm

Les derniers Nehalem sont des QuadCore SMT, donc 8 threads.

[Matthieu Brucher]

Disons que ça pourrait rassurer les clients : ils se disent que s'ils investissent en temps et en argent dans ma solution, je ne vais pas fermer du jour au lendemain a cause d'une autre entreprise qui dépose le même algo avec un brevet logicielle.
Si je vais voir 3 boites, qu'est ce qui garantir aux 2 plus petite que la première va pas retrouver le principe et déposer un brevet ? Si ça arrive, les deux plus petites n'ont plus qu'a s'asseoir sur leur investissement et chercher une autre solution pour la parallélisation...

Si tu démontre ton antécédent par rapport au brevet, tu peux continuer à travailler avec. C'est le principe universel valable dans le monde entier.