What exactly are you trying to evaluate?
Libraries that use PolyesterWeave.jl (this includes, among others, Polyester.jl and LoopVectorization.jl) use PolyesterWeave.request_threads to get the threads they are allowed to run on. This will make sure they do oversubscribe.
E.g., if you run Octavian.matmul from inside @batch, it’ll probably be single threaded. But if you run it from toplevel, it’ll be multithreaded.
At one point, Polyester supported reserving threads per threads (e.g., if you have 16 threads total, it’d like you run 4 threads, that each have 3 extra ones reserved the others do not have access to). I didn’t want to keep maintaining that code, so I eventually took it out, but if someone wants something like that, I’d be happy to explain how to add support for this once again.
None of these libraries will work well when mixed with Threads.@threads or Threads.@spawn, however.