Bonjour,
 
Nous avons migré au travail une application principalement écrite en C# / .NET et tournant sur un OS 32Bits vers un OS 64Bits, avec un changement de machine à la clef.
 
La raison pour laquelle nous l'avons faite est que cette appli fait un usage massif de mémoire cache et que les 1.6Go du process 32Bits devenaient trop courts.
 
Après migration, le code étant resté identique, je constate que l'appli est environ 25% plus lente en 64Bits qu'en 32Bits.
Bien évidemment, cette perte apparente de vitesse peut être due à une multitude de paramètres (l'appli est plutôt complexe avec beaucoup de modules), mais je me demandais si selon votre expérience, il était courant d'avoir ce genre de dégradation.
 
Merci.
 

J'avais lu que la vitesse en 32 bits et en 64 bits était grosso modo la même.
 
Donc, cette perte de 25% n'est pas hyper étonnante pour moi.

 
Est hyper étonnante tu veux dire?

Malheureusement, je n'ai plus références exactes des tests que j'ai lus.
 
Avoir 25% de différence ne m'étonne pas vraiment. J'aurais été étonné à partir de 50% dans un sens ou dans l'autre.
 
A quoi vous attendiez-vous ?

25% de performances en moins me paraît énorme, et on ne peut pas parler des performances similaires dans ce cas là. (ce serait la différence entre une voiture roulant à 270 km/h et une voiture roulant à 200 km/h)
 
J'aurais imaginé un Delta de 1 à 2% intuitivement.
 
Je n'arrive pas à trouver sur Internet de références sur ce sujet.

25% de différences de perf, c'est considérable.
 
J'imagine que les deux points qui vont coûter chers quand on passe à du 64 bits, ce sont d'une part les pointeurs plus gros (donc structures contenant des pointeurs plus larges, sur certaines implémentations, ca peut jouer) et coût de l'appel de fonction augmenté (registres plus gros, plus nombreux, donc plus gros volume de données à empiler).
 
Pour avoir 25% d'écart de perfs, tu as peut-être un autre souci que le passage au 64 bits. Tu devrais commencer par profiler ton appli. Vérifie notamment que tu n'es pas plus souvent en train d'attendre ton disque qu'avant (on vient de faire une transition douloureuse sur les disques, avec le changement de taille des secteurs)
 
Edit : typo

Je suis d'accord avec toi pour la taille des pointeurs plus grosse (mais je n'avais pas pensé à la taille des paramètres d'appels de fonctions, mais ça fait sens également).
 
Pour info, pour la partie processing de l'appli, tout se passe en mémoire. Il y a en fait une partie récupération de données (multisources provenant d'autres machines), qui est aussi rapide qu'avant, et une partie processing environ 25% plus lente.
 
Je vais commencer par demander à bencher les deux machines, pour m'assurer qu'il n'y a pas un processus grévant les performances sur la nouvelles machine (on ne sait jamais en entreprise...).
 
Ensuite, il faudra que je puisse effectivement descendre dans le détail de l'appli. En ce qui concerne le profiling, est ce que ce n'est pas intrusif comme processus, au point de changer totalement les performances et de rendre les différences entre les deux instances non significatives?

si tu lances le même traitement sur tes deux machines (32 et 64 bits) normalement, les proportions du profiler devraient être similaires, vu que le coût du profiling sera présent des deux côtés. Du coup, il te restera juste à regarder plus précisément dans quelle(s) fonction(s) tu perds plus de temps qu'avant.
 
Tu dois assez aisément pouvoir trouver des profilers pour la plateforme .net, j'imagine.

 
OK, très bien. il faudra que je me base sur des valeurs absolues et non pas relatives (gros %age du temps passé dans le profiler).
 
Donc, ce sera l'étape numéro deux après le bench de la machine.
 
Par contre, ce ne sera pas facile de faire accepter du profiling sur une machine de PROD, et de plus, je pense que l'analyse sera ardue, vue la profondeur dela pile d'appels (AOP, interception, multicouches, etc)
 
La question principale ici était de savoir si ces 25% étaient normaux ou pas. (selon expérience)
 
Merci.

Je pense également qu'une telle variation est très surprenante.
Autant le passage en x64 occasionne une hausse de l'occupation mémoire (taille des pointeurs, structs, etc), autant au niveau temps CPU il n'est pas sensé être aussi coûteux.

J'ai une petite question : ton appli est full .Net, issue d'un process de build unique qui cible du x64, ou bien elle fait également de l'intéropérabilité avec du COM (PInvoke) ou des assemblies .Net tierces en x86 ?
Car l'hétérogénéité des solutions pourrait expliquer certains problèmes.

Pourquoi le profiling doit impérativement se faire sur la plateforme de prod, je ne saisis pas ? L'environnement n'est pas reproductible ? Dans ce cas comment vous développez ?

Hello,
 
Le build unique cible bien du x64. (je peux l'affirmer même si ce n'est pas moi qui la builde).
 
Il y a effectivement de l'interopérabilité avec du COM, mais j'ai pu cibler mes tests sur du traitement interne pur, utilisant donc uniquement des objets .NET. Au final, si je me souviens bien de la philosophie du code qui est mise en jeu, c'est beaucoup de récupération et de manipulation d'objets depuis des dictionnaires, de manipulation de chaînes de caractères (type "findstr" ) et aussi de branching ("switch/case" énorme, sous forme de tests if/then/else).
 
Je n'ai hélas pas encore eu l'autorisation de faire du profiling, et je n'ai pas encore pu obtenir de machiens tirces sur lesquelles confirmer ou infirmer cette baisse de perfs, et donc savoir si elle était liée au x64 en tant que tel ou à la machine physique.