Re: Benchmark of Relative instructions vers Base+displacement ones

[Shmuel Metz (Seymour J.)]

In
<985915eee6984740ae93f8495c624c6c2319ba1...@jscpcwexmaa1.bsg.ad.adp.com>,
on 07/15/2013
   at 07:00 PM, "Farley, Peter x23353" 
said:

>Whatever their timing formulas or model-dependant behavior, in the
>old days of non-pipelined or minimally-pipelined CPU engines you ran
>your batch application program once with the appropriate test data
>using the "production" load module on an unloaded or lightly loaded
>machine, then you ran it once more with the same test data using a
>changed version of the same load module on that same machine, and you
>could compare the timing of those two jobs to see if you had improved
>or worsened that program's performance characteristics. 

With results that varied depending on what else was running
concurrently. OS overhead was another factor that was not consistent.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[J R]

And I didn't say that you do have to google to find the POO.  I was responding 
to someone that said that's what s/he does.  

As a follow-up, I would say that neither should you have to follow a link with 
Jim Elliott's name in it.  That hardly smacks of IBM's official source of the 
information.  

Having said that, I know Jim and respect him highly as a great resource.  
Suffice to say that I have bookmarked the link you posted.  

= 


 
> Date: Tue, 16 Jul 2013 08:41:54 -0500
> From: m42tom-ibmm...@yahoo.com
> Subject: Re: Benchmark of Relative instructions vers Base+displacement ones
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> On Wed, 10 Jul 2013 07:54:09 -0400, J R wrote:
> 
> >You shouldn't have to google to find this book.  
> 
> You don't.  For the correct edition of the POO, I use the page at
> http://www.vm.ibm.com/devpages/jelliott/cmosproc.html
> 
> -- 
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John Gilmore]

That site also provides information about the model prerequisite to a
particular version of z/VM, relegated for some odd reason to the notes
at the end.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Tom Marchant]

On Wed, 10 Jul 2013 07:54:09 -0400, J R wrote:

>You shouldn't have to google to find this book.  

You don't.  For the correct edition of the POO, I use the page at
http://www.vm.ibm.com/devpages/jelliott/cmosproc.html

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Farley, Peter x23353]

Whatever their timing formulas or model-dependant behavior, in the old days of 
non-pipelined or minimally-pipelined CPU engines you ran your batch application 
program once with the appropriate test data using the "production" load module 
on an unloaded or lightly loaded machine, then you ran it once more with the 
same test data using a changed version of the same load module on that same 
machine, and you could compare the timing of those two jobs to see if you had 
improved or worsened that program's performance characteristics.  Two tests and 
done, and good enough for all but the most finicky measurements (or for ISV 
code, which had to run on many varying models -- they always had a tougher job 
measuring useful performance characteristics, BTDTGTTS).

Now you run each version multiple times (some say 10 or more, others say 5) and 
take an average of the numbers to make that same comparison or it's not good 
enough.

But as I said previously, I know that's just the way it is now, so I live with 
it.  It's just part of the job today.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: Monday, July 15, 2013 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Benchmark of Relative instructions vers Base+displacement ones

In
<985915eee6984740ae93f8495c624c6c2319af4...@jscpcwexmaa1.bsg.ad.adp.com>,
on 07/15/2013
   at 11:01 AM, "Farley, Peter x23353" said:

>I remember when I first was disabused of the quaint notion that the
>CPU performance of a batch z/OS application could be measured in a
>deterministic manner,

There's deterministic and there's usefully deterministic. Back when
IBM was still publishing instruction timings, there was a progression
to increasingly complex timing formulae. There was also the issue that
the time ranking of two code sequences would vary by model.

-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Shmuel Metz (Seymour J.)]

In
<985915eee6984740ae93f8495c624c6c2319af4...@jscpcwexmaa1.bsg.ad.adp.com>,
on 07/15/2013
   at 11:01 AM, "Farley, Peter x23353" 
said:

>I remember when I first was disabused of the quaint notion that the
>CPU performance of a batch z/OS application could be measured in a
>deterministic manner,

There's deterministic and there's usefully deterministic. Back when
IBM was still publishing instruction timings, there was a progression
to increasingly complex timing formulae. There was also the issue that
the time ranking of two code sequences would vary by model.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John Gilmore]

Peter Farley's lament is understandable, but it is important to
[better] understand that all scientific and engineering questions are
statistical in character and that they become so increasingly as a
subject advances.

Deterministic, Newtonian methods served physics well in the 17th
century; but the question is there or is there not a Higgs Boson must
be and is being addressed statistically. (The tentative answer is yes.)

Performance measurement has reached this stage.  Non-statistical
questions only mislead; such measurements are experiments that
must be designed explicitly and in advance.  As Sir Ronald Fisher put
the matter


To consult the statistician after an experiment is finished is often
merely to ask him to conduct a post mortem. He can perhaps say what
the experiment died of.


John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Farley, Peter x23353]

I remember when I first was disabused of the quaint notion that the CPU 
performance of a batch z/OS application could be measured in a deterministic 
manner, here on this very list some years ago.  The implications of processor 
pipelining and branch prediction and AGI and cache lines had just not sunk into 
my thick Irish head before that time.  I well remember my sincere and 
aggravated frustration that performance measurement had been reduced to 
"statistical averages".  I was at that time engaged in an active and crucial 
CPU reduction exercise for my employer, and having the ability to perform 
deterministic measurement would have made my job then SO much easier.

I am still at least mildly upset that we can no longer accurately measure or 
predict performance, but only produce statistical estimates.  OTOH, having seen 
the kind of processor-specific, pipeline-optimized instruction generation that 
the current C/C++ compiler back end can produce (and that hopefully the new 
COBOL back end will produce as well), I am more sanguine about our ability as 
programmers to produce fast, efficient code for our employers.

However, it would be extraordinarily helpful if IBM commissioned a Redpaper or 
two about application programming paradigms and design patterns (in more than 
one application language) so that current and future mainframe coding 
practitioners could "keep current" with the tremendous hardware enhancements 
that have been and are being brought into our world, will we, nil we.

Or perhaps such desiderata have already been written and I am just ignorant of 
their availability?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Wednesday, July 10, 2013 2:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Benchmark of Relative instructions vers Base+displacement ones

Charles Mills wrote:
> In other words, if one had to venture a *guess* it would be that the
> immediate instructions were in practice a heck of a lot faster.
>
> (Don't know that this sort of issue is relevant to the relative versus
> branch/displacement comparison.)
>


This is a performance question, right?  So "it depends."  (Yes, I know 
you knew that.)  And I'm not a performance expert, nor did I stay in a 
well-known hotel last night.  But I'll venture out on this "branch" 
anyway, to say...

That John hit the nail on the head when he said that processors have 
gotten a lot faster than memory.  To put this into perspective, since 
the 3168-3 processor came out in the 1970's the cost of a cache-miss 
real memory access when counted in machine cycles has risen over 400x. 
(That's not a typo.  It's really more than a factor of four hundred.)

That some of our compilers are maximizing the use of immediate and 
register operands to some extent just for this reason.  Although the 
path length is "theoretically" longer for some of these strings of 
instructions, they avoid memory accesses often enough that on a 
practical level they are faster.

That it's time for everyone to be thinking of memory accesses the way 
we've thought about I/O accesses for half a century.  Avoid, buffer, 
prestage...etc.

And, finally, that the branch instruction itself does not stand alone. 
One must load a register to use it as a base in order to establish 
addressability, and load another to use it as a displacement register, 
and Load instructions can cause real memory (vs. cache) accesses.  So, 
it seems to me there can be some applicability to relative branch as well.

-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[DASDBILL2]

Be careful how you determine whether a particular instruction is described in 
the POO or not.  I once made the mistake of looking only in the index at the 
end of the book for a particular instruction op code.  It was not in the index, 
but it was fully described in the book.  My buddy Reza kept sending me the same 
version of the book because he knew the instruction in question WAS in the 
book, and I kept telling him that it was NOT in the book that he had sent me 
for the 3rd or 4th time.   After finally understanding my error, I sent a 
Reader's Comment Form to IBM and asked them please to give this new instruction 
the same respect as the good old Load Address instruction by putting it in the 
index. 


Bill Fairchild 
- Original Message -
From: "Richard Verville"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, July 9, 2013 5:38:15 PM 
Subject: Re: Benchmark of Relative instructions vers Base+displacement ones 

J R 's link works just fine... and indeed has the LGFI and others in it. Thanks 
very much for this...Richard 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Shmuel Metz (Seymour J.)]

In
,
on 07/11/2013
   at 07:38 AM, John Gilmore  said:

>Auden spoke of the privations of the poor, "to which they are fairly
>accustomed", and I am entirely accustomed to Shmuel's fulminations,
>which are largely predictable.

PKB.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Peter Relson]

>Even if they are a little slower, it would not take very many eliminated
>"save and load another base register" scenarios to make up for it.

It is my understanding that if anything relative branches are faster, not 
slower than base-displacement branches (at least in part because the 
pipeline can know that the target of a relative branch cannot possibly 
change, unlike a base-displacement branch where the base could conceivably 
change even if in practice it almost never does)

>why can't we inspect control 
>register 0 in problem state (without the extraction bit on)

May I inquire what in control register 0 is of interest/use to your 
program? Most data represented in CR0 is not of interest to applications 
(or is identified to applications by the presence of feature bits, such as 
in the CVT).

>Immediate vs other
Quite clearly, an "immediate" is going to beat the heck out of a reference 
to storage (even if the data is in the L1 cache).
I don't know how things like
LHI   0,8 and LA0,8 
compare.

When your "immediate" is more bytes of instructions than the alternative, 
to the extent that causes your code footprint to occupy more cache lines, 
comparisons become even more difficult. 

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[David Crayford]

On 11/07/2013 1:47 PM, Ed Jaffe wrote:

On 7/10/2013 11:54 AM, John Eells wrote:


And, finally, that the branch instruction itself does not stand 
alone. One must load a register to use it as a base in order to 
establish addressability, and load another to use it as a 
displacement register, and Load instructions can cause real memory 
(vs. cache) accesses.  So, it seems to me there can be some 
applicability to relative branch as well.


Branch prediction is a wonderful thing for optimizing loops and other 
repetitive branch paths, but it makes it difficult to get meaningful 
branch benchmarks. Relative branch, in addition to providing relief 
from the oppressive 4K base register domain, should help a program 
perform better because:




Great info. And it's easy to enable relative branching in your existing 
code base simply by using the IEABRCX DEFINE macro.


1. Branch prediction occurs early in the pipeline when there is no 
access to register contents. With relative branch there is no need for 
the processor to "waste" time double-checking the branch target 
address once the contents of the base register are actually known.
2. AGI (address generation interlock) can cause an instruction using a 
base register to run *brutally* slowly (i.e., stop for a while) if it 
executes shortly after the base register is loaded. This applies to 
based branches as well as other types of instructions. Base registers 
get loaded more often than people think e.g., LM when returning from a 
subroutine. With relative branch there is ZERO possibility of AGI.
3. Freeing up code base registers for other uses allows program code 
to be better interleaved by compilers, HLASM programmers that know 
what they're doing, and OOO execution pipelines on the latest machines.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John Gilmore]

Of my view that traditional base register-displacement coding idioms
are, at best, obsolescent, Shmuel wrote


Nonsense; they're still needed for referring to data in dynamic
storage. My general rule on such matters is that you have to cut the
bird at the joints.


which remarks prompt me to two [rhetorical] questions.  How much code
is Shmuel in fact writing these days?  Does he in fact understand the
difference between the words 'obsolescent' and 'obsolete'?

That there are exiguous residual uses for base registers may be
conceded, although 'access to data in dynamic storage' is a very poor
description of the principal one.

Auden spoke of the privations of the poor, "to which they are fairly
accustomed", and I am entirely accustomed to Shmuel's fulminations,
which are largely predictable.  I should not, however, wish other
readers to take this one seriously.  It is at once wrong and
wrong-headed.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Ed Jaffe]

On 7/10/2013 11:54 AM, John Eells wrote:


And, finally, that the branch instruction itself does not stand alone. 
One must load a register to use it as a base in order to establish 
addressability, and load another to use it as a displacement register, 
and Load instructions can cause real memory (vs. cache) accesses.  So, 
it seems to me there can be some applicability to relative branch as well.


Branch prediction is a wonderful thing for optimizing loops and other 
repetitive branch paths, but it makes it difficult to get meaningful 
branch benchmarks. Relative branch, in addition to providing relief from 
the oppressive 4K base register domain, should help a program perform 
better because:


1. Branch prediction occurs early in the pipeline when there is no 
access to register contents. With relative branch there is no need for 
the processor to "waste" time double-checking the branch target address 
once the contents of the base register are actually known.
2. AGI (address generation interlock) can cause an instruction using a 
base register to run *brutally* slowly (i.e., stop for a while) if it 
executes shortly after the base register is loaded. This applies to 
based branches as well as other types of instructions. Base registers 
get loaded more often than people think e.g., LM when returning from a 
subroutine. With relative branch there is ZERO possibility of AGI.
3. Freeing up code base registers for other uses allows program code to 
be better interleaved by compilers, HLASM programmers that know what 
they're doing, and OOO execution pipelines on the latest machines.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Shmuel Metz (Seymour J.)]

In
,
on 07/10/2013
   at 02:44 PM, John Gilmore  said:

>Let me also take this opportunity to add my personal view that
>base-register-displacement schemes are at best obsolescent in new
>code. 

Nonsense; they're still needed for referring to data in dynamic
storage. My general rule on such matters is that you have to cut the
bird at the joints.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Shmuel Metz (Seymour J.)]

In , on 07/10/2013
   at 07:54 AM, J R  said:

>You shouldn't have to google to find this book.

That's better than google not being able to find it. Where is Systems
Network Architecture Format and Protocol Reference Manual:
Architectural Logic (SC30-3112)?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Shmuel Metz (Seymour J.)]

In , on 07/10/2013
   at 07:40 AM, J R  said:

>> Finding -09 (when it came out) was harder than I expected it to be, and 
>> harder than I think it should be.  

>And still is!  

Finding the SNA manuals, e.g., Format and Protocol Logic, is just as
bad. Does anybody have links to the current editions?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John Eells]

Charles Mills wrote:

In other words, if one had to venture a *guess* it would be that the
immediate instructions were in practice a heck of a lot faster.

(Don't know that this sort of issue is relevant to the relative versus
branch/displacement comparison.)




This is a performance question, right?  So "it depends."  (Yes, I know 
you knew that.)  And I'm not a performance expert, nor did I stay in a 
well-known hotel last night.  But I'll venture out on this "branch" 
anyway, to say...


That John hit the nail on the head when he said that processors have 
gotten a lot faster than memory.  To put this into perspective, since 
the 3168-3 processor came out in the 1970's the cost of a cache-miss 
real memory access when counted in machine cycles has risen over 400x. 
(That's not a typo.  It's really more than a factor of four hundred.)


That some of our compilers are maximizing the use of immediate and 
register operands to some extent just for this reason.  Although the 
path length is "theoretically" longer for some of these strings of 
instructions, they avoid memory accesses often enough that on a 
practical level they are faster.


That it's time for everyone to be thinking of memory accesses the way 
we've thought about I/O accesses for half a century.  Avoid, buffer, 
prestage...etc.


And, finally, that the branch instruction itself does not stand alone. 
One must load a register to use it as a base in order to establish 
addressability, and load another to use it as a displacement register, 
and Load instructions can cause real memory (vs. cache) accesses.  So, 
it seems to me there can be some applicability to relative branch as well.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John Gilmore]

John Ehrman knows much more about what kinds of older mainframes are
still in use than I do, and I imagine that he had good reason to use
the qualifying language ". . . so if your processor supports useful
immediate operands, take advantage".

Still, the extended-immediate facility dates back ten years now, to
June 2003; and I have found the 'new' instructions it makes available
very helpful.  The FLOGR instruction alone has, for example,
revolutionized the way in which I do bit-map processing.

I would urge any HLASM programmer who is not already using these
instruction to familiarize himself with them, for reasons of
convenience and code compactness as well as the performance reasons
John mentions.

Let me also take this opportunity to add my personal view that
base-register-displacement schemes are at best obsolescent in new
code.  There is no excuse for using them ab initio.  Equally, of
course, there is no compelling case for their doctrinaire elimination
from old code.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Charles Mills]

In other words, if one had to venture a *guess* it would be that the
immediate instructions were in practice a heck of a lot faster. 

(Don't know that this sort of issue is relevant to the relative versus
branch/displacement comparison.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Ehrman
Sent: Wednesday, July 10, 2013 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Benchmark of Relative instructions vers Base+displacement ones

On Tue, 9 Jul 2013 15:30:12 -0400, Richard Verville
 asked:

> Has anyone done benchmarks on different scenarios with instructions 
> with
immediate & relative instructions versus the old instructions. 

The more important issue is memory access: CPU speeds have increased much
faster than memory speeds.

There is no memory pentaly for immediate operands, while memory references
can be quite costly: an item taken from memory can displace other items in
the data cache, or they might cross a cache-line or memory-page boundary, or
require paging. A memory reference can take anywhere from a few cycles to
many thousands, so if your processor supports useful immediate operands,
take advantage.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Benchmark of Relative instructions vers Base+displacement ones

[John Ehrman]

On Tue, 9 Jul 2013 15:30:12 -0400, Richard Verville
 asked:

> Has anyone done benchmarks on different scenarios with instructions with
immediate & relative instructions versus the old instructions. 

The more important issue is memory access: CPU speeds have increased much
faster than memory speeds.

There is no memory pentaly for immediate operands, while memory references
can be quite costly: an item taken from memory can displace other items in
the data cache, or they might cross a cache-line or memory-page boundary,
or require paging. A memory reference can take anywhere from a few cycles
to many thousands, so if your processor supports useful immediate operands,
take advantage.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Kirk Talman]

LLILF LLIHF LGFI and for smaller values LAY

IBM Mainframe Discussion List  wrote on 
07/09/2013 03:30:12 PM:

> From: Richard Verville 

> Has anyone done benchmarks on different scenarios with instructions 
> with immediate & relative instructions versus the old instructions. 
> I have to rewrite some code for CICS on zOS & VSE and I wonder if 
> it's worth it. Also I can't find a Load Fullword Immediate 
> instruction (like LHI) where the intent is to load a value greater 
> than 64K into a register and finally, why can't we inspect control 
> register 0 in problem state (without the extraction bit on), 
> instructions like ISVK should be "free", don't you think ? Richard


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Steve Thompson]

From:   Charles Mills 
Date:   07/10/2013 11:15 AM



This drifted into a discussion of manual links. Did anyone address

> Has anyone done benchmarks on different scenarios with instructions with
immediate & relative instructions versus the old instructions

My personal opinion are

1. I doubt that the differences are significant unless you are calculating
pi to 1000 digits or implementing your own 8192-bit encryption.
2. The relative instructions are SO convenient relative (sorry) to the old
base/displacement instructions that I wonder how we ever lived without 
them.
3. Even if they are a little slower, it would not take very many 
eliminated
"save and load another base register" scenarios to make up for it.
4. Because of pipelining, caching and so forth it is difficult to 
construct
benchmarks that are going to accurately reflect your real-world situation.

Charles
--

Amen to 1, 2, and 4. Especially 4. 

In a past life, working at AMDAHL, we had to use standalone time to run 
specific loads to do timing determinations. Most companies can't afford to 
put a machine in basic mode (assuming it were even possible with PR/SM 
today) for a few hours to do such testing.

Until one programs at the level of the machine's "Hypervisor" (what else 
would you call a Domain/LPAR controller?), one probably does not have an 
appreciation for all the interrupts that take place (including some that 
are not in the PoOP manual). This makes it very difficult to get into a 
deterministic environment to do such timings. And again, with pipelining, 
cache, out-of-order execution, etc., getting such timings is nearly 
impossible.

Also, in a life prior to AMDAHL, I worked for a S/3 competitor whose 
machines were ASCII based. We used relative addressing instructions. Once 
I got use to it, I often wondered why this was not implemented by IBM in 
the S/3x0 architecture. 

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Charles Mills]

This drifted into a discussion of manual links. Did anyone address

> Has anyone done benchmarks on different scenarios with instructions with
immediate & relative instructions versus the old instructions

My personal opinion are

1. I doubt that the differences are significant unless you are calculating
pi to 1000 digits or implementing your own 8192-bit encryption.
2. The relative instructions are SO convenient relative (sorry) to the old
base/displacement instructions that I wonder how we ever lived without them.
3. Even if they are a little slower, it would not take very many eliminated
"save and load another base register" scenarios to make up for it.
4. Because of pipelining, caching and so forth it is difficult to construct
benchmarks that are going to accurately reflect your real-world situation.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Richard Verville
Sent: Tuesday, July 09, 2013 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Benchmark of Relative instructions vers Base+displacement ones

Has anyone done benchmarks on different scenarios with instructions with
immediate & relative instructions versus the old instructions. I have to
rewrite some code for CICS on zOS & VSE and I wonder if it's worth it. Also
I can't find a Load Fullword Immediate instruction (like LHI) where the
intent is to 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John Gilmore]

J  R  wrote

| You shouldn't have to google to find this book.

about the PrOp, and you need not do so.  The IBM Publications Center website

http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss

will give you a list of all of the available, downloadable and/or
orderable-as-hardcopy versions; and all you need then do is choose the
latest one.  Currently, all of SA22-7832-00, . . . , SA22-7832-09 can
be downloaded.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[J R]

Right, but when you get there you have to sign in to download the book.  
(A process that sometimes works, sometimes not.)  

Wouldn't it be better for the Elements and Features page to include the latest 
version?  

Yes, I know that Elements and Features is a z/OS-relevant page and Principles 
of Operation is zArchitecture related, but the vast majority of those 
developing assembler code for z are doing so for z/OS.  

You shouldn't have to google to find this book.  

===


 
> Date: Wed, 10 Jul 2013 05:33:45 -0500
> From: jan.moeyers...@gfi.be
> Subject: Re: Benchmark of Relative instructions vers Base+displacement ones
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> GIYF... 
> 
> "principles of operation" in the address bar of Chrome and the first link is 
> the right one...
> 
> Cheers,
> 
> Jantje.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[J R]

> Finding -09 (when it came out) was harder than I expected it to be, and 
> harder than I think it should be.  

And still is!  

The "z/OS V1R13.0 Elements and Features" web page still refers to dz9zr008.pdf, 
aka SA22-7832-08.  

And, that's another thing, are "dz9zr009.pdf" and "SA22-7832-09.pdf" aliases 
(alternate names) of the exact same file?  
Or, if not, what is the likelihood of not picking up the latest, current 
version?  

RedBooks, while conveniently using a file naming standard that reflects the 
external document number, do not usually include the level number.  You have to 
open the pdf to see which one you actually got.  

===


 
> Date: Tue, 9 Jul 2013 16:55:01 -0500
> From: walt.farr...@gmail.com
> Subject: Re: Benchmark of Relative instructions vers Base+displacement ones
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> On Tue, 9 Jul 2013 16:11:51 -0500, John McKown  
> wrote:
> 
> >Well, I tried JR's link and it got me the -09 version of the manual. LGFI
> >is on the top of page 7-219. I don't know how I could have goofed up my
> >link.
> >
> 
> Your link was to -08, so either you used a site that has a downlevel version, 
> or somehow you picked the wrong one to link to :)
> 
> Finding -09 (when it came out) was harder than I expected it to be, and 
> harder than I think it should be.
> 
> -- 
> Walt
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Shmuel Metz (Seymour J.)]

In <8D261BD3BE29432A8E80B90B218DA523@RichardPC>, on 07/09/2013
   at 04:51 PM, Richard Verville  said:

>that link has the same manual I have already

z/Architecture Principles of Operation, SA22-7832-09?

>and the LGFI instruction is not in it

P. 7-219
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Jantje.]

GIYF... 

"principles of operation" in the address bar of Chrome and the first link is 
the right one...

Cheers,

Jantje.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[retired mainframer]

-08 is two years behind the -09 version

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of John McKown
:>: Sent: Tuesday, July 09, 2013 1:45 PM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Re: Benchmark of Relative instructions vers Base+displacement
:>: ones
:>:
:>: Download from here
:>:
:>: http://www-05.ibm.com/e-
:>: business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SA22-
:>: 7832-08
:>:
:>:
:>: On Tue, Jul 9, 2013 at 3:17 PM, Richard Verville
:>: wrote:
:>:
:>: > Now I feel really stupid, I went back to the POP manual I have and
:>: It's
:>: > dated October 2001. I just tried the LGFI instruction and it compiles
.
:>: Now
:>: > I need to get my hands on the latest POP manual...The control register
:>: R0
:>: > has the extraction bit (if ISVK is allowed for example) , so we could
:>: test
:>: > the bit before getting a privilege operation exception. Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Walt Farrell]

On Tue, 9 Jul 2013 16:11:51 -0500, John McKown  
wrote:

>Well, I tried JR's link and it got me the -09 version of the manual. LGFI
>is on the top of page 7-219. I don't know how I could have goofed up my
>link.
>

Your link was to -08, so either you used a site that has a downlevel version, 
or somehow you picked the wrong one to link to :)

Finding -09 (when it came out) was harder than I expected it to be, and harder 
than I think it should be.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Richard Verville]

J R 's link works just fine... and indeed has the LGFI and others in it. Thanks 
very much for this...Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John McKown]

Well, I tried JR's link and it got me the -09 version of the manual. LGFI
is on the top of page 7-219. I don't know how I could have goofed up my
link.

On Tue, Jul 9, 2013 at 3:53 PM, J R  wrote:

> Try this link:
>
>  http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf
>
> ==
>
> > Date: Tue, 9 Jul 2013 16:51:13 -0400
> > From: r.vervi...@videotron.ca
> > Subject: Re: Benchmark of Relative instructions vers Base+displacement
> ones
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > that link has the same manual I have already and the LGFI instruction is
> not in it, unless I'm doing something wrong. Richard
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John McKown]

Download from here

http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SA22-7832-08


On Tue, Jul 9, 2013 at 3:17 PM, Richard Verville wrote:

> Now I feel really stupid, I went back to the POP manual I have and It's
> dated October 2001. I just tried the LGFI instruction and it compiles . Now
> I need to get my hands on the latest POP manual...The control register R0
> has the extraction bit (if ISVK is allowed for example) , so we could test
> the bit before getting a privilege operation exception. Richard
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[J R]

Try this link:  

 http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf 

==
 
> Date: Tue, 9 Jul 2013 16:51:13 -0400
> From: r.vervi...@videotron.ca
> Subject: Re: Benchmark of Relative instructions vers Base+displacement ones
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> that link has the same manual I have already and the LGFI instruction is not 
> in it, unless I'm doing something wrong. Richard
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Richard Verville]

that link has the same manual I have already and the LGFI instruction is not in 
it, unless I'm doing something wrong. Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[Richard Verville]

Now I feel really stupid, I went back to the POP manual I have and It's dated 
October 2001. I just tried the LGFI instruction and it compiles . Now I need to 
get my hands on the latest POP manual...The control register R0 has the 
extraction bit (if ISVK is allowed for example) , so we could test the bit 
before getting a privilege operation exception. Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Benchmark of Relative instructions vers Base+displacement ones

[John McKown]

Why not use IILF? It inserts a full word immediate value into the lower
fullword of the specified register. There are a bunch of the IIxx
instructions to load to full word or half words into any of the 2 full word
or 4 halfwords within a given register with an immediate value. Gotta have
the proper hardware, of course

There is also an LGFI .It loads a fullword immediate value into the Grande
register. The sign bit is propogated into the high word of the Grande
register. This assumes you're on the proper hardware level.

I can, maybe, see why ISVK would be protected. If anybody could use, the
malevolent programmer could use it to scan memory for memory areas that
could be corrupted without detection. This would be especially nasty for
that code which still insists on getting common memory (CSA, ECSA in z/OS,
I don't know z/VSE) in a user's protect key "because it's easier". Maybe
z/VSE people are not so stupid.

I looked at what is in control register 0 and didn't personally find
anything of interest.

On Tue, Jul 9, 2013 at 2:30 PM, Richard Verville wrote:

> Has anyone done benchmarks on different scenarios with instructions with
> immediate & relative instructions versus the old instructions. I have to
> rewrite some code for CICS on zOS & VSE and I wonder if it's worth it. Also
> I can't find a Load Fullword Immediate instruction (like LHI) where the
> intent is to load a value greater than 64K into a register and finally, why
> can't we inspect control register 0 in problem state (without the
> extraction bit on), instructions like ISVK should be "free", don't you
> think ? Richard
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Benchmark of Relative instructions vers Base+displacement ones

[Richard Verville]

Has anyone done benchmarks on different scenarios with instructions with 
immediate & relative instructions versus the old instructions. I have to 
rewrite some code for CICS on zOS & VSE and I wonder if it's worth it. Also I 
can't find a Load Fullword Immediate instruction (like LHI) where the intent is 
to load a value greater than 64K into a register and finally, why can't we 
inspect control register 0 in problem state (without the extraction bit on), 
instructions like ISVK should be "free", don't you think ? Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN