Use the same batch size threshold for enabling OpenBLAS and disabling ggml threading

[Piezoid]

Commit 4640eff disabled ggml's multi-threading when OpenBLAS is used for processing large prompts.
This avoids running two thread pools at the same time.

However, OpenBLAS is used by ggml on tensors with dims >= 32, but llama.cpp only reduce the number of threads for batch size > 255.

See also this discussion: #229 (reply in thread) and issue #578

[linouxis9]

I confirm that your branch fixes the issue I had in the aforementioned discussion and in issue #578. Thank you @Piezoid!!

[ggerganov]

@linouxis9 Does this improve the performance on your machine for processing the initial prompt when it is larger than 31 tokens and less than 256?

[linouxis9]

It's slightly faster @ggerganov than no BLAS (34s vs 40s for initial ingestion on llama-30B with the new chat example), but it heavily depends on the number of threads chosen and batch sizes. And, I'm having a hard time properly finding out the best parameters to evaluate the performance (number of BLAS and of ggml threads, batch sizes...) and monitoring the speed of each run.
In any case IMHO, this PR is needed to fix the discrepancy of check inside ggml and llama.cpp (to avoid having both ggml threads and BLAS threads spawned at the same time) when b >= 32 and b < 255 even until we find the proper b before switching to BLAS.

[rabidcopy]

This seemed to provide a small but noticeable bump in performance for me.