Discussion :

[DonQuiche]

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.

Je ne parle pas de CPU comme nous les connaissons (deux à quatre coeurs très puissants) mais à la Xeon Phi (50-80 coeurs d'il y a dix ans). Et là je doute très fortement que le GPU ait l'avantage.

notre amis Shaynox développe un moteur en voxel et est parfaitement fluide

La plupart des moteurs basés sur des voxels n'utilisent pas de raytracing et le problème ne serait pas différent de celui de triangles dans un octree, il n'y aurait donc pas grand intérêt à utiliser des voxels. Or on ne peut pas encore faire de raytracing en temps réel sur GPU - loin s'en faut.

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

Plutôt 2x.

[qnope]

Je ne parle pas de CPU comme nous les connaissons (deux à quatre coeurs très puissants) mais à la Xeon Phi (50-80 coeurs d'il y a dix ans). Et là je doute très fortement que le GPU ait l'avantage.


La plupart des moteurs basés sur des voxels n'utilisent pas de raytracing et le problème ne serait pas différent de celui de triangles dans un octree, il n'y aurait donc pas grand intérêt à utiliser des voxels. Or on ne peut pas encore faire de raytracing en temps réel sur GPU - loin s'en faut.


Plutôt 2x.

Il suffit de voir ce que donne Embree pour voir que les Xeons phi a base de Ray Tracing packed ne tiennent pas la route contre Optix.

En fait, les moteurs basées sur les voxels s'appuient sur de la voxelization basé sur des images load / store et un cone tracing afin d'émuler l'illumination globale. Je t'invite à regarder la partie de la thèse de Cyril Crassin sur Giga Voxels (la partie Voxel cone tracing) si cela t'intérèsse .

Pour donner des chiffres. Embree donne moins de 200M rayons par secondes. Optix monte a 350 400M. Et il en faudrait 12 000M pour faire un rendu à 30 FPS en full HD .

[Invité]

DonQuiche:

Ce n'est pas toi qui m'as vanté les mérites du gpu par rapport au CPU il y a peu ? c'est quoi ce revirement de situation x)
Sinon, pour appuyer ton argumentation (ça fait bizarre ):
https://software.intel.com/en-us/art...ons-intel-avx/
http://www.extremetech.com/gaming/13...ing-graphics/3
http://vr-zone.com/articles/intel-ta...idge/5652.html

Et pour mon moteur, il ne fonctionne pas comme tu le penses, comme je les dis, il n’est unique en son genre, aucun tour de passe-passe pour alléger la mémoire de coordonnée pour les textures, donc j'ai la main sur n'importe quel point de mon objet solide sans passer par des calcules.

Et c'est comme cela que fonctionne le monde réel, parce que tes calculs prennent aussi en compte le zoom de la caméra, pour que l'on ait l'impression que ton objet texture soit infranchissable et qu'il n'y ait pas de trous comme sur http://newscenter.lbl.gov/wp-content...5-graphene.jpg , même si tu zoom au niveau atomique sur ta texture (picomètre) .

[DonQuiche]

Pour donner des chiffres. Embree donne moins de 200M rayons par secondes. Optix monte a 350 400M. Et il en faudrait 12 000M pour faire un rendu à 30 FPS en full HD .

Aurais-tu une source pour cela stp ?

Sur une même scène, puisque autrement ça n'aurait aucun intérêt (le nb de rayons par seconde dépend de la scène), et en comparant un Xeon Phi avec un GPU du même prix ? Parce que si la comparaison est faîte entre un GPU grand public et un CPU grand public, encore une fois ça n'a aucun intérêt vu l'orientation actuelle des CPU (peu de coeurs aussi rapides que possibles).

En fait, les moteurs basées sur les voxels s'appuient sur de la voxelization basé sur des images load / store et un cone tracing afin d'émuler l'illumination globale. Je t'invite à regarder la partie de la thèse de Cyril Crassin sur Giga Voxels (la partie Voxel cone tracing) si cela t'intérèsse

Ah, le retour du fils de la vengeance du SVOGI. J'avais oublié ça.

On commence par un moteur de rastérisation et à la fin on utilise du raytracing dans un monde en grossier légo (sparse octree ou clipmap) pour calculer la composante indirecte de l'illumination. Ce qui donne certes un résultat très sympa mais qui ne tourne que sur les gros PC et, à ma connaissance, pas sur PS4/X1.

Sauf que ça reste de la rastérisation enrichie par un raytracing grossier, et on n'a résolu qu'un seul problème, celui de l'illumination globale, avec certaines limites. C'est important pour le consommateur, peut-être suffisamment pour rendre inintéressant pour longtemps les solutions de raytracing (ou peut-être pas) et maintenir l'intérêt des GPU pour le jeu. Mais ça n'est pas une solution de raytracing proprement dite.

Sur le plan technique, j'insiste : un moteur basé sur des triangles utilise lui aussi un sparse octree, et stocke les triangles dans les feuilles. La différence ici c'est que l'on se fiche que le monde ressemble à du gros légo puisqu'on ne l'utilise que pour l'illumination indirecte.

Ce n'est pas toi qui m'as vanté les mérites du gpu par rapport au CPU il y a peu ? c'est quoi ce revirement de situation x)

J'ai vanté la supériorité du GPU pour la plupart des tâches de parallélisme de données dans un contexte où tu jurais tes grands dieux que l'on pouvait faire aussi bien avec AVX.

Ici je suppute la supériorité de CPU à 50+ coeurs pour la tâche particulière du raytracing.

[foetus]

Et encore lorsqu'on sait qu'il faut combiner 2 algos : L'algo raytracing - "lancer de rayons" pour la lumière spéculaire et l'algo de radiosité pour la lumière diffuse.

Mais, l'algo de radiosité est indépendant du point de vue (donc on peut le calculer avant) et si je ne dis pas de bêtises quelque soit l'ordre, [quasi] rien ne change

[qnope]

C'est vrai qu'il ne me semble pas qu'il y ai eu des tests fait sur les mêmes scènes :p.

Après je n'en démord pas, a prix égal, sur du CPU ou GPU grand publique, le Ray tracing est plus rapide sur GPU, et même bien plus rapide.

Après, sur des Xeons contre une titan Z, ou des GRID ou quaddro, je ne sais pas, mais je pense quand même que les GPU sont plus performant .

Pour l'idée de combinée radiosité et ray tracing, le mieux, c'est de faire du photon mapping, tu profites en plus des caustiques .

[Invité]

J'ai vanté la supériorité du GPU pour la plupart des tâches de parallélisme de données dans un contexte où tu jurais tes grands dieux que l'on pouvait faire aussi bien avec AVX.

Ne crois-tu pas que c'est un peu le même contexte à propos de ce qu'on est en train de parler ?

Si l'avx était si insignifiant que ça, peux-tu m'expliquer ce résultat (que tu n'a pas lu parmis les liens que je t'ai donnée https://software.intel.com/en-us/art...ons-intel-avx/)



(Et je n'imagine même pas combien de fps il va avoir avec l'avx-512 (zmm register) qui sera commercialisé en 2016)

Et sa conclusion:

Intel AVX offers improved FLOPS performance if an application can find a way to utilize it. SOA style implementation is not the first thing that comes to mind when people think of cloth simulation. This novel approach is able to demonstrate good SIMD usage and could potentially be appropriate for video game scenes with lots of active cloth objects or deformable debris in the environment.

[DonQuiche]

Après je n'en démord pas, a prix égal, sur du CPU ou GPU grand publique, le Ray tracing est plus rapide sur GPU, et même bien plus rapide.

Nous sommes d'accord sur ce point.

Ce que je dis c'est que pour le raytracing je pense qu'il vaut mieux une archi CPU mais avec de nombreux CPU raisonnablement optimisés plutôt que peu de CPU hyper-optimisés. L'archi GPU ne me semble pas bien adaptée pour le raytracing.

Si l'avx était si insignifiant que ça, peux-tu m'expliquer ce résultat (que tu n'a pas lu parmis les liens que je t'ai donnée https://software.intel.com/en-us/art...ons-intel-avx/)

Je ne trouve pas que doubler la vitesse soit insignifiant et je n'ai pas le temps de me pencher sur la pub d'Intel, de chercher leur code source, de comparer l'asm généré, etc. Par ailleurs de ce que j'ai lu ils vont se retrouver avec un pur code de calcul sur tableaux avec accès séquentiels alors que le raytracing est quant à lui dominé par des accès aléatoires et des branchements conditionnels à foison qui font que les instructions SIMD ne pourront pas exprimer leur potentiel. En fait le 2x était probablement trop optimiste.


EDIT : Cela dit, à vue de nez, leurs données ont été éclatées en tableaux distincts pour le bénéfice des instructions vectorielles, ce qui n'est pas du tout adapté aux instructions ordinaires. Il aurait fallu comparer avec un code naïf, où les infos de chaque sommet seraient regroupées, pour juger du bénéfice réellement apporté par les instructions SIMD en échange de tout ce travail.

[ChristianRoberge]

« Un beau logiciel résout un problème, et il le fait mieux que tout autre » Très d'accord sur ce point... Mais c'est un critère très subjectif qui laisse beaucoup de place à l'interprétation et à du folklore...
L'inclusion de TROP d'entête en est une. Il faudrait plutôt dire que l'appel inutile d'entête dégrade un code et, indirectement sa "beauté".
L'utilisation de bibliothèque C performante ne remplie pas "faire mieux qu'un autre" n'en déplaise aux adeptes de ces librairies. C'est du folklore maintenant basé sur des vielles histoires (souvent véridiques). En C++ moderne, il pratiquement toujours possible de faire mieux que dans l'ensemble des libraires scientifiques (ou autre) C ou Fortran qui ont été optimisés depuis des décennies. L'exemple du qsort par Stroustrup lui-même est assez éloquent sur le sujet (Voir https://isocpp.org/blog/2014/12/myths-3 ) mais je pourrais en apporter de nombreux autres. Aujourd'hui même avec un minimum de talent en C++, la performance sera au pire égal aux vielles routines C.

Une idée, une vision différente du problème, conduisent quelque fois à des "beaux" logiciels. C'est la voie que je privilégie. Développer un "beau" logiciel qui fait mieux que les autres en y consacrant seulement plus de temps est rarement un avenue très fructueuse. Voici ce que je conseillerait à ceux qui veulent développer des "beaux" logiciels, des logiciels d'exception:

1. Cultiver vos idées en vous informant continuellement. N'ayez pas peur de sortir de votre discipline ou spécialité.
2. Soyez un programmeur paresseux. Habituellement, plus vous avez un code concis, meilleure sera les performances.
3. N'hésitez pas à sortir des sentiers battus. Si vous le faites, de grâce, ne réinventer pas ce qui existe déjà ailleurs.
4. Expérimentez toutes les facettes de ou des langages que vous utiliser. Les changements majeurs de versions d'un langage sont un moment idéal pour se mettre à jour. À la limite, n'hésitez pas à regarder l'assembleur pour connaître la version la plus efficace dans un contexte donné.
5. N'ayez pas d'idées préconçues sur qui peut être fait ou pas avec un langage. Mon exemple classique est mon utilisation d'un "ou exclusif" entre 2 pointeurs. C'est en soit une opération qui n'a pas de sens. Vous ne verrez pas cela dans aucun bouquin mais c'était le détail qui donnait un avantage marqué sur tous les autres logiciels du marché de cet époque.

[devEric69]

Ça n'est pas une polémique, c'est une précision que je veux apporter, car je lis des choses sur Apple en exemple de "beauté de logiciel": c'est à mes yeux un constat qui sonne trop proche d'un slogan marketing. Apple, c'est plus compliqué que cela entre terme d'OS. Quand on parle d'Apple, il existe l'Apple d'avant 2001 et l'Apple d'après 2001: Apple a laissé tomber son ancien OS 100% fait maison, (trop bogué, avec Apple-Talk et d'autres à côté) et donc aussi ces clients historiques (j'en connais, fans historiques depuis le révolutionnaire Macintosh; ceux qui avaient les moyens d'en avoir un faisaient saliver les autres; qui n'ont pas eu d'autre choix que de jeter 15-20 ans de code-source à la poubelle, au moment même où le slogan publicitaire "Apple, l'ultime mise à jour de votre PC" fleurissait partout sur les panneaux publicitaires. Pour un fan de la première heure, ça voulait dire "Apple passe sous l'architecture hardware PC qu'ils ont si longtemps critiquée" ). Ils utilisent depuis le code source de FreeBSD, clang et Grand Central Dispatch. De ces libérations open-source, ils créent leur propre mouture, avec leur charte graphique. Donc à mes yeux, Apple n'est pas ce que j'appellerais le meilleur des exemples pour parler de la beauté d'un logiciel surtout en matière d'OS (les vrais acteurs qui écrivent un bel OS de A à Z, sont Microsoft, Linux, freeBSD, ...).

Ou plutôt, Apple est un exemple intéressant qui prouve que le beauté d'un logiciel commence par un code source bien écrit sur le fond (leur constat de survie en 2000-20001), maintenable avec une IHM visuellement compréhensible, sous peine de devoir l'abandonner tôt ou tard. Ensuite, appliquer tel ou tel peau sur les fenêtres, c'est la touche finale de beauté forcément subjective, sur la forme.

Sinon, un logiciel, c'est du temps capitalisé pour résoudre au mieux un problème récurrent: donc faire passer subtilement dans le ressenti de l'utilisateur, le temps ou l'argent que son utilisation lui dégage, peut être une piste à creuser pour lui donner le sentiment d'utiliser un bon/beau logiciel.

[devEric69]

Apple a laissé tomber son ancien OS 100% fait maison[/B], (trop bogué, avec Apple-Talk et d'autres à côté) et donc aussi ces clients historiques

Erratum: Apple avait édité à cette époque un "kit de transition" pour migrer de leur ancienne architecture-OS-100% maison, vers le monde PC-Intel+nouvelle mouture personnalisée de BSD.

[Invité]

Qu’en pensez-vous ?

1. Dans le sous-titre de la discussion : « cela n’a rien à voir » et non pas « cela n’a rien à avoir », qui ne veut strictement rien dire !
2. Pour ce qui est de l’actualité, le texte auquel il est fait référence date quand même du 22 mars 2013 !...
3. La dernière question « Quelle est la place de la technologie et la qualité du code dans la création d’un beau logiciel ? » oriente à tort la discussion sur la beauté du code, sujet maintes fois traité et débattu (Qu’est-ce qui fait un bon code ?) ; et qui n’a précisément rien à voir avec le discours d’Ole Lensmar auquel se réfère le sujet proposé.
4. Le sujet a partiellement été traité dans cette discussion : Quelles idées avez-vous de l'utilisateur final lors du développement d'une application ?
   
   Pour argumenter au-delà, cela nécessite d’avoir fait une certaine démarche, d’avoir vécu certaines situations.
   
   Comme dit Jitou :
   
   

   « Certains clients peuvent regretter l'époque révolue des "services informatiques internes" d'avant la mainmise des SSII sur le marché, et dans lesquels les développeurs étaient aussi des experts fonctionnels investis dans leur mission et surtout très proches des utilisateurs finaux. »

________________________________________

« Qu’est-ce qui fait un beau logiciel ?... »

La beauté dont parle Ole Lensmar n’est pas seulement la beauté au sens esthétique, ergonomique et convivial :

1. c’est cette complicité, cette osmose constructive entre utilisateur et développeur,
2. c’est cette écoute, cette attention du développeur à l’égard de l’utilisateur,
3. c’est cette pulsion créatrice du développeur,
4. c’est cette valeur ajoutée indicible que le développeur attentif crée :
   
   • en synthétisant, en structurant le savoir-faire de l’utilisateur,
   • en révélant le non-dit, en découvrant ce que l’utilisateur ne sait pas qu’il sait,
   • en informatisant judicieusement les vrais besoins de l’utilisateur,
   • en ouvrant de nouveaux horizons, en suscitant de nouveaux besoins,
   • en comprenant les rouages de la problématique,
   • en connectant des entités périphériques confinées dans leur bulle de compétences,
   • en rendant l’utilisateur autonome,
   • en faisant de l’outil un véritable support de formation au métier de l’utilisateur et non en réinventant son métier,
   • en insufflant aux gestionnaires la confiance, l’optimisme, l’enthousiasme, la sérénité, la complicité, l’humour…
   • en stimulant leur communication, leur imagination…
5. c’est ce concentré invisible :
   
   • de hoshin attitude (s’investir totalement et librement),
   • de poulpe attitude (utiliser son intuition pour prendre les bonnes décisions),
   • de positive attitude (vivre en mode chance, savoir lire la vie),
   • d’impulse attitude (se mettre en danger pour être performant).

Il n’existe pas de mot pour exprimer tout cela. Il faut seulement comprendre tout ce que recouvre le mot « beauté » ou utiliser plusieurs mots comme : sublime, ingénieux, inventif, pratique, pertinent, subtile, intelligent, judicieux, etc.

Cette discussion est une véritable métaphore de l’informatisation d’une problématique de gestion :

• L’utilisateur : Ole Lensmar
• Le chef de projet : Michael Guilloux, Chroniqueur actualités
• Les développeurs : les intervenants dans cette discussion
• La problématique : le blog d’Ole Lensmar
• Le cahier des charges : la chronique actualité de Michael Guilloux
• Le vilain-pas-beau logiciel : les posts des intervenants

… Et la caricature des balançoires illustre parfaitement cette métaphore.
________________________________________

Quelle est la place de la technologie et la qualité du code dans la création d’un beau logiciel ?

Ole Lensmar le dit lui-même et le sous-titre le rappelle, cela n’a rien à voir avec la beauté du logiciel.

Un commentateur du blog de Ole Lensmar dit cependant qu’un mauvais code peut fonctionner durant un temps limité, mais un logiciel mal conçu causera inéluctablement sa perte en générant des difficultés de maintenance et d’évolution.

La technologie et la qualité du code n’impactent pas immédiatement la beauté du logiciel mais conditionne sa pérennité.
________________________________________

A suivre… peut-être !

[Invité]

je pense à l'intégration du composant.
Sa réutilisation critique.
Sa disponibilité.
Son prix.


Grosso, mais c'est un dérivé de marketting.

[Mat.M]

bonsoir j'ai remodifié mon message.

Qu’est-ce qu’un beau logiciel ? Quelle est la place de la technologie et la qualité du code dans la création d’un beau logiciel ?

Affirmer qu'un logiciel est beau ça peut peut-être s'appliquer à des jeux vidéos ou des logiciels de création de paysage comme Bryce3d avec une interface utilisateur "design"

maintenant la "beauté d'un logiciel" peut se caractériser par la manière dont on transcende le génie et l'intelligence humaine.
Moi ce qui me motive à faire un logiciel c'est de le construire comme une montre avec un mécanisme d'horloge suisse c.a.d. avec des modules qui s'interconnectent entre eux intelligemment , qui sont fonctionnels.
Par exemple comme la la machine d'anticythère pour extrapoler...

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).

paroles sensées...qui résument ma pensée...

L'utilisateur final déteste se qui n'est pas universelle.

remarque très pertinente que j'aime bien lire....
si l'utilisateur final déteste ce qui n'est pas universel ( et générique ) c'est que le le logiciel a soit été mal pensé, correspond mal aux besoins des utilisateurs...contrairement à des outils comme Word, Excel très simples à utiliser.
Bref les projets "non universels" c'est peut-être la vision romantique des directeurs de services informatiques qui veulent "leur" projet informatique, une SSII arrive et développe ce projet et les utilisateurs disent "bof à quoi ça sert ? "

La beauté c'est quelque chose de subjective, c'est comme le goût.

tout à fait exact.J'a déjà eu un sujet de philo dans ce genre au baccalauréat.

[phil_tema]

Cela me fait repenser à une citation de Marcel Dassaut : "Si il est beau, il volera bien !".

De mon point de vue :
Il est très important de soigner l'IHM, même pour un logiciel "simple". Cela met en confiance l'utilisateur et il sera + tolérant avec les nouvelles contraintes d'utilisation
que le soft peut engendrer (essayez par exemple de déloger un collègue qui a toujours fait du Fortran depuis 20 ans pour l'envoyer sur Matlab...

L'utilisateur voit l'extérieur du soft. Pour l'intérieur, c'est au développeur de se débrouiller, par n'importe quel moyen. Evidemment, cela n'empêche pas de coder avec
pertinence et prendre en compte les évolutions potentielles, les mises à jour, les corrections de bugs... mais ce n'est pas le problème de l'utilisateur !

Dans mes premiers développements, je m'attachais aux fonctionnalités, peu ou pas à l'IHM. Puis j'ai été confronté à des clients (au sens business) qui utilisaient un produit
développé par ma boite (pilotage de vérins hydrauliques + acquisition de données, le tout sous DOS): 90% des remarques étaient liées à l'IHM, les 10% restant à des performances
et/ou fonctionnalités Hard. Le hard avait été bien pensé, pas l'IHM. Nous avons rapidement corrigé le tir sur l'IHM : explosion des ventes ! Aujourd'hui encore, certains logiciels
tournent encore (si si !) et les clients reconnaissent que "ça avait de la gueule pour du DOS !"

Nous avions une chance dans notre boite : un débogueur fou ! Un collègue spécialiste des manips foireuses à la souris, en mixant les clics et les touches, les mouvements
de fenêtre dans des endroits improbables, tout en appuyant sur les touches pourries, genre ESC... Il nous en a trouvé pas mal !

Pour la version Windows, nous avons lancé un sondage chez tous nos clients avant d'attaquer le développement : encore une fois, 90% des remarques concernaient l'IHM.

Depuis, j'essaye de "penser" comme un utilisateur avant de coder : qu'attend-il du logiciel ? comment lui simplifier la vie ? Quelles sont les évolutions possibles qu'il demandera ?
C'est imparable.

Un beau logiciel est un logiciel qui fonctionne bien, robuste et qui répond au cahier des charges.

Ce n'est que mon avis !!!

[LeoBeutel]

Honnêtement, pour moi la beauté (interface) d'un logiciel c'est pas ce qu'il y a de vraiment d'important.

A la limite si on me demande ce qui faut absolument faire pour avoir un bon logiciel prêt à être "commercialiser", c'est sa simplicité d'utilisation et ses fonctionnalités. Le reste, c'est du détail.

[CodeurPlusPlus]

Le plus important c'est le marketing et la pub.

Un logiciel génial mais mal vendu, ce sera un flop et personne ne saura qu'il existe.

Un logiciel qui fait la même chose en pourri, avec un bon marketing et une bonne pub, fera gagner le jackpot.

EDIT : et la "joliesse" d'une interface graphique, ça fait partie du marketing.