Well, it appears that our subject line has been usurped ... :-)

Re: SAS is slow? (cpu time, etc)

On Wed, 2 Oct 2002 13:34:21 John Whittington wrote: >At 10:19 01/10/02 -0500, Puddin' Man wrote: > >>This appears to be correct. I restart SAS, read the >>data from the hard drive, and it takes 4 seconds. >>100 mb / 4 secs is about 25mb/sec, which is in line >>with my expectations of hardware performance. > >As you say, that seems to 'add up'.

Yes, I think SAS did quite well with this little micro-test. I'm pleasantly surprised that Win/SAS was evidently able to dynamically allocate the large memory buffer as needed. Might run a little test or 2 to see if it deallocates properly if I find the time <g>.

>It also reinforces the fact that >anyone who expends appreciable time/effort writing programs (in C or >whatever) to try to improve upon that performance is really being pretty >stupid, since it's obvious that NO software can make hardware go faster >than its theoretical maximum.

Oh, I wouldn't go so far as to say "stupid". And I think Paul's micro-test has somewhat limited relevance to a broader class of computer applications.

In general, I don't think it makes sense to criticise SAS because one can allegedly write a specialized program for a very specialized task which runs faster than SAS. Consider for a moment the incredibly broad cross-section of users, applications, platforms, etc that SAS was designed for. There are so many different types of utility that can be derived from the various SAS products that it boggles my po' mind.

The primary benefit I perceive from using SAS is the minimization of development/testing time with attendant ability to maximize system efficiency within the limits of the software architecture. I think this was a primary objective in the design of SAS.

As such, performance comparisons between SAS and, say, a custom-coded 3gl program have very, very limited relevance for po' me. Brings to mind comparisons between apples and oranges. Or even tricycles and M-80 tanks. If I were forever responsible for only one specialized application that strained properly tuned system resources to the max _and_ for which SAS performance was unacceptable, then by all means, I would seek another way to do it. I doubt that such a scenario accurately describes the work responsibilities for even 1% of sas-l folk.

>>Even with the 100+mb memory buffer, it's curious >>that cpu time = wall-clock time because my 850mhz cpu >>is allegedly running 8.5 times faster than my >>100mhz FSB (memory bus). Oh, well ... > >This, I guess, is the oft-repeated discussion as to exactly _what_ gets >reported as 'CPU time'.

Appears to be. More below ...

On Wed, 2 Oct 2002 06:40:22 Tim Churches wrote: >Puddin' Man wrote: >> Even with the 100+mb memory buffer, it's curious >> that cpu time = wall-clock time because my 850mhz cpu >> is allegedly running 8.5 times faster than my >> 100mhz FSB (memory bus). Oh, well ... > >Hardware and OS experts can correct me here, but I don't >think that Windows or any other OS counts the time which >the CPU spends waiting for memory as idle time.

That appears to be the case for my little Whinney-Doze. Of course, this means that "cpu time" doesn't necessarily measure cpu cycle consumption correctly.

I would _hope_ that certain hard-core multi-user systems (i.e. MVS, OS/390, Z/OS) would do a better job with this. Perhaps "La Unices" as well?

>What would be really interesting would be to repeat the test >on three systems with identical Pentium 4 CPUs, but one with >slower SDRAM and one with much faster (throughput) RDRAM, >and one with DDR RAM.

Yes, that should be interesting.

>With gigahertz CPU speeds and the ability >cache significant amounts of data in RAM, memory bandwidth >and latency, not just disc I/O speed, really start to matter >again.

For systems where the memory bus is slower than the internal cpu speed (virtually all systems nowadaze), methinks it has _always_ mattered. At least in the Intel world, this importance has been mitigated somewhat by increasing cpu cache sizes. Modern Pentium L1 and L2 caches are "on-die" and run at the speed of the cpu. With larger L1/L2 architectures, memory accesses are less frequent.

Zalut, Puddin'

****************************************************** *** Puddin' Man *** Pudding_Man@lycos.com ******** ******************************************************;

"Man in a suit with a bow-tie neck wanna buy a grunt with a third-party check!" from "Willie The Pimp", Frank Zappa, maybe 1968

____________________________________________________________ Watch a championship game with Elway or McGwire. Enter Now at http://champions.lycos.com