Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

03/08/2009

Unsung heroes: Performances

Pour une raison qui m’échappe, quand on parle des performances d’un jeu entre codeurs, on tombe très vite dans un certain nombre de travers qui vont du déni le plus farouche (ce n’est pas le plus important) au délire mystique façon secte (c’est fait comme ça parce que c’est comme ça qu’il faut faire) en passant par les égos les plus sensibles qui soit (mon code est toujours le meilleur).



Sigh, c’est à vous découragez de vouloir avoir une discussion adulte ^_^



Commençons par reprendre les faits. Pourquoi les performances des applications sont elles si importantes ?



1 - On recherche les performances pour réduire la latence gameplay :



- Nous programmons des jeux i.e des programmes qui interagissent avec un être humain.


- Pour que ces programmes soient efficaces, il faut que la boucle de feedback soit la plus rapide possible i.e il faut réduire la latence au strict minimum.


- La latence acceptable varie en fonction du design du jeu. Ce qui est acceptable pour un démineur ne l’est déjà plus pour un Tetris. Ce qui est acceptable pour un Tetris ne l’est plus pour un jeu de course. Et nombre de joueurs ne peuvent pas jouer à un FPS en dessous de 60 Hz.


- Pour ce faire, la latence « gameplay » est donc la première considération de la programmation orientée performance.



2 – On recherche les performances pour délivrer une expérience :



- Beaucoup de jeux (en particulier ceux qu'on appellent les AAA) recherchent à délivrer une expérience réaliste (voir surréaliste).


- Pour ce faire, on souhaite rendre les décors et les personnages les plus beaux possibles, avec un maximum de détails et d’animations diverses.


- On cherche aussi souvent à augmenter la diversité sans augmenter le surcout en production de données.


- Enfin, on cherche parfois à créer des expériences uniques qui ne peuvent pas être sans une couche software dédié.


- Dans tout ces cas là, la considération de performance est importante, puisqu’elle défini les limites techniques de l’expérience délivrable.



3 – Les considérations de performances ne sont souvent pas dissociables de la plateforme hardware.



- Nous programmons des jeux sur plateforme embarquée (oui, les consoles sont des plateformes embarqués).


- Ces consoles, même si elles ont une couche OS relativement fine, proposent toutes des services et des composants différents, et souvent en quantité limité.


- Pour maximiser les performances de nos applications, on souhaite exploiter chacune de ces ressources du mieux possible (mémoire, parallélisations, optimisation…).


- Dans ce cadre, il y a donc deux types de performances qui nous intéresse : la performance mémoire (ou comment utiliser le moins de mémoire possible), et les performances logicielles (ou comment maximiser son throughput i.e combien de choses peut on faire à la frame).



Quand on prend un point de vue très pragmatique, ça parait simple dit comme cela, alors pourquoi est-ce un sujet si controversé ?



Pour simplifier, il y a deux dérives fréquentes : l’excès de zèle, et le déni.



L’excès de zèle est une pratique commune qui revient à mettre les considérations de performances sur un pied d’estale et à dénigrer tout le reste (lisibilité, maintenance, simplicité). C’est un travers parce qu’il oublie que la performance est au service de l’application, et pas l’inverse.



C’est une attitude de programmeur cowboy qui conduit souvent à l’arrogance ^_^



Le déni lui provient en général d’une mauvaise interprétation de la fameuse phrase « premature optimization is the root of all evil ». Il semble qu’elle soit souvent comprise comme étant une excuse pour ne considérer les performances qu’en aval de l’exécution. S’il s’agit d’une attitude saine en règle général, il ne faut pas non plus que cela devienne une excuse pour renoncer à la pensée !



Puisque l’on connait nos plateformes, nos contraintes, et nos objectifs, c’est bel et bien en amont qu’il faut penser aux performances ! En fait, ce qu’il faut comprendre de la phrase, c’est ça : « premature optimization in the implementation is the root of all evil ».



Ce sont les optimisations incertaines dans l’implémentation qui posent problème, pas le fait de s’être creuser la tête pour choisir les bons algorithmes et les bonnes structures de données dès le départ !



Programmer pour les performances, c’est savoir se poser des questions, et de préférences les bonnes questions, et ce dès le départ. Prenons quelques exemples, fournis par Mike Acton, directeur technique chez Insomniac.



Dans « Quicksort is not a concurrent algorithm », Mike reviens sur le grand cas d’école typique qui tout le monde apprend pendant ses études : le quick sort. Souvent, on passe beaucoup de temps à apprendre différents algorithmes de tri, et parfois on apprend même à les implémenter plus ou moins efficacement.



Du coup, comme on tri souvent pas mal de choses dans les moteurs de jeu, on pense naturellement à optimiser ces algorithmes là. Logique non ?



Pourtant, est ce que l’on se pose les bonnes questions ? Déjà, pourquoi est ce que l’on tri ces données ? Et c'est quoi qu'on tri au fait ? Qu’allons-nous faire de la liste une fois trier ? Ai-je vraiment besoin de construire la liste avant de faire ce que je veux faire avec ces données ? Et puis d'abord, est ce vraiment le tri qui fait bottleneck de toute façon ?

 

 

607502049_E5U3W-M.jpg
607500913_9g4QE-M.jpg
607502496_X86VV-M.jpg
607511303_ZFgZ4-M.jpg
607512040_rYeSX-M.jpg
607513958_4ycnr-M.jpg
607514302_iH8T6-M.jpg
607514643_eLhhh-M.jpg
607520763_iAUki-M.jpg
607517752_D6sDV-M.jpg
607518080_Gr9MT-M.jpg

 

[ La suite chez Mike Acton ]



Autre cas d’école, autre exemple analysé par Mike, implémentation d’un algorithme de détection de collision entre une sphère et un plan. Ca aussi, c’est du code très utilisé et balisé depuis des années dans les graphics gems.



Pour autant, ca ne nous dispose pas de savoir se poser les bonnes questions : combien de plans et de sphères ait je besoin de tester exactement ? Une, deux, mille ? Et comment se comporte mes données sur la plateforme cible ? Et dans combien de situation fait avoir à implémenter un comportement différent nécessitant une implémentation virtuelle? Est-ce que mes données sont triés, et si elles ne le sont pas, est ce que je ne gagnerai pas à ce qu’elle le soit avant ?

 

 

1.jpg
2.jpg
3.jpg
4.jpg
5.jpg
6.jpg
7.jpg
8.jpg

[ La suite chez Mike Acton ]



Programmer pour les performances pour plateforme embarquée nécessite donc un certain état d’esprit (et, il faut bien le reconnaitre, de solides connaissances au sujet de la plateforme et du compilateur). Mais il y a certains principes qui émergent toutefois, et que l’on peut garder à l’esprit quand on s’y essaye. Ce sont ce que Mike appelle les 3 mensonges :



Lie 1: Software is a platform



Something that often is being teached at schools. It comes around the idea that you shouldn't care about what hardware you are running. Software is not a platform, software is always running on hardware and even if it may be different hardware its hardware that we can understand and optimize for.



Lie 2: Code should be designed around a model of the world



In typical C++ and OOP code there is idea that you need to model your code around the real world.





The typical problem with code like this is that above all it doesn't scale. Today all code that is used during run-time needs to been designed with data layout in mind and for multicore.


...



Lie 3: Code is more important than data



I touched a bit about this in the above point as well. This is the big one. We spend way way too much time talking about code when it really doesn't matter. When doing time critical programming one can think of it as a complex DSP. We get data in, modify it and send out. We spend very little time on actually talking about how the data flows in an application. Data is what should be dictating all decisions in your application. If you don't know the data how will you know how it will perform? where the bottlenecks will be, etc. You have no idea.



If data is designed in a correct (and often simple way) you should only be able to write the code in one way.



 

[ Daniel Colin ]



Ce n’est pas que ces conseils soient définitifs ou absolus, ni qu'ils doivent s'appliquer partout pour tout, ils peuvent parfaitement être invalidés par les progrès techniques et logicielles. Mais pour l’heure, en ce qui concerne les plateformes embarquées actuelles, et à venir dans un futur proche, ce sont les meilleurs conseils qui soient.

 

Et dans tout les cas, il faut bien admettre que tout travail sérieux démarre au moment où l'on commence à se poser des questions, et c'est la qualité première en ingénierie, n'est ce pas ? ^_^

14:00 Publié dans Code | Lien permanent | Commentaires (21)

Commentaires

J'ai changé d'état d'esprit le jour ou j'ai commencé a bosser sur PS3.
J'analysais en pensant aux traitements a faire. Maintenant, je pense aux datas (merci saletés de SPU). Quelles sont les datas, d'ou viennent elles, ou vont elles, etc. Après, plus qu'a les transformer au bon moment (en cohérence avec les autres datas).

L'intérêt de penser en mode data est aussi lié au fait que les consoles ont des caches de merde. Bien grouper tes datas , dans le format le plus facilement manipulable par le CPU et le plus tot possible est la meilleure solution pour de bonnes performances.

Les consoles sont de - en - des plateformes embarquées. Manque plus que la virtualisation de la mémoire (on y arrivera) et on pourra enlever le mot embarqué.

Écrit par : skaven | 03/08/2009

Lol ^_^

C'était tout à fait logique que le problème des datas allaient nous exploser cette génération. On sait bien que tandis que les fréquences et les capacités des processeurs augmentent, ce n'est pas le cas des mémoires caches, de la RAM, et surtout des temps de latence à l'accès les uns aux autres.

Du coup, on reviens à de bonnes vieilles considérations simple comme le "mais bon dieu pourquoi j'ai du padding ici" au "attends, je te fourre 4 booleens dans un bitfield", en passant par le toujours actuel "mince, c'est pas aligné ce truc?".

Oh joy...

Par contre, personnellement, je pense que l'ère des plateformes embarquées est loin d'être révolu. Si comme toi j'apprécierai le confort que peut apporter la mémoire virtuelle (par exemple), ça ne change pas fondamentalement la donne: si on peux s'en passer, on s'en passera.

En fait, la caractéristique principale des plateformes embarquées, ce n'est pas forcément l'accès plus direct au hardware. Ce qui compte, c'est l'unicité de ce dernier i.e toutes les instances physiques de la plateforme ont les mêmes caractéristiques techniques.

Du coup, pour continuer dans l'exemple que tu donnes, si on peux gagner ne serait ce que 5% en me passant de la mémoire virtuelle, quelqu'un le fera (ce qui ne veut pas dire que tout le monde le fera, mais vu comment le secteur est compétitif...).

La raison pour laquelle on le fait rarement en environnement PC, c'est juste qu'il y a aucune garantie au niveau du hardware, pas parce qu'on ne peut pas ^_^

Tant qu'il existera un marché de masse pour la vente de machine propriétaire (comme les consoles), les problématiques de programmation embarqué seront relevantes.

Écrit par : Daz | 03/08/2009

L'optimization est un probleme analytique.

Je pense que Mike a raison sur quelques points (malgres certaines formes d'expressions que je desaprouve de plus en plus ...) en particulier lorsqu'il parle de "all is data" et de trouver des informations (statistiques) sur les donnees (et donc le code puisque c'est une aussi une donnee ...) .

Les problemes recurants crees par les gens qui optimizent trop tot proviennent du fait qu'ils n'ont pas, ou se trompent a propos, des informations relatives a leurs donnees. Par exemple, ce que Mike pointe comme "le cas general" dans un slides : est-ce que le cas general est 1 plan vs 1 sphere, ou N, N , ou N , M, ou autre?
L'optimisation d'un morceau de code est process simple qui suit une demarche scientifique :
- ecriture d'une solution generale, optimale selon un cahier des charges (cdc trop souvent implicite)
- obtention d'informations statistique sur le signal d'entree
- obtention d'informations sur la methode de transformation (solution generale)
- sauvegarde du signal de sortie
- rectification et specialisation du cahier des charges
- changement de la transformation en prenant en compte les informations liee au signal d'entree (solution specifique au signal d'entree)
- comparaison du nouveau signal de sortie a l'ancien (pour eviter l'introduction de bugs)

Rien ne sert d'optimiser avant d'avoir des donnees precises sur ce que l'on traite. Le seul moment ou cette reponse est definitive correspond a un temps T generalement tres pres de la date de ship (puisque les donnees et le code sont presques definitif). Ou alors le cdc etait parfaitement redige mais je n'en ai encore jamais vus (sinon on n'utiliserait pas de methode iterative).
De plus, ce que l'on traite est sujet a changement et donc une solution specifique concue trop tot pourrait devenir obsolete.

De plus, en regle generale tout process d'optimization est un tradeoff : soit parce que l'on s'appuie sur donnees hardware (qui font que le code scale moins bien sur differentes plateformes), soit parce que l'on s'appuie sur des donnees d'entree (qui font que le code scale moins bien en fonction des donnees d'entrees). Toujours parce que l'optimization provient de la specialisation.
Si le process d'optimization n'a rien "echange" contre la performance, c'est que le code d'origine etait mal ecrit (etant donne le contexte precis de capture) ou trop general (mauvaise comprehension du cdc).

Nous avons la chance de travailler sur du materiel bien defini et les softs que nous developpons ne sont fait que pour ce materiel. Il est donc normal que l'on prenne en consideration des specifications materielles.

@skaven, l'optimization du cache est une bonne chose et penser a ses donnees tres tot dans la prod est generalement bon. Mais es tu sur que les problemes que tu resouds sont les bons ? Je veux dire, c'est bien d'optimiser le cache quand on a des problemes de cache, mais as tu vraiment ces problemes ? Est-ce que la solution de grouper tes donnees est toujours la bonne (parce qu'en hyperthread, ca ne fonctionne pas forcement, entre autre...) ? Est-ce que tu optimises aussi ton instruction cache avant d'avoir fini ton set de features?
Je ne dit pas que "penser en mode data" est inutile : loin de la et je dirais meme que je suis d'accord avec toi. Mais je voudrais juste preciser que l'optimization ne se fait pas par anticipation.
Il faut developper par besoin (ce que Mike fait parfaitement). Et tant qu'on a pas besoin d'optimiser le cache, ca ne sert a rien de penser a grouper ses donnees pour quelles soient manipulable par un CPU. Il faut le faire quand, et seulement a l'endroit ou, il y a besoin et a priori seul un profiler peut te le dire (ou un cahier des charges extremement precis qui demande a ce que tes donnees soient groupees parce que tu SAIS qu'un bus n'ira pas assez vite pour tout transferer d'un endroit a un autre).

Mes recommandations :
- pas (trop) d'anticipations puisque si vous vous trompez, le resultat sera pire qu'une methode generique
- Developper par besoin et jamais par envie (je m'en fou que mes donnees soient groupees par access ou par taille si ca me prend un temps qui empeche d'ajouter une feature c'est inutile).
- Toujours developper des features tant que les performances sont correctes
o Ce qui implique toujours garder un oeil sur les performances
- Des que l'on passe dans le orange cote performances :
o Obetnir des informations sur le build
o Optimiser uniquement ce qui demande a etre optimiser
o recommencer, des que possible, a developper des features.
- Ne jamais attendre d'etre dans le rouge ....

Apres tout, on delivre une experience et les performances sont lies a cette experience : si elles sont suffisantes ca ne sert a rien d'aller plus loin. Ca ne sert a rien d'anticiper des problemes potentiels il vaut mieux corriger des problemes concrets. Il faut donc se poser les bonnes questions au bon moment.

Écrit par : Gabriel Ware | 03/08/2009

J'ai du mal m'exprimer :)
Les traitements ne sont finalement que des services aux datas.
Reflechir en data seulement pour voir la circulation des données facilite la prise de décisions pour faire une architecture. Dans mes précédents tafs, après avoir vu l'architecture du pipeline, on se mettait a coder un morceau du pipe tous en même temps. Vu qu'on connaissait chacun les tenants et les aboutissants des datas, on pouvait 'bouchonner', +/- profiler et en tout cas trouver les erreurs de design assez tot.
En outre, humainement, c'etait vraiment agréable d'etre client et serveur de datas pour ses camarades. Des échanges dynamiques et rapides ou tu pouvais tu reposer sur tes collègues.

Prevenez moi si je suis dans les choux :D

Écrit par : skaven | 03/08/2009

Oula, tu es loin d'être dans les choux Skaven, Gab se contente de préciser deux trois points intéressants ^_^

@Gab: comme d'hab, ton post est d'une richesse extrême, et tout à fait "spot on" ^_^

Il y a plusieurs idées qui mérite d'être définies: ce qui constitue (ou pas) une optimisation prémature, quels process à mettre en place pour réunir et traiter les informations liées aux performances générales, les paramètres des tradeoffs que l'on peut (doit) faire, définir quand la considération de performance prend place au cours de la production, etc etc... :-)

Pour moi, il y a deux approches complémentaires: la performance "défensive", et la performance "aggressive".

Etre défensif, c'est prendre à coeur le souçis de performance dès le design. Prenons un exemple que l'on connait bien tout les deux, un moteur d'animation dans un certain moteur populaire ;-)

La problématique de l'animation est un domaine relativement bien balisé: je veux dire par là que l'on a pas besoin de chercher loin pour se donner une idée relativement précise des données et des algorithmes principaux que l'on va devoir implémenter.

C'est même quasiment un cas d'école en fait.

Pour autant, il est très facile d'implémenter quelque chose de fonctionnel, mais qui va trasher tous tes caches, faire du LHS à gogo, effectuer des calculs inutiles etc etc...

En fonction des choix éditoriaux, cela peut devenir un problème - ou pas. Mais coder défensivement - c'est à dire en faisant des choix simples au niveau des structures de données et des boucles principales - permet parfois de se libérer d'un point plus tard dans une production quand viens l'heure...

...de coder agressivement! Coder agressivement, c'est aller écrire du code qui va explicitement tirer parti de tel ou tel features hardware.

En général, comme tu le signales très justement, on vient à ces phases là souvent par besoin. Comme tu le dis également, ce type de mode de programmation requiert une grande connaissance à la fois du domaine d'application que des contraintes hardwares.

Etre aggressif, c'est faire le choix du spécifique pour servir un besoin (en l'occurrence la performance). Pour ce faire, il faut une rigueur extrême, et une méthode scientifique digne d'un CSI ^_^

Le hic, c'est qu'il est parfaitement possible d'arriver trop tard !!!

Quand on dois changer les structures de données et l'implémentation d'un système, il faut avoir le temps devant soi! On ne fait pas ce genre de travaux une semaine avant une deadline, et j'argumenterai même que si il suffit de réécrire deux ou trois trucs en Altivec ou en SSE, c'est que le problème n'était pas très sérieux !

C'est aussi pour çela que l'on doit mettre en passe une forme d'écriture "défensive" en amont, afin de simplifier le cas échéant la tache si il faut être un peu plus aggressif.

Par exemple, l'équipe de God Of War 3 fonctionnent comme çela: ils codent sur PPU "normalement", et si il y a besoin, ils poussent le code sur SPU. Et si vraiment ç'est pas suffisant, ils recodent le module avec les intrinsics.

Quand le travail en amont n'est pas fait, il est parfaitement possible de se retrouver avec une tache titanesque sur les bras...

Ca y est, moi aussi, je m'étale, suite au prochain épisode ^_^

Écrit par : Daz | 03/08/2009

@skaven : Non non ca n'est pas ce que je voulais dire. Je suis d'accord avec toi (et d'autres) qu'il est important de comprendre qu'on traite de la donnee, et donc que bien integrer comment cette donnee circule dans le programme est une des clefs pour bien programmer.
Tu n'es pas dans les choux, au contraire ce que tu exprimes semble etre le mouvement de ces temps ci.

@Daz : Je suis d'accord avec ce que tu exprimes (comme souvent :P). et d'ailleurs a tel point d'accord, que je vais m'approprier tes dires mais en le reformulant pour que personne ne s'en rende compte ;P

Une partie de la performance provient de la specialisation possible des methodes de traitements des donnees des la conception. Pour les programmeurs console il est important d'integrer les specificites architecturales de celles-ci en evitant LHS, integrant correctement le multithreading, et faisant attention au memory wall. Surtout que ces specificites n'ont pas (ou peu) d'impact sur des plateformes plus laxistes. Donc performance en amont, pas besoin de profiler il suffit de bien penser a ses donnees (c'est la ou je suis d'accord avec toi skaven) et aux architectures sur lesquelles le code a besoin de tourner (comme tu dis Daz').

L'autre partie vient de la surspecialisation des methodes de traitements. Cette fois le process est souvent (peut etre meme toujours?) destructif. Et donc doit absolument etre fait par necessite. Ce processus est dirige par profiling ou autre methode d'analyse.

Pour optimiser, si le travail en amont n'est pas fait, il faut le faire. S'il est mal fait, c'est encore pire ;)

Ceci dit je vais quand meme contre argumenter un de tes points (parce que c'est marrant :P ... mais aussi constructif). Tu dis que "si il suffit de reecrire deux ou trois trucs en Altivec ou SSE c'est que le probleme n'etait pas tres serieux". Heureusement ca n'est pas tout a fait mon experience et je ne suis pas tout a fait d'accord avec ca. Souvent les meilleures optimisations sont les plus courtes : enlever un lhs d'une boucle, un cache miss d'une fonction, ou une indirection. Et malheureusement reecrire tout un systeme de collision en VMX c'est long, fastidieux et la fin le gain n'est pas forcement au rendez vous ... Des fois la solution est compliquee, des fois la solution est simple mais dans tous les cas le probleme est serieux.

Comme d'habitude je m'etale... je ferais bien de poster ca chez moi ! :P

My 2 cents,
Gab'

Écrit par : Gabriel Ware | 03/08/2009

Moi je dis comme toi Gab'. De toute façon, je me risquerai pas à argumenter avec un type capable de faire des prises de psychopathes à la machine à café le matin !!! ^_^

Bon, ok, il est trop tard aussi pour que je puisse continuer à digresser pendant des heures sur le sujet, j'avoue :P

Juste un truc pour reélargir le débat vite fait: c'est quand même bien dommage que des qu'on parle perf, les gens semble se braquer sur leurs acquis. A Dark, j'ai de la chance, j'ai des collègues ouverts et enrichissants (comme toi Gab'), mais s'est pas le cas partout malheureusement... :(

Oh, juste pour ma culture gé, Skaven, tu bosses pour qui toi ces derniers temps ?

Écrit par : Daz | 03/08/2009

Merci pour ces posts super intéressants (même si je n'ai pas tout capté dans le détail).

Cette histoire de quicksort me rappelle mes cours de quand j'étais petit...
Le tri à bulle est peu performant avec un processeur, mais devient redoutable dès lors que l'on en a suffisamment (à l'inverse du quicksort).
Cela m'avait presque donné envie de m'intéresser au hardware à l'époque :-)

Où que l'on se place (raz du métal / haut niveau d'abstraction), on se retrouve toujours confronté au même probléme: où placer le curseur "générique/spécifique" en fonction du projet, du moment du projet, de l'équipe, etc.

Pas facile...

Écrit par : Serpico | 03/08/2009

Oui, c'est un débat que l'on a toujours pas résolu, même après 30 ans d'histoires! Pour beaucoup de personnes, c'est aussi juste une histoire de confort ^_^

Et apparemment, ça reste un débat d'actualité, puisque même au US, on ressent de plus en plus un problème avec la formation des jeunes programmeurs...

http://www.embeddedgurus.net/barr-code/2009/08/real-men-program-in-c.html

Écrit par : Daz | 04/08/2009

"Oh, juste pour ma culture gé, Skaven, tu bosses pour qui toi ces derniers temps ?"


J'ai bossé dans le JV il y a quelques années. Sorti 2 jeux sur ps2 et coder un moteur 3D sur PS3. On a décroché un deal pour une pre-prod 1st party chez Sony. Le résultat était mauvais et Sony n'a pas donné suite. Décu par le domaine (heures supp, stress, salaire de misère), je suis parti dans l'industrie. J'ai doublé mon salaire en faisant beaucoup moins d'efforts. Ce qui me laisse du temps pour ma famille et mes projets persos. En fait, je crois que le gamedev est plus qu'une drogue, c'est une facon de vivre. Tout ca pour dire que je ne travaille plus dans le JV :D. Je ne sais pas comment vous faites pour tenir.

Écrit par : skaven | 04/08/2009

Ça doit être, ça... une drogue :)

Écrit par : Mokona | 04/08/2009

Ouais, je comprend tout à fait ce que tu veux dire Skaven. L'industrie a burné tellement de monde...

Perso, j'ai une théorie à ce sujet: si je continue à bosser "professionnellement" dans le secteur, c'est surtout parce que je... manque d'imagination !!! ^_^

Ben ouais, c'est un comble tu vas me dire, mais je n'arrive tout simplement pas à m'imaginer en train de faire autre chose. Mon cerveau fait tout simplement choux blanc... ou BSOD si tu préfères ;-)

Epic fail moi je dis : P ;-)

Écrit par : Daz | 04/08/2009

En plus, les projets de JV sont de plus en plus long. Difficile de garder sa motivation pendant 3 ou 4ans. Pour au final ne pas 'tripper' sur la boite de son jeu quand tu le vois a carrefour ou auchan.

Le bon coté de l'industrie est qu'on te laisse le temps de faire/refaire/chercher (dans une certaine mesure). Fini les periodes de crunch qui durent, qui durent....

Ce qui me manque, ce sont les discussions live sur du code, du design,... avec des personnes passionnées. Le terme 'passionné' a certains drawbacks aussi :D

Écrit par : skaven | 04/08/2009

Ouais, on a quand même la chance de bosser avec des gens sympa et en général passionné par ce qu'ils font, et sur des problèmes souvent terribles!

Bon, on est tous pauvres, mais c'est pas bien grave ça :-D

C'est pas tout le monde qui peu se vanter d'avoir été payé pour écrire un code permettant d'embrocher trois ragdolls au bout d'une lance et de se balader avec ;-)

Écrit par : Daz | 04/08/2009

1) Le pire code que j'ai jamais vu c'est moi qui l'ait écris. Et je pense que c'est le cas de tous le monde ici. Je me souviens encore de certains trucs que j'ai écris sur Desperados, mes yeux saignent rien que d'y penser.

2) Au niveau de formation, c'est la merde. Simple question à un entretien d'embauche : "pourquoi vous utiliseriez plutôt une liste qu'un tableau dynamique ?" 9 gus sur 10 n'en ont absolument aucune idée. Et c'est des gens qui ont poussé la porte d'une boite de jeux pour essayer d'entrer.

Écrit par : Whirly | 05/08/2009

1) Non, même pas vrai !! :P Mon code est le meilleur de tous les codes, et je n'ai jamais écrit de code pourri... ou alors c'était il y a longtemps... genre en 1986, quand j'avais écrit 6000 lignes de Logo pour dessiner un soleil avec ma tortue... et puis aussi deux ou trois trucs y a moins longtemps... et pis de toute façon, "ça marche sur ma machine" (tm), alors... ^_^

2) Oui, on a toujours eu un gros problème avec les formations en France (y compris celles que j'ai reçu). Après, je crois dur comme fer que le métier s'apprend d'abord et avant tout sur le terrain.

Du coup, je pense que l'on ne peux pas faire passer le même entretien à un jeune diplômé qu'à quelqu'un qui a 10 ans d'expérience. Mais dans les deux cas, ce qui compte surtout, c'est:

1 - Eliminer les psychopathes divers et variés, ceux qui vont pourrir l'ambiance du studio, qui vont dénigrer à tout va, qui vont agresser les gens, qui vont te faire chier à cause de leur égo, etc etc

2 - S'assurer que le candidat à le bagage intellectuel suffisant pour pouvoir s'atteler aux problèmes qui vont lui incomber. Note, je parle de bagage intellectuel, pas de bagage culturel ou scolaire. L'important, ce n'est pas forcement de "savoir", mais plutôt de "savoir faire", voir de "savoir quoi faire quand on sait pas".

3 - Checker enfin si ça va "coller" avec la culture de l'entreprise, avec l'équipe, avec l'apport de fraicheur et/ou d'enthousiasme...

Après, si en plus, le candidat est sur-compétent, alors là, royal ^_^

Écrit par : Daz | 05/08/2009

1. Ca c'est ce que j'ai appris "the hard way", mais maintenant c'est bon. Le pire c'est qu'une fois que tu as embauché ton premier sociopathe tu passes ton temps à te repasser l'entretien dans ta tête en te disant "merde j'ai loupé quoi". Ensuite il suffit de quelques mecs aigris pour transformer ta boite en bocal à cornichons.

2. Ca c'est la partie "simple" :)

3. Là je tourne la roue et je regarde si je tombe sur banqueroute :)

Mais bon globalement un stage de 6 mois permet effectivement de se faire une bonne idée.

Écrit par : Whirly | 05/08/2009

Ouais, il faut du temps pour s'en rendre compte: stage chez certains, CDD chez d'autres (the Ubisoft way).

En parlant de RH, là, je suis en train de lire les notes d'intentions chez Netflix, fascinant comme lecture aussi:

http://www.slideshare.net/reed2001/culture-1798664

Écrit par : Daz | 05/08/2009

Petit soucis de vocabulaire : un portable sous Windows CE est il embarque ?

Si non, ca fait quand meme rudement peu de ressources pour un systeme classique, et on se demande d'ou vient le Embedded de "CE"

Si oui, ou se trouve le lien entre 'memoire virtuelle' et 'systeme embarque', etant donne que Windows CE met a disposition de la memoire virtuelle (restreinte a 32MB par process, certes) ?

Merci de m'eclairer ;)

Écrit par : MMoi | 18/08/2009

Salut,

J'adore les soucis de vocabulaires donc je vais essayer de m'y coller :P

Si tu me le permets, je vais reformuler ta question "un portable sous windows CE est il embarque ?" par :
"Un portable est il une plateforme embarquee ? et est ce que le windows qui fonctionne dessus est un systeme d'exploitation embarque"

Une plateforme embarquee est un systeme hardware dediee a des taches specifiques. Le nom vient des puces que les fabriquants "embarquent" dans des appareils mobiles si je ne m'abuse. Je pense qu'un telephone portable est un excellent exemple d'embarque ;) Ceci dit on pourrait citer d'autres exemples comme les controlleur de locomotives, relais telecoms ou encore les gps .

Est-ce que windows CE est un systeme d'exploitation embarque ? J'aurais tendance a dire oui puisque, malgres le fait qu'il fasse plus que la telecomunication, il reste developpe dans l'optique de tourner sur des plateformes embarquees ou similaire.

Le developpement d'applications sur des plateformes embarques est generalement dirige par des contraintes de ressources : processeur et memoire y limitent les calculs en temps reel.

Le developpement console est souvent associe a l'embarque puisque les contraintes sont assez similaire, bien qu'avec le temps les consoles deviennent plus puissantes et tendent a proposer un hardware similaires aux ordinateurs traditionnels. Ceci dit, les puces embarques sont de plus en plus puissantes elles aussi ... mais j'avoue qu'il me semble que cela reste tres inferieur a nos consoles de salon, et encore plus inferieur aux high end pc ;)

Pour finir, le lien entre memoire virtuelle et les systemes embarques se retrouve dans l'architecture des plateformes embarques qui ne disposent generalement que de peu de memoire et de systemes d'exploitation sommaires. Historiquement les OS disponibles sur des plateformes embarques ne proposaient pas de virtualisation de memoire (pour ne pas gacher "inutilement" des ressources).
Ceci dit, je ne crois pas que le fait de proposer ou non la virtualisation de memoire soit un attribut decisif dans la definition d'embarque (mais il y participe un peu).

My 2 cents,
Gab'

Écrit par : Gabriel Ware | 18/08/2009

On est d'accord, donc, merci pour le commentaire...

ce lien etant etabli dans quelques commentaires au debut de la discussion, la confusion est nee dans ma petite tete ("memoire virtuelle ? gne ? n'aurais-je rien compris a ce qu'est un systeme embarque ?")

Écrit par : MMoi | 19/08/2009

Les commentaires sont fermés.