I have just converted a large assembler application to baseless code:
- brach relative instructions
- data completly separated from instruction part of the code
- SYSSTATE ARCHLVL=2 compiled
For my big surprise in our z/800 machine the firts test shows two times
higher CPU consumtion for the baseless code as in the original code
--
Mit freundlichen Grüßen / Best regards
Miklos Szigetvari
ISIS Information Systems GmbH
Alter Wienerweg 12
2344 Maria Enzersdorf
Austria
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------
>> ...conversion ...two times higher CPU ...<<
I can not believe this.
Would you elaborate?
relative instructions should have about the same timings as their bddd
brothers (and sisters) - what else did you do?
seaparate data and instructions.... that should not have any
consequences (I do understand the result of a pagefault and the effect
of an instruction next to the data avoiding the pagefault vs. data far
far away (and causing pagefault on first ref).
ARCHLEVEL=2---sorry I am more a person from the other opsys- does this
have major impact on the pathlength?
--
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de
> Miklos,
>
> >> ...conversion ...two times higher CPU ...<<
>
> I can not believe this.
>
I thought maybe the z/800 machine is not so "smart".
I will check again code, I think I made somewhere a mistake.
It is a long running STC server, and I have compared the "startup" CPU
times.
As far as I remember , I don't made any significant change.
The conversion was quite "mechanic" .
With ARCHLEVEL=2 most of the system macros compiled well with baseless
code.
> Would you elaborate?
>
> relative instructions should have about the same timings as their bddd
> brothers (and sisters) - what else did you do?
>
> seaparate data and instructions.... that should not have any
> consequences (I do understand the result of a pagefault and the effect
> of an instruction next to the data avoiding the pagefault vs. data far
> far away (and causing pagefault on first ref).
>
> ARCHLEVEL=2---sorry I am more a person from the other opsys- does this
> have major impact on the pathlength?
>
> --
> Martin
> --
> XML2PDF - the way to get all features of PDF into your documents
> on mainframe or PC systems; more at http://www.pi-sysprog.de
>
Sorry, sorry everything o.k,
In the baseless version there was a DEBUG flag switched on.
Now the baseless code needs 0.4 second CPU and the old code 0.49 CPU.
Hard to believe. I've done many similar conversions and have never
experienced anything like this.
Any chance you used instructions with long displacements? Though
supported, they run extremely slowly on a z800 machine.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
(Couldn't resist.)
Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project
> Miklos Szigetvari wrote:
>
>> I have just converted a large assembler application to baseless code:
>> - brach relative instructions
>> - data completly separated from instruction part of the code
>> - SYSSTATE ARCHLVL=2 compiled
>>
>> For my big surprise in our z/800 machine the firts test shows two times
>> higher CPU consumtion for the baseless code as in the original code
>
>
> Hard to believe. I've done many similar conversions and have never
> experienced anything like this.
>
> Any chance you used instructions with long displacements? Though
> supported, they run extremely slowly on a z800 machine.
>
I'm just thinking about this.
( I run out of some work area BASE , and the option was to use
long displacements)
But at least Ed pointed out a hardware difference.
Sorry again, in my case it was a wrong DEBUG flag in the baseless code
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 5200 W Century Blvd, Suite 800
> Los Angeles, CA 90045
> 310-338-0400 x318
> edj...@phoenixsoftware.com
> http://www.phoenixsoftware.com/
>
But you could have at least TRIED to resist. <grin>
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.