Re: SixPacks mods for GCIC users

--- In [email protected], "Rocky" <rocsystems@...> wrote:
>
> Whoops
> 
>  
> 
> I missed the little phrase "bypassing for the getmains"
> 
> If you only did it there and checked that it was the getmain SVC than I
> guess that is an acceptable approach.
> 
>  
> 
> Since there are about 60 different SVCs skipping on that one specific SVC
> should not be too much of an issus.
> 
>  
> 
> Rocky

Hi Roc,

what I did was to put on top of the two CLC series of instructions the checks for GETMAIN and FREEMAIN.
In the routine with OURSVC label I saved 46 instructions and in the second with OURSVC1 label I saved about 500 instructions (I put on top the second check before the DIAG *ONLY* for GETMAIN and FREEMAIN - I thougt it was uninfluent to get the time for these two functions;-)

The wait time passing from 65 sec to 28 secs with your brilliant GSVC mod makes lot of sense:

1): the time was of 18 secs and not of 28 (read well the post ;-)

2): The wait figure - with equal MIPS -should be of 3.5 (LOAD time) + 6.2(GETMAIN time) = about 10 secs - *BUT* in the original GSVC routine the greater part of instructions was made by this loop:

LPGTSTRG L 2,PTRNEXT
CLC STGCODE,=C'$END'
BNE K4STG
MVC RCDBAD,=F'8'
B RTBAD
*------------------------------
K4STG C 4,STGLEN
BH LPGTSTRG
CLC STGCODE,=CL4'FREE'
BNE LPGTSTRG

that evidently were more speedy that the average in your routine (giving so a nearly twofolders MIPS figure).

BTW to optimize the original loop I'd make two CLI compare instead of the CLC and put the CLC STGCODE,=CL4'FREE' on top (perhaps I'll try just for fun - I'd expect a 30% of wait time reduction) ;-)

I had realized that your original GCIC wasn't made for so many GETMAINs - it was a nice home made CICS for VM - I guess much more performing than official CICS/VM (that alas I can't find anywhere:-(.

But *our* GCIC editor is mostly a mono task application - so some little performance mods could be done without doing any arm (I don't expect 16 users editing files on VM/370 simultaneously on my little PC;-)

Regards.

Paul
 
   _____  
> 
> From: [email protected] [mailto:[email protected]] On Behalf Of
> paoloG
> Sent: Monday, November 08, 2010 22:24 
> To: [email protected]
> Subject: [H390-VM] Re: SixPacks mods for GCIC users
> 
>  
> 
>   
> 
> 
> 
> --- In [email protected] <mailto:H390-VM%40yahoogroups.com> , "Rocky"
> <rocsystems@> wrote:
> >
> > Paolo thanks for testing
> > 
> > You originally wrote:
> > 
> > > >> I suspected that the poor performances were related to all
> > > >> these GETMAINs, so I tried a quick and dirty correction:
> > > >> I acquired an unique area of 500k at the beginning of the routine
> > > >> and modified the code to cope with this unique area.
> > > >>
> > > >> I got a response time of 3 sec (instead of 65) and exiting
> > > >> from BROWSE or EDIT is almost immediate.
> > 
> > You say that the response time is NOW 28 seconds instead of 65 but the
> path
> > length is reduced from 60K to 10K
> > 
> > I added three instructions (MVI.MVC,Store) on every getmain to prevent a
> > loop of thousands of ( LA and C and CLC and BR)
> > The path length shows that I succeeded with that.
> > 
> > Hard to work with responses times without understanding your environment.
> > I would immediatly suspect "IO" but you say that you got a responses of 3
> > seconds with the routine that did one GETMAIN.
> > 
> > I think I need more information because that doesn't make sense to me yet.
> > Not saying it's wrong just that I don't understand why.
> > 
> > If we reduced the instruction path by 80% then the rest is a constant.
> > Of course it's going to take more time than your routine with ONE GETMAIN.
> > 
> > Like to know what the instruction path was for your routine with the one
> > GETMAIN.
> > 
> > I'd Like to know how much the path reduced by. That way I would have an
> idea
> > of how much the GETMAIN is taking Relative to the other stuff in the load
> of
> > a file.
> > 
> > Possibly this has something to do with the hardware.
> > Perhaps the hardware is allocating storage to Hercules etc. etc.
> > Maybe this last test was the first time you got storage and something
> > special happens.
> > 
> > Let me Know --- As you say I would expect a corresponding reduction.
> > 
> > On my box - the Dimension 9200 that's about what I got. From around 60
> > seconds to around 6. Asctually the first time I did it I think it was
> > slightly slower maybe the developers have an idea about that.
> > 
> > 
> > Roc
> > 
> Hi Roc, 
> 
> I've done some more tests, with a file of 3,742 lines and one of 14,032
> lines, calculating the path length for line loading the file with BROWSE.
> 
> Original GSVC routine:
> 
> 1) File of 3743 lines:
> 
> 15,000 instructions/line for GETMAINs
> 1,000 instructions/line for LOAD etc. 
> 
> 2) File of 14013 lines:
> 
> 51,500 instructions/line for GETMAINs
> 1,000 instructions/line for LOAD etc.
> 
> That makes lot of sense as every new GETMAIN requires a scan of all
> the chain of memory already allocated, so increasing the path length
> for line increasing the lines of the file.
> 
> Modified (by Rocky) GSVC routine:
> 
> 1,500 instructions/line for GETMAINs (great improvement!)
> 1,000 instructions/line for LOAD 
> 
> Path length for each instruction doesn't depend on the number of lines in
> the file.
> 
> I've dome some further improvement reducing the path length from
> 1,500 to 1,000 instruction/line, simply bypassing the DIAG for getting DATE
> at the beginning of GSVC for GETMAIN and FREEMAIN).
> 
> The remaining 1,000 instructions/line are caused in great part by SVC 11
> call overhead; invoking GETMAIN and FREEMAIN with a simple BALR 14,15 could
> give further great improvement.
> 
> Regards.
> 
> Paul
> 
> > 
> > 
> > 
> > 
> > ><rocsystems@> wrote:
> > >>
> > >>
> > >> Hi Paolo
> > >>
> > >> This is in reply to your original problem with GCIC - slow loading of
> > >large
> > >> files.
> > >> I took a look at the code and "lo and behold" I have a BUG in my
> > >"Efficient
> > >> Storage handling" routines.
> > >>
> > >> Your numbers didn't make sense to me.
> > >> the logic.
> > >>
> > >> I took a look at my storage handling routines and found a logic bug.
> > >>
> > >> I fixed the bug with about 6 instructions and now on my dimension 9200
> > >the
> > >> same file that took 60 seconds to load - loads in about 3. (17000
> records
> > >of
> > >> 132 pos.) That seems to be a fair response time.
> > >>
> > >> Rocky
> > >>
> > >
> > >Hi Roc,
> > >done a quick test on my ARM test NAS.
> > >
> > >Path length reduced from 60M to 10M:
> > >I'd expect a correspondent reduction of wait time (in the order of 10
> > >sec), but I got a time of 18.5 secs (MIPS decreased from 0.98 to 0.55
> > >- perhaps you introduced some heavy instruction ?-)
> > >
> > >Anyhow a good improvement; I'm going to test it on other platforms.
> > >
> > >I'm going out with my wife - BFN ;-)
> > >
> > >Paul
> > >
> > >
> > >
> >
>