*sourit dans son coin en repensant à ses débuts en assembleur et soupire*
"Dieu, comme c'est loin !"
Ils vont se déchirer, ça y est
Bon, puisqu'on parle de performances...
Il y a un truc que j'ignore si vous le savez, mais TOUS les jeux en temps réel se basent sur le partage du temps machine pour effectuer des tâches auxquelles sont affectées des priorités. Il n'y a qu'à voir le problème que posent les gros modules avec l'horloge, ou le décrochement de l'AI quand le serveur est surchargé et à rapprocher ça des machines qui les font tourner. Je suppose que ça vous est déjà arrivé à tous si vous jouez un tant soit peu.
D'un coté, plus on charge sa machine, plus les actions secondaires seront oblitérées et passeront à la trappe (je suis conforté là-dessus par MR Georg Zoeller himself). D'où la haine farouche de certains ne sachant pas optimiser envers les OHB, ou les enchaînements de DelayCommand(). Je ne reviendrais pas dessus, mais quand même... Votre histoire de dizaines de milliers de variables me fait froid dans le dos...
Quand on pompe des informations, c'est pour les traiter. Or, à moins de bosser à la météo, nos pauvres ordinateurs, même de la dernière génération, n'ont pas encore d'architecture parallèle et la possibilité de traiter 10000 infos en même temps. Par conséquent, tout sera fait de façon SEQUENTIELLE, ne vous en déplaise !
J'ignore ce qui est prioritaire dans le jeu lui-même par rapport au reste, mais au niveau d'un PC, je le sais:
- les entrées sorties: clavier, souris (ridiculement pas gourmandes, je le concède)
- les entrées-sortie fichier (disque, flux externes -série, parallèle, buffers réseau, etc... Si vous ne me croyez pas, mettez une disquette bien pourrie dans votre lecteur, et interrogez-la, même sous Win2K ou XP, vous serez surpris)
C'est simple, elles INTERROMPENT le microprocesseur dans ses traitements pour demander son intervention pour charger les données en mémoire. Cela dit, plus le PC est puissant, plus la réponse sera rapide, MAIS, il y a les goulets résidant des tuyaux (BUS, largeur des ports, débit du réseau, etc)
Par conséquent, plus vous allez charger ces entrées-sorties, moins vous aurez de temps-machine pour faire faire autre chose à votre machine et ce malgré toutes les astuces développées en terme de "mémoire-tampon" ou de "spooling". Il y a forcément un moment où ça va saturer.
Donc, à moins d'avoir une machine de guerre genre serveur dédié avec RAM-cache sur les contrôleurs de disques durs, carte réseau 1Gb avec RAM-cache, et architecture SCSI (et encore, ce n'est même pas sûr que ça suffise...), traiter des bases de données enchaînant des milliers de données pour un pauvre joueur, j'ai comme l'impression que vous allez vous planter...
Il y a des process d'usine qui traitent moins de volume et qui ne se contentent pas d'un pauvre PC de chez RaqueFour mais qui recourent à des montages en clusters pour essayer de simuler un traitement en parallèle des données et bien sûr le tout sur fibre optique.
C'est sûr qu'en optimisant son code, on va gagner quelques microsecondes par ci, ou par là, mais quid d'interrogations de bases qui demandent à charger, hmmm, mettons... 10000 enregistrements...
Un simple calcul:
en admettant que l'on oublie les protocoles et les flux secondaires liés à la structure des données (encapsulage, protocole TCP/IP, cryptage, etc), que notre ordinateur est seul sur le réseau qui interroge la base distante, et qu'on utilise le volume de données brut, on transférera 10000 entiers codés sur 4 octets sur un réseau à 100Mbits/s en ??? 3,2 secondes (environ) ! et ça, au mieux ! Donc, pendant 3,2 secondes, la machine hyper-optimisée ne va rien glander que de gérer ses entrées sorties et ramer sur tout le reste !
Ca en fait des millions d'instructions, ça, 3,2 secondes... Et ce ne sont que des entiers ! Imaginez des chaînes ou des types "object".
Moi, je rapproche ça des CINQ MINUTES, qu'il m'a fallu pour sauvegarder un inventaire moyen de personnage avec le système Bioware en utilisant la technique de base du StoreCampaignObject()... Alors même en utilisant MyMegaSql et NWFX-Save-plus-vite-que-son-ombre, vous m'excuserez, mais je reste partisan de traiter un petit volume de données en mémoire !
Et qu'on ne vienne pas me dire que les requêtes SQL sont plus rapides qu'un GetLocalInt() !
Sherazade me fait peur quand elle parle de centaines de milliers de données à gérer, on dirait qu'elle parle du processus de fabrication d'une voiture à la chaîne chez Renault.
Hep, les enfants, c'est un jeu, pas un concours de celui qui fera le plus gros module
EDIT: vue la juste rectification apportée plus bas à mes calculs, ma démonstration devient un brin moins spectaculaire mais reste néanmoins vraie... La quantité de donnée étant environ multipliée par 3 si on inclut les protocoles divers et en estimant que toutes les trames arrivent au destinataire en un temps idéal, je ne me suis QUE planté de 250 fois environ. Soit non pas 3,2 secondes mais 13 centièmes de secondes environ. Reste après à les traiter, ces données qui jusque là n'ont fait qu'arriver par les tuyaux.