At 11:32 AM +0200 5/22/06, BankHacker wrote: >> Hey nice work! It seems the problem is bracketed into glibc random_r >> and rand in the dynamic lib. > >Yes. Is it possible to debug glibc in order to find out what is the >source of the slowdown? Yes, but I don't think you have the chops to do it. I'd certainly have a tough time if I were to try. >On the other hand, I have install single-cpu kernel for FC5. >Beforewards I was working with SMP version because of the >Hyperthreading. Now it runs single cpu kernel and the results are the >same or similar: > ># ./dynamic-test-cpu-2 >Reservado 0.1 Gb de memoria en 0.000 s. >Escritura sobre 0.1 Gb de memoria en 0.600 s. >10 M de rand() en 45.560 s. (ejemplo.: 1997016613) >10 M de sqrt(i) en 0.210 s. (ejemplo.: 3162) >10 M de log(i) en 9.420 s. (ejemplo.: 16) >10 M de log10(i) en 9.520 s. (ejemplo.: 6) >LINUX: 10 M de random() en 38.900 s. (ejemplo.: 1682960195) >LINUX: 10 M de random_r() en 19.610 s. (ejemplo.: 1997016613) >LINUX: 10 M de lrand48() en 31.240 s. (ejemplo.: 627140866) > >Do you think Hyperthreading could be responsible of the slowdown? No, you've tried the UP kernel and it didn't affect the problem, thus HT is eliminated. Also, it doesn't have anything to do with the possible threading-related locking issue in glibc. Locking is needed whenever there are multiple threads, even on a single processor, though such locking issues show up more frequently with SMP / HT. If your program is really single-threaded, then locking is not needed for the random-related data structures. If it is locking anyway, that might be the cause of your slowdown. Now is the time to move to asking the developers for help. File a bug against glibc in bugzilla. Include your source code as an attachment. ____________________________________________________________________ TonyN.:' <mailto:tonynelson@xxxxxxxxxxxxxxxxx> ' <http://www.georgeanelson.com/>
