New comment by tornaria on void-packages repository https://github.com/void-linux/void-packages/pull/29635#issuecomment-808792043 Comment: > Maybe I'm misinterpreting this? > > ... > // *** Warning: increasing stack size to 1024000. > *** the thread stack overflows ! > current stack size: 512000 (0.488 Mbytes) > [hint] set 'threadsizemax' to a nonzero value in your GPRC > *** matdet: Warning: increasing stack size to 2048000. > *** at top-level: matdet([-10,-7,6,-7,1,4,-1,-2,-2,-5,1,7,-6,7,- > *** ^---------------------------------------------- > *** matdet: the thread stack overflows ! > current stack size: 512000 (0.488 Mbytes) > [hint] set 'threadsizemax' to a nonzero value in your GPRC > *** the thread stack overflows ! > ... I think you are confusing the actual stack used by the cpu, with the pari stack where computations are done (this is the basic design of pari using a stack for allocations instead of GC, etc). Usually (with single threaded pari) when the stack overflows pari doubles the stack and retries the computation. I think this already happened for this test. However it seems that in multi-threaded pari the doubling-the-stack behaviour is limited by `threadsizemax` (I guess to avoid using up a lot of memory), so the stack size, originally at 512K, is increased to 1024K, but `threadsizemax` prevents that (note that the second time the current stack size is still 512K). I will have a look into this. It might be: (a) that the particular computation giac is doing in this test is hard and it really require more than 512k of stack (b) there's a "bug" in pari, maybe some routine in pari is not checking the stack to reallocate often enough so it ends up not working in limited stack space. Regarding pthread pari: I'd like to discuss a bit more what's the right way to proceed. Indeed for lots of applications having a pthread pari is a good thing (I use a 36-core machine for my computations so I'd definitely take advantage of this). However, I've noticed a slowdown by a factor of 2 with pthread pari in some of my computations, so I often use single-threaded pari and arrange my computation so it can be done by 36 independent pari processes. I think the reason is that TLS is _slow_. I wonder if it would make sense to offer different versions of pari (single thread / multi thread). At the very least, I'd make pthread a build option so that one can easily compile one or the other as needed. More generally: in math software is often important to have different versions of the same software available. I don't know if there is a reasonable way to offer this in void. Also might be desirable: offering a way to compile math software with -march=native so it can take advantage of avx, etc. Is there a way void could support something like "subarchitectures"? Say `x86_64-avx` where some packages are compiled for this architecture and the rest default to the packages for `x86_64`.