substitution par nombres premiers

[Anonyme77]

Voilà l'algo, fred sais tu tester sur ta machine pour voir les différences de performances ?

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <malloc.h>
#define MAX 10000

int main (void)
{
	int depart=2,i,divisible;
	int *resultat;
	int taille;

	resultat=(int *)malloc(1*sizeof(int));
	resultat[0]=2;
	taille=1;

	depart++;
	while(depart<MAX)
	{

		i=0;
		divisible=0;
		while(resultat[i]<=sqrt((float)depart) && divisible==0)
		{
			if(depart%resultat[i]==0)
			{
				divisible=1;
			}
			i++;
		}

		if(!divisible)
		{
			taille++;
			resultat=(int *)realloc(resultat,taille*sizeof(int));
			resultat[taille-1]=depart;
		}
		depart++;
	}

	for(i=0;i<taille;i++)
        printf("%d\n",resultat[i]);

	return(0);
}

[SAKAROV]

je ferais un algorythme en C retournant les nombres premiers et je ferais un appel à ce programme en C dans mon code python pour récupérer les résultats et faire je vais dire tout le reste...

Tu n'as pas fait du tout ce que tu avais dit (ce qui avait suscité les apostrophes).

Il est où le python ?

Y'a que du C là

Qui a nié que le C aurait de bonnes perf' ?

[Anonyme77]

Autant pour moi je me suis fouvoyé sur ce que tu me demandais.

Je vais de ce pas faire la jonction. Par exemple, afficher le résultat via python.

[SAKAROV]

check by this way: http://hackademics.fr/showthread.php...mme-avec-gprof

pour toi ce sera donc la partie SOF vu que ton main sera en py.

[Ghostweber]

ben c'est du lourd ! trop pour moi

[fred]

Un langage qui nécéssite une recompilation pour chaque plate forme est forcément moins portable qu'un langage interprété (pour peu que les clients soient tous déjà équipés de l'interpréteur ou de la VM qui va bien).

Mais il existe le makefile, non ?

Du côté de la cross compilation, à partir d'un seul OS, tu peux générer ce que tu veux en une seule fois.

Si tu veux en troller en privé, ce sera avec joie !

Pourquoi du troll ? On donne de l'information, ça serait du gâchis de cacher cela au lecteur, non?

@Anonyme77

Il manque le free(resultat)

J'ai aussi comme le pressentiment que ça sera moins bon, rien qu'en C tout court, tu peux comparer avec mes valeurs ci-dessus

Pour 100000000, j'ai

[email protected]:~/Documents/Anonyme77$ time ./test

real 0m42.941s
user 0m42.879s
sys 0m0.032s

Ce qui semble être 20 fois moins rapide. Ceci dit sans doute dû à ton algorithme, je suppose...

[Anonyme77]

Fred: une chose auquel je n'ai pas pensé est de supprimer la boucle d'affichage des résultats. Je pense qu'elle doit prendre un temps non négligeable à s'exécuter.
Cecci dit, au point de vue de l'algorithme, je me suis plié à ce que l'on m'avait proposé à l'université, à savoir de vérifier si le nombre actuel est divisible par chacun des nombres premiers déjà généré. Si il ne l'est pas il est premier sinon ...

Toutefois pour l'interfacage avec le python, cela va obligatoirement le rendre plus lent et plus gourmant en RAM. En effet, même si la production était plus rapide, le python doit recevoir une chaine de caractère à découper pour obtenir finalement les chiffres.

Le soucis étant que cette production de la chaine de caractère nécessite beaucoup d'allocation et réallocation de mémoire (et donc beaucoup de temps processeur) et que de plus elle prendra beaucoup de temps à être envoyée d'un processus à un autre.

Je me plie donc à votre idée selon laquelle un seul langage sera plus rapide dans ce cas. J'avoue en fait ne jamais avoir vu les choses sous cet angle dans le passé. Merci beaucoup pour vos précieuses idées. Je trouve que notre échange sur ce sujet est très constructif .