Re: SixPacks mods for GCIC users

--- In [email protected], "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
> >
> >
> >
>