Un projet pour exploiter au mieux le multicore

Remarque, la théorie est simple pour la programmation multithread, les mutex, les sémaphores ya rien de compliqué, c'est pas une question d'apprentissage, ce qui est difficile c'est la conception. C'est comme les maths, les 4 opérations +-*/ c'est simple mais on peut quand même tomber sur des problèmes complexes avec ces opérations.

De toutes facons le codage ce n'est pas pour les genis, c'est la conception qui demande de la reflexion
et de toutes facons etre informatcien ce n'est pas bien difficile compare a d'autres iers comme ceux de l'electronique

tampigns a écrit:

et de toutes facons etre informatcien ce n'est pas bien difficile compare a d'autres iers comme ceux de l'electronique

Moaurh, je n'ai jamais réussi à me lancer dans la programmation (à part celle des calculatrice et encore.). Ca me parait imbitable. :/

tampigns a écrit:
de toutes facons etre informatcien ce n'est pas bien difficile compare a d'autres iers comme ceux de l'electronique

Assez réducteur et faux. D'accord pour les développeurs de la plupart des domaines basiques (la plupart des SSII, désolais pour ceux qui en sont ;)) ; pas pour les domaines techniquement pointus, et surtout pas d'accord pour tout ce qui touche au rendu, aux jeux, Os, IR et j'en passe :
article.gmane.org...
article.gmane.org...
Edité le 04/05/2008 à 15:29

tampigns a écrit:
De toutes facons le codage ce n'est pas pour les genis, c'est la conception qui demande de la reflexion
et de toutes facons etre informatcien ce n'est pas bien difficile compare a d'autres iers comme ceux de l'electronique

Tout de même, s'il est assez simple de programmer, savoir bien coder en entreprise me semble demander pas mal de connaissances : savoir commenter, faire la doc, respecter les conventions d'écriture, se servir de cvs / svn, de la prog objet, ... sans compter que les frameworks genre .Net ne me semble pas si évidents à maîtriser pour un autodidacte.
J'ai pas mal de copains en entreprise qui dépriment quand ils voient le code pondu par des autodidactes, genre du java codé comme du C, du SQL complètement sous-optimisé parce qu'il n'utilise pas des trucs un peu complexes, etc..

tfpsly a écrit:
De toute façon la prog ne s'apprend jamais en classe/univ/école d'ingé. On y apprend des concepts théoriques, mais la programmation s'apprend en pratiquant, que ce soit en algorithmie en générale ou pour tout ce qui est particulier à certains domaines ou applis (rendu, multithreading & parallélisation...). Pas pour rien que pas mal de bons programmeurs ne sortent justement pas de formation d'informatique mais d'école d'ingés généralistes, ou de Masters non CS aux Usa par exemple.

C'est quand même bien d'avoir la pratique en // de la théorie, même si je suis d'accord que la théorie a plus d'importance et que la pratique peut être obtenu en pratiquant par soin même. Y a aussi un point intéressant à faire la pratique en école, c'est qu'on simule le travail en équipe qui peut poser bien plus de problème que de ne pas savoir coder en C ;) Par ailleurs, dans mon école d'ingé, les stages étaient obligatoires chaque année parce qu'en sortie, si t'as que de la connaissance et pas de pratique on ne te prend pas: les boites sont exigeantes, elles veulent des personne fonctionnelle dès le premier jour. :neutre: Ca te permet aussi d'appréhender le travail en entreprise et de voir justement la différence entre la théorie et la pratique :paf:

tfpsly a écrit:
Une appli multithreadée tournant sur un monoproc monocore (ou sur un trop petit nombre de cpus) tournera toujours un peu moins vite à cause des changements de threads qui ne sont pas du tout gratuits. Mais c'est quantité négligeable à moins de vraiment avoir un nombre énorme de threads.

+1 et tu as des pertes aussi en synchro pour les caches CPU que tu n'a pas en monothread, qui impactent les applis multi-thread, là aussi semble-t-il de façon légère d'après les quelques tests que j'ai vu. Je sais pas ce que ça va donner avec l'augmentation du nombre de cœur .

kpouer a écrit:
Remarque, la théorie est simple pour la programmation multithread, les mutex, les sémaphores ya rien de compliqué, c'est pas une question d'apprentissage, ce qui est difficile c'est la conception. C'est comme les maths, les 4 opérations +-*/ c'est simple mais on peut quand même tomber sur des problèmes complexes avec ces opérations.

+1 Et on le voit qu'en pratiquant :)

kpouer a écrit:

HeavyArmor a écrit:
Traduction, programmeurs, si vous voulez être payé: faites des études de ce genre :paf: Non c'est vrai, 3 ans et un gros budget pour proposer une solution de simplification (y a rien de neuf à inventer...) qui va arriver en retard :super: J'ose espérer que ça sera vraiment très pratique...
Je note encore une fois que y a des programmeurs qui se plaignent alors que ça fait belle lurette qu'ils auraient dû se pencher sur la question...

Ce qui est incroyable c'est qu'avec une telle quantité d'experts en multicore sur le forum de clubic ces processeurs ne sont toujours pas exploités a fond par la plupart des logiciels

Ce qui est incroyable c'est la vitesse à laquelle certains jugent les autres sans les connaitre :/ Je ne me suis jamais considéré comme un expert un multi-threading ou programmation multi-cœur, mais j'ai quand même pratiqué assez pour voir les problèmes que l'on rencontre, j'ai déjà étudier le fonctionnement d'un jeu et je sais que c'est possible: on a même des exemples concrets. Je suis un programmeur parmi tant d'autres.
J'ai pas dit que c'était facile, simplement que dans 3 ans, le public visé sera équipé quad-core pour un grand nombre, bi-core pour les autres (octo pour les hardcore) et que c'était prévisible. On va vers une augmentation du nombre de threads physiques et la puissance par thread physique va certainement stagner à côté. Il est donc nécessaire d'en passer par là, même si ça a un coût important (refaire l'architecture éventuellement). Ils devraient mettre de l'énergie là-dedans plutôt que de râler pour rien: ça défoule peut-être, c'est un moyen de s'expliquer j'en sais rien. Mais l'important c'est que la migration avance, et on va pas attendre 3 ans pour ça... C'est une éternité 3 ans :/ Dans les autres domaines que le jeu ça marche très bien sans ce projet, je ne sais pas encore si ça apportera grand chose dans 3 ans, à voir.

d9pouces a écrit:
savoir commenter, faire la doc

Savoir ne pas avoir besoin de commenter est encore mieux ;) Code auto-documenté, api/interfaces évidentes... Extreme Programming again... ;)
Les commentaires importants sont ceux expliquant un choix technique ou expliquant un algo complexe ; la plupart des commentaires sont en général superflu, à peine mieux que "camera.updateMatrix(); // update the current camera matrix".

tfpsly a écrit:

tampigns a écrit:
de toutes facons etre informatcien ce n'est pas bien difficile compare a d'autres iers comme ceux de l'electronique

Assez réducteur et faux. D'accord pour les développeurs de la plupart des domaines basiques (la plupart des SSII, désolais pour ceux qui en sont ;)) ; pas pour les domaines techniquement pointus, et surtout pas d'accord pour tout ce qui touche au rendu, aux jeux, Os, IR et j'en passe :
article.gmane.org...
article.gmane.org...

En même temps le terme "informaticien" ça veut tout et rien dire :neutre: C'est super vague. Ca va du programmeur/agent de saisie qui code bêtement ce qu'on lui demande (passer d'un langage à un autre par exemple, voir recopier le même code en changeant un paramètre), à l'ingénieur qui conçoit l'architecture de tout un SI.
Chacun a ses compétences, sa fonction et l'ensemble ne marche pas si on enlève un maillon... Après y a les spécialités qui viennent s'ajouter ce qui nous donne une multitude de profils et je doute que l'on puisse comparer, dire qu'un domaine est plus dur que l'autre: ça dépend du candidat et de l'exigence du domaine. Pour les jeux j'imagine que l'exigence doit être bien présente.

d9pouces a écrit:
J'ai pas mal de copains en entreprise qui dépriment quand ils voient le code pondu par des autodidactes, genre du java codé comme du C, du SQL complètement sous-optimisé parce qu'il n'utilise pas des trucs un peu complexes, etc..

Et t'as vu la gueule de l'autodidacte quand il voit le code "optimisé" avec les trucs complexes ? :paf: Je dis pas qu'il ne faut pas exploiter l'outil tant qu'on peut, mais faut faire gaffe que d'autres puissent te relire, et ils sont pas forcément aussi spécialistes que celui qui a initialement codé... C'est un paramètre qui a son importance en entreprise, comme la doc.

tfpsly a écrit:

d9pouces a écrit:
savoir commenter, faire la doc

Savoir ne pas avoir besoin de commenter est encore mieux ;) Code auto-documenté, api/interfaces évidentes... Extreme Programming again... ;)
Les commentaires importants sont ceux expliquant un choix technique ou expliquant un algo complexe ; la plupart des commentaires sont en général superflu, à peine mieux que "camera.updateMatrix(); // update the current camera matrix".

Si ton applis est assez grosse, tu devras quand même faire une doc expliquant l'architecture générale employée.
Le commentaire dans le code, c'est sûr que s'il paraphrase le code, autant donner un bouquin expliquant le langage au potentiel lecteur :paf: D'autant qu'on en est normalement plus à donner des noms à coucher dehors: les objets sont nommé de façon suffisamment claire.
Tu peux aussi préciser les valeurs normales d'une variable à un endroit stratégique du code, pourquoi tu ne testes pas telle ou telle valeur... ce qui rendra un fier service à celui qui relira si tu as fais volontairement l'impasse sur certains test ou si tu as optimisé au point de rendre le code un peu dur à suivre... Si en plus quelqu'un doit faire une modif après, il vaut mieux lui décrire ta démarche à moins que ton code soit académique, l'algo simple et les variables idéalement nommées :)


PS: à oui, l'autre ça peut être toi dans 6 mois. Penses à toi :ane:

HeavyArmor a écrit:
Si ton applis est assez grosse, tu devras quand même faire une doc expliquant l'architecture générale employée.

Oui et ça s'appelle un TDD - Technical Design Document.

HeavyArmor a écrit:
Le commentaire dans le code, c'est sûr que s'il paraphrase le code, autant donner un bouquin expliquant le langage au potentiel lecteur :paf: D'autant qu'on en est normalement plus à donner des noms à coucher dehors: les objets sont nommé de façon suffisamment claire.

Voila.

HeavyArmor a écrit:
Tu peux aussi préciser les valeurs normales d'une variable à un endroit stratégique du code, pourquoi tu ne testes pas telle ou telle valeur...

Non, car un assert fera ça de bien meilleure façon car il auto-documente le code tout en vérifiant que le cas non géré ne se produit pas ; ce que ne fera jamais un commentaire. Les énumérations servent également à vérifier - à la compilation, donc ça n'empêche pas de mettre des asserts - que l'on utilise des valeurs correctes.
D'où ce que je disais : code propre = lisible, concis, auto-documenté, pas besoin de commentaire, sauf algo très complexe.

---

HeavyArmor a écrit:
(recopier le même code en changeant un paramètre)

Ouch, code smell spotted!
Exemple typique de code crado! Les copiers-collers de bloc de code devraient être interdit.
Edité le 04/05/2008 à 17:02

tfpsly a écrit:

d9pouces a écrit:
savoir commenter, faire la doc

Savoir ne pas avoir besoin de commenter est encore mieux ;) Code auto-documenté, api/interfaces évidentes... Extreme Programming again... ;)
Les commentaires importants sont ceux expliquant un choix technique ou expliquant un algo complexe ; la plupart des commentaires sont en général superflu, à peine mieux que "camera.updateMatrix(); // update the current camera matrix".

Oui, possible... enfin, c'est typiquement le genre de trucs que je ne connais absolument pas même si je suis dans l'informatique, vu que je n'ai eu aucun cours dessus... Et justement, c'est comme ça que je me rends compte que c'est loin d'être évident pour un autodidacte de connaître tout ça (enfin, je m'en fous, ce n'est pas du tout mon rôle, je me contente de produire dans le pire des cas du pseudo-code :ane:)

d9pouces a écrit:
Oui, possible... enfin, c'est typiquement le genre de trucs que je ne connais absolument pas même si je suis dans l'informatique, vu que je n'ai eu aucun cours dessus... Et justement, c'est comme ça que je me rends compte que c'est loin d'être évident pour un autodidacte de connaître tout ça (enfin, je m'en fous, ce n'est pas du tout mon rôle, je me contente de produire dans le pire des cas du pseudo-code :ane:)

Je suis autodidacte en grande partie ;)
Portage de programmes en Basic sur mon Apple II à 8 ans, début de programmation en Pascal + ASM à 13 ans, demoscene, jeux vidéos... Mine de rien, entre mes quelques stages d'école d'ingé en SSII et mes boulots dans le JV, je vois clairement de quel coté j'ai vu du code de qualité et un minimum de vraie méthodologie... Clairement pas en SSII :o

PS: un moyen de s'améliorer à écrire du code lisible et facile à utiliser : relire du code que l'on a écrit 5 ou 10 ans auparavant et se prendre une bonne poilade à découvrir les conneries qu'on a pu faire ;)
Edité le 04/05/2008 à 17:24

tfpsly a écrit:

---

HeavyArmor a écrit:
(recopier le même code en changeant un paramètre)

Ouch, code smell spotted!
Exemple typique de code crado! Les copiers-collers de bloc de code devraient être interdit.

Exemple typique que j'ai vu appliqué à grande échelle (sur gros système), parce qu'on veut pas modifier trop l'existant alors on utilise des "informaticiens" pour recopier ce qui marche et adapter au nouveau cas. C'est ultra lourd, chiant, redondant... Par contre c'est assez robuste, simple à lire parce que ce sont de petites opérations que l'on enchaine... Evidemment c'est pas adapté aux changements, mais alors pas du tout, et je crois que c'est voulu ;) Le système lui même était pas adapté au changement et l'organisation non plus donc, c'était pas le pire :paf:

Sinon le copier / coller ça ne me dérange pas particulièrement: ce qui me dérange c'est pas de copier/coller, c'est d'avoir de la redondance, donc deux modifs à faire là où une seule suffirait. C'est pour le suivit que ça me chagrine, parce qu'après le code que tu récupères peut très bien s'insérer de façon harmonieuse et logique dans le code cible. Ca m'arrive, mais en général, je le relis et le retape parce que c'est rarement pile-poil adapté, ou alors je m'en sert de guide pour recoder... ça dépend.Rassures-toi j'ai horreur des mélanges informes.

Tu viens de me rappeler que les asserts existent... Je ne m'en sers jamais. Peut-être parce que je code surtout de l'appli de gestion que que le traitement des erreurs je le fais en direct avec des tests, ou c'est un cas anormal et je capte une exception pour limiter la casse: je ne peux rien y faire de toute façon. De toute façon si je pose une assertion, je serais obligé de dire pourquoi. Je veux que ce soit compris, pas seulement protégé contre un plantage (qui de toute façon va se produire).

Edit: je commence à plus apprécier ces bugs d'envoi :/ ²
Edité le 04/05/2008 à 17:31

HeavyArmor a écrit:
ce qui me dérange c'est pas de copier/coller, c'est d'avoir de la redondance, donc deux modifs à faire là où une seule suffirait.

C'est ce à quoi je faisais référence par copier-collé de code ;)

HeavyArmor a écrit:
je capte une exception pour limiter la casse

Pourquoi on n'utilise pas d'exception dans le jeu vidéo :
www.codercorner.com...
Par l'auteur de Opcode - une des plus célèbres lib de détection de collision ; juste pour dire que le gars est connu et fiable/solide - Code testé sur son moteur Ice (rendu, collisions par Opcode, un peu de gameplay...) : 10% plus large, 21% plus lent.

HeavyArmor a écrit:

kpouer a écrit:

HeavyArmor a écrit:
Traduction, programmeurs, si vous voulez être payé: faites des études de ce genre :paf: Non c'est vrai, 3 ans et un gros budget pour proposer une solution de simplification (y a rien de neuf à inventer...) qui va arriver en retard :super: J'ose espérer que ça sera vraiment très pratique...
Je note encore une fois que y a des programmeurs qui se plaignent alors que ça fait belle lurette qu'ils auraient dû se pencher sur la question...

Ce qui est incroyable c'est qu'avec une telle quantité d'experts en multicore sur le forum de clubic ces processeurs ne sont toujours pas exploités a fond par la plupart des logiciels

Ce qui est incroyable c'est la vitesse à laquelle certains jugent les autres sans les connaitre :/ Je ne me suis jamais considéré comme un expert un multi-threading ou programmation multi-cœur, mais j'ai quand même pratiqué assez pour voir les problèmes que l'on rencontre, j'ai déjà étudier le fonctionnement d'un jeu et je sais que c'est possible: on a même des exemples concrets. Je suis un programmeur parmi tant d'autres.
J'ai pas dit que c'était facile, simplement que dans 3 ans, le public visé sera équipé quad-core pour un grand nombre, bi-core pour les autres (octo pour les hardcore) et que c'était prévisible. On va vers une augmentation du nombre de threads physiques et la puissance par thread physique va certainement stagner à côté. Il est donc nécessaire d'en passer par là, même si ça a un coût important (refaire l'architecture éventuellement). Ils devraient mettre de l'énergie là-dedans plutôt que de râler pour rien: ça défoule peut-être, c'est un moyen de s'expliquer j'en sais rien. Mais l'important c'est que la migration avance, et on va pas attendre 3 ans pour ça... C'est une éternité 3 ans :/ Dans les autres domaines que le jeu ça marche très bien sans ce projet, je ne sais pas encore si ça apportera grand chose dans 3 ans, à voir.

Ca n'empeche pas que tu n'ais pas l'air de savoir de quoi tu parle, on dirait que tu vois l'arrivée des multicore comme l'arrivée de la pénurie de pétrole pour l'automobile, dans un cas il faut trouver une méthode de programmation miracle, dans l'autre cas il faut trouver une énergie différente.
Mais ca n'a rien a voir, la programmation multithread ca fait longtemps que ca existe et que c'est connu et il n'y a pas une solution qui va permettre de tout changer pour que tout soit multithread.
La programmation multithread apporte énormément de problèmes, donc si les développeurs pensent que leur truc tournera bien avec un PC moyen d'aujourd'hui, ben ils se casseront pas la tête pour le plaisir, et il faut pas imaginer qu'il va sortir un bouzin qu'il suffira de coller a coté du compilateur pour rendre le soft multithread car ce n'est pas possible

Il faudrait aussi modérer vos propos les gars, quand vous dites que "le multithread apporte énormément de problèmes"... si ça en apportait autant que vous en donnez l'impression ici, personne (pas même les fondeurs) n'investiraient dedans ;)

Une nouvelle technologie/possibilité arrive, bah je sais que ça fait méga chier les "spécialisés/experts" mais faut savoir remettre ses acquis en question et retourner à l'école... (se remettre en question... voilà quelque chose qui n'est vraiment pas donné à tout le monde)
Edité le 04/05/2008 à 18:40

Mais justement le multithread apporte énormément de problèmes c'est un fait, et ce n'est pas une question de retourner a l'école. :neutre:
Evidemment ca apporte de grands avantages c'est clair, mais ca multiplie les bugs potentiels de facon exponentielle, et les bugs qui y sont liés sont souvent très difficiles à détecter.
Et ce n'est en aucun cas une nouvelle technologie, ca fait plus de 50 ans que ca existe

kpouer a écrit:
Ca n'empeche pas que tu n'ais pas l'air de savoir de quoi tu parle, on dirait que tu vois l'arrivée des multicore comme l'arrivée de la pénurie de pétrole pour l'automobile, dans un cas il faut trouver une méthode de programmation miracle, dans l'autre cas il faut trouver une énergie différente.

Je comprend vraiment rien à ce que tu me raconte: je vois le multicore comme une techno qui date de longtemps (c'est comme le multiproc) et qui va devenir nécessaire dans certaines applis et on a l'impression que c'est tout un fromage, moi je pense que non. Je vois as où je parle de miracle et ta comparaison me parait très obscure... :/

Mais ca n'a rien a voir, la programmation multithread ca fait longtemps que ca existe et que c'est connu et il n'y a pas une solution qui va permettre de tout changer pour que tout soit multithread.

Et j'ai jamais dis ça, mais c'est pas grave... Moi je te dis que beaucoup d'appli sont déjà multithread, j'ai pas dis que j'allais butter chaque programmeur qui code en monothread :o² A eux de voir s'ils peuvent et s'ils en tire quelque chose ou pas. Dans les jeux va falloir, à moins de limiter la gourmandise des jeux, et franchement, j'y crois pas... :neutre:

La programmation multithread apporte énormément de problèmes, donc si les développeurs pensent que leur truc tournera bien avec un PC moyen d'aujourd'hui, ben ils se casseront pas la tête pour le plaisir, et il faut pas imaginer qu'il va sortir un bouzin qu'il suffira de coller a coté du compilateur pour rendre le soft multithread car ce n'est pas possible

Là encore j'ai jamais dis ou pensé ça, et je n'ai pas l'impression que apporte autant de problème que ça. Le multicore rajoute une problématique de répartition physique, le multi-thread on sait le gérer. Et quand je dis ça, avant que tu déformes tout, je veux pas dire qu'on peut tout paralléliser, mais que quand on peut le faire c'est pas si sorcier que ça à gérer, mêm s'il y a un coût. Je sais très bien que y a un aspect économique là-dedans. par contre j'oublie pas l'autre aspect économique aussi: si un jeu n'exploite pas les cœurs dispo, il se met en difficulté face à ces concurrents qui eux les exploitent. A mon avis pour les jeux ils sont obligés d'y passer et de trouver des solutions, et ce, bien avant le délai de ans. S'ils arrivent à pondre un jeu monothread (ou du moins monocore) bat les concurrents, tant mieux, mais j'y crois pas vraiment... :/

---

kpouer a écrit:
Mais justement le multithread apporte énormément de problèmes c'est un fait, et ce n'est pas une question de retourner a l'école. :neutre:
Evidemment ca apporte de grands avantages c'est clair, mais ca multiplie les bugs potentiels de facon exponentielle, et les bugs qui y sont liés sont souvent très difficiles à détecter.

J'ai pas créé plus de bugs que d'habitude pourtant [:paysan] :ane: J'ai des cas ou ça me simplifie grandement la tâche: pouvoir traiter plusieurs opérations simples en même temps au lieu d'avoir une espèce de traitement combiné merdique et illisible. Ca fait des petites boites noires qui travaillent en //, que je peux développer/tester indépendamment et j'ai juste à gérer les points communs: les structures de données et leur accès. :)
Je sais pas si ça créé plus de bug ou pourquoi ce serait plus dur à détecter, mais en tout cas va falloir y passer pour les jeux (et c'est en cours). Il faudra y passer pour la vidéo certainement: là c'est assez simple, et là aussi c'est déjà fait pour certains.
Mais je peux admettre que sur un jeu ça peut agacer le concepteur...

tfpsly a écrit:

HeavyArmor a écrit:
ce qui me dérange c'est pas de copier/coller, c'est d'avoir de la redondance, donc deux modifs à faire là où une seule suffirait.

C'est ce à quoi je faisais référence par copier-collé de code ;)

HeavyArmor a écrit:
je capte une exception pour limiter la casse

Pourquoi on n'utilise pas d'exception dans le jeu vidéo :
www.codercorner.com...
Par l'auteur de Opcode - une des plus célèbres lib de détection de collision ; juste pour dire que le gars est connu et fiable/solide - Code testé sur son moteur Ice (rendu, collisions par Opcode, un peu de gameplay...) : 10% plus large, 21% plus lent.

J'adore le "Bigger exe size" :paf: Qu'est-ce qu'on s'en tape :paf: Les autres arguments se défendent, mais alors celui-ci il est périmé depuis 10 ans... :/