Date: Mon, 15 Jun 2009 12:24:08 -0400
Reply-To: Paul Dorfman <sashole@BELLSOUTH.NET>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Paul Dorfman <sashole@BELLSOUTH.NET>
Subject: Re: How Green is your SAS Code?
Tom,
I have no issue with anything you say here (except for one point I will
elaborate on below; and the fact that I truly have no idea what the
sentence "That's an interesting perspective considering its coming from
one who has the most to lose from a few inches rise in sea level ;-)"
really means - only being able to interpret the smiley as your evaluation
of the strength of the causal link between the area of St.Augusine Beach
and one's adroitness at tuning SAS programs). If you are saying that your
are a SAS performance nut, I can tell you that we share the same cuckoo
nest, and I have a track record and a few testimonials of folks much saner
than me to prove that.
I feel, though, that I have failed to make my point sufficiently eminent:
There are plenty excellent reasons to program with efficiency in mind, all
the more that most of the time, it costs next to nothing compared with
sloppy programming. You have named many of them, and I could add that one
of my own reasons is pure aethestics, even if it (at the first,
superficial, glance) may sound somewhat impractical. However - and this is
my point - it never occurred to me to think of computer performance in
terms of saving electricity or to justify the former by the latter simply
because, short of turning the computer off (in which case there is nothing
to talk about), there exists no correlation between the two.
A faster running program may consume less energy - or more, depending on
how much faster it needs to be, the underlying algorithm, hardware, and a
myriad of other factors on the path from the SAS program to the kWh-meter,
too numerous to account for. That is why, when I first saw the performance
paper authored by the fine duo of Mikes (gentlemen whose sense of humor I
have had many opportunities to personally appreciate) I decided that the
title had been chosen with tongue in cheek - especially given Mike
Raithel's long history of humorous SAS presentations. Amused by the clever
boarish title, I perceived the entire summary in the same spirit, and the
occasional reiteration of the word "energy" in the rest of the paper (as
always, superb) - as part of the distraction strategy, lest the reader
should get bored.
Now, you write "That is why I think its important that we all realize that
every bit counts". First, I would agree with the modified notion that
every *significant* bit counts, where "significant" refers to the
reasonable cost of dealing with the potentially wasteful bit; however, as
stated, the notion is immediately knocked down by the universally
applicable PEB principle, thus automatically invalidating the stated
importance to realize that it is true.
Finally, one general consideration. I would speculate (note: I did not
say "think") that it is likely that under certain circumstances, a modern
mainframe machine would be more energy efficient than any other machine
(or, especially, a collection of machines) bearing the same workload. This
speculation is based on two considerations. First, no computer is
automated and self-monitored as well as a mainframe. Second, it follows
from the general engineering principle that one large, centrally-
controlled unit is more efficient that a number of units bearing the same
workload in the same manner. For example, freight train's efficiency per
unit of load carried is times greater than than of a big rig. And, in the
computer world, mainframe is a freight train.
Having said that, a disclamer: I have absolutely, positively no intent to
start any sort of mainframe vs whatever vs whatever flame or unproductive
discussion here.
Kind regards
------------
Paul Dorfman
Jax, FL
------------
On Fri, 12 Jun 2009 12:18:53 -0700, The Architect
<thomas.michael.skinner@GMAIL.COM> wrote:
>On Jun 12, 1:43 pm, sash...@BELLSOUTH.NET (Paul Dorfman) wrote:
>> Mike,
>>
>> I hardly need to prove to you that SAS programming efficiency is not a
>> subject completely foreign to my heart.
>>
>> Having disclaimed that, methinks the entire idea of going after energy
>> efficiency with machine programming efficiency is wrongheaded because it
>> squarely fits into the inviolable PEB principle (aka the general
principle
>> of a Pimple on an Elephant's Butt). If you wanted to address the
>> elephant's obesity problem, would you start spending a month with a
loupe
>> in order to find and eliminate an asswart or rather begin with reducing
>> his ration in half? PEB has many important corrolaries, among them:
>>
>> 1) An attempt to address a problem worth 1 million TU (trouble units) by
>> reducing its size by 1 TU will cost more than 1 TU
>> 2) If there exists a way of reducing the problem by 250k TU, spending
>> resources to reduce it by another 25 TU is most likely unproductive
>>
>> Getting back to computing and energy/fossil fuel consumption, at least
90
>> percent of computer programming personnel - let us say 2000 people for
my
>> average client - have absolutely no need to be physically present in
>> office to do their jobs. Imagine that they were let to work from home
>> instead via thin clients. Down with 200W PC+monitor and 1kW for lighting
>> and HVAC - 2.4MW saved. Down with commute - 4000 gallons saved daily
based
>> on 2 gallons per soul.
>>
>> Now suppose we have a goal to improve general execution clock and/or CPU
>> time by 5 per cent across the org. First I will posit it to you that it
is
>> impossible overall. It can be done at the level of a single individual
or
>> a group of like-minded individuals, but not on the average for a large
>> group of heterogeneous programmers under the circumstances when their
>> programming efficiency runs far ahead of machine efficiency. Just
imagine
>> what it will take merely to monitor who writes efficient programs and
who
>> is not. Also take into account that most people using SAS in the org are
>> not programmers at all, and their only reaction to any efficiency
question
>> could be at most "Huh?!".
>>
>> Second, I will posit that one would be hard pressed to even discover
clear
>> correlation between clock/CPU time and energy consumption (and even the
>> lofty goal of 5 per cent were achieved, the correlation will be likely
>> nill).
>>
>> But let us say for the sake of the argument that there is 100 percent
>> positive correlation. Now what is 5 per cent saved at the expense of
great
>> strides made to make a large number of people program more efficiently
>> (such effort has its latent energy costs, too) compared to saving
>> virtually 100 per cent at the expense of virtually nothing? Right, the
>> pimple on we know what.
>>
>> I probably pay much more attention to machine performance in my own
>> practices than the PEB principle warrants, so it is not surprising that
I
>> have read yours and Mike's "You Might Be a SAS(r) Energy Hog If..." with
>> obvious interest. In the light of dubious correlation between being a
>> somewhat inefficient programmer and being an energy hog (or, conversely,
>> between my programming practices and local hurricane activity), I find
>> your usage of the verb "might" , even more conditional that its
>> infinitive, quite apt in the context.
>>
>> Kind regards
>> ------------
>> Paul Dorfman
>> Jax, FL
>> ------------
>>
>> On Fri, 12 Jun 2009 08:40:38 -0400, Michael Raithel
>>
>>
>>
>>
>>
>> <michaelrait...@WESTAT.COM> wrote:
>> >Dear SAS-L-ers,
>>
>> >Long-time SAS-L-er Tom Skinner began the following interesting thread:
>>
>> >> I was reading an interesting story in Forbes (see:
>> >>http://www.forbes.com/2009/05/15/software-energy-enterprise-te
>> >> chnology-cio-network-software.html
>> >> ) about the efforts to green the IT Data Center by reducing
>> >> power consumption and the Carbon footprint, but the gist of
>> >> this story was more about what does your legacy code cost you.
>>
>> >> I thought it would make a good topic to discuss here as many
>> >> folks certainly make it their business to code the most
>> >> efficient code they can for expediency of business processes.
>> >> I have spent a good bit of my career lspecializing in
>> >> performance monitoring, platform tuning and CPU utilization,
>> >> and helping others to right size their computing platforms.
>> >> So I wonder to what extent you and others in your
>> >> organization have looked into efficiency as a corporate or
>> >> organizational mandate.
>>
>> >> I'd like to hear everything there is to know, including all
>> >> sorts of platform and integration issues ranging from disk
>> >> drives to CPUs and from I/O to "in memory" techniques. What
>> >> gets you the most bang for buck?
>>
>> >> Are there any subsystems or components of SAS you find
>> >> especially thrifty or greedy? Have you found alternatives to
>> >> SAS code that provide efficiency gains?
>>
>> >> Lets share our knowledge and experiences,
>>
>> >Tom, great topic; and one that is near and dear to my heart!
>>
>> >I made my mainframe DBA and then my SAS bones tuning computer
>>
>> applications so that they approached the minimum amount of computer
>> resource consumption necessary to get the related unit of work done. In
>> fact, that is the topic of my first book-and-a-half (half-book, because
it
>> was a second edition of the first book). Like you, I have spent a lot
of
>> my career performance monitoring, platform tuning and CPU utilization,
and
>> helping others to right size their computer applications. It is a
blast!
>>
>> >Overall, I think it is much better for SAS programmers to learn
>>
>> efficiency techniques up-front so that they can make them a normal part
of
>> how they code. To me, that is a better approach than having to go back
>> later and rewrite applications. And, it silences the gadfly's who posit
>> that the price of memory/disk/processors/etc. are coming down so quickly
>> that people do not have to be concerned about how much corporate
computing
>> resources they consume. Ah; those people have provided me with a G-R-E-
A-
>> T career!
>>
>> >So, here is a paper that fellow SAS-L-er and SAS Mecca colleague Mike
>>
>> Rhoads and I presented at SAS Global Forum 2009, in our big back yard:
>>
>> >You Might Be a SAS(r) Energy Hog If ...
>>
>> >http://support.sas.com/resources/papers/proceedings09/041-2009.pdf
>>
>> >...to move this thread further along.
>>
>> >Tom, best of luck in all of your endeavors!
>>
>> >I hope that this suggestion proves helpful now, and in the future!
>>
>> >Of course, all of these opinions and insights are my own, and do not
>>
>> reflect those of my organization or my associates. All SAS code and/or
>> methodologies specified in this posting are for illustrative purposes
only
>> and no warranty is stated or implied as to their accuracy or
>> applicability. People deciding to use information in this posting do so
at
>> their own risk.
>>
>>
>>
>>
>>
>> >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >Michael A. Raithel
>> >"The man who wrote the book on performance"
>> >E-mail: MichaelRait...@westat.com
>>
>> >Author: Tuning SAS Applications in the MVS Environment
>>
>> >Author: Tuning SAS Applications in the OS/390 and z/OS Environments,
>> Second Edition
>>
>> >http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172
>>
>> >Author: The Complete Guide to SAS Indexes
>>
>> >http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409
>>
>> >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >Reality is that which, when you stop believing in it,
>> >doesn't go away. - Phillip K. Dick
>> >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- Hide
quoted text -
>>
>> - Show quoted text -- Hide quoted text -
>>
>> - Show quoted text -
>
>Paul,
>
>That's an interesting perspective considering its coming from one who
>has the most to lose from a few inches rise in sea level ;-)
>
>I can understand that from the perspective of coding one off
>investigations and small tasks that makes a lot of sense, but consider
>that the size of datasets has grown tremendously over the last decade
>and even small things like testing code for logic and syntax by
>limiting nobs is a usefull productivity technique for both the
>programmer and the systems.
>
>It reminds me of my first corporate job at Nielsen Media where in the
>first week I bacame the Number one CPU user. The honor garnered me an
>invitation to meet with Director of Operation, not an altogether
>unpleasant experience as the face to face was conducted on a Friday
>evening at the Original Hooters on Gulf to Bay Blvd in Clearwater.
>After giving a brief explanation of what I had accomplished through
>the use f Macros and other code generation techniques, the
>conversation soon turned to his instructing me n the proper technique
>for eating chicken wings... It was a bit of a distinction for me as I
>was well aware of the immense computing resources that Nielsen was
>known for, often being the first in line for the latest model of Big
>Blue Iron.
>
>I retained that crown for some time, performing such feats of
>spectactular coding wizardry ias building a prototype of a minute to
>minute ratings system for the NYC market. In order to get a time slot
>in a queue for that processing to happen, I had to be efficient. Now
>prototyping is one thing, but as I started out saying about doing one
>off work, production is quite another. Today Nielsen in fact has a
>minute to minute service (for monitoring us habitual channel surfers
>no doubt), but I can almost guarantee you that those routines are not
>coded in SAS. For efficiency sake, I would guess they are a bit more
>sophisticated than the prototype code I wrote.
>
>That is why I think its important that we all realize that every bit
>counts (no pun inteded). It may seem like a drop in the bucket, but
>it does add up to buckets. Particularly when our code ends up in
>production schedules that run long after we may be around... That was
>the gist of the first article I referenced... What becomes of legacy
>code.
>
>Tom Skinner
>http://www.linkedin.com/pub/thomas-m-skinner/6/a31/516
| 
