LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (October 2002, week 1)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Sat, 5 Oct 2002 14:38:57 GMT
Reply-To:     Mauro Morandin <second_name@LIBERO.IT>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Mauro Morandin <second_name@LIBERO.IT>
Organization: TIN
Subject:      Re: SAS is slow? (cpu time, etc)
Content-Type: text/plain; charset=us-ascii; format=flowed

Puddin',

sometimes I'm right, sometimes I'm wrong. If my impression of SAS beeing an interpreter is wrong and you and others want to share your thoughts with me I am really grateful. I WAS WRONG on that, so what now?

I consider this newsgroup a valuable source of information where I can ask for help or share an experience. We all stand behind what we believe /percieve/think is true. But none of us has all the truth, especially in such complex matters as SAS internals. I haven't worked on SAS development so my only possible approach to it is a black box approach. I put something in, do some work, and see how fast it gets out. There is more truth behind a well designed black box stress test, than anything you could read in a book you buy in a bookstore, because what you read in a book may not be an impartial view of the subject.

As I said, I stand behind what I post to this newsgroup (there is my name, email, the company I work for) and so do many other beginner, experienced and SAS gurus like Dorfman, DeVenezia, Patridge, Ward, Cassell, Whitlock, Hermansen, Groeneveld, Whittington, ... sorry I can't name you all. I appreciate all the people who post to this newsgroup giving their real names and email addresses (it's a form of warranty), and I think that they should be free to bring up even unpopular arguments like ("SAS is slow") without beeing smashed by a horde of SAS evangelists.

You say: """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. """

I say: I was not criticizing SAS, but pointing out a weak point.

Let me tell you a brief story about the Windows/Linux debate: More or less two years ago, Microsoft was spending money to set up a set of benchmarks, which would prove without any reasonable doubt that NT was faster then Linux in a set of common tasks. They found that very set of tasks in which NT really ran faster than Linux and presented these findings to everyone, and thought they would regain market shares in the low end server market (this was during the 2.2 Linux kernel). What actually happened was that Linux developers said "Many thanks!" to Microsoft and improved the 2.4 kernel addressing all the weak points which have been found by Microsoft staff.

Even a smart product like SAS has some weak points and SI has always done a very good work listening carefully to it's customers in implementing new and improving existent features. Thinking about the person who recently asked for: "What makes SAS unique?" I would say that this makes SAS a unique product.

WRT performance there are a some possibilities to solve the problem using SAS tools --> SAS/SPDS, SAS/C+SAS/Toolkit.

Please accept my excuses for beeing a little bit rough with my comments on your comments. Sometimes my italian temperament takes over. It was not professional and it is not fair on a newsgroup to say: "Thou art stupid!". Surely you have more insight into SAS internals than I have (I have read through you past posts) and I would like to have your advice on forthcoming issues I may post to this newsgroup in the future.

Thanks. Ciao. Mauro.

Puddin' Man wrote: > Mauro, > > Very briefly, you refer to The SAS System as "an > interpreter", exhibiting an incredible misunderstanding of > the complexity of your subject matter. Even if your middle > name weren't "Flamebait", I wouldn't want anything > to do witcha. > > "I Deny The Troll!" and have nothing more to say ... > > Puddin' > > ****************************************************** > *** Puddin' Man *** Pudding_Man@lycos.com ******** > ******************************************************; > > > On Fri, 4 Oct 2002 21:06:34 > Mauro Morandin wrote: > >>Puddin' Man wrote: >> >>>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's not SAS, but the operating system which does that. >>The test is not necessary. If it would not deallocate the I/O buffers >>you couldn't run any software on your Windoze. Why do you want to find >>out if it deallocates immediately, I bet it doesn't. What are I/O >>buffers there for ... for beeing reused as many times as possible ... >> >> >> >>>>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. >>> >>You (not Puddin' man) are pretty stupid. >> >> >> >>>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. >> >>I surely agree. >> >> >>>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. >> >>SAS Institute consultants are pushing SAS to its limits every day, but I >>haven't found any of them on SAS-L, that's true, so might be that your >>guess of 1% is correct. >> >> >>> >>>>>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 ... >>>> >>You have no clue of what's going on in your PC. >> >>1. SAS uses your pentium 850Mhz CPU to do it's work. >>2. It reads 123Mbyte/s from main memory (this is SAS maximum speed for >>this CPU). >>3. It uses your FSB to do that. >> >>Given that you have a FSB of 100Mhz which is 32 bit wide your operating >>system is able to transfer data from memory to the CPU at the maximum >>theoretical limit of 400Mb/s. I bet that if you had a 3Ghz CPU with the >>same FSB than SAS would have reached this limit. >> >> >> >>>>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. >>> >>Again you should ask SI as to what exactly gets reported as CPU time. >>I have the experience that CPU time IS CPU time, so idle time (like I/O >>waits) is not in here. You find it added to the real time reported by >>SAS. Anyway, with SAS writing in asynchronus mode to the filesystem the >>real time figure is of no importance. >> >> >>>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. >>> >> >>SAS again doesn't measure anything, it takes this info from the >>operating system. SAS is not an operating system. It seems that you are >>mixing things up a bit. >> >> >> >>>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. >> >> >>It doesn't matter to me if your useless program runs faster with RDRAM >>or DDRAM .... >>Anyway, I bet you would see no difference because even this stupid and >>useless SAS program reads from memory slower than SDRAM speed. >>RAM speed increases OS and user interface performance (these are C >>programs which do a lot of memcopy() calls). >> >>Don't do system performance measures using SAS. SAS can't do anything. >>It wasn't designed to do that. But, of course, if all you have is a >>hammer, everything looks like a nail. >> >> >> >>> >>>>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. >> >> >>It happens that RAM speed, I/O and CPU speed grow steadily and are >>balanced by system designers. There is no system which can do everything >>equally well. >> >> >> >> >>> 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 >> >> >>-- >>mauro morandin >>SAS consultant >>red hat certified engineer >>mauro.morandin***************@ieee.org >> > > > > ____________________________________________________________ > Watch a championship game with Elway or McGwire. > Enter Now at http://champions.lycos.com

-- -- mauro morandin SAS consultant red hat certified engineer mauro.morandin-NOSPAM-@ieee.org

-- matrix srl via postioma di salvarosa 25b tel +39-423-724620 31033 castelfranco veneto (tv) fax +39-423-770798 http://www.matrix-online.it info-TAKEAWAY-@matrix-online.it


Back to: Top of message | Previous page | Main SAS-L page