RE: Re: SixPacks mods for GCIC users

Paolo

 

Thanks for those tests.

 

That seems about right. And what I expect.

Which doesn't tell me what caused 28 seconds relative to sixty rather than 6
to sixty

 

The GSVC  wasn't designed to do the thousands of getmains one after the
other as we are now doing and there are reasons for timer routine on every
GSVC.

Probably not relevant now since we are using at as a single user machine.

 

But that timer interrupt was to prevent a runaway task from monopolizing the
machine.

Remember multi-user.

Sort of overhead.

There are some checks in there for a runaway task and and a dump and then
rest of tasks keep running.

 

That’s a price that I paid by design. There for a reason.

That’s a do at your own risk thing. Take it out if you want but I cant take
it of the base modules.

 

Normally GETMAINS were limited to 4 or 5 per transaction and those numbers
are irrelevant to overall performance.

Doing 3000  extra get mains during the load  was not the original  design of
GSVC.

 

There is a probelm doing the BALR.

 

Storage is shared bewteen tasks –  program needs to keep control of all the
storage and allow interrupts in between the getmains.

IO interrupts and timer interrupts. ETC.

 

More to the point thats where I do the time slicing between tasks and change
priority.

I'm not saying that it wont work but there was logic and a reason for almost
everything.

 

I agree that with a major overhaul of the logic I could probably make it
more effeceint for the editor application specifically, but whats there ,is
there for a reason on the most part.

Changing the overall LOGIC is risky and could have unexpected results.

 

Fixing obvious bugs is better.

One place that would probably save a lot of instructions in the GSVC routine
is where it checks if its one of my SVC's or a system SVC.

 

And then after it decides its one of mine, it goes and and does the checking
again to determine the routine.

That alone is probably 200  CLC and BR instructions.

 

Even if you don’t change the logic a lot; since I didn’t pay attention to
the order it was checking that could be changed with little risk..

There might be improvement in putting the check for the GETMAIN up front
instead of somewhere in the middle.

Might prevent a lot of loops  if it found the getmain first and wouldn't
affect other stuff too much..

.

I allow multiple waits on timers for multiple tasks. Remember it can run
40-50 user tasks simultaneously.

So in truth Thre is only one  real timer interrrupt and that occurs every
second. One second task I think it called.

 

And the timer interrupt checks in GSVC if any tasks are waiting  on a timer
and then switches to the task that was waitng all done in the SVC routines.

More overhead. I limited my scheduled waits to round seconds.

 

Suggestion is not to make  changes  unless they are very LOCAL.

 

Better to fix my lousey programming techniques. 

And get rid of or improve  too many not well thought out loops.

 

That BASIC GSVC module has been working more or less unchanged in a real
production environment  for 35 years.

 

Which reminds me.

 

That gettimer routine also had the purpose of charging users for CPU time.
(Real production envirionement.)

Multiuser machine again --- needed to keep track of CPU TIME by USER. TASK.

There were routines to save the total CPU to a file at logon and logoff
time. And keeping track of CPU needed me to do it in GSVC because that were
the time slicing and tasks got switched.

 

OVERHEAD OVERHEAD OVERHEAD,

 

 

Roc

 

 

 

 

 

By the way if you have been playing with the code you must have a gotten a
dump now and then.

Did you notice the nice DUMP routine in the GSVC which sends a DUMP to your
reader.

Debugging in VM without a real dump was terrible,

 

Try adding a Bc 15,* instructions and you will get a DUMP.

I think its five cpu seconds without IO.

 

Taske abends and you get the dump in the reader

 

  _____  

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
> >
> >
> >
>