CatchChallenger 2 et passage sur C++11

Salut,

J’ai fini la partie cluster de CatchChallenger 2, la localité des données est vraiment bonne, juste des petites réquetes pour un veroux global non bloquant sur les données communes et des serveurs indépendants. La passerelle avec cache (permet d’exposer un server sur TOR/I2P vers l’internet normal ou l’inverse), et les CDN sont aussi codés. L’infrastructure réseau est donc principalement prête pour fonctionner même dans les pires conditions: réseau trés lent <60Ko/s, ping/latence énorme: >800ms. Ce que semble confirmer les testes que j’ai pu faire via i2p et sur l’internet normal au travers du monde entier.
 
J’ai voulu faire des optimisations particuliérement de refesant le protocole, mais pour avoir un bon bon de vu sur ce qui est lent, j’ai besoin de refaire en C++11 le programme car les conteneur Qt sont lent (32x plus lent pour les chaines). Le version 11 me permet d’avoir accés a plein chose sur les containers, permet au compilateur de mieux optimiser le code, ajoute les regex, timer, temps, être plus portable sans recourrir a Qt. Cela vas me permettre aussi de faire des programmes avec trés peu de dépendance, et donc pouvoir les embarquer et cacher un peu partout. Ce remake vas être très long, surtout car je ne suis pas prêt pour le C++11 et que je doit donc tout apprendre. Ce qui est du standard, il permet de définir un certain nombre de propiété, par exemple les espace mémoire continu pour certain conteneur ContiguousContainer (for T other than bool) (since C++17) ou ContainerAllocatorAwareContainerSequenceContainer and ReversibleContainer tout cela permet d’être pris en compte par le compilateur et donc d’ouvrir des oportunités d’optimisation. Si elle pourront être profité par le compilateur et si elle le seront, seul l’avenir nous le dira. Donc oui, C++17 > C++14 > C++11 > C++99 > C++ pour les performance.
On pourra potentielement imaginer de puissant assitant de preuve avec les nouveaux standard pour détecter les failles potentielles, les cas de buffer overflow, … il ne feront pas tout, ce n’est qu’un outils, mais cela limitera les failles basiques, enseignera les bonnes habitudes.
 
J’ai mon portable datacenter qui est en ARM, ce qui me permet de tester mon jeu sur différente architecture (avec x86 sur Intel Atom z530 et AMD Geode LX800, et x86_64 Intel haswell) et tracker les possibles régréssions. J’ai ouvert les options de compression et rajouter lz4 pour comblé un vide, sur ARM les performances été desastreuses, j’ai donc ouvert quelques noeux pour l’auteur de xxhash et lz4, Yann Collet, que je salut en passant, qui as optimisé ces derniers pour ARMv6 et ARMv7.
Les changements pour le support des clusters sont donc fait, il reste ceux pour la portabilité, un énorme remake sur le protocole pour optimiser le parsage des packets. Il faut toujours différencier le format/algo/protocole de l’implémentation (comment c’est codé). C’est comme une maison, les plans peuvent être super mais la réalisassion pas génial.