Version imprimable
Bonjour,
j'aimerais savoir comment je pourrais optimiser une application pour ces 2 type de processeurs, les double coeur et les 64bits
les double coeur s'optimiserais grace a la parrallelisation des taches => multithread??
qu'est ce que ces 2 optimisations(double coeur + 64bits) donne de concret dans notre manière de programmer??
les resultats en val t-il vraiment la peine?? (de realiser plusieur version d'une application en fonction du CPU)
A part les verrous de synchronisation, dans l'immédiat je vois pas trop...Citation:
Envoyé par TheBlackReverand
Cela peut se faire simplement avec des directives de préprocesseur mais les applications 64 bits ne sont pas très utiliséesCitation:
Envoyé par TheBlackReverand
euh ... c'est vraiment en natif mais en .NET le CLR gère ça lui même et paf ça fait des chocapic. Bref on s'occupe de rien et fonctionne nativement en 64 bits. :lun:Citation:
Envoyé par harz62
Une version par CPU ? mais alors à quoi sert d'avoir prit la peine de mettre le CLR entre les deux ? sincèrement je pense que tu n'y gagnera rien, tu va par contre perdre du temps à le faire sans gagner grand chose.Citation:
Envoyé par TheBlackReverand
Perso je pense que tu devrais programmer dans l'optique où ton programme s'exécute sur des multicores (ce qui est de plus en plus probable) en programmant en multithread : si un processeur simple cœur ça ne changera pas grand chose, et sur un multi cœur t'ira plus vite (en exécutant les tâches en parallèle).
Pour le 64 bits comme dit précédemment le CLR se charge de toute les basses besognes et d'ailleurs un programme .NET par défaut s'exécute en 32 bits sur un CPU 32 bits et en 64 bits sur un CPU 64 bits ...
C'est fort en chocolat :mouarf:Citation:
Envoyé par dev01
Attention ! multithread != multi core.Citation:
Envoyé par smyley
C'est parce que l'on a plusieurs thread et plusieurs cœur que la charge va être répartie afin que l'application tourne plus ! L'OS fait absolument ce qu'il est bien souvent on voit que l'application n'utilise qu'un cœur pour tout faire. Le multi-thread est la afin de donner l'illusion que tout peux s'exécuter en même temps mais rien en garantis que les threads seront exécuté réellement en parallèle sur un multi-cœur
Quoi ? j'ai dit ça ? :aie:Citation:
Envoyé par dev01
Un exemple concret, je suis allé faire pour préparer un exercice de TIPE en math le calcule des nombres du problèmes de Syraccuse de manière récursive. Avec un seul thread j'ai un cœur qui tourne au max, et ce en permanence, avec 3 000 000 de tests à la seconde. Avec 2 threads (j'ai un double cœur) j'arrive à 5 000 000. C'est dans cette optique que je dit de programmer un multithread si on s'attend à des multicoeurs, le système s'arrange pour ce soit équilibré, mais c'est beau quand ça marche comme ça pour les gros calculs :D
d'accord donc
optimisation pour multi-coeurs => le multithread peut donner un beau gain si l'OS le gére bien
optimisation pour 64bits => rien
j'espair avoir bien était compris, la compatibilitè avec les 64bits ne me surprend pas, mais je penser que l'on aurais pus optimiser en utilisant certain element plutot que d'autre :)
merci pour vos reponses
ce n'est pas vrai. il y a des gains dans certaines opérations mais plus "subtile"Citation:
Envoyé par TheBlackReverand
http://msdn.microsoft.com/fr-fr/netf...29(en-us).aspx
oui mais des optimisation gérè par le Framework, aucun changement dans la structuration de notre code
Un code .NET n'est pas compilé directement en code machine mais en langage intermédiaire. C'est la tâche du JIT d'optimiser le code (juste avant son exécution) en fonction du processeur sur lequel il tourne donc c'est à ce niveau que le gros de la différence entre un processeur 32 et 64 se fait sentir, mais cet effet n'a pas vraiment de répercussion sur le code source .NET car le but a justement été de s'abstraire de toutes ces spécificités du matériel...