Ik liep een aantal tijdstippen in mijn code om te zien welke van de verschillende functies was de beste en ik heb steeds een aantal vreemde resultaten. Hier is de code die ik heb gebruikt:

static double time_loop(int (*foo)(int)) {
	clock_t start, end;
	int n = 0, i = 0;
	start = clock();
	for (; i <= MAXN; i++)
		if ((*foo)(i)) n++;
	end = clock();
	if (n != 50847534)
		return -1;	// Error
	return ((double) (end - start)) / CLOCKS_PER_SEC;
}

static double median3(int (*foo)(int)) {
	double t1 = time_loop(foo);
	double t2 = time_loop(foo);
	double t3 = time_loop(foo);
	printf("  ((%f %f %f))\n", t1, t2, t3);
	int errors = 0;
	if (t1 < 0)
		errors++;
	if (t2 < 0)
		errors++;
	if (t3 < 0)
		errors++;
	if (errors > 0)
		return -errors;
	if (t1 > t2) {
		if (t2 > t3)
			return t2;
		return t3 < t1 ? t3 : t1;
	} else {
		if (t1 > t3)
			return t1;
		return t3 < t2 ? t3 : t2;
	}
}

  ((4.560000 3.750000 6.540000))
Original: 4.560000 s
  ((4.920000 3.760000 6.690000))
Original: 4.920000 s
  ((4.190000 3.750000 6.620000))
Original: 4.190000 s
  ((3.820000 3.130000 5.640000))
New:      3.820000 s
  ((3.580000 3.150000 5.580000))
New:      3.580000 s
	  ((3.670000 3.140000 5.510000))
New:      3.670000 s

Kun je post de code voor de functie foo.

for (; i <= MAXN; i++)
		if ((*foo)(i)) n++;

Meer vragen. Wat voor soort systeem gebruikt u? Welke OS?

Het zou leuk zijn om te zien wat foo doet en je kunt gprof gebruiken voor profilering uw code om erachter te komen waarom sommige gesprekken zijn langer duurt.

Niets grappig, net beetje manipulatie en toegang tot een grote array. De functies zijn allemaal gelijk en allemaal weer dezelfde resultaten, hier is een voorbeeld:

#define GET(b) ((sieve[(b)>>5]>>((b)&31))&1)
static int isprime3(int p) { return (p&1) ? p > 2 && !GET(p >> 1) : p == 2; }

	printf("New:     %f s\n", median3(&isprime3));
	printf("New:     %f s\n", median3(&isprime3));
	printf("New:     %f s\n", median3(&isprime3));

Oorspronkelijk geplaatst door jim McNamara Ik toevallig niet op de statische verklaring van functies, zoals voor een aantal redenen, behalve in bepaalde gevallen - maar dat is zeer waarschijnlijk niet de oorzaak van dit probleem.

Met betrekking tot statische functies:
Ik neem aan dat dit komt omdat de C99 standaard weinig over uitvoeringsprogramma van statische tekst, met uitzondering van wijzigingen in de consolidatiekring zegt --

In grote enkel bestand programma's met veel statische functies gemengd met automatische functies --
Ik heb echt encounteered obscure problemen in gcc 3.1, cc op HP UX 11.1. Bijvoorbeeld een automatische functie niet helemaal uitgevoerd. Klinkt vreemd, maar het is waar. Dezelfde "geërfd programma ontwerp" ook verpest door optimalisaties dwingt de compiler om besluiten was het niet verwacht te maken - volgens de HP compiler team te maken toch.

Principe het oplossen van de problemen die ik had om volledig uit te schakelen optimzation, en verklaren alle functies statisch juiste resultaten te krijgen. Aangezien een vaste makefile is een vereiste voor de gehele applicatie suite, betekende dit een grote herschrijven voor een aantal zeer grote programma's.

Uw probleem is niets zo. Het is bijna te cache-gerelateerde Gebaseerd op wat u hebt gezegd over je hardware, als je om je stuk 125MB van gegevens in 21 ~ 6MB brokken, dan iterate (1,2,3) over elke deelverzameling brok het probleem niet zou worden daar. Als het cache verband - en met geen andere opmerkingen te werken aan dat zou mijn gok.