topic Re: Processor speed vesus multi-threading in SAS Procedures

Processor speed vesus multi-threading

awesome_opossum — Fri, 28 Apr 2023 13:27:14 GMT

Hi all, I'm not really sure where to put this because it's kind a broad, maybe somewhat more of a general computer science question than a SAS question per se. Basically I've been charged by my organization to decide what computer system would be best for running some of the notorious hogs such as GLIMMIX.

In reading, while there's a number of Base and SAS/STAT procedures that permit multi-threading and parallel processing, many do not, such as GLIMMIX, which can only run on a single processor (except perhaps along with some sort of macro--that I do not know even exists or is possible for GLIMMIX, but also I'm not exactly keen on using or getting into macros).

Thusly I have a sort of two-part assumption: 1) multiple processors lend no advantage to some procs we desire to use, as GLIMMIX, may be helpful for others like SQL, GLM, MIXED and so forth, 2) and this is a gross assumption on my part, a FASTER processor (as in, say 3.60 GHZ vs. 2.8 GHZ), as compared to multiple processors, may be more helpful for use of something that can only run on a single processor, like GLIMMIX. Is this correct?

More broadly, do you have any other recommendations to maximize computational performance in SAS? I understand, as with processors, it may depend on how SAS itself was written, hence my asking the community here. But again, I'm no computer scientist, so I'm trying to be careful about assumptions.

Thanks in advance!

Re: Processor speed vesus multi-threading

sbxkoenk — Fri, 28 Apr 2023 16:20:16 GMT

Hello,

I am also NO hardware / infrastructure / architecture guy ...

Just this :

PROC MIXED (and PROC HPMIXED) is already having a CAS-enabled "equivalent" being PROC LMIXED. SAS R&D is currently working on a CAS-enabled equivalent / alternative for PROC GLIMMIX as well. Not sure when that one will be released.
Sometimes people use PROC GLIMMIX because they use this procedure all the time. Often, many of these models can also be fit with other procedures (PROC CPANEL , PROC GENSELECT , PROC LOGSELECT ... to name only a few that are also CAS-enabled procedures)
Processor speed is important, but ... if tables are not uploaded in memory ... disk speed is extremely important as well.
Here's a paper on recommendations for circumventing memory problems and reducing execution times for your mixed modeling analyses (including glimmix analyses).
Paper 332-2012
Tips and Strategies for Mixed Modeling with SAS/STAT® Procedures
Kathleen Kiernan, Jill Tao, and Phil Gibbs, SAS Institute Inc., Cary, NC, USA
https://support.sas.com/resources/papers/proceedings12/332-2012.pdf

Koen

Re: Processor speed vesus multi-threading

SASKiwi — Fri, 28 Apr 2023 22:36:55 GMT

Are you referring to server-based SAS or PC SAS? For computationally-intensive and IO intensive applications, server-based SAS will typically run a lot faster. Also I'd suggest running these jobs in batch-mode outside business hours to avoid impacting other users too much. If your jobs run after-hours when no other users are running anything, then tweaking SAS for ultimate performance becomes less important.

Re: Processor speed vesus multi-threading

Patrick — Sat, 29 Apr 2023 03:07:56 GMT

"Basically I've been charged by my organization to decide what computer system would be best for running some of the notorious hogs such as GLIMMIX"

I guess that would result in selecting/changing the platform. Given this would likely also have licensing implications I feel best would be to contact SAS directly with such a question.

Besides of single threaded vs. multi-threaded you will also need to determine if your processes are mostly CPU bound or I/O bound. Often I/O is the bottleneck (network, disk).