Date:         Fri, 10 Jan 2003 04:40:05 +0000
Reply-To:     sashole@bellsouth.net
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Paul Dorfman <paul_dorfman@HOTMAIL.COM>
Subject:      Re: Hyperthreading?
Comments: To: scott.chapal@JONESCTR.ORG
Content-Type: text/plain; format=flowed

Scott,

There are too many factor at play to say what makes the two OSsa handle  it
so differently given the closesness of the setup. Apparently, a
single-threaded sort is much more efficient under Solaris, even if the
processor speeds are similar. I am not sure, but it is possible that under
Solaris, much better use of the available memory is being made (e.g.
although I have 1 Gb here, the Task Manager never indicated using more than
30 Mb), or else the I/O may be handled much more efficiently. I reran the
program in batch, having provided for two physically different and
independently spinning locations of the unsorted and sorted data. Please see
the log below. I guess I will take Unix, thank you :-). I do not have a
little s/390 black box in the corner of my home office at the moment, but if
I recall correctly the last time I did a similar test for Proc SyncSort
under 6.09e (single-threaded, fo course and available for mainframes only),
it would take about 10 CPU and 30 elapsed seconds to run. The bottom line
is, multithreading is of real benefit to OSsa maladroit enough to handle a
single-threaded process efficiently...

1          option msglevel = i ;
2          libname d "d:\" ;
NOTE: Libref D was successfully assigned as follows:
      Engine:        V9
      Physical Name: d:\
3          libname h "h:\" ;
NOTE: Libref H was successfully assigned as follows:
      Engine:        V9
      Physical Name: h:\
4          data d.a ;
5             array nn (100)     ; do _n_ = 1 to 100 ; nn (_n_) = _n_ ; end
;
6             array cc (100)     ; do _n_ = 1 to 100 ; cc (_n_) = _n_ ; end
;
7             do _n_ = 1 to 1e6 ;
8                key1 = ranuni (1) ;
9                key2 = ranuni (1) ;
10              key3 = ranuni (1) ;
11              output ;
12            end ;
13         run ;

NOTE: The data set D.A has 1000000 observations and 203 variables.
NOTE: DATA statement used (Total process time):
      real time           1:33.12
      cpu time            27.28 seconds

14         option threads ;
15         proc sort data = d.a out = h.b ;
16            by key: ;
17         run ;

NOTE: SAS threaded sort was used.
NOTE: There were 1000000 observations read from the data set D.A.
NOTE: The data set H.B has 1000000 observations and 203 variables.
NOTE: PROCEDURE SORT used (Total process time):
      real time           3:36.09
      cpu time            2:48.31

18         option nothreads ;
19         proc sort data = d.a out = h.b ;
20            by key: ;
21         run ;

NOTE: SAS sort was used.
NOTE: There were 1000000 observations read from the data set D.A.
NOTE: The data set H.B has 1000000 observations and 203 variables.
NOTE: PROCEDURE SORT used (Total process time):
      real time           21:06.73
      cpu time            1:57.75

Kind regards,
---------------------
Paul M. Dorfman
Jacksonville, FL
---------------------


>From: Scott Chapal <scott.chapal@JONESCTR.ORG>
>Reply-To: Scott Chapal <scott.chapal@JONESCTR.ORG>
>To: SAS-L@LISTSERV.UGA.EDU
>Subject: Re: Hyperthreading?
>Date: Thu, 9 Jan 2003 14:52:40 -0500
>
>Paul,
>
>paul_dorfman@HOTMAIL.COM (Paul Dorfman) writes:
>
> > (My impression has been that this sort of thing has been available
> > on some commercial Unices, too, but here I am not sure. Someone who
> > knwos will surely chime in.)
>
>This got me curious so I ran your test on a SUNFire 280R 2x~900Mhz,
>4Gb, Solaris 9 :
>
>NOTE: AUTOEXEC processing completed.
>
>1       option cpucount = actual;
>2       option msglevel = i ;
>3       *libname user "h:\" ;
>4       data a ;
>5          array nn (100)     ; do _n_ = 1 to 100 ; nn (_n_) = _n_ ; end ;
>6          array cc (100)     ; do _n_ = 1 to 100 ; cc (_n_) = _n_ ; end ;
>7          do _n_ = 1 to 1e6 ;
>8             key1 = ranuni (1) ;
>9             key2 = ranuni (1) ;
>10            key3 = ranuni (1) ;
>11            output ;
>12         end ;
>13      run ;
>
>NOTE: The data set WORK.A has 1000000 observations and 203 variables.
>NOTE: DATA statement used (Total process time):
>       real time           47.82 seconds
>       cpu time            13.91 seconds
>
>
>14
>15      option threads ;
>16      proc sort data = a out = b ;
>17         by key: ;
>18      run ;
>
>NOTE: SAS threaded sort was used.
>NOTE: There were 1000000 observations read from the data set WORK.A.
>NOTE: The data set WORK.B has 1000000 observations and 203 variables.
>NOTE: PROCEDURE SORT used (Total process time):
>       real time           1:33.51
>       cpu time            1:04.64
>
>
>19
>20      option nothreads ;
>21      proc sort data = a out = b ;
>22         by key: ;
>23      run ;
>
>NOTE: SAS sort was used.
>NOTE: There were 1000000 observations read from the data set WORK.A.
>NOTE: The data set WORK.B has 1000000 observations and 203 variables.
>NOTE: PROCEDURE SORT used (Total process time):
>       real time           1:34.86
>       cpu time            54.98 seconds
>
> > As you see, when SAS uses 2 CPUs in the SMP mode, it (logically) uses
>twice
> > the CPU time, but how cares if the real time is 1/6 that of the
>non-threaded
> > sort. Impressed?
>
>In neither case on the Solaris server was the process CPU-bound.  Also
>as you can see, there is much less difference than on your system.
>What is going on here?
>
>Also, in your example the ratio of real:cpu is 15:1 for nothreads.
>What causes that?
>
>Interesting... thanks.
>
>--
>Scott Chapal


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail