il y en a qui perdent des heures dans le jeu video, dans les bars ou autres. mais je pense que fabriquer quelque chose de ces mains est une passion mais aussi une sacré réussite aussi !
1 « J'aime »
Enorme boulot. Impressionnant…
1 « J'aime »
Autant je ne cautionne pas la première partie de cette remarque, autant je suis entièrement d’accord avec la seconde.
Le jeu vidéo n’engendre pas que des abrutis et les bars n’engendrent pas que des alcolos… + de 40 ans d’expérience dans les deux domaines 
.
Après, et j’y revient souvent il est vrai, c’est peut-être un soucis générationnel ?! 
1 « J'aime »
Il y a tellement à voir en haut niveau… Et même en intermédiaire pour optimiser en comprenant l’organisation de la mémoire, que le temps nécessaire pour comprendre aussi le hard est énorme!
Sans compter que le hard lui-même est menteur. On n’est plus à l’époque du 8086 et du 68000: les instructions assembleur ne reflètent pas exactement ni ce qui sera exécuté ni dans quel ordre, y compris sur arm(et même certains RISC)
1 « J'aime »
Techniquement, même les cpu de l’époque faisaient tourner quaker. La version origine est en rendu ‹ soft › via le cpu uniquement (on parle donc de pentium 133 à l’époque).
La version accélérée (glquake) n’était pas obligatoire…
Totalement d’accord. Il est de toute manière utopiste de vouloir tout maitriser.
Et surtout, sur des apps standards, c’est totalement contreproductif. Après bon, savoir comment ça se passe en arrière plan, meme sans tout maitriser, c’est quand meme un gros plus.
1 « J'aime »
Connaître comment ça fonctionne, c’est nécessaire quand on a un besoin de réduire un coût en infra important.
Mais … il y a tellement de couches, qu’on peut trouver un bonne dizaine d’endroits où optimiser! Et souvent optimiser un endroit limite l’optimisation d’autres endroits… C’est notamment le cas quand on se penche sur les charges de travail et qu’on commence à les répartir: en les répartissant, on limite la vision à un morceaux de la charge de travail, donc les systèmes qui vont l’exécuter ne pourront pas trouver d’autres optimisations…
Sans compter l’overhead pour les petites charges de travail que représentent souvent l’optimisation des grosses charges.
Je parle de façon générale, mais ces principes se déclinent sur toute optimisation en parallèle, que ce soit la répartition des charges web sur les serveurs, la parallélisation en SQL, ou la répartition des shaders dans une CG.
1 « J'aime »
ce n’est pas précisé dans le titre si il était en état d’ébriété .