Add minimum threshold for number of buffers

[brada4]

And dont break expectation that single-thread version can work in many threads.
#1847

[martin-frbg]

Also related are #938, #1141 - though it could be that is it ultimately the GEMM buffer handling that needs looking into.

[brada4]

Yes, it is wiping dirt under doormat type of solution.

[martin-frbg]

Not sure if we want to go all the way to 64 as at least with the non-tls implementation this will actually have an impact on memory requirements ?

[brada4]

Just in memory.c

#endif /* defined(SMP) */
    local_memory_table = (struct alloc_t **)malloc(sizeof(struct alloc_t *) * NUM_BUFFERS);
    memset(local_memory_table, 0, sizeof(struct alloc_t *) * NUM_BUFFERS);
#if defined(SMP)

i.e more 62 64-bit pointers (496 bytes) get pre-allocated for 1-CPU version

[martin-frbg]

Yes, but that's the experimental TLS version you are looking at - pretty sure that in the other/older/default implementation it corresponds to an actual allocation.

[brada4]

The "old" version
(8+8+8+8+48)*62=4960

static volatile struct {
  BLASULONG lock;
  void *addr;
#if defined(WHEREAMI) && !defined(USE_OPENMP)
  int   pos;
#endif
  int used;
#ifndef __64BIT__
  char dummy[48];
#else
  char dummy[40];
#endif

[martin-frbg]

Just looking for reasons why nobody tried to uncouple NUM_BUFFERS from NUM_CPU (NUM_THREADS) before, although this problem has come up in some form or other every few months in the past years.

[brada4]

I think it is buffer (me) or two (formula there) per thread, the big issue is that single-threaded version depends on this structure at all.