El siguiente programa es esencialmente el mismo que el descrito here. Cuando funciono y compilar el programa utilizando dos hilos (NTHREADS == 2), consigo los siguientes tiempos de funcionamiento:Multi-threaded random_r es más lento que la versión de una sola rosca
real 0m14.120s
user 0m25.570s
sys 0m0.050s
Cuando es ejecutado con un solo hilo (NTHREADS == 1) veces, consigo corro significativamente mejor a pesar de que solo usa un núcleo.
real 0m4.705s
user 0m4.660s
sys 0m0.010s
Mi sistema es de doble núcleo, y sé random_r es seguro para subprocesos y estoy bastante seguro de que es no bloqueante. Cuando se ejecuta el mismo programa sin random_r y se utiliza un cálculo de cosenos y senos como reemplazo, la versión de doble subproceso se ejecuta en aproximadamente la mitad del tiempo como se esperaba.
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#define NTHREADS 2
#define PRNG_BUFSZ 8
#define ITERATIONS 1000000000
void* thread_run(void* arg) {
int r1, i, totalIterations = ITERATIONS/NTHREADS;
for (i = 0; i < totalIterations; i++){
random_r((struct random_data*)arg, &r1);
}
printf("%i\n", r1);
}
int main(int argc, char** argv) {
struct random_data* rand_states = (struct random_data*)calloc(NTHREADS, sizeof(struct random_data));
char* rand_statebufs = (char*)calloc(NTHREADS, PRNG_BUFSZ);
pthread_t* thread_ids;
int t = 0;
thread_ids = (pthread_t*)calloc(NTHREADS, sizeof(pthread_t));
/* create threads */
for (t = 0; t < NTHREADS; t++) {
initstate_r(random(), &rand_statebufs[t], PRNG_BUFSZ, &rand_states[t]);
pthread_create(&thread_ids[t], NULL, &thread_run, &rand_states[t]);
}
for (t = 0; t < NTHREADS; t++) {
pthread_join(thread_ids[t], NULL);
}
free(thread_ids);
free(rand_states);
free(rand_statebufs);
}
estoy confundido por eso que cuando la generación de números aleatorios los dos ejecución roscada realiza mucho peor que la versión de un solo subproceso, teniendo en cuenta random_r está destinado a ser utilizado en aplicaciones de subprocesos múltiples.
Ugh. Esto puede morder prácticamente cualquier estructura pequeña y densa de la que varios hilos van a intentar escribir en partes, ¿no? –
Gracias a un millón por su ayuda, nunca lo hubiera averiguado por mi cuenta. Ps. Trasladé los rand_states y rand_statebufs al hilo y recién inicié el generador de números aleatorios a partir de ahí. Lo cual también resuelve muy bien el problema de la memoria caché de una manera muy simple. – Nixuz
@Nicholas: Sí. Vale la pena no ser excesivo con la memoria. Eso sí, empacar sus asignaciones locales de hilos también puede ayudar. Thread-locals puede ser una gran victoria cuando se hace bien, ya que puedes evitar tanta contención de caché y bloqueo. –