Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#873 assertion !pthread_create(&thr->thrH, &attr, rout, arg) fail

Stable_(v3.10.x)
closed-wont-fix
5
2014-07-09
2012-11-25
Evren Yurtesen
No

In the 3.8.4 version the number of threads were scaled down if atlas was executed on a machine with less cores than the machine where it was compiled on.

However with 3.10.0, it seems to use a fixed number and it fails if the number of processors is not equal to or less than where it was compiled on. (more cores seems to work fine)

assertion !pthread_create(&thr->thrH, &attr, rout, arg) failed, line 111 of file /ATLAS/gnu/..//src/threads/ATL_thread_start.c

I guess one can argue that this is due to performance reasons, but well... I think I would like to be able to run my test programs with the same library on a different machine if I am not doing an actual production run.

Also, it would be nice if ATLAS could use an environment variable to control the actual number of threads it uses, similarly to OpenMP's omp_num_threads.

Discussion

  • No, ATLAS always used a fixed number of threads, 3.8 just didn't use affinity, which meant that a lib compiled for 4 cores could run on a system with 2 by having multiple threads/node.

    I switched to affinity because it turned out the OS was doing a terrible job, and robbing us of about 1/2 of our parallel performance, so it is here to stay.

    If you don't care about performance, it *may* work to tell ATLAS to use OpenMP for threading (which doesn't support affinity, and so should work lile 3.8) by throwing the -Si omp 1 flag to configure.

    As for dynamically changing the number of threads, that's been an feature request for several years, and cannot be supported under the current paradigm of threading without massive loss of performance. I'm contemplating a rewrite that would make it possible, but that is still in the future.

    Let me know,
    Clint

     
    • assigned_to: nobody --> rwhaley
     
  • Evren Yurtesen
    Evren Yurtesen
    2012-12-07

    I understand the performance reasons for using affinity. What about using OMP_PROC_BIND with OpenMP? I guess I will have to run some benchmarks :)

    I will try the -Si omp 1 when I have time. Thanks for the advice.

     
  • Evren Yurtesen
    Evren Yurtesen
    2012-12-07

    One more thing... wouldnt it be possible to detect number of cores and use whatever is available while threads still binding to them?

     
    • status: open --> closed-wont-fix
     
  • Since a workaround exists, I'm not going to fix this in 3.10. The problem will eventually be addressed in the forthcoming threaded rewrite happening now in the developer release, however,