L'assembleur, plus rapide que le C/C++ ?

L'assembleur, plus rapide que le C/C++ ? - ASM - Programmation

Marsh Posté le 12-03-2005 à 17:13:32    

Bonjour,
 
Je fais des recherches sur les nombres premiers à l'aide de programmes très longs (certains peuvent tourner pendant plusieurs mois). J'écris en C/C++ (avec la librairie GMP) mais passer à l'assembleur me ferait gagner beaucoup de temps, non? Des proches me disent que oui, d'autres que non... Je ne sais plus à quel saint me fier!
 

Reply

Marsh Posté le 12-03-2005 à 17:13:32   

Reply

Marsh Posté le 12-03-2005 à 17:22:37    

Je serais tenter de dire que si tu te contentes d effectuer des calculs numériques tu ne gagneras pas bcp en passant à l'asm

Reply

Marsh Posté le 12-03-2005 à 17:59:28    

roooh zut!
 
en effet, je me contente de calculs numériques (additions, multiplications, soustractions, modulos, etc...).
En temps d'exécution, je gagnerai moins qu'un facteur deux par exemple?

Reply

Marsh Posté le 12-03-2005 à 18:00:35    

n'importe quoi ...

Reply

Marsh Posté le 12-03-2005 à 18:02:03    

est-ce que d'autres gens peuvent me confirmer l'affirmation de phnatomass??

Reply

Marsh Posté le 12-03-2005 à 18:02:29    

quoi "n'importe quoi" ?

Reply

Marsh Posté le 12-03-2005 à 18:04:04    

y a rien à confirmer. le C ou le C++ te fournisses des abstractions qui te permettent de programmer rapidement et efficacement. Je vois mal comment tu pourrais t'en sortir en faisant de l'assembleur -- tu n'as aucune expérience -- comparé a des bibliothèques optimisisées ...
 
Surtout que si tu débutes, t'imagines même pas le bordel que ça va être de faire une multiplication de grands nombres en ASM déjà qu'en C++ c'est pas facile ...

Reply

Marsh Posté le 12-03-2005 à 18:45:46    

en C++ (avec une libraire adaptée) c'est très facile!  
 
bref, passons.  
 
d'autres avis?

Reply

Marsh Posté le 12-03-2005 à 18:56:06    

qeu ca peut, comme ca ne peut pas, par contre ce qui est sur c'est que tu passeras par du sang de la sueur et des larmes

Reply

Marsh Posté le 12-03-2005 à 18:57:55    

Ca dépend de comment tu codes, si t'as jamais fait d'ASM laisse béton...


Message édité par djok_fb le 12-03-2005 à 18:58:12
Reply

Marsh Posté le 12-03-2005 à 18:57:55   

Reply

Marsh Posté le 12-03-2005 à 19:28:54    

un algo de multiplication de grands chiffres en asm si tu débutes ca peut t'occuper pour environ 6 mois je pense...


---------------
Il y a autant d'atomes d'oxygène dans une molécule d'eau que d'étoiles dans le système solaire.
Reply

Marsh Posté le 12-03-2005 à 19:38:33    

LOL. merci pour vos encouragements!  
C'est vrai, je débute, je pars de bas. mais est-ce une raison suffisante pour baisser les bras? Je ne crois pas.
 
Par ailleurs, je pense repêcher du code sur des sources publiées et simplement faire quelques modifs pour implémenter mon propre algorithme...
 
Je pense m'inspirer du code du projet GIMPS. Vous connaissez?

Reply

Marsh Posté le 12-03-2005 à 19:47:09    

initial a écrit :

LOL. merci pour vos encouragements!  
C'est vrai, je débute, je pars de bas. mais est-ce une raison suffisante pour baisser les bras? Je ne crois pas.
 
Par ailleurs, je pense repêcher du code sur des sources publiées et simplement faire quelques modifs pour implémenter mon propre algorithme...
 
Je pense m'inspirer du code du projet GIMPS. Vous connaissez?


 
euh moi je suis sympa hein, mon estimation de 6 mois n'est pas du cynisme, c'est valable si tu es un codeur pas trop mauvais... si vraiment tu es grand débutant la multiplication numérique fiable de nombres très longs ca peut te prendre bien plus de temps  [:spamafote]  
 
Coder en assembleur est vraiment beaucoup plus long. Dans les logiciels qui estiment la durée de développement d'un gros projet, il y a des coefficients multiplicateurs pour chaque langage, et plus le coefficient est grand, plus le temps de développement sera long. Si le C++ est à environ 60, l'assembleur sera à environ 310 :D


---------------
Il y a autant d'atomes d'oxygène dans une molécule d'eau que d'étoiles dans le système solaire.
Reply

Marsh Posté le 12-03-2005 à 19:49:32    

salut
 
Tu gagnerais beaucoup plus en te penchant sur la parallèlisation du code, si l'algorithme est parallèlisable. Il suffit d'avoir plusieurs machines à disposition et d'utiliser MPI.
Si tu as une machine seule mais multi processeurs, dirige toi vers OpenMP.
 
Sinon tu peux essayer la vectorisation par des intrinsics SSE, ça dépend de ton code - ce n'est peut etre pas possible avec GMP - mais ça peut etre interressant de voir ça.
 

Reply

Marsh Posté le 12-03-2005 à 21:41:31    

Xavier_OM a écrit :

euh moi je suis sympa hein, mon estimation de 6 mois n'est pas du cynisme, c'est valable si tu es un codeur pas trop mauvais... si vraiment tu es grand débutant la multiplication numérique fiable de nombres très longs ca peut te prendre bien plus de temps  [:spamafote]  
 
Coder en assembleur est vraiment beaucoup plus long. Dans les logiciels qui estiment la durée de développement d'un gros projet, il y a des coefficients multiplicateurs pour chaque langage, et plus le coefficient est grand, plus le temps de développement sera long. Si le C++ est à environ 60, l'assembleur sera à environ 310 :D


 
Ça c'est le nombre moyen de lignes de code source livrées par points de fonctions.
Mais effectivement si tu fais une estimation COCOMO en te basant là-dessus, la charge est effectivement très beaucoup plus élevée pour de l'assembleur...
 
Concernant le topic : le mieux est de profiler le binaire développé en C avec la bibliothèque GMP et de faire de même avec un prototype développé vite fait en assembleur, juste pour comparer (l'ordre de grandeur). Mais à mon avis c'est une belle perte de temps (cela dit, ça peut être sympa  si tu veux faire de l'assembleur).


Message édité par printf le 12-03-2005 à 21:42:38
Reply

Marsh Posté le 12-03-2005 à 21:50:32    

Exo 7, tu peux me donner quelques indications supplémentaires sur "la vectorisation par des intrinsics SSE"? De quoi s'agit-il?
 
Pour l'instant, j'ai une seule machine mono-processeur.
D'ailleurs MPI n'est efficace qu'à partir d'un certain nombre de machines non? En-dessous, ça perd plus de temps qu'autre chose, j'imagine?

Reply

Marsh Posté le 13-03-2005 à 02:41:44    

SSE c'est une extension des instructions x86, permettant de faire plusieurs calculs sur un groupe de donnée en une seule instruction. Pour cela les données sont chargées dans des registres 128 bits, et une instruction SSE opère sur des blocs de données à l'interieur de ces 128 bits (par exemple,  par groupe de 32 bits).
Du coup pour faire des additions d'entiers, on peut charger 8 entiers contigues en mémoire avec 2 instructions, et faire 4 additions en une seule instruction.
Pour les utiliser, soit on code les routines directement en assembleur si on est un peu suicidaire, soit on utilise des intrinsics : ce sont des sortes de macro instructions, utilisable en C après un #include "intrinsics.h".
Il doit y avoir un pdf avec toutes les intrinsics utilisable sur le site d'Intel.
Evidemment pour que le programme s'execute, il faut disposer d'un processeur qui supporte le SSE.
 
Au niveau des conditions de vectorisation, les principales contraintes sont d'avoir un accès aux données par pas unitaire et de ne pas avoir de dépendance de données.
 
Pour MPI, le facteur d'accélération dépend entièrement de l'efficacité de la parallèlisation. Si tes calculs sont complètement indépendants, tu peux obtenir une accélération linéaire en nombre de processeur (voir plus, si chaque morceau de données découpées tient dans le cache d'un processeur).
Grosso modo avec 2 processeurs j'ai codé des applications de calculs matricielles avec une accélération de 1.9, 8 processeurs accélération de 7.
On perd de l'efficacité en augmentant de trop le nombre de processeurs car tout passe par le meme tuyau (le réseau) et les latences augmentent.

Reply

Marsh Posté le 13-03-2005 à 08:39:58    

Bon, merci à tous pour vos avis.  
Je vais à présent donner une autre direction à ce topic (sans sortir du sujet pour autant) :
Pensez-vous que le code du projet GIMPS (http://www.mersenne.org/source.htm) est "récupérable" et pourrait permettre de coder facilement un algorithme qui, de i = 0 à i = 1000 (par exemple), appliquerait à i plusieurs transformations (additions, mutliplications, puissance), puis qui testerait à chaque fois la primalité de i au moyen du test de Miller-Rabin (! difficulté : ce test n'est pas implémenté dans GIMPS!) pour finalement inscrire les nombres premiers dans un fichier .txt (et passer au i suivant) ?

Reply

Marsh Posté le 13-03-2005 à 09:15:25    

Ce que je sais, c'est que si les auteurs de GIMPS ne se sont pas emmerdés à coder le bousin en asm, tu devrais présumer de tes forces et faire de même, ou alors il faut que tu te sentes vraiment plus doué qu'eux. Comme ce sont des algos assez velus il y a des chances que tu n'en voies jamais le bout.  
Dans ce code, il y a sans doute des routines de calcul sur les grands nombres récupérables, oui. P-ê même qu'au fin fonds de ces routines, il y a des bouts de code optimisables via SSE2 ou asm x86 (il y a des chances que ce soit déjà fait). Pour ce qui est de la parallélisation avec MPI, c'est p-ê faisable. Ou alors tu te sers de leur code pour du grid computing, ce qui de toute façon est plus efficace qu'une optim asm si tu as les ressources matérielles sous la main.


Message édité par el muchacho le 13-03-2005 à 09:17:23
Reply

Marsh Posté le 13-03-2005 à 09:29:43    

non non je ne parlais pas d'optimiser leur code. je n'ai pas cette prétention!! juste : modifier leur code pour lui faire faire mon algorithme (totalement différent des nombres de Mersenne) et non le leur.  
 
Par ailleurs, qu'est-ce que le grid computing au juste?

Reply

Marsh Posté le 13-03-2005 à 09:35:33    

Calcul à travers le réseau. Comme le GIMPS ou Seti@home par ex.

Reply

Marsh Posté le 18-03-2005 à 21:58:20    

OK, merci...

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed