Date: Fri, 25 Jul 2003 01:25:36 -0500
Reply-To: Serguei Ishchenko <sishchen@PRAIRIENET.ORG>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Serguei Ishchenko <sishchen@PRAIRIENET.ORG>
Subject: Re: computer requirements for sas 9
Content-Type: TEXT/PLAIN; charset=US-ASCII
Pavlo tuk kak tut :-)
It's nice to get couple of e-mails from two respected members of the list.
Finally, some relief from the "size matters" variety.
On Sat, 19 Jul 2003, Paul Dorfman wrote:
> >From: Serguei Ishchenko <sishchen@PRAIRIENET.ORG>
> Perhaps so. But you are not specifying what the people are using their
> computers for.
> >More than that, for cpu-bound SAS jobs
> Most real-world SAS jobs are not likely to be CPU-bound.
Exactly. That's why I wrote "cpu-bound". Even though most are not
cpu-bound, but there is a large enough class of SAS applications that
could benefit quite a bit from the sheer (and cheap) power of Intel/AMD
workstations. Even quite big i/o-bound jobs will run nicely on a
well-configured PC (like Jack Hamilton's. I wonder how much noise his
box makes). Personally, I haven't seen a SAS job yet that I could't run on
my own one (most likely at least as fast as on other computers I need to
use). But I have to admit: our datasets in the north are about 10 times
smaller on average, so I haven't experienced a real thing yet :-)
> >even a basic Athlon/P4 workstation could run circles around some "real
> >I've seen.
> First, even CPU-bound jobs beg some percentages, too. Not all of them are
> created equal. Windoze is hardly for jobs that can benefit from
> multiprocessing (even "hand-organized", meaning letting the machine run N
> batches simultaneosly, then combine the results). Neither 2000 nor XP is
> clever enough to distribute the workload between ever two CPUs. I've heard
> Windoze servers are smarter, but I am quite sure still quite dumb compared
> to, say, z/OS' Workload Manager. Secondly, whilst the statement that a
I think this is too strong a statement. I know Windoze is not perfect, but
on average it does benefit from SMP, whether it's Pro or Server OS (when
it runs cpu-hungry stuff). Now if it comes to mainframe job management,
from what I understand it will leave behind not
only Windows but also most if not all UNIXes. This is simply a different
league. All I was and am trying to say was that Wintel boxes got so
powerful and so much progress has been made in the last few years, that
some respect is due to both software and hardware.
> Corvette can run circles around a loaded tractor-trailer is certainly
> undisputable, I am not sure it proves anything... The former will certainly
> manage to drag a couple of posteriors and their attachments much faster -
> which utility, however not without a useful function, is somewhat limited.
> It cannot go off-road or haul a load much heavier than a golf bag. As you
> remember, in the beginning of the nineties, some enthusiasts who came up
> with the idea of tying 1000 Corvettes together with ropes, proclaimed the
> trucking industry dead and were quite surpised it did not happen.
Right. So, when I have a model to run, and it takes 10 hours of mainframe
cpu time, and 2 hours of PC wall time, that's when I say PC runs circles
around the mainframe.
> >512MB memory is plenty enough for SAS V9 / Windows workstation.
> I do not think so, unless SAS is the only major application running there -
> which is almost never the case. I would leave at least 512 of *spare* memory
> for SAS alone in the anticipation of such things as Summary with way too
> many distinct CLASS values and especially the forthcoming explosion of hash
> table usage in V9.1.
Nah. The hash table concept will need some time to catch the attention of
most SAS users. And from what was written in the original post, 512MB
should do just fine. As compared to 512MB in a server spec that I've seen
not so long ago. Oh my.
> Returning to the question of OSsa, I am intrigued by the Apple's new 2-way
> G5, whose performance, compared to any W-machine, proves that a high clock
> speed per se is pretty much the same as high RPMs in an engine disconnected
> from the wheels. I do not have one [not in the budget :-(], but the pure
> perception I got from playing with it for a short time is not unlike that of
> getting out of Taurus and making yourself comfortable in Lexus LS430. If I
> had one, I would definitely see if V9.1 could be successfully installed and
> run on the machine via an virtual emulator. If someone has tried, please
Interesting. Maybe it could, but I bet for the same money one could set up
couple of good PCs, that would in native mode fare quite nicely compared
to emulation, and still have some change left in one's pocket.
> Kind regards,
> Paul M. Dorfman
> Jacksonville, FL
> P.S. Serega, soglasis', chto W - eto vse-taki govno - pravda, deshevoe i v
> bol'shom kolichestve ;-). Privet sem'e. P.
Pasha, vzaimno. I hope to see you in Montreal next spring. And I hope you
choose a Corvette and not a tractor-trailer to get there :-)
> >Sigurd Hermansen <HERMANS1@westat.com> wrote:
> >: Your question ties into earlier questions about SAS performance under MS
> >: Windows. While the small marginal cost of adding memory to a PC supports
> >: idea that you cannot have too much memory, MS Windows machines may 1)
> >: to allocate memory as the SAS System requests, 2) fail to recover memory
> >: from closed processes, or 3) under the SAS System fail to manage
> >: memory correctly. I know that MS Windows XP fails to recover memory
> >: effectively (if you leave an XP machine running for an extended period of
> >: time, performance of all applications degrades). In contrast to Unix, MS
> >: Windows OS's work better when you turn them off! Whatever the cause, all
> >: Windows SAS machines at times take much more time than expected to run
> >: processes that should run quickly were memory capacity used effectively.
> >: All this means that you may not gain that much in performance by stepping
> >: from minimal 256MB RAM to 512, but it won't cost that much and could help
> >: new service packs improve memory allocation methods. The 128 VRAM also
> >: appropriate. I suspect that within a couple of years standards for memory
> >: will jump up above 2GB. You'll probably need new machines to make good
> >: of that configuration. On our SAS servers we are specifying a separate
> >: for the work directory as well as 2GB RAM. That configuration does make a
> >: substantial difference in performance, but not in the range of data
> >: that you anticipate.
> >: Adding extra memory to MS Windows machines sometimes has an odd effect.
> >: far as I can determine, the OS calculates by default the swap file size
> >as a
> >: linear proportion of memory. At times management of a large swap size
> >: appears to swamp the machine. Others may have a better explanation of
> >: is happening under XP.
> >: Sig
> >: -----Original Message-----
> >: From: Gail Rogers [mailto:gail.rogers@TUFTS.EDU]
> >: Sent: Thursday, July 10, 2003 12:42 PM
> >: To: SAS-L@LISTSERV.UGA.EDU
> >: Subject: computer requirements for sas 9
> >: Hi All,
> >: We are in the process of purchasing new computers (windows XP OS) with
> >: the expectation of running SAS 9 on them. I've read the windows
> >: requirements for SAS v9 documentation (32 and 64) and have an idea of
> >: what we are going purchase but I'm a little stuck on RAM and VRAM
> >: recommendations. We typically use SAS graphics/fsp/stat/ modules with
> >: usually no more that 50,000 cases and 300 variables and I don't think we
> >: are planning to immediately use 64 bit stuff. I'm leaning toward 512 MB
> >: RAM and 128 V RAM but am wondering if that is enough. If you are using
> >: SAS 9 in a windows environment could you email me your thoughts on how
> >: it handles under your RAM and V RAM specs and what your opinions are
> >: regarding the appropriate amount?
> >: Thanks!
> >: Gail
> >: --
> >: Gail Vanca Rogers
> >: Sr. Statistical Programmer
> >: Epidemiology Program
> >: USDA-HNRC at Tufts University
> >: email: Gail.Rogers@tufts.edu
> >: voice: 617 556-3338
> >: fax: 617 556-3344
> MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.