Discussion :

[DonQuiche]

skeleton:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
close loop
{
    if (keyboard(z, q, s, d, alt, ²) or mouse(right_click + move_mouse)) is active, then
    {
        if msg = (alt + ²)                 , then quit the close loop
        if msg = (z, q, s, d)              , then move   the camera
        if msg = (right_click + move_mouse), then rotate the camera

        clear the screen
        update the scene(object) (by applying object rotation/movement and camera rotation/movement      )
        update the screen        (by project the scene into the array_screen through perspective equation)
        show   the screen        (by send the array_screen to the screen                                 ) 
    }

    show the frame per second
}

Voilà à vous maintenant de définir votre conception de l'art.

Voici un code (pas un squelette)

Code ruby :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
until UserAskedToQuit?() do
   UpdateCamera()
   Update(object)
 
   ClearScreen()
   Raster()
   Present()

Non je ne vérifie pas qu'un nouveau rendu soit nécessaire : dans un jeu il y a toujours des animations ou autres, cette optimisation n'a donc aucun intérêt ou trop marginale pour justifier la pollution du code. Et oui j'ai sous-divisé et augmenté le nombre d'appels de functions, ce qui ne pose aucun problème puisqu'on parle de quelques appels par frame, soit 0,0001% du budget CPU de la frame.

[DonQuiche]

On ne pourra jamais s'entendre sur ces choses là.
La beauté c'est quelque chose de subjective, c'est comme le goût.

On peut au moins s'entendre à peu près sur ce qu'est un code propre. D'ailleurs certains enseignent même comment en écrire : Clean Code.

[Invité]

Non je ne vérifie pas qu'un nouveau rendu soit nécessaire : dans un jeu il y a toujours des animations ou autres, cette optimisation n'a donc aucun intérêt ou trop marginale pour justifier la pollution du code. Et oui j'ai sous-divisé et augmenté le nombre d'appels de functions, ce qui ne pose aucun problème puisqu'on parle de quelques appels par frame, soit 0,0001% du budget CPU de la frame.

J'ai fait cette opti car mon moteur fonctionne sur CPU (je n'utilise pas le pipeline du gpu) et soit très rudimentaire pour l'instant (monde fixe)
Donc autant ne pas bouffer trop de temps CPU ^^

J'appelle ça squelette, car il faut bien que je montre son fonctionnement en globalité, même en C je ne peux retranscrire un tel "code", donc en gros c'est un peu un résumé de ce qui se passe en interne.
Et je pense que je vais m'en servir pour mieux documenter ma source (m'à l'air du bonne idée) ^^



Sinon pour le sujet principale, j'ai beau être un fanatique de l'asm/programmation, mais le simple fait qu'il y ait ce genre de débat montre clairement le fait (même dans le milieu professionnel) que certains ne sont pas d'accord sur le point de ne voir la programmation que comme un simple vulgaire outil ne servant qu'à créer des softwares à la chaine.

Qu'est-ce cela veut dire ? que pour beaucoup, ils ont déjà copié la mentalité des consommateurs intégralement et ont perdu leur âme de programmeur (bon ok j'y vais un peu fort)
Oui cela sert à créer des softwares, mais aussi à choisir quelle est la plus belle manière de le faire, le choix technologique, d'évoluer sa créativité et son savoir (enfin l’acquisition du savoir est un peu le but ultime à tous programmeur, enfin pour certains, que pour vivre avec surement)

Alors, mais à quoi bon faire tout ce micmac pour au final n'avoir qu'un logiciel ... tout ça pour n'avoir que cette récompense -_-
Et bien, je dirais que la récompense n'est pas forcément le logiciel, mais le savoir et l'expérience, c'est cela même la récompense, même si elle n'est qu'intellectuelle et non visible

Et donc au lieu de ne vénérer que les logiciels et en faire leurs promotions, on devrait plus faire la promotion de comment ils ont été conçus, mais ça m'étonnerait que les médias acceptent x)



La programmation n'est pas un outil comme les autres, il est vraiment spécial
Même les fanas de mécanique ne sont pas aussi fanatiques que certains programmeurs sur le regard qu'ils ont avec leurs outils, je pense

[transgohan]

L'utilisateur ne voit pas un logiciel mais un produit.
Cela change tout...

On ne s'émerveille pas devant la motorisation d'une voiture (bien que) ou bien de son système d'air conditionné.
Par contre on s'émerveille du rendu final et de son utilisation.

[pcaboche]

Alors, mais à quoi bon faire tout ce micmac pour au final n'avoir qu'un logiciel ... tout ça pour n'avoir que cette récompense -_-

L'utilisateur ne voit pas un logiciel mais un produit.

Ce sont souvent les petites choses (comme du code bien écrit et un bon environnement de travail) qui font parfois la différence entre un bon développeur qui reste dans la boite, et un bon développeur qui se barre en se disant "de toute façon, c'est partout pareil alors je vais dans cette boite car le salaire est meilleur / ça fera bien sur mon CV...".

Et parfois, il se barre au pire moment (ex. quand on est sur le point de démarrer un gros projet) et on n'arrive pas à le remplacer au pied levé.

Et sans bon développeur, pas de bon produit...

On ne s'émerveille pas devant la motorisation d'une voiture (bien que) ou bien de son système d'air conditionné.
Par contre on s'émerveille du rendu final et de son utilisation.

C'est justement ce soucis du détail qui fait la différence entre un bon et un mauvais produit.

[e-ric]

Pour répondre à la question: l'emballage des CD et la pub
Pour ça, j'aime bien WinDev


( une deuxième fois, c'est pas une attaque sur le produit mais il y a toujours des sacrés photos)

[Jitou]

Un solution logicielle pourra être dotée d'une implémentation "sexy" selon le développeur mais comme déjà souligné ce qui importe au final ce sont le gain de productivité apporté pour l'utilisateur et la maintenabilité future de la solution.

Beaucoup de développeurs oublient qu'une fois développé un logiciel va vivre et être utilisé probablement quotidiennement. Cet aspect peut facilement être éludé car la plupart du temps le développeur n'échangera jamais avec les utilisateurs finaux au cours du développement du projet, son intervention se terminera définitivement à la livraison du projet et il repartira alors sur un autre projet chez un autre client. Certains problèmes d'implémentation et/ou de conception rencontrés au court du développement et impactant la maintenabilité ne seront pas résolu par gain de temps d'autant que le projet sera confié vraisemblablement à un prestataire qui alors héritera des malfaçons.

De ce point de vue, certain clients peuvent regretter l'époque révolue des "services informatiques internes" d'avant la main mise des SSII sur le marché, et dans lesquels les développeurs étant aussi des experts fonctionnels investis dans leur mission et surtout très proches des utilisateurs finaux.

Mon expérience m'a montré que dans 90% des projets l'utilisateur final n'a pas participé à la définition du projet, ni à la recette (souvent réalisé par une société de service tierce). Enfin la maintenabilité future reste un préoccupation largement sous évaluée. Croyez moi le client fini par payer très cher son projet ... il y a beaucoup de négligences que l'on se permet dans les projets informatiques qui seraient rédhibitoires dans d’autres industries.

[Luckyluke34]

C'est peine perdue de tenter de définir un logiciel en termes de beauté, c'est une notion tellement floue et subjective que personne ne l'associera jamais aux mêmes caractéristiques. On est déjà à des années-lumière de l'ombre du poil d'un accord sur ce qu'est un logiciel maintenable, une UI ergonomique, du code lisible, même entre développeurs qui utilisent le même langage et les mêmes approches. Pourquoi vouloir poser une définition aussi stupidement vaste ? Quel est le but ?

[Invité]

Pourquoi vouloir poser une définition aussi stupidement vaste ? Quel est le but ?

Si on ne peut pas se mettre d'accord, alors autant partager notre définition d'un beau code comme je l'ai fait, rien que pour le savoir et non plus pour en débattre.

[landry161]

Effectivement, si on se place du côté du développeur ou de celui de l'utilisateur, on aura certainement une définition différente de ce qu'est un beau logiciel. Je suis développeur mais j'ai été sensibilisé (et essaie de le resté) à l'aspect pratique de ce que je développe vis à vis de l'utilisateur final. Après tout, c'est pour ce dernier que je travaille (et aussi pour gagner de l'argent si on se veux plus bassement terre à terre).

Mais un autre aspect doit-être pris en considération. Les clients pour qui je travaille on souvent des demandes d'évolutions, il peut aussi y avoir des bugs (personne n'est parfait). Et je ne suis pas forcément disponible (vacances, déplacement...). Il faut donc que le code soit lisible, facilement compréhensible pour quiconque aurait à le maintenir. C'est un aspect extrêmement important il me semble.

Très important

[e-ric]

C'est peine perdue de tenter de définir un logiciel en termes de beauté, c'est une notion tellement floue et subjective que personne ne l'associera jamais aux mêmes caractéristiques. On est déjà à des années-lumière de l'ombre du poil d'un accord sur ce qu'est un logiciel maintenable, une UI ergonomique, du code lisible, même entre développeurs qui utilisent le même langage et les mêmes approches. Pourquoi vouloir poser une définition aussi stupidement vaste ? Quel est le but ?

On approche de la bonne réponse à la question. Le sujet est fondamentalement subjectif et ce fil de discussion risque de durer longtemps sans que l'on trouve un consensus. Qu'est-ce que la beauté en général ?

La beauté visuelle, je ne parle pas du code, est à graduer selon l'emploi du logiciel. Pour un produit d'usage professionnel, une compta par exemple, il n'est forcément utile, ni rentable, de faire quelque chose de sexy mais l'ergonomie et la fiabilité sont primordiale, pour un jeu vidéo, l'aspect esthétique, pas forcément la beauté, demeure fondamental.

Parler de la laideur d'un logiciel serait plus novateur et au moins, on aurait droit à de beaux trolls .

Cdlt

[reventlov]

Je ne sais pas si c'est un critère de beauté mais pour ma part j'apprécie énormément un code qui se comprend même sans commentaires. Surtout avec la POO (et même sans d'ailleurs, quelle drôle d'idée ), pour peut que les méthodes, les fonctions et les variables aient un nom bien choisi et bien catégorisé, les commentaires deviennent inutiles pour la compréhension de la logique du code. Et je trouve ça chouette Les choses simples s'énoncent simplement...

[foetus]

Surtout avec la POO (et même sans d'ailleurs, quelle drôle d'idée ), pour peut que les méthodes, les fonctions et les variables aient un nom bien choisi et bien catégorisé, les commentaires deviennent inutiles pour la compréhension de la logique du code. Et je trouve ça chouette Les choses simples s'énoncent simplement...

Je ne pense pas que ce soit vrai : tu peux faire du code bien ordonné, bien nommé ... ce que tu préfères en somme, mais il peut y avoir un mécanisme "bas niveau" qui soit tordu/ crade/ personnalisé/ bizarre et peut-être difficile d'accès.

Une analogie pourrie Tu as une belle voiture profilée/ racée avec tout: le volant, les sièges baquets, vraiment tout.
Mais tu soulèves le capot et là tu as un V5 en fonte qui fonctionne au colza sans bougies ... mais un moteur impeccable à tous les niveaux

[qnope]

Je ne suis pas d'accord avec vous sur ce point.
Un bon code dois justement utiliser a mon sens un maximum de bibliothèques/dépendances existante (si nécessaire bien sur), car en générale, les développeurs (dont moi y compris) réinventent très mal la roue.

En python j'arrive a faire un code aussi puissant que si je l'avais fais en C ou en assembleur, car j'utilise des bibliothèques bien optimisé, pour le calcule scientifique par exemple, je défis quoiqu'onques de faire un code plus performant que numpy (qui est fais en C).
numpy est conçue par de brillant mathématiciens et ce depuis plus de 10ans , aucun développeur ne peut faire mieux dans le temps qui lui est impartis pour faire son projet, et même au delà, je connais très peu de personnes qui soient des génies en informatique et en mathématiques.



C'est le gros défauts des langages de haut niveau, manipuler par les débutants.
En php ou en python, on arrive a faire de ces trucs que parfois on se demande comment le langage peut accepter de telles ineptie.

Plus rapide que numpy en C? Probablement pleins de débutant sur CUDA ou OpenCL .

[RyzenOC]

Plus rapide que numpy en C? Probablement pleins de débutant sur CUDA ou OpenCL .

Pas sur, déjà faut une bonne carte graphique.
Ensuite CUDA, faut de l'Nvidia, je crois que sur AMD ou intel sa doit marcher (jamais essayé), mais sa ne serait pas du tous optimisé.
OpenCL, je ne connais pas.

Utiliser CUDA ou OpenCL sa a des contraintes. Sur mes serveurs ou je développe avec numpy, y'a des Xeon a 5000€, mais pas de carte graphique.
Au dernière nouvelle, les gros calcules se font sur des serveurs, et en générale les serveurs n'ont que des processeurs.

D'ailleurs, je serais intéressé qu'il ait un benchmark, entre un processeur a 1000€ et une carte graphique a 1000€ pour ce genre de calcule.

[transgohan]

Pas sur, déjà faut une bonne carte graphique.
Ensuite CUDA, faut de l'Nvidia, je crois que sur AMD ou intel sa doit marcher (jamais essayé), mais sa ne serait pas du tous optimisé.
OpenCL, je ne connais pas.

Utiliser CUDA ou OpenCL sa a des contraintes. Sur mes serveurs ou je développe avec numpy, y'a des Xeon a 5000€, mais pas de carte graphique.
Au dernière nouvelle, les gros calcules se font sur des serveurs, et en générale les serveurs n'ont que des processeurs.

D'ailleurs, je serais intéressé qu'il ait un benchmark, entre un processeur a 1000€ et une carte graphique a 1000€ pour ce genre de calcule.

Un processeur graphique fera toujours des calculs plus rapides qu'un processeur serveur.
Par contre ce qui peut changer la donne c'est le fait de devoir retravailler le jeu de données pour l'envoyer au processeur graphique et donc de perdre le gain de temps dans cette opération.

[madmarsu]

Déjà, en premier lieu, si on veut qu'il existe (et s'il est issu d'une entreprise dont le but est d'être rentable, c'est très différent pour un(e équipe de) développeur(s) indépendant(e)), il faut qu'il serve à quelque chose, et en effet réponde à un besoin.

Là où ça se gâte généralement, c'est que ceux qui conçoivent ne se sont pas réellement renseigné sur le besoin (voire d'où est issu ce besoin), et comme l'adresser. Ensuite ils ne transfèrement pas forcément de la bonne façon à celles/ceux qui le réalisent. Quelquefois même on s'appuie sur des statistiques de haut niveau pour déterminer ce qui serait recherché/utilisé ou pas. Et on aboutit parfois à des trucs débiles (Ctrl-H et/ou Ctrl-F pour Remplacer/Rechercher dans un éditeur de texte connu, et deux clics mini pour retrouver cette fonction Remplacer qui autrefois était en accès direct. La faute à la statistique sus-mentionnée du nombre d'utilisateurs qui l'utilisent directement) ou qui satisferont une partie des utilisateurs mais pas les autres (autres qui, eux, utilisent 80% du logiciel, au lieu de 5-15% des premiers, majoritaires).
Et ça, c'est typique de l'approche top-down et/ou waterfall.

A contrario, en rapprochant développeurs et usagers, on a une chance d'avoir un "beau" logiciel : qui soit codé de façon pérenne (quel dév a envie de refaire du code pour une fonction similaire à celle de la semaine précédente ?), ergonomique (on a le retour client en live) et efficace (idem et ça inclut les performances). Et ça, c'est ce que l'on peut obtenir via des "Sprints" en Scrum, avec un résultat plus rapide et surtout plus proche du besoin.

Là où la beauté intervient réellement, c'est dans l'évolution du logiciel. Car un logiciel qui n'évolue pas (sauf à répondre à un besoin qui n'évolue pas non plus), c'est beau, mais pas longtemps : un autre le remplacera inéluctablement. Il deviendra donc inutile... Ce sera un vieux beau. Exit.

[DonQuiche]

Au dernière nouvelle, les gros calcules se font sur des serveurs, et en générale les serveurs n'ont que des processeurs.

Beaucoup de calculs se font sur GPU, tout dépend de tes besoins.

Quand préférer le CPU ?
* Tu utilises des matrices creuses ou autres structures de données nécessitant beaucoup de branchements conditionnels : les GPU étaient historiquement mauvais pour ça. C'est en train de changer.

* Ton code a besoin de muter de nombreuses données possédées par d'autres threads : le GPU privilégie l'isolation et ne peut (pouvait) communiquer qu'avec les threads du même groupe (travaillant sur le même tableau ou bout de tableau), ce qui reste (restait) une opération longue. C'est en train de changer.

* Tu as un dataflow complexe et des threads doivent lancer d'autres threads, attendre des mutexes, etc. C'est (c'était) impossible.

* Ton code a un faible degré de parallélisme. Un GPU sera sous-exploité en-dessous de millions d'éléments (ou quelques milliers seulement si chaque élément est long à calculer et que les astres sont alignés)

* Chaque thread a besoin de lire de petits fragments très dispersés de données, sans organisation séquentielle ou locale dans un espace 2D/3D (comme pour les textures). Le GPU est optimisé pour des lectures par blocs (disons 128*128 pixels mais je ne sais pas vraiment) : un groupe de threads se partageant le rendu de la même intersection rectangle + modèle 3D utilisera les mêmes parties d'une texture.


Pour tout le reste, le GPU sera dix fois supérieur (vitesse, conso, espace, etc) à un CPU grand public avec une consommation en rapport.

Cela dit le cas récent du Xeon Phi et ses 50+ processeurs est à part : même sur les problèmes typiquement GPU il offre une bonne alternative, bien qu'inférieure. Si vous avez besoin d'un calculateur généraliste, capable de satisfaire tous les besoins, le Xeon Phi est parfait. Mais si vos besoins sont typiquement GPU alors il n'y a pas photo.

Cela dit je ne sais pas si les GPU sont vraiment pérennes : si les consommateurs arrêtaient d'acheter des GPU je doute que ceux-ci demeurent économiquement viables pour le calcul.. Or les algos dont les JV vont avoir besoin (raytracing) se prêtent moins au SIMT (GPU), le modèle à nombreux coeurs est tellement plus flexible et les consoles n'exercent plus de course à la performance... Peut-être garderons-nous des copros SIMT avec un partage physique de la mémoire et exposant un modèle mémoire unifié, comme chez les APU d'AMD.

[Invité]

Dans la famille des composants d'un PC, il y a le père (CPU), la mère (motherboard) et le garçon (GPU).

Un jour le garçon entre dans la puberté et se rebelle, mais il aura beau faire son pitit caprice, il ne prendra jamais la place du père de famille

[qnope]

Cela dit je ne sais pas si les GPU sont vraiment pérennes : si les consommateurs arrêtaient d'acheter des GPU je doute que ceux-ci demeurent économiquement viables pour le calcul.. Or les algos dont les JV vont avoir besoin (raytracing) se prêtent moins au SIMT (GPU), le modèle à nombreux coeurs est tellement plus flexible et les consoles n'exercent plus de course à la performance... Peut-être garderons-nous des copros SIMT avec un partage physique de la mémoire et exposant un modèle mémoire unifié, comme chez les APU d'AMD.

Pour le RayTracing, je puis t'assurer que le code sur GPU est bien plus efficace que sur CPU a code égal, sans aucune optimisation particulière. Faire du real time sur CPU si tu n'utilises pas du FMA / AVX et que tu agences bien tes données pour faire du cache hit en tout temps, c'est assez difficile, en ray tracing j'entends, car notre amis Shaynox développe un moteur en voxel et est parfaitement fluide . Sur GPU, en CUDA en tout cas, OpenCL 2.1 n'étant pas encore vraiment sorti à ma connaissance, tu n'as juste à faire un code "CPU-like" et tu seras plus rapide. Je ne parle d'optimisation a base de Shared memory et de coallescing access, juste avec un code trivialement simple, j'ai des performances qui explosent mes codes sur CPU de manière égale. Bien que je suis certains que l'AVX permet de multiplier par 8 / 16 les perfs d'un CPU si l'on se débrouille bien, si on optimise de cette même façon coté GPU, pour le RT, le GPU est plus efficace que le CPU .

Il n'y a qu'à voir OptiX vs Embree, je rappelle qu'Embree est codé par des mecs d'Intel, qui, je n'en doute pas, savent de quoi ils parlent .

En revanche, tu marques un point sur le fait que le GPU, préférant les données proches entre elles, de préférence sous bloque de 32 * 16 / 32 * 32, et en ce sens, le ray tracing n'est pas des plus adapté . Mais si on se débrouille bien, je ne doute pas de la possiblité de clairement tout optimiser, structure de donnée etc.