Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-18 Thread Paul Gilmartin
On Sun, 18 Aug 2019 20:43:52 +, Seymour J Metz wrote:
>
> 5. No memory pricing for any of the 7 dwarves (BUNCH,  RCA and General 
> Electric),
>Bendix, Data General, DEC, PB, Philco,  SDS, Sylvania, TRW or the major 
> European manufacturers.
> 
The DEC PDP-6 was relentlessly asynchronous (no clock!) with complex
operand-sensitive timings.  It allowed (core) memory in an outboard chassis,
and the timing chart said something like "Add 3 nsec/foot of cable for
operands in outboard chassis."

-- gil

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


Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-18 Thread Seymour J Metz
I find the chart rather strange for several reasons.

 1. In 1957 transistors an vacuum tubes were used for registers; transistors 
were
 far too expensive to be relevant to memory prices.

 2. No pricing for delay line (used through the IBM 2848) and 
drum ((IBM 650, RR Solid State 80/90) memory.

 3. No pricing for core on IBM 700 or 7000 series machines

 4 No pricing for other magnetic memory, e.g., rod, thin film

 5. No memory pricing for any of the 7 dwarves (BUNCH,  RCA and General 
Electric),
Bendix, Data General, DEC, PB, Philco,  SDS, Sylvania, TRW or the major 
European manufacturers.

 6. No pricing of core or semiconductor memory for most models of the S/370,
including the initial lineup


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Friday, August 16, 2019 7:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reason for 2 digit years was Re: Instruction speeds

I'd note this fun page:

https://secure-web.cisco.com/18kuXr81FRG9p54gqADcWVkcYmTQXffhiK4Ers5F11xSKS6wAIAKzH6d7DowqDutj_r9tF6_H62YEDeLgP3BtD5mFAXomrWZ3rdpM8Tv79hcatwYgpAAA1HVZiqmiz-ZKectudTasQg-0QUBg6UC93k4Cq09awLJXU1-wz5BkBWY0Kae1Z_VZ2piGZNPnTQrstLjB_5FqNyx1CmMfBQZnTCMPcA1CgZtMSw75zndRzG4pbNLjO8as-mvfS_1vF52YEwZ9wDdr06jxCr1DQhvUOD36BKlVLhAQ2w7xF19vLtsp1NzTU8CiWdRe7EqHq9I0NLR8L18Pppyau17BLAulyq1ogLNFCHrvm0suaolNFq52xSqumj5_qnU30DTBrNkkOfBSCRh2Y4VsL3MLh46OYdja4GTvg-8Uj8mqN4eG6Rxl5JexelKmSCZET9_PaOR1/https%3A%2F%2Fweb.archive.org%2Fweb%2F20170108175446%2Fhttp%3A%2F%2Fwww.jcmit.com%2Fmemoryprice.htm
 
<https://secure-web.cisco.com/1ubUAE-Ed9qJXDyYX340ZF9ZQ--16Z7krh8ve8sokSqb8l5-GoQPtSyLbAfSzKnqsT4PF0E6uMrqa9eIY-u3SggrS1yMKq9OzAvSov_pITItlShIvOIp_rtJnVV2TfyoIfXwh3GMxi74OHJc4ZKzj3qK7koCpXAjufeGE0DbBwz3WH2Xtj2aet_bmRnl3P81S_ypX9u3P-ZTqlz_io6bM5oD1t9V2AEsLSX0xMSFJVBAKhdGl4pPr-i30D_whBJR7Q85T691aS-4Z-U8EJrC_wGYdbNmSxJAq6tsx7G1iwOTtzM58Lk9f3XkneMqW9YyVrSQokGQctbZrgoJU-azQ2-YI8slb8rCxsdL6JLbYmK5Tcc0Mq8z0AoQxqxOAcY0nQdivlMTmohwfh1hqZRkE6DbF8eYQEWE7U10nC8DZciN0BR92Howq5JtiLjcapT3I/https%3A%2F%2Fweb.archive.org%2Fweb%2F20170108175446%2Fhttp%3A%2Fwww.jcmit.com%2Fmemoryprice.htm>


--
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: Reason for 2 digit years was Re: Instruction speeds

2019-08-16 Thread Phil Smith III
I'd note this fun page:

https://web.archive.org/web/20170108175446/http://www.jcmit.com/memoryprice.htm 

 


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


Re: Instruction speeds

2019-08-16 Thread David Crayford

On 2019-08-16 3:17 AM, Tony Harminc wrote:

This is really interesting. For those put off by the "C++" note that the
issue has nothing whatsoever to do with C++. It is a pure branch prediction
issue. Picture a program that computes an array of pseudo-random 8-bit
integers from 0 to 255. Then it solves the problem "what is the sum of all
of the numbers in the table greater than or equal to 128?" It does that
with the obvious loop, which then contains

IC   R0,next_table_byte
CHI  R0,128
JL   *+6
AR   R2,R0

The assertion of the thread -- and I don't doubt it -- is that the above
code uses 1/6 the CPU time if you first sort the table. (Obviously, a
stupid way of doing things: you could sort the table high to low and then
exit once you got a value below 128; but that's not the point.)

It illustrates the value of, or problem with, depending on your point of
view, branch prediction. If the table is random then the outcome of the
CHI/JL is unpredictable, and the branch prediction is at best useless and
at worst counter-productive. But if the table is sorted, then the branch
prediction has a chance to be right most of the time.


Of course the sort doesn't generally come free. As well as the basic CPU
cost (typically n log n for any modern sort), it will have some amount of
startup CPU and additional memory references. Yes, of course I understand
that this is an example to demonstrate branch prediction. But in the Real
World, branch prediction is just one of many aspects of modern CPUs that
are hard to predict.


I think that was the pertinent point of the thread that even with the 
overhead over the sort it was faster

than processing an unsorted array.




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


Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Paul Gilmartin
On Thu, 15 Aug 2019 00:46:00 -0500, Support, DUNNIT SYSTEMS LTD. wrote:

>2 digit years I recall a shop who throughout the 70's implemented 1 digit 
>year dates across their files because of the precious cost and availability of 
>DASD space. In 1979, someone there took are hard look at what the future held 
>in store. So they did a full conversion project and changed all of their date 
>fields to. 2 digit year dates!
>
I'll go 20% better:

DEC PDP-8 had 12-bit words.  OS 8 stored each date in a single 12-bit
word: 5 bits for day; 4 bits for month; 3 bits for year-1970.  I was not
in a position to confront it after about 1976.

-- gil

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


Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Jesse 1 Robinson
Ah yes. I have a calendar application that reminds me I'm really old. But my 
very first job in IT as an application programmer trainee was in 1978. So I'm 
kinda like the guy in that old up-down intermarriage puzzle who can be 
considered my own grandfather. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 15, 2019 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Reason for 2 digit years was Re: Instruction speeds

>  foremoms and foredads

Some of us were there at the time. I've lost track of the number of times that 
I've criticized something only to be accused, decades later, of only having 
"20-20 hindsight". W4 aren't allo newbies.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Wednesday, August 14, 2019 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reason for 2 digit years was  Re: Instruction speeds

It's a modern day cottage industry--or hobby maybe--to excoriate our foremoms 
and foredads for the reckless choice they made decades ago to store dates in 
two-digit format. Making our lives miserable in the process. OTOH I remember 
reading some diary excerpts from US Civil War soldiers who routinely recorded 
dates as 61, 63, and so on.

Suppose you were an influencer in, say, 1975. Would you walk into an 
application design meeting and propose *any* change to date representation? 
There were already countless date fields stored in other intersecting 
applications. Those would have to change also or be interfaced only with 
conversion routines.

I think the only point in IT history where a radical change actually made sense 
was just when it happened: right ahead of the wrecking ball. And rather than 
saturate the landscape with a gajillion *useless* year digits, many companies 
were content to implement sliding windows that permanently solved the problem 
with minimal extra storage space.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Clark Morris
Sent: Wednesday, August 14, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Reason for 2 digit years was Re: Instruction speeds

[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main 
sme...@gmu.edu (Seymour J Metz) wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
>
The conversion to and from binary would have been costly in CPU time and for 
dates stored as packed decimal 0yymmdds the use of the high order nibble would 
have worked at the cost of complexity.  I suspect that the real saving was in 
data entry and the desire to fit as much information on one 80 byte punch card 
as well as on to a 132 character print line.  I note that my credit cards still 
use 2 digit years.

Clark Morris
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on 
>behalf of Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000, 
>insurance companies apparently coasted along because they had ALWAYS needed to 
>handle four-digit years from the inception of IT. For them it was business as 
>usual.
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On 
>Behalf Of Seymour J Metz
>Sent: Wednesday, August 14, 2019 7:49 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Instruction speeds
>
>> That assumes that you know what is unnecessary. The smart money says that

Re: Instruction speeds

2019-08-15 Thread Tony Harminc
On Wed, 14 Aug 2019 at 18:56, Charles Mills  wrote:

> This is really interesting. For those put off by the "C++" note that the
> issue has nothing whatsoever to do with C++. It is a pure branch prediction
> issue. Picture a program that computes an array of pseudo-random 8-bit
> integers from 0 to 255. Then it solves the problem "what is the sum of all
> of the numbers in the table greater than or equal to 128?" It does that
> with the obvious loop, which then contains
>
> IC   R0,next_table_byte
> CHI  R0,128
> JL   *+6
> AR   R2,R0
>
> The assertion of the thread -- and I don't doubt it -- is that the above
> code uses 1/6 the CPU time if you first sort the table. (Obviously, a
> stupid way of doing things: you could sort the table high to low and then
> exit once you got a value below 128; but that's not the point.)
>
> It illustrates the value of, or problem with, depending on your point of
> view, branch prediction. If the table is random then the outcome of the
> CHI/JL is unpredictable, and the branch prediction is at best useless and
> at worst counter-productive. But if the table is sorted, then the branch
> prediction has a chance to be right most of the time.
>

Of course the sort doesn't generally come free. As well as the basic CPU
cost (typically n log n for any modern sort), it will have some amount of
startup CPU and additional memory references. Yes, of course I understand
that this is an example to demonstrate branch prediction. But in the Real
World, branch prediction is just one of many aspects of modern CPUs that
are hard to predict. For that matter branch prediction itself is more than
just remembering which way previous branches went. As a rule, if you know
which path is more likely (and you have reason to think that the predictor
doesn't know better than you do), you should make the likely path the
non-branch one. Similarly you should make the test as unlikely to branch as
possible, e.g. arrange the algorithm to use JL rather than JNH, even if JNH
might give the same result. The predictor, if it knows nothing else, is
going to guess branching based on the number of bits on in the mask.


> There's a lot more than that in the thread, and it fundamentally has to do
> with modern CPU technology, not C++.
>

Yup. It is a good thread, with a nice explanation/analogy.

Tony H.

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


Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Seymour J Metz
If you don't like binarythen there's unsigned packed decimal. The code to 
convert between packed decimal and unsigned packed decimal is not exactly 
rocket science.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Wednesday, August 14, 2019 6:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Reason for 2 digit years was  Re: Instruction speeds

[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
>
The conversion to and from binary would have been costly in CPU time
and for dates stored as packed decimal 0yymmdds the use of the high
order nibble would have worked at the cost of complexity.  I suspect
that the real saving was in data entry and the desire to fit as much
information on one 80 byte punch card as well as on to a 132 character
print line.  I note that my credit cards still use 2 digit years.

Clark Morris
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000, 
>insurance companies apparently coasted along because they had ALWAYS needed to 
>handle four-digit years from the inception of IT. For them it was business as 
>usual.
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Seymour J Metz
>Sent: Wednesday, August 14, 2019 7:49 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Instruction speeds
>
>> That assumes that you know what is unnecessary. The smart money says that 
>> the unnecessary code will turn out to be necessary, at the least convenient 
>> time.
>
>> A nice example is how to determine leap years: from as long as I program the 
>> flow is:
>>- dividable by 4?
>>- dividable by 100?
>>- dividable by 400?
>
>The last 2 are completely unnecessary until the year 2100.
>
>And in the year 2100 people will curse you for deciding that it's unnecessary.
>
>Après Moi Le Déluge (Après nous le deluge for purists.)

--
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: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Seymour J Metz
>  foremoms and foredads

Some of us were there at the time. I've lost track of the number of times that 
I've criticized something only to be accused, decades later, of only having 
"20-20 hindsight". W4 aren't allo newbies.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Wednesday, August 14, 2019 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reason for 2 digit years was  Re: Instruction speeds

It's a modern day cottage industry--or hobby maybe--to excoriate our foremoms 
and foredads for the reckless choice they made decades ago to store dates in 
two-digit format. Making our lives miserable in the process. OTOH I remember 
reading some diary excerpts from US Civil War soldiers who routinely recorded 
dates as 61, 63, and so on.

Suppose you were an influencer in, say, 1975. Would you walk into an 
application design meeting and propose *any* change to date representation? 
There were already countless date fields stored in other intersecting 
applications. Those would have to change also or be interfaced only with 
conversion routines.

I think the only point in IT history where a radical change actually made sense 
was just when it happened: right ahead of the wrecking ball. And rather than 
saturate the landscape with a gajillion *useless* year digits, many companies 
were content to implement sliding windows that permanently solved the problem 
with minimal extra storage space.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Clark Morris
Sent: Wednesday, August 14, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Reason for 2 digit years was Re: Instruction speeds

[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main 
sme...@gmu.edu (Seymour J Metz) wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
>
The conversion to and from binary would have been costly in CPU time and for 
dates stored as packed decimal 0yymmdds the use of the high order nibble would 
have worked at the cost of complexity.  I suspect that the real saving was in 
data entry and the desire to fit as much information on one 80 byte punch card 
as well as on to a 132 character print line.  I note that my credit cards still 
use 2 digit years.

Clark Morris
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on
>behalf of Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000, 
>insurance companies apparently coasted along because they had ALWAYS needed to 
>handle four-digit years from the inception of IT. For them it was business as 
>usual.
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On
>Behalf Of Seymour J Metz
>Sent: Wednesday, August 14, 2019 7:49 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Instruction speeds
>
>> That assumes that you know what is unnecessary. The smart money says that 
>> the unnecessary code will turn out to be necessary, at the least convenient 
>> time.
>
>> A nice example is how to determine leap years: from as long as I program the 
>> flow is:
>>- dividable by 4?
>>- dividable by 100?
>>- dividable by 400?
>
>The last 2 are completely unnecessary until the year 2100.
>
>And in the year 2100 people will curse you for deciding that it's unnecessary.
>
>Après Moi Le Déluge (Après nous le deluge for purists.)


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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Seymour J Metz
> IBM 701 with 2048, later 4095 36 bit word

ITYM 4096

The Williams Tube was one of those technologies that I was too young to know 
about, for which I am grateful.

> two digit dates and Packed Decimal 

It's not that hard to used unsigned packed decimal for a three digit year in 
two bytes.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Nightwatch RenBand 
Sent: Thursday, August 15, 2019 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Reason for 2 digit years was Re: Instruction speeds

My first programming experience was in the mid to late 1960's and even then
there were "old timers" who explained things like this in lurid detail;
perhaps, as King Henry V said " with advantages what feats he did that
day". As I remember they said that the problem was memory.  They programmed
on IBM 701 with 2048, later 4095 36 bit wordd of CRT memory.  Yes, you
could output to tape or punched cards, but you had to do your calculations
in main memory.  Virtual memory had been proven in the labs, but for years
programmers struggled with "overlays" where your code actually moved the
next routine into memory before continuing processing.  Naturally, the
smaller you could make your code and data areas the less you would have to
do overlays, so two digit dates and Packed Decimal saved main memory at the
cost of cpu cycles.  Also the reason that the ZAP and AP commands were
devised.  CPU cycles are a cost, but remember that overlays take many more
instructions than packing dates, and programmer time was just as expensive,
perhaps more so, than today (since wages have been close to stagnant since
about 1980).  Oh, did I mention that they were programming with early
Assembler which did not include symbolics?  You had to remember the offsets
for every piece of data as well as the location of the instructions in
memory.  Perhaps that's why so many of them smoked and drank.
SO that's the story as they saw it.  It may not stand up to rigorous
computer science analysis, but it "seemed like a good idea at the time".
Which reminds me of my favorite joke.  From the Maginficent Seven"
https://www.youtube.com/watch?v=0ieicflBG_Y

Calvera: What I don't understand is why a man like you took the job in the
first place, hum? Why, heh?

Chris: I wonder myself.

Calvera: No, come on, tell me why.

Vin: It's like this fellow I knew in El Paso. One day, he just took all his
clothes off and jumped in a mess of cactus. I asked him that same question,
"Why?"

Calvera: And?

Vin: He said, "It seemed like a good idea at the time."

--
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: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Matthew Stitt
I worked at such company that had 1 digit years.  The routine(s) to keep them 
straight across the decades I never did fully understand.

OTOH, I also worked at a small Insurance company.  The best (non) joke was when 
a client called regarding a new build discount she was getting on her house.  
The house was built in 1892.

Matthew

On Thu, 15 Aug 2019 00:46:00 -0500, Support, DUNNIT SYSTEMS LTD. 
 wrote:

>2 digit years I recall a shop who throughout the 70's implemented 1 digit 
>year dates across their files because of the precious cost and availability of 
>DASD space. In 1979, someone there took are hard look at what the future held 
>in store. So they did a full conversion project and changed all of their date 
>fields to. 2 digit year dates!
>

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


Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Nightwatch RenBand
My first programming experience was in the mid to late 1960's and even then
there were "old timers" who explained things like this in lurid detail;
perhaps, as King Henry V said " with advantages what feats he did that
day". As I remember they said that the problem was memory.  They programmed
on IBM 701 with 2048, later 4095 36 bit wordd of CRT memory.  Yes, you
could output to tape or punched cards, but you had to do your calculations
in main memory.  Virtual memory had been proven in the labs, but for years
programmers struggled with "overlays" where your code actually moved the
next routine into memory before continuing processing.  Naturally, the
smaller you could make your code and data areas the less you would have to
do overlays, so two digit dates and Packed Decimal saved main memory at the
cost of cpu cycles.  Also the reason that the ZAP and AP commands were
devised.  CPU cycles are a cost, but remember that overlays take many more
instructions than packing dates, and programmer time was just as expensive,
perhaps more so, than today (since wages have been close to stagnant since
about 1980).  Oh, did I mention that they were programming with early
Assembler which did not include symbolics?  You had to remember the offsets
for every piece of data as well as the location of the instructions in
memory.  Perhaps that's why so many of them smoked and drank.
SO that's the story as they saw it.  It may not stand up to rigorous
computer science analysis, but it "seemed like a good idea at the time".
Which reminds me of my favorite joke.  From the Maginficent Seven"
https://www.youtube.com/watch?v=0ieicflBG_Y

Calvera: What I don't understand is why a man like you took the job in the
first place, hum? Why, heh?

Chris: I wonder myself.

Calvera: No, come on, tell me why.

Vin: It's like this fellow I knew in El Paso. One day, he just took all his
clothes off and jumped in a mess of cactus. I asked him that same question,
"Why?"

Calvera: And?

Vin: He said, "It seemed like a good idea at the time."

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


Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Mike Schwab
I interned in a catalog sales company in the marketing department in
1984.  Used 1 digit year and purged sales data over 6 years old.

On Thu, Aug 15, 2019 at 12:46 AM Support, DUNNIT SYSTEMS LTD.
 wrote:
>
> 2 digit years I recall a shop who throughout the 70's implemented 1 digit 
> year dates across their files because of the precious cost and availability 
> of DASD space. In 1979, someone there took are hard look at what the future 
> held in store. So they did a full conversion project and changed all of their 
> date fields to. 2 digit year dates!
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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


Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-14 Thread Support, DUNNIT SYSTEMS LTD.
2 digit years I recall a shop who throughout the 70's implemented 1 digit 
year dates across their files because of the precious cost and availability of 
DASD space. In 1979, someone there took are hard look at what the future held 
in store. So they did a full conversion project and changed all of their date 
fields to. 2 digit year dates!

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


Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-14 Thread Clark Morris
[Default] On 14 Aug 2019 15:50:58 -0700, in bit.listserv.ibm-main
jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:

>It's a modern day cottage industry--or hobby maybe--to excoriate our foremoms 
>and foredads for the reckless choice they made decades ago to store dates in 
>two-digit format. Making our lives miserable in the process. OTOH I remember 
>reading some diary excerpts from US Civil War soldiers who routinely recorded 
>dates as 61, 63, and so on. 
>
>Suppose you were an influencer in, say, 1975. Would you walk into an 
>application design meeting and propose *any* change to date representation? 
>There were already countless date fields stored in other intersecting 
>applications. Those would have to change also or be interfaced only with 
>conversion routines. 
>
>I think the only point in IT history where a radical change actually made 
>sense was just when it happened: right ahead of the wrecking ball. And rather 
>than saturate the landscape with a gajillion *useless* year digits, many 
>companies were content to implement sliding windows that permanently solved 
>the problem with minimal extra storage space.  
>
As someone involved in a Year 2000 project where I both validated the
functioning of the windows used by one software vendor and wrote the
date subroutine used for 4 digit year date handling, I guarantee
sliding or fixed windows do not necessarily solve the problem for all
time.  The sliding window may well do it going forward depending on
the data other than for year 00 and if keyed against a current 4 digit
year handle that it might even do that.  However, the window only
works where the range of dates in the active data is 100 years or less
and would fail on birth dates for all of the centenarians among us
including a retired pastor of my church. Using sliding windows could
be dicey when dealing with historic data.  In general, each
application should be reviewed to see if long term 2 digit years can
lead to wrong results regardless of windowing provision chosen.

Clark Morris 
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Clark Morris
>Sent: Wednesday, August 14, 2019 3:29 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Reason for 2 digit years was Re: Instruction speeds
>
>[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main 
>sme...@gmu.edu (Seymour J Metz) wrote:
>
>>There were other options to reduce the storage requirement of a date, e.g., 
>>store them in binary.
>>
>The conversion to and from binary would have been costly in CPU time and for 
>dates stored as packed decimal 0yymmdds the use of the high order nibble would 
>have worked at the cost of complexity.  I suspect that the real saving was in 
>data entry and the desire to fit as much information on one 80 byte punch card 
>as well as on to a 132 character print line.  I note that my credit cards 
>still use 2 digit years.
>
>Clark Morris  
>>
>>--
>>Shmuel (Seymour J.) Metz
>>http://mason.gmu.edu/~smetz3
>>
>>____________
>>From: IBM Mainframe Discussion List  on 
>>behalf of Jesse 1 Robinson 
>>Sent: Wednesday, August 14, 2019 12:10 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: Instruction speeds
>>
>>A couple of observations on Y2K accommodation.
>>
>>-- As my shop was slogging through remediation required for year 2000, 
>>insurance companies apparently coasted along because they had ALWAYS needed 
>>to handle four-digit years from the inception of IT. For them it was business 
>>as usual.
>>
>>-- Can't cite attribution, but I remember the calculation that despite our 
>>late 1990s poignant misery, the ancient choice to represent dates with two 
>>digits was actually economically correct. The burdensome cost of both media 
>>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>>remediation. It's easy to ask what difference two bytes would have made, but 
>>the hard-money cost of billions and billions of 'extra' bytes would have been 
>>substantial.
>>
>>.
>>.
>>J.O.Skip Robinson
>>Southern California Edison Company
>>Electric Dragon Team Paddler
>>SHARE MVS Program Co-Manager
>>323-715-0595 Mobile
>>626-543-6132 Office ?=== NEW
>>robin...@sce.com
>>
>>-Original Message-
>>From: IBM Mainframe Discussion List  On 
>>Behalf Of Seymour J Metz
>>Sent: Wednesday, August 14, 2019 7:49 AM
>>To: IBM-MAIN@LISTSE

Re: Instruction speeds

2019-08-14 Thread Charles Mills
This is really interesting. For those put off by the "C++" note that the issue 
has nothing whatsoever to do with C++. It is a pure branch prediction issue. 
Picture a program that computes an array of pseudo-random 8-bit integers from 0 
to 255. Then it solves the problem "what is the sum of all of the numbers in 
the table greater than or equal to 128?" It does that with the obvious loop, 
which then contains

IC   R0,next_table_byte
CHI  R0,128
JL   *+6
AR   R2,R0

The assertion of the thread -- and I don't doubt it -- is that the above code 
uses 1/6 the CPU time if you first sort the table. (Obviously, a stupid way of 
doing things: you could sort the table high to low and then exit once you got a 
value below 128; but that's not the point.)

It illustrates the value of, or problem with, depending on your point of view, 
branch prediction. If the table is random then the outcome of the CHI/JL is 
unpredictable, and the branch prediction is at best useless and at worst 
counter-productive. But if the table is sorted, then the branch prediction has 
a chance to be right most of the time.

There's a lot more than that in the thread, and it fundamentally has to do with 
modern CPU technology, not C++. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Tuesday, August 13, 2019 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Some interesting information on branch prediction in that paper.

If you've got a z/OS C++ compiler try this snippet out, it's fascinating:

https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array

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


Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-14 Thread Jesse 1 Robinson
It's a modern day cottage industry--or hobby maybe--to excoriate our foremoms 
and foredads for the reckless choice they made decades ago to store dates in 
two-digit format. Making our lives miserable in the process. OTOH I remember 
reading some diary excerpts from US Civil War soldiers who routinely recorded 
dates as 61, 63, and so on. 

Suppose you were an influencer in, say, 1975. Would you walk into an 
application design meeting and propose *any* change to date representation? 
There were already countless date fields stored in other intersecting 
applications. Those would have to change also or be interfaced only with 
conversion routines. 

I think the only point in IT history where a radical change actually made sense 
was just when it happened: right ahead of the wrecking ball. And rather than 
saturate the landscape with a gajillion *useless* year digits, many companies 
were content to implement sliding windows that permanently solved the problem 
with minimal extra storage space.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Clark Morris
Sent: Wednesday, August 14, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Reason for 2 digit years was Re: Instruction speeds

[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main 
sme...@gmu.edu (Seymour J Metz) wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
>
The conversion to and from binary would have been costly in CPU time and for 
dates stored as packed decimal 0yymmdds the use of the high order nibble would 
have worked at the cost of complexity.  I suspect that the real saving was in 
data entry and the desire to fit as much information on one 80 byte punch card 
as well as on to a 132 character print line.  I note that my credit cards still 
use 2 digit years.

Clark Morris  
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on 
>behalf of Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000, 
>insurance companies apparently coasted along because they had ALWAYS needed to 
>handle four-digit years from the inception of IT. For them it was business as 
>usual.
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On 
>Behalf Of Seymour J Metz
>Sent: Wednesday, August 14, 2019 7:49 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Instruction speeds
>
>> That assumes that you know what is unnecessary. The smart money says that 
>> the unnecessary code will turn out to be necessary, at the least convenient 
>> time.
>
>> A nice example is how to determine leap years: from as long as I program the 
>> flow is:
>>- dividable by 4?
>>- dividable by 100?
>>- dividable by 400?
>
>The last 2 are completely unnecessary until the year 2100.
>
>And in the year 2100 people will curse you for deciding that it's unnecessary.
>
>Après Moi Le Déluge (Après nous le deluge for purists.)


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


Reason for 2 digit years was Re: Instruction speeds

2019-08-14 Thread Clark Morris
[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
>
The conversion to and from binary would have been costly in CPU time
and for dates stored as packed decimal 0yymmdds the use of the high
order nibble would have worked at the cost of complexity.  I suspect
that the real saving was in data entry and the desire to fit as much
information on one 80 byte punch card as well as on to a 132 character
print line.  I note that my credit cards still use 2 digit years.

Clark Morris  
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000, 
>insurance companies apparently coasted along because they had ALWAYS needed to 
>handle four-digit years from the inception of IT. For them it was business as 
>usual.
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Seymour J Metz
>Sent: Wednesday, August 14, 2019 7:49 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Instruction speeds
>
>> That assumes that you know what is unnecessary. The smart money says that 
>> the unnecessary code will turn out to be necessary, at the least convenient 
>> time.
>
>> A nice example is how to determine leap years: from as long as I program the 
>> flow is:
>>- dividable by 4?
>>- dividable by 100?
>>- dividable by 400?
>
>The last 2 are completely unnecessary until the year 2100.
>
>And in the year 2100 people will curse you for deciding that it's unnecessary.
>
>Après Moi Le Déluge (Après nous le deluge for purists.)

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


Re: Instruction speeds

2019-08-14 Thread Edward Finnell
IBM has published the LSPR numbers for thirty years. They're a ballpark of what 
to expect.Each company should have a benchmark workload for capacity planning 
and growth. In 2017 WDC came out with MF counters to help measure the effects 
of different 
workloads.http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TC66 

There have been some whoppers in reporting. Like the 9672-n3 to n4 weren't 
adding up to expectations. Cheryl pointed out what had happened was they ran 
out of room on the chip and had to add an off-board processor for some of the 
instructions. It was really nasty in some of the COBOL programs with Indexed by 
usage was high. So in the LSPR numbers no COBOL pgms with Indexed-by were used.
There were also a couple z9's sent back because they were slower than the 
predecessors with 'old COBOL'. Always something...In a message dated 8/14/2019 
1:50:42 PM Central Standard Time, jcew...@acm.org writes:
In 1965, even thoseexposed to S/360 would have had no experience yet to make 
them assumethe architecture would be stable enough and kept as a subset of 
futurearchitectures to allow running the same code decades later, much lesshave 
z-architecture hardware supporting the same instructions as asubset in 2019.

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


Re: Instruction speeds

2019-08-14 Thread Raphaël Jacquot

Le 14/08/2019 à 18:10, Jesse 1 Robinson a écrit :

A couple of observations on Y2K accommodation.

-- As my shop was slogging through remediation required for year 2000, 
insurance companies apparently coasted along because they had ALWAYS needed to 
handle four-digit years from the inception of IT. For them it was business as 
usual.

-- Can't cite attribution, but I remember the calculation that despite our late 
1990s poignant misery, the ancient choice to represent dates with two digits 
was actually economically correct. The burdensome cost of both media and memory 
storage in, say, 1970, outweighed on balance the eventual cost of remediation. 
It's easy to ask what difference two bytes would have made, but the hard-money 
cost of billions and billions of 'extra' bytes would have been substantial.


the smart solution would have been to store year as 2 bytes binary 
integer, they'd have been good for 65535 years...


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


Re: Instruction speeds

2019-08-14 Thread Paul Gilmartin
On Wed, 14 Aug 2019 11:34:14 -0700, Charles Mills wrote:

>... Not to mention that time in microseconds since 1900 would have fit in a 
>64-bit integer.
>
With a several thousand year range.  And when another choice was made
there were many extant birth dates and contract dates prior to 1900.  I
still feel that ETOD should be made signed to accommodate historic dates.

>Of course, ease of conversion and formatting is/was also a factor. The year 
>could have been stored in binary, but that might have required conversion from 
>and to decimal as punched into Hollerith cards and printed on reports.
> 
IBM, more than most other suppliers, was swayed by a desire that the
storage format be human-readable.  I suspect this was the motive for
making packed decimal sign-magnitude rather than 10s-complement
which would have provided 5 times the range in the same storage and
avoided the need for a recomplement when the result has unexpected
sign.

-- gil

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


Re: Instruction speeds

2019-08-14 Thread Charles Mills
Yes, I am sometimes amazed at the choices made, the contradiction between 
omitting data to save storage, while storing the remainder in an inefficient 
format. An example I dealt with a lot was the "SMF timestamp" format: eight 
bytes consisting of the time in hundredths of a second past midnight in binary 
followed by the date in "packed Julian": 00 yy dd dF. No century, even though 
there are two unused and one constant nibbles; and time in hundredths, even 
though milliseconds or ten-thousandths would have fit in a 32-bit integer. (And 
yes, I know they kludged the century for Y2K into one unused nibble.) Not to 
mention that time in microseconds since 1900 would have fit in a 64-bit integer.

Of course, ease of conversion and formatting is/was also a factor. The year 
could have been stored in binary, but that might have required conversion from 
and to decimal as punched into Hollerith cards and printed on reports.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Wednesday, August 14, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

There were other options to reduce the storage requirement of a date, e.g., 
store them in binary.

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


Re: Instruction speeds

2019-08-14 Thread Paul Gilmartin
On Wed, 14 Aug 2019 17:21:06 +, Seymour J Metz wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
> 
In some cases, dates have been stored in two-byte signed decimal, biased
by -1900, supporting dates through 2899 with minimal code change.

>
>From: Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
> 
Me, too.  However I doubt that many organizations invested those savings
in reliable securities to be redeemed for the eventual cost of remediation.

In the mid 80s, I suggested that a product we were designing store 4-digit
years in anticipation of Y2K.  Overruled by manager:
o No then available OS interface reported 4-digit years.
o No need; who cares?!

-- gil

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


Re: Instruction speeds

2019-08-14 Thread Seymour J Metz
There were other options to reduce the storage requirement of a date, e.g., 
store them in binary.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Wednesday, August 14, 2019 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

A couple of observations on Y2K accommodation.

-- As my shop was slogging through remediation required for year 2000, 
insurance companies apparently coasted along because they had ALWAYS needed to 
handle four-digit years from the inception of IT. For them it was business as 
usual.

-- Can't cite attribution, but I remember the calculation that despite our late 
1990s poignant misery, the ancient choice to represent dates with two digits 
was actually economically correct. The burdensome cost of both media and memory 
storage in, say, 1970, outweighed on balance the eventual cost of remediation. 
It's easy to ask what difference two bytes would have made, but the hard-money 
cost of billions and billions of 'extra' bytes would have been substantial.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, August 14, 2019 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Instruction speeds

> That assumes that you know what is unnecessary. The smart money says that the 
> unnecessary code will turn out to be necessary, at the least convenient time.

> A nice example is how to determine leap years: from as long as I program the 
> flow is:
>- dividable by 4?
>- dividable by 100?
>- dividable by 400?

The last 2 are completely unnecessary until the year 2100.

And in the year 2100 people will curse you for deciding that it's unnecessary.

Après Moi Le Déluge (Après nous le deluge for purists.)

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Vernooij, Kees (ITOP NM) - KLM 
Sent: Wednesday, August 14, 2019 2:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

And: don't write unnecessary code.
A nice example is how to determine leap years: from as long as I program the 
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?

The last 2 are completely unnecessary until the year 2100.
How many useless instructions will have been executed for this reason in the 
150 years until 2100?
How much of our assembler code will live until 2100? Lots were not even 
prepared for 2000.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Seymour J Metz
> Sent: 13 August, 2019 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
>
> Avoid processor-specific optimizations; what is millicode on one box
> may not be on another. Worry first about getting your code correct and
> maintainable.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Christopher Y. Blaicher 
> Sent: Monday, August 12, 2019 9:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
>
> There is no instruction cycle time table.  There are some general
> guidelines you can follow.
>
> Don't overload cache.  Locality of reference for instructions and data
> is important.
>
> The machine will do out-of-order instruction processing, but there are
> limits.  If you load a register don't use it as a base register in the
> next instruction, if you can help it.
>
> MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up
> to about 32K.
>
> JUMPs are faster than BRANCHes.
>
> Don't use instructions that set the condition code, unless you need it.
>
> Millicode instructions have startup and shutdown overheads.  Many
> times you can go faster using open code to do what a millicode instruction 
> does.
>
> Here is one that has nothing to do with an instruction - Don't assign
> CPs from different drawers to an LPAR, that includes ZIIPs.  Task
> switching across drawers kills cache and kills performance.  You will
> lose hundreds, if not thousands, of cycles.
>
> There are some articles on the net that go over processor design and
> cache design.  The processor designs will give you a hint to the
> number of stages an instruction goes through.  Pipeline delays are
> what you try to avoid.
>
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
>
>
> -Original Message-
> From: IBM Mainframe Di

Re: Instruction speeds

2019-08-14 Thread Jesse 1 Robinson
A couple of observations on Y2K accommodation. 

-- As my shop was slogging through remediation required for year 2000, 
insurance companies apparently coasted along because they had ALWAYS needed to 
handle four-digit years from the inception of IT. For them it was business as 
usual. 

-- Can't cite attribution, but I remember the calculation that despite our late 
1990s poignant misery, the ancient choice to represent dates with two digits 
was actually economically correct. The burdensome cost of both media and memory 
storage in, say, 1970, outweighed on balance the eventual cost of remediation. 
It's easy to ask what difference two bytes would have made, but the hard-money 
cost of billions and billions of 'extra' bytes would have been substantial. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, August 14, 2019 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Instruction speeds

> That assumes that you know what is unnecessary. The smart money says that the 
> unnecessary code will turn out to be necessary, at the least convenient time.

> A nice example is how to determine leap years: from as long as I program the 
> flow is:
>- dividable by 4?
>- dividable by 100?
>- dividable by 400?

The last 2 are completely unnecessary until the year 2100.

And in the year 2100 people will curse you for deciding that it's unnecessary.

Après Moi Le Déluge (Après nous le deluge for purists.)

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Vernooij, Kees (ITOP NM) - KLM 
Sent: Wednesday, August 14, 2019 2:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

And: don't write unnecessary code.
A nice example is how to determine leap years: from as long as I program the 
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?

The last 2 are completely unnecessary until the year 2100.
How many useless instructions will have been executed for this reason in the 
150 years until 2100?
How much of our assembler code will live until 2100? Lots were not even 
prepared for 2000.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Seymour J Metz
> Sent: 13 August, 2019 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
>
> Avoid processor-specific optimizations; what is millicode on one box 
> may not be on another. Worry first about getting your code correct and 
> maintainable.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Christopher Y. Blaicher 
> Sent: Monday, August 12, 2019 9:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
>
> There is no instruction cycle time table.  There are some general 
> guidelines you can follow.
>
> Don't overload cache.  Locality of reference for instructions and data 
> is important.
>
> The machine will do out-of-order instruction processing, but there are 
> limits.  If you load a register don't use it as a base register in the 
> next instruction, if you can help it.
>
> MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up 
> to about 32K.
>
> JUMPs are faster than BRANCHes.
>
> Don't use instructions that set the condition code, unless you need it.
>
> Millicode instructions have startup and shutdown overheads.  Many 
> times you can go faster using open code to do what a millicode instruction 
> does.
>
> Here is one that has nothing to do with an instruction - Don't assign 
> CPs from different drawers to an LPAR, that includes ZIIPs.  Task 
> switching across drawers kills cache and kills performance.  You will 
> lose hundreds, if not thousands, of cycles.
>
> There are some articles on the net that go over processor design and 
> cache design.  The processor designs will give you a hint to the 
> number of stages an instruction goes through.  Pipeline delays are 
> what you try to avoid.
>
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 8:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Instruction speeds
>
> Hi everyone,
>
> I did some searching, but I didn't find anything that really discussed 
> this on the topic that I'm interested. Is there an

Re: Instruction speeds

2019-08-14 Thread Seymour J Metz
> That assumes that you know what is unnecessary. The smart money says that the 
> unnecessary code will turn out to be necessary, at the least convenient time.

> A nice example is how to determine leap years: from as long as I program the 
> flow is:
>- dividable by 4?
>- dividable by 100?
>- dividable by 400?

The last 2 are completely unnecessary until the year 2100.

And in the year 2100 people will curse you for deciding that it's unnecessary.

Après Moi Le Déluge (Après nous le deluge for purists.)

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Vernooij, Kees (ITOP NM) - KLM 
Sent: Wednesday, August 14, 2019 2:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

And: don't write unnecessary code.
A nice example is how to determine leap years: from as long as I program the 
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?

The last 2 are completely unnecessary until the year 2100.
How many useless instructions will have been executed for this reason in the 
150 years until 2100?
How much of our assembler code will live until 2100? Lots were not even 
prepared for 2000.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: 13 August, 2019 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
>
> Avoid processor-specific optimizations; what is millicode on one box may
> not be on another. Worry first about getting your code correct and
> maintainable.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Christopher Y. Blaicher 
> Sent: Monday, August 12, 2019 9:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
>
> There is no instruction cycle time table.  There are some general
> guidelines you can follow.
>
> Don't overload cache.  Locality of reference for instructions and data is
> important.
>
> The machine will do out-of-order instruction processing, but there are
> limits.  If you load a register don't use it as a base register in the
> next instruction, if you can help it.
>
> MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up to
> about 32K.
>
> JUMPs are faster than BRANCHes.
>
> Don't use instructions that set the condition code, unless you need it.
>
> Millicode instructions have startup and shutdown overheads.  Many times
> you can go faster using open code to do what a millicode instruction does.
>
> Here is one that has nothing to do with an instruction - Don't assign CPs
> from different drawers to an LPAR, that includes ZIIPs.  Task switching
> across drawers kills cache and kills performance.  You will lose hundreds,
> if not thousands, of cycles.
>
> There are some articles on the net that go over processor design and cache
> design.  The processor designs will give you a hint to the number of
> stages an instruction goes through.  Pipeline delays are what you try to
> avoid.
>
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 8:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Instruction speeds
>
> Hi everyone,
>
> I did some searching, but I didn't find anything that really discussed
> this on the topic that I'm interested. Is there anything published that
> compares the cycle times of the most used instructions?
>
> For example; moving an address between areas of storage. I would assume
> that executing a LOAD and STORE would be much quicker than executing a
> MVC.
>
> Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> WORD.
>
> Or does this really matter as much as ordering the instructions so they
> are optimized for the pipeline?
>
> --
> 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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
***

Re: Instruction speeds

2019-08-14 Thread Mike Schwab
Heck, just 30 year mortgages required printing 2000 in 1970.

On Wed, Aug 14, 2019 at 7:49 AM Pommier, Rex  wrote:
>
> Hi Kees,
>
> I respectfully (somewhat) disagree with your leap year calculation assertion. 
>  I used to work for a Surety company and now work for a life insurance 
> company.  In both cases we have policies that can reach out 50-100 years.  We 
> definitely need the 100 year rule in some calculations.  Yes, there are 
> definitely areas where one could forget about using the 100 year rule in leap 
> year calculations, but not always.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Vernooij, Kees (ITOP NM) - KLM
> Sent: Wednesday, August 14, 2019 1:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Instruction speeds
>
> And: don't write unnecessary code.
> A nice example is how to determine leap years: from as long as I program the 
> flow is:
> - dividable by 4?
> - dividable by 100?
> - dividable by 400?
>
> The last 2 are completely unnecessary until the year 2100.
> How many useless instructions will have been executed for this reason in the 
> 150 years until 2100?
> How much of our assembler code will live until 2100? Lots were not even 
> prepared for 2000.
>
> Kees.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Seymour J Metz
> > Sent: 13 August, 2019 19:23
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Instruction speeds
> >
> > Avoid processor-specific optimizations; what is millicode on one box
> > may not be on another. Worry first about getting your code correct and
> > maintainable.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > ____________
> > From: IBM Mainframe Discussion List  on
> > behalf of Christopher Y. Blaicher 
> > Sent: Monday, August 12, 2019 9:32 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Instruction speeds
> >
> > There is no instruction cycle time table.  There are some general
> > guidelines you can follow.
> >
> > Don't overload cache.  Locality of reference for instructions and data
> > is important.
> >
> > The machine will do out-of-order instruction processing, but there are
> > limits.  If you load a register don't use it as a base register in the
> > next instruction, if you can help it.
> >
> > MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up
> > to about 32K.
> >
> > JUMPs are faster than BRANCHes.
> >
> > Don't use instructions that set the condition code, unless you need it.
> >
> > Millicode instructions have startup and shutdown overheads.  Many
> > times you can go faster using open code to do what a millicode instruction 
> > does.
> >
> > Here is one that has nothing to do with an instruction - Don't assign
> > CPs from different drawers to an LPAR, that includes ZIIPs.  Task
> > switching across drawers kills cache and kills performance.  You will
> > lose hundreds, if not thousands, of cycles.
> >
> > There are some articles on the net that go over processor design and
> > cache design.  The processor designs will give you a hint to the
> > number of stages an instruction goes through.  Pipeline delays are
> > what you try to avoid.
> >
> > Chris Blaicher
> > Technical Architect
> > Syncsort, Inc.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Brian Chapman
> > Sent: Monday, August 12, 2019 8:48 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Instruction speeds
> >
> > Hi everyone,
> >
> > I did some searching, but I didn't find anything that really discussed
> > this on the topic that I'm interested. Is there anything published
> > that compares the cycle times of the most used instructions?
> >
> > For example; moving an address between areas of storage. I would
> > assume that executing a LOAD and STORE would be much quicker than
> > executing a MVC.
> >
> > Or executing a LOAD ADDRESS to increment a register instead of ADD
> > HALF WORD.
> >
> > Or does this really matter as much as ordering the instructions so
> > they are optimized for the pipeline?
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to list

Re: Instruction speeds

2019-08-14 Thread Charles Mills
I TOTALLY disagree (with Kees)!

Number one, 2100 is only 80+ years away, not 150. Number two, who knows how
long the code I write today will be running. The Y2K problem was precisely
because people said "good grief -- 2000 is thirty years away -- why waste
two bytes?" 2100 is less than three times as far away as 2000 was in 1970.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Pommier, Rex
Sent: Wednesday, August 14, 2019 5:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Hi Kees,

I respectfully (somewhat) disagree with your leap year calculation
assertion.  I used to work for a Surety company and now work for a life
insurance company.  In both cases we have policies that can reach out 50-100
years.  We definitely need the 100 year rule in some calculations.  Yes,
there are definitely areas where one could forget about using the 100 year
rule in leap year calculations, but not always.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, August 14, 2019 1:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Instruction speeds

And: don't write unnecessary code. 
A nice example is how to determine leap years: from as long as I program the
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?

The last 2 are completely unnecessary until the year 2100. 
How many useless instructions will have been executed for this reason in the
150 years until 2100?
How much of our assembler code will live until 2100? Lots were not even
prepared for 2000.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Seymour J Metz
> Sent: 13 August, 2019 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> Avoid processor-specific optimizations; what is millicode on one box 
> may not be on another. Worry first about getting your code correct and 
> maintainable.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Christopher Y. Blaicher 
> Sent: Monday, August 12, 2019 9:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> There is no instruction cycle time table.  There are some general 
> guidelines you can follow.
> 
> Don't overload cache.  Locality of reference for instructions and data 
> is important.
> 
> The machine will do out-of-order instruction processing, but there are 
> limits.  If you load a register don't use it as a base register in the 
> next instruction, if you can help it.
> 
> MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up 
> to about 32K.
> 
> JUMPs are faster than BRANCHes.
> 
> Don't use instructions that set the condition code, unless you need it.
> 
> Millicode instructions have startup and shutdown overheads.  Many 
> times you can go faster using open code to do what a millicode instruction
does.
> 
> Here is one that has nothing to do with an instruction - Don't assign 
> CPs from different drawers to an LPAR, that includes ZIIPs.  Task 
> switching across drawers kills cache and kills performance.  You will 
> lose hundreds, if not thousands, of cycles.
> 
> There are some articles on the net that go over processor design and 
> cache design.  The processor designs will give you a hint to the 
> number of stages an instruction goes through.  Pipeline delays are 
> what you try to avoid.
> 
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 8:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Instruction speeds
> 
> Hi everyone,
> 
> I did some searching, but I didn't find anything that really discussed 
> this on the topic that I'm interested. Is there anything published 
> that compares the cycle times of the most used instructions?
> 
> For example; moving an address between areas of storage. I would 
> assume that executing a LOAD and STORE would be much quicker than 
> executing a MVC.
> 
> Or executing a LOAD ADDRESS to increment a register instead of ADD 
> HALF WORD.
> 
> Or does this really matter as much as ordering the instructions so 
> they are optimized for the pipeline?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@l

Re: Instruction speeds

2019-08-14 Thread Joel C. Ewing
On 8/14/19 5:29 AM, Raphaël Jacquot wrote:
> Le 14/08/2019 à 08:18, Vernooij, Kees (ITOP NM) - KLM a écrit :
>> And: don't write unnecessary code.
>> A nice example is how to determine leap years: from as long as I
>> program the flow is:
>> - dividable by 4?
>> - dividable by 100?
>> - dividable by 400?
>>
>> The last 2 are completely unnecessary until the year 2100.
>> How many useless instructions will have been executed for this reason
>> in the 150 years until 2100?
>> How much of our assembler code will live until 2100? Lots were not
>> even prepared for 2000.
>>
>> Kees.
>>
>
> that's what they said in 1965 when they were storing years in dates on
> 2 digits...
> hilarity ensued in 1999 when they were all panicked that their 1964
> vintage cobol code world would crumble...
>
> my 0.02€
>
> Raphael
> ...

To be fair to history, in 1965 most had good reason to expect that
assembly code would be short-lived.   Prior to the announcement of
S/360  in April 1964, almost every time you had to upgrade to a newer or
faster processor the hardware architecture changed enough that you had
to completely rewrite assemblly code every several years.   S/360
guaranteed compatibility for performance upgrades within S/360, but
didn't rule out incompatible future architectures.   In 1965, even those
exposed to S/360 would have had no experience yet to make them assume
the architecture would be stable enough and kept as a subset of future
architectures to allow running the same code decades later, much less
have z-architecture hardware supporting the same instructions as a
subset in 2019.

    Joel C Ewing

-- 
Joel C. Ewing

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


Re: Instruction speeds

2019-08-14 Thread Pommier, Rex
Hi Kees,

I respectfully (somewhat) disagree with your leap year calculation assertion.  
I used to work for a Surety company and now work for a life insurance company.  
In both cases we have policies that can reach out 50-100 years.  We definitely 
need the 100 year rule in some calculations.  Yes, there are definitely areas 
where one could forget about using the 100 year rule in leap year calculations, 
but not always.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, August 14, 2019 1:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Instruction speeds

And: don't write unnecessary code. 
A nice example is how to determine leap years: from as long as I program the 
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?

The last 2 are completely unnecessary until the year 2100. 
How many useless instructions will have been executed for this reason in the 
150 years until 2100?
How much of our assembler code will live until 2100? Lots were not even 
prepared for 2000.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Seymour J Metz
> Sent: 13 August, 2019 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> Avoid processor-specific optimizations; what is millicode on one box 
> may not be on another. Worry first about getting your code correct and 
> maintainable.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Christopher Y. Blaicher 
> Sent: Monday, August 12, 2019 9:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> There is no instruction cycle time table.  There are some general 
> guidelines you can follow.
> 
> Don't overload cache.  Locality of reference for instructions and data 
> is important.
> 
> The machine will do out-of-order instruction processing, but there are 
> limits.  If you load a register don't use it as a base register in the 
> next instruction, if you can help it.
> 
> MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up 
> to about 32K.
> 
> JUMPs are faster than BRANCHes.
> 
> Don't use instructions that set the condition code, unless you need it.
> 
> Millicode instructions have startup and shutdown overheads.  Many 
> times you can go faster using open code to do what a millicode instruction 
> does.
> 
> Here is one that has nothing to do with an instruction - Don't assign 
> CPs from different drawers to an LPAR, that includes ZIIPs.  Task 
> switching across drawers kills cache and kills performance.  You will 
> lose hundreds, if not thousands, of cycles.
> 
> There are some articles on the net that go over processor design and 
> cache design.  The processor designs will give you a hint to the 
> number of stages an instruction goes through.  Pipeline delays are 
> what you try to avoid.
> 
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 8:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Instruction speeds
> 
> Hi everyone,
> 
> I did some searching, but I didn't find anything that really discussed 
> this on the topic that I'm interested. Is there anything published 
> that compares the cycle times of the most used instructions?
> 
> For example; moving an address between areas of storage. I would 
> assume that executing a LOAD and STORE would be much quicker than 
> executing a MVC.
> 
> Or executing a LOAD ADDRESS to increment a register instead of ADD 
> HALF WORD.
> 
> Or does this really matter as much as ordering the instructions so 
> they are optimized for the pipeline?
> 
> --
> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. Thi

Re: Instruction speeds

2019-08-14 Thread Peter Relson
>JNE generates the same machine instruction as BNE, etc.

Not true. 
BNE generates the same machine instruction as BC x (47xy).
JNE generates the same machine instruction as BRC x (A7x4).

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: Instruction speeds

2019-08-14 Thread Greg Price

On 2019-08-14 8:40 PM, Raphaël Jacquot wrote:
that's what they said in 1965 when they were storing years in dates on 2 
digits...
hilarity ensued in 1999 when they were all panicked that their 1964 
vintage cobol code world would crumble...


Yeah...

Didn't Fred Brooks in "The Mythical Man Month" complain that OS/360 
wasted 24 bytes by catering for a leap year changing from 28th Feb to 
29th?  The operator could manually fix that without OS help - after all, 
it only happened once every four years.


So, you are updating your master file with millions of records and for 
each record you go through 5 excess instructions (say) to cater for the 
year 2100.  How long extra will several lots of 5 million instructions 
take on today's BIPS engines?  Less than a thousand I/O operations?


It's nice to reduce path length overhead, but it's also nice to be 
future proof - or at least future tolerant.


Cheers,
Greg

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


Re: Instruction speeds

2019-08-14 Thread Raphaël Jacquot

Le 14/08/2019 à 08:18, Vernooij, Kees (ITOP NM) - KLM a écrit :

And: don't write unnecessary code.
A nice example is how to determine leap years: from as long as I program the 
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?

The last 2 are completely unnecessary until the year 2100.
How many useless instructions will have been executed for this reason in the 
150 years until 2100?
How much of our assembler code will live until 2100? Lots were not even 
prepared for 2000.

Kees.



that's what they said in 1965 when they were storing years in dates on 2 
digits...
hilarity ensued in 1999 when they were all panicked that their 1964 
vintage cobol code world would crumble...


my 0.02€

Raphael

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


Re: Instruction speeds

2019-08-14 Thread Vernooij, Kees (ITOP NM) - KLM
It may be fast, but it runs a long time. Talking about 'speed'!

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rick J. Valles
> Sent: 13 August, 2019 18:13
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> Here’s my IEFBR15 “Utility” - it’s pretty fast:
> 
>   Active Usings: None
>   Loc  Object CodeAddr1 Addr2  Stmt   Source Statement
> 000 2 1 IEFBR15  CSECT
> 00 07FF   2  BR15
>   3  END
> 
> :)
> 
> 
> r
> 
> > On Aug 13, 2019, at 10:09 AM, Brian Chapman 
> wrote:
> >
> > Thanks Charles and Steve.
> >
> > Now that I am becoming a more experience assembler programmer, I have
> > wondered if I should be greatly concerned about instruction timings or
> > pipeline order, or just simply focus on readability and maintenance.
> > Especially since assembler programming is becoming a dying art. I think
> I
> > am only 1 of a handful of assembler programmers at my shop with hundreds
> of
> > mainframe programmers! I think you both answered my question. Thanks!
> >
> >
> >
> > Thank you,
> >
> > Brian Chapman
> >
> >
> > On Tue, Aug 13, 2019 at 11:39 AM Steve Smith  wrote:
> >
> >> Write good code and forget about instruction timings.  With any luck
> your
> >> code will have to perform on several generations of architecture and
> >> machines.
> >>
> >> There's a big difference between B- (base-index-displacement) branches
> and
> >> J- (or BR-) (relative address) instructions.  Surely by now, this
> should go
> >> without saying.  Regardless of whether they're "faster" or not, they
> are
> >> much better, and as that is well-documented, I won't belabor it.
> >>
> >> sas
> >>
> >> --
> >> 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
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Instruction speeds

2019-08-14 Thread Vernooij, Kees (ITOP NM) - KLM
And: don't write unnecessary code. 
A nice example is how to determine leap years: from as long as I program the 
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?

The last 2 are completely unnecessary until the year 2100. 
How many useless instructions will have been executed for this reason in the 
150 years until 2100?
How much of our assembler code will live until 2100? Lots were not even 
prepared for 2000.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: 13 August, 2019 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> Avoid processor-specific optimizations; what is millicode on one box may
> not be on another. Worry first about getting your code correct and
> maintainable.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on behalf
> of Christopher Y. Blaicher 
> Sent: Monday, August 12, 2019 9:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> There is no instruction cycle time table.  There are some general
> guidelines you can follow.
> 
> Don't overload cache.  Locality of reference for instructions and data is
> important.
> 
> The machine will do out-of-order instruction processing, but there are
> limits.  If you load a register don't use it as a base register in the
> next instruction, if you can help it.
> 
> MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up to
> about 32K.
> 
> JUMPs are faster than BRANCHes.
> 
> Don't use instructions that set the condition code, unless you need it.
> 
> Millicode instructions have startup and shutdown overheads.  Many times
> you can go faster using open code to do what a millicode instruction does.
> 
> Here is one that has nothing to do with an instruction - Don't assign CPs
> from different drawers to an LPAR, that includes ZIIPs.  Task switching
> across drawers kills cache and kills performance.  You will lose hundreds,
> if not thousands, of cycles.
> 
> There are some articles on the net that go over processor design and cache
> design.  The processor designs will give you a hint to the number of
> stages an instruction goes through.  Pipeline delays are what you try to
> avoid.
> 
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 8:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Instruction speeds
> 
> Hi everyone,
> 
> I did some searching, but I didn't find anything that really discussed
> this on the topic that I'm interested. Is there anything published that
> compares the cycle times of the most used instructions?
> 
> For example; moving an address between areas of storage. I would assume
> that executing a LOAD and STORE would be much quicker than executing a
> MVC.
> 
> Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> WORD.
> 
> Or does this really matter as much as ordering the instructions so they
> are optimized for the pipeline?
> 
> --
> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the 

Re: Instruction speeds

2019-08-14 Thread David Crayford

Some interesting information on branch prediction in that paper.

If you've got a z/OS C++ compiler try this snippet out, it's fascinating:

https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array

On 2019-08-13 11:47 PM, Charles Mills wrote:

A GREAT introduction to this topic, by someone who unlike me actually knows 
what he is talking about:

https://linuxmain.blogspot.com/2017/02/zoptimizationprimer.html

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume
that executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
WORD.

Or does this really matter as much as ordering the instructions so they are
optimized for the pipeline?

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


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


Re: Instruction speeds

2019-08-13 Thread Jim Mulder
  This link has been posted here before, but in case anyone missed it,


https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/07c69512-ac74-4394-87b9-a61ea201347e/media/IBMzSystemsProcessorOptimizationPrimerv2.pdf


Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY



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


Re: Instruction speeds

2019-08-13 Thread CM Poncelet
BTW Change "LHI   4,4096*512" and "LHI   5,4096*1024" to something like
"LHI   4,4096*16-1"etc. or it will not fit in a halfword - just wrote it
"off the top of my head" without checking. :-(
 

On 14/08/2019 03:24, CM Poncelet wrote:
> FWIW
>  
> On the Hitachi Skyline bipolar mainframe (from 1995), the instruction
> processor speeds were:
> - RR: 3ns.
> - SS: 6-10ns if L2 cached, else 60-80ns if data-fetched from central
> storage.
>  
> On IBM's CMOS G4 mainframes:
> - RR: 20ns approx.
> - SS: no idea, did not check.
>  
> IBM said it had 'improved' its CMOS processors since then, but I do not
> know whether this includes 'improved' RR times.
>  
> As regards loops, try to ensure that they fit entirely within the
> instruction register (was 128 bytes) to avoid instruction cache faults. 
>  
> E.g. try something like the following (adjust as required) to see what
> happens with instruction cache faults:
> WHATEVER CSECT OUR ENTRY POINT
>  USING WHATEVER,15 USE R15 AS OUR BASE REGISTER
> INIT STM   14,12,12(13)    STORE CALLER'S REGISTERS
>          ST    13,SAVEAREA+4   OUR BACKWARD POINTER
>  LR    4,13    USE R4 AS TEMP CALLER'S R13
>  LA    13,SAVEAREA USE R13 FOR OUR SAVEAREA
>          ST    13,8(4)             CALLER'S FORWARD POINTER
>  LHI   4,4096*512  USE R4 AS OUTER LOOP COUNTER
> *
> OUTLOOP  CNOP  0,4 OUTER LOOP START
>  LHI   5,4096*1024     USE R5 AS INNER LOOP COUNTER
> *
> INLOOP   CNOP  0,4                 INNER LOOP START
> B    CONTINUE  BRANCH PAST INSTRUCTION CACHE STORAGE
> IN   DS    F   STORAGE INSIDE INSTRUCTION CACHE
> CONTINUE DS    0F  NOW CARRY ON
>  ST    5,OUT   STORE R5 OUTSIDE THE INSTRUCTION
> CACHE  <--
> *    ST    5,IN    STORE R5 INSIDE  THE INSTRUCTION
> CACHE  <--
>  BCT   5,INLOOP    DECREMENT AND BACK TO INNER LOOP
>  BCT   4,OUTLOOP   DECREMENT AND BACK TO OUTER LOOP
> FILL     DS    XL(132+WHATEVER-*)  FILL UP THE INSTRUCTION CACHE
> OUT  DS    F   STORAGE OUTSIDE INSTRUCTION CACHE
> SAVEAREA DS    18F OUR REGISTER SAVE AREA
> *
> EXIT L 13,4(13)    RESTORE CALLER'S REGISTERS
>  LM    14,12,12(13)
>  BR    14  BACK TO CALLER
>  END   WHATEVER    START AT WHATEVER'S EP
>
> An above "ST   5,IN" causes an instruction cache fault at every INLOOP
> iteration, which results in approx 20 times more CPU than the "ST   5,OUT".
>  
> When possible use registers instead of L2 cache for temporary storage,
> because registers (RR) are much faster than storage to storage
> operations (SS).
>  
> Avoid MVCL: use MVC iteratively in a loop.
>  
> HTH. 
>  
> Cheers, Chris Poncelet (retired sysprog)
>
>  
>  
>  
>
>
> On 13/08/2019 16:39, Steve Smith wrote:
>> Write good code and forget about instruction timings.  With any luck your
>> code will have to perform on several generations of architecture and
>> machines.
>>
>> There's a big difference between B- (base-index-displacement) branches and
>> J- (or BR-) (relative address) instructions.  Surely by now, this should go
>> without saying.  Regardless of whether they're "faster" or not, they are
>> much better, and as that is well-documented, I won't belabor it.
>>
>> sas
>>
>> --
>> 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
> .
>

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


Re: Instruction speeds

2019-08-13 Thread CM Poncelet
FWIW
 
On the Hitachi Skyline bipolar mainframe (from 1995), the instruction
processor speeds were:
- RR: 3ns.
- SS: 6-10ns if L2 cached, else 60-80ns if data-fetched from central
storage.
 
On IBM's CMOS G4 mainframes:
- RR: 20ns approx.
- SS: no idea, did not check.
 
IBM said it had 'improved' its CMOS processors since then, but I do not
know whether this includes 'improved' RR times.
 
As regards loops, try to ensure that they fit entirely within the
instruction register (was 128 bytes) to avoid instruction cache faults. 
 
E.g. try something like the following (adjust as required) to see what
happens with instruction cache faults:
WHATEVER CSECT OUR ENTRY POINT
 USING WHATEVER,15 USE R15 AS OUR BASE REGISTER
INIT STM   14,12,12(13)    STORE CALLER'S REGISTERS
         ST    13,SAVEAREA+4   OUR BACKWARD POINTER
 LR    4,13    USE R4 AS TEMP CALLER'S R13
 LA    13,SAVEAREA USE R13 FOR OUR SAVEAREA
         ST    13,8(4)             CALLER'S FORWARD POINTER
 LHI   4,4096*512  USE R4 AS OUTER LOOP COUNTER
*
OUTLOOP  CNOP  0,4 OUTER LOOP START
 LHI   5,4096*1024     USE R5 AS INNER LOOP COUNTER
*
INLOOP   CNOP  0,4                 INNER LOOP START
B    CONTINUE  BRANCH PAST INSTRUCTION CACHE STORAGE
IN   DS    F   STORAGE INSIDE INSTRUCTION CACHE
CONTINUE DS    0F  NOW CARRY ON
 ST    5,OUT   STORE R5 OUTSIDE THE INSTRUCTION
CACHE  <--
*    ST    5,IN    STORE R5 INSIDE  THE INSTRUCTION
CACHE  <--
 BCT   5,INLOOP    DECREMENT AND BACK TO INNER LOOP
 BCT   4,OUTLOOP   DECREMENT AND BACK TO OUTER LOOP
FILL     DS    XL(132+WHATEVER-*)  FILL UP THE INSTRUCTION CACHE
OUT  DS    F   STORAGE OUTSIDE INSTRUCTION CACHE
SAVEAREA DS    18F OUR REGISTER SAVE AREA
*
EXIT L 13,4(13)    RESTORE CALLER'S REGISTERS
 LM    14,12,12(13)
 BR    14  BACK TO CALLER
 END   WHATEVER    START AT WHATEVER'S EP

An above "ST   5,IN" causes an instruction cache fault at every INLOOP
iteration, which results in approx 20 times more CPU than the "ST   5,OUT".
 
When possible use registers instead of L2 cache for temporary storage,
because registers (RR) are much faster than storage to storage
operations (SS).
 
Avoid MVCL: use MVC iteratively in a loop.
 
HTH. 
 
Cheers, Chris Poncelet (retired sysprog)

 
 
 


On 13/08/2019 16:39, Steve Smith wrote:
> Write good code and forget about instruction timings.  With any luck your
> code will have to perform on several generations of architecture and
> machines.
>
> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions.  Surely by now, this should go
> without saying.  Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>
> sas
>
> --
> 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: Instruction speeds

2019-08-13 Thread Seymour J Metz
Even on a S/360 some of the timing formulae were pretty hairy, and it got worse 
on the S/370. I shuuder to think of the size of a timing manual for a 
contemporary processor.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Christopher Y. Blaicher 
Sent: Tuesday, August 13, 2019 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Sorry, but 360 timings have no relevance to today's systems.  Out-of-order 
processing, executing up to 6 instructions concurrently and a myriad of other 
factors make accurate timings impossible.

Cache utilization is one of the biggest factors. Processing more data than the 
L1 and L2 caches can hold will really mess things up.  Most people don't have 
to worry about that, unless you have large tables in memory that you access a 
lot, especially randomly.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Giliad Wilf
Sent: Tuesday, August 13, 2019 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman  wrote:

>Hi everyone,
>
>I did some searching, but I didn't find anything that really discussed
>this on the topic that I'm interested. Is there anything published that
>compares the cycle times of the most used instructions?
>
>For example; moving an address between areas of storage. I would assume
>that executing a LOAD and STORE would be much quicker than executing a MVC.
>
>Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
>WORD.
>
>Or does this really matter as much as ordering the instructions so they
>are optimized for the pipeline?
>

There used to be, with every new IBM System/360 machine, a "Functional 
Characteristics" publication stating "Instruction Times" in microseconds.
Here is one for the IBM System/360 Model 85:

http://secure-web.cisco.com/19LNkGXX4Edz3NAluLE3GhjFTVP9_mLYBd22slvDhfvUbm2Jt5ekKOU--1Kz0QVMQx1ouoa_BpMetCCoJ4xdIyY4NzLIdk88VX53anaLQuobJ75avxCyDJy-kwo_H5lVCr_v9X1WR-vV1o1MIABDa_d-f-Df8HGhW8zIp74ofJjbGlLsCjMS5Mt2dfXQktNY6965-re-qUFXfAceAhav4eNGeEb4ZIldHWp6mxvcae4JG2AuTzf-1eTaqaS1vF5RRXD5ViUDbK07v8Z3bfmV0DbtaHqNWsLYgLxiTpvZlXKP75_Meq7ZXcIMEri_ZB6RPUip72u7G43rsdRwfV7SnWdsQoZBRaXNT6Y9JQEVdK0otoAc3Eiz-yqND-iCbOYOnQJnQAd0JLLPVugKCcyT-Deh4rov50L9tIPEncm1MSAm5R4utmPTYZW9sStO45i3m/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F360%2FfuncChar%2FA22-6916-1_360-85_funcChar_Jun68.pdf

See page 27.

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

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


Re: Instruction speeds

2019-08-13 Thread Tony Harminc
If you are interested in how these things work under the covers (regardless
of whether it is possible or useful to minutely optimize your code these
days), you might check out any of the several presentations done at SHARE
and other places by Bob Rogers, now retired from IBM, under titles like
"How do you do what you do when you're an xxx CPU". The only one I can find
right now is for the z13, and it concentrates on the then-new SIMD
implementation, but nonetheless has a bunch on more general pipelining and
out of order execution.
https://share.confex.com/share/125/webprogram/Handout/Session17797/How%20do%20you%20do%20what%20you%20do%20when%20youre%20a%20z13%20CPU.pdf

Tony H.

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


Re: Instruction speeds

2019-08-13 Thread Christopher Y. Blaicher
Sorry, but 360 timings have no relevance to today's systems.  Out-of-order 
processing, executing up to 6 instructions concurrently and a myriad of other 
factors make accurate timings impossible.

Cache utilization is one of the biggest factors. Processing more data than the 
L1 and L2 caches can hold will really mess things up.  Most people don't have 
to worry about that, unless you have large tables in memory that you access a 
lot, especially randomly.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Giliad Wilf
Sent: Tuesday, August 13, 2019 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman  wrote:

>Hi everyone,
>
>I did some searching, but I didn't find anything that really discussed 
>this on the topic that I'm interested. Is there anything published that 
>compares the cycle times of the most used instructions?
>
>For example; moving an address between areas of storage. I would assume 
>that executing a LOAD and STORE would be much quicker than executing a MVC.
>
>Or executing a LOAD ADDRESS to increment a register instead of ADD HALF 
>WORD.
>
>Or does this really matter as much as ordering the instructions so they 
>are optimized for the pipeline?
>

There used to be, with every new IBM System/360 machine, a "Functional 
Characteristics" publication stating "Instruction Times" in microseconds.
Here is one for the IBM System/360 Model 85:

http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf

See page 27.

--
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: Instruction speeds

2019-08-13 Thread Seymour J Metz
Avoid processor-specific optimizations; what is millicode on one box may not be 
on another. Worry first about getting your code correct and maintainable.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Christopher Y. Blaicher 
Sent: Monday, August 12, 2019 9:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

There is no instruction cycle time table.  There are some general guidelines 
you can follow.

Don't overload cache.  Locality of reference for instructions and data is 
important.

The machine will do out-of-order instruction processing, but there are limits.  
If you load a register don't use it as a base register in the next instruction, 
if you can help it.

MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up to about 
32K.

JUMPs are faster than BRANCHes.

Don’t use instructions that set the condition code, unless you need it.

Millicode instructions have startup and shutdown overheads.  Many times you can 
go faster using open code to do what a millicode instruction does.

Here is one that has nothing to do with an instruction - Don't assign CPs from 
different drawers to an LPAR, that includes ZIIPs.  Task switching across 
drawers kills cache and kills performance.  You will lose hundreds, if not 
thousands, of cycles.

There are some articles on the net that go over processor design and cache 
design.  The processor designs will give you a hint to the number of stages an 
instruction goes through.  Pipeline delays are what you try to avoid.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 8:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this on 
the topic that I'm interested. Is there anything published that compares the 
cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume that 
executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF WORD.

Or does this really matter as much as ordering the instructions so they are 
optimized for the pipeline?

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

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


Re: [SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Seymour J Metz
Not only no but hell no.

JNE foo generates A74 with a mask of F, the same code as BRC 15,foo; BNE foo 
generates 47 with a mask of F, the same code as BC 15,foo.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Mike Shaw 
Sent: Tuesday, August 13, 2019 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [SUSPECTED SPAM] Re: Instruction speeds

On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> ..>
> JUMPs are faster than BRANCHes.
> .

I don't know what you mean by that Chris.

The various types of Jump instructions are just extended mnemonics for
various types of Branch instructions. JNE generates the same machine
instruction as BNE, etc.

Do you mean the combined compare and jump instructions like CLGRJ?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

--
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: Instruction speeds

2019-08-13 Thread Seymour J Metz
It's almost impossible to compare timings between processors except in the 
context of a well defined benchmark; run a different benchmark and you get a 
different answer. A classic example is comparing a 370/158 to a 4341; use 
packed decimal heavily and you get one answer; use floating point heavily and 
you get the opposite answer.

IBM used to publish instruction timings, and with every new model the rules got 
more complicated. The last one that I saw was for the 370/168, and it was full 
of special cases. I suspect that an instruction timing manual for, e.g., a z14, 
would be bigger than PoOps, and not terribly useful even if you were certain 
that the code would only run on that model.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Brian Chapman 
Sent: Monday, August 12, 2019 8:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume
that executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
WORD.

Or does this really matter as much as ordering the instructions so they are
optimized for the pipeline?

--
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: Instruction speeds

2019-08-13 Thread Pew, Curtis G
On Aug 13, 2019, at 11:26 AM, Jesse 1 Robinson  wrote:
> 
> My advice is always to make it easy for next guy. Chances are, over time, the 
> 'next guy' will be the future you. 

Amen. The advice I give (I got it from Eric S. Raymond) is “Always write code 
as if the next person who will maintain it is a homicidal maniac who knows 
where you live.”

-- 
Pew, Curtis G
curtis@austin.utexas.edu






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


Re: Instruction speeds

2019-08-13 Thread Seymour J Metz
The rules for assemblers are the same as the rules for any language processor:

  1. Correctness trumps speed

  2. Make it easier for somebody to figure out how it works and how to change 
it. Clever
 code is fine, but document it adequately.

  3. When you change platforms or change translators, that which was slow may 
be fast
 and that which was fast may be slow. Beware of optimizations that 
disappear when you
 upgrade or that impede maintenance.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Brian Chapman 
Sent: Tuesday, August 13, 2019 12:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Thanks Charles and Steve.

Now that I am becoming a more experience assembler programmer, I have
wondered if I should be greatly concerned about instruction timings or
pipeline order, or just simply focus on readability and maintenance.
Especially since assembler programming is becoming a dying art. I think I
am only 1 of a handful of assembler programmers at my shop with hundreds of
mainframe programmers! I think you both answered my question. Thanks!



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 11:39 AM Steve Smith  wrote:

> Write good code and forget about instruction timings.  With any luck your
> code will have to perform on several generations of architecture and
> machines.
>
> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions.  Surely by now, this should go
> without saying.  Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>
> sas
>
> --
> 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

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


Re: Instruction speeds

2019-08-13 Thread Jesse 1 Robinson
My advice is always to make it easy for next guy. Chances are, over time, the 
'next guy' will be the future you. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: Tuesday, August 13, 2019 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Instruction speeds

On Tue, Aug 13, 2019 at 11:10 AM Brian Chapman  wrote:

> Thanks Charles and Steve.
>
> Now that I am becoming a more experience assembler programmer, I have 
> wondered if I should be greatly concerned about instruction timings or 
> pipeline order, or just simply focus on readability and maintenance.
> Especially since assembler programming is becoming a dying art. I 
> think I am only 1 of a handful of assembler programmers at my shop 
> with hundreds of mainframe programmers! I think you both answered my 
> question. Thanks!
>

KISS - make it easy to maintain. I have written code which even I didn't 
understand a few years later.


>
>
> Thank you,
>
> Brian Chapman


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


Re: Instruction speeds

2019-08-13 Thread John McKown
On Tue, Aug 13, 2019 at 11:10 AM Brian Chapman  wrote:

> Thanks Charles and Steve.
>
> Now that I am becoming a more experience assembler programmer, I have
> wondered if I should be greatly concerned about instruction timings or
> pipeline order, or just simply focus on readability and maintenance.
> Especially since assembler programming is becoming a dying art. I think I
> am only 1 of a handful of assembler programmers at my shop with hundreds of
> mainframe programmers! I think you both answered my question. Thanks!
>

KISS - make it easy to maintain. I have written code which even I didn't
understand a few years later.


>
>
> Thank you,
>
> Brian Chapman
>
-- 
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx

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: Instruction speeds

2019-08-13 Thread Tony Harminc
On Tue, 13 Aug 2019 at 11:39, Steve Smith  wrote:


> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions.  Surely by now, this should go
> without saying.  Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>

There is one way in which the relative branch instructions are "worse", not
at run time, but assembly time. Say you have a module with (generally good
practice) a bunch of small internal subroutines. Let's say SUBA to start:

SUBA   entry code
 USING SUBA,Rbase
 do SUBA's work
 LTR   R15,R15   Success?
 BZUPDATE_DATA_A
 deal with failure and return
UPDATE_DATA_A store some data related to A
 Return
 DROP Rbase

Now you want to add a routine to do work B. So you clone the SUBA code, and
then change all the labels.

SUBB   entry code
 USING SUBB,Rbase
 do SUBB's work
 LTR   R15,R15   Success?
 BZUPDATE_DATA_A
 deal with failure and return
UPDATE_DATA_B store some data related to B
 Return
 DROP Rbase

But - as I did above - you fail to change the branch to UPDATE_DATA_A to
UPDATE_DATA_B. With BZ you will have an addressibility error (or at least
with careful use of USING and DROP you can force one), but with JZ it will
almost certainly assemble without error. Then at run time you will branch
into the middle of the wrong routine.

I'm not aware of assembly time tools or options to avoid this. Really this
is a larger assembler issue where name scoping is required, but the
relative branch instructions have made it a much easier mistake to make.

Tony H.

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


Re: Instruction speeds

2019-08-13 Thread Rick J. Valles
Here’s my IEFBR15 “Utility” - it’s pretty fast:

  Active Usings: None
  Loc  Object CodeAddr1 Addr2  Stmt   Source Statement
000 2 1 IEFBR15  CSECT
00 07FF   2  BR15
  3  END

:)


r

> On Aug 13, 2019, at 10:09 AM, Brian Chapman  wrote:
> 
> Thanks Charles and Steve.
> 
> Now that I am becoming a more experience assembler programmer, I have
> wondered if I should be greatly concerned about instruction timings or
> pipeline order, or just simply focus on readability and maintenance.
> Especially since assembler programming is becoming a dying art. I think I
> am only 1 of a handful of assembler programmers at my shop with hundreds of
> mainframe programmers! I think you both answered my question. Thanks!
> 
> 
> 
> Thank you,
> 
> Brian Chapman
> 
> 
> On Tue, Aug 13, 2019 at 11:39 AM Steve Smith  wrote:
> 
>> Write good code and forget about instruction timings.  With any luck your
>> code will have to perform on several generations of architecture and
>> machines.
>> 
>> There's a big difference between B- (base-index-displacement) branches and
>> J- (or BR-) (relative address) instructions.  Surely by now, this should go
>> without saying.  Regardless of whether they're "faster" or not, they are
>> much better, and as that is well-documented, I won't belabor it.
>> 
>> sas
>> 
>> --
>> 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


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


Re: Instruction speeds

2019-08-13 Thread Brian Chapman
Thanks Charles and Steve.

Now that I am becoming a more experience assembler programmer, I have
wondered if I should be greatly concerned about instruction timings or
pipeline order, or just simply focus on readability and maintenance.
Especially since assembler programming is becoming a dying art. I think I
am only 1 of a handful of assembler programmers at my shop with hundreds of
mainframe programmers! I think you both answered my question. Thanks!



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 11:39 AM Steve Smith  wrote:

> Write good code and forget about instruction timings.  With any luck your
> code will have to perform on several generations of architecture and
> machines.
>
> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions.  Surely by now, this should go
> without saying.  Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>
> sas
>
> --
> 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


[SUSPECTED SPAM] Re: [SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Gord Tomlin

On 2019-08-13 10:33, Mike Shaw wrote:

JNE generates the same machine instruction as BNE, etc.


Nope.

Are you possibly fooling yourself by looking at code that uses IEABRC or 
IEABRCX?


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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


Re: [SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Charles Mills
> JNE generates the same machine instruction as BNE, etc.

Not really. The (old) branch instructions like BNE use a base register and a 
<4K displacement. The Jxx opcodes are synonyms for (new -- as in 20+ years) 
relative branch instructions which use a +/-64K relative displacement. 

The jumps are potentially faster because the processor never has to worry about 
whether the base register was changed a couple of instructions back. It always 
knows where the instruction counter is.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Shaw
Sent: Tuesday, August 13, 2019 7:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [SUSPECTED SPAM] Re: Instruction speeds

On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> ..> 
> JUMPs are faster than BRANCHes.
> .

I don't know what you mean by that Chris.

The various types of Jump instructions are just extended mnemonics for 
various types of Branch instructions. JNE generates the same machine 
instruction as BNE, etc.

Do you mean the combined compare and jump instructions like CLGRJ?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

--
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: Instruction speeds

2019-08-13 Thread Charles Mills
A GREAT introduction to this topic, by someone who unlike me actually knows 
what he is talking about:

https://linuxmain.blogspot.com/2017/02/zoptimizationprimer.html 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume
that executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
WORD.

Or does this really matter as much as ordering the instructions so they are
optimized for the pipeline?

--
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: Instruction speeds

2019-08-13 Thread Steve Smith
Write good code and forget about instruction timings.  With any luck your
code will have to perform on several generations of architecture and
machines.

There's a big difference between B- (base-index-displacement) branches and
J- (or BR-) (relative address) instructions.  Surely by now, this should go
without saying.  Regardless of whether they're "faster" or not, they are
much better, and as that is well-documented, I won't belabor it.

sas

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


Re: Instruction speeds

2019-08-13 Thread Charles Mills
+1

Hardware is cheap. Programmers (and bugs!) are expensive.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Giliad Wilf
Sent: Tuesday, August 13, 2019 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Hi Brian,

I did not see this sort of publications for three or four decades.

Maybe IBM zServer engineers still use some instruction timing charts during 
chip design/development.

As far as I'm concerned, my emphasis while coding is on clarity and 
readability. 

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


Re: Instruction speeds

2019-08-13 Thread Charles Mills
> how do I know that my literal pool is actively
> cached at execution of a certain instruction?

Short answer: you cannot.

Long answer: Keep your data in a 256-byte-aligned area separate from your 
instructions. If you are really fussy, separate read-only from read/write data 
in separate 256-byte-aligned areas. Separate into another area any data that is 
modified by one task and read or written by another. This will give you a 
fighting chance that your data will be in cache. If my hypothetical L R0,=F'1' 
were shortly preceded by L R2,=F'2' then there is a good chance that the F'1' 
will already be in cache when you get to the L R0. (A good example but poor 
coding practice! Use LHI R0,1 not L R0,=F'1' and avoid data cache issues 
altogether.)

Really long answer: The hardware keeps track. There is a set of counters for 
cache hits and misses of various types. The counters are model-dependent. Take 
a look at SMF 113 and go from there. (Products like Omegamon and MainView may 
have the ability to report on the counters -- I don't know.) 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Tuesday, August 13, 2019 7:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Thanks everyone for your input. I learned a lot from these responses. I
actually meant to write ADD HALFWORD IMMEDIATE in my original email. I was
surprised to hear about LA. I had assumed that direct register manipulation
was the fastest.

On the topic of cache, how do I know that my literal pool is actively
cached at execution of a certain instruction? What would cause the hardware
to move my literal pool out of cache?

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


Re: Instruction speeds

2019-08-13 Thread Giliad Wilf
Hi Brian,

I did not see this sort of publications for three or four decades.

Maybe IBM zServer engineers still use some instruction timing charts during 
chip design/development.

As far as I'm concerned, my emphasis while coding is on clarity and 
readability. 

Regards,
 
On Tue, 13 Aug 2019 10:52:05 -0400, Brian Chapman  wrote:

>Thanks Giliad. This is what I was searching for. I understand that the
>timings in this document are very old and probably wildly inaccurate for
>today's Z systems, but would it be on a relative scale? Would a LR be twice
>the speed of a L?
>
>
>
>Thank you,
>
>Brian Chapman
>
>
>On Tue, Aug 13, 2019 at 10:28 AM Giliad Wilf <
>00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman 
>> wrote:
>>
>> >Hi everyone,
>> >
>> >I did some searching, but I didn't find anything that really discussed
>> this
>> >on the topic that I'm interested. Is there anything published that
>> compares
>> >the cycle times of the most used instructions?
>> >
>> >For example; moving an address between areas of storage. I would assume
>> >that executing a LOAD and STORE would be much quicker than executing a
>> MVC.
>> >
>> >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
>> >WORD.
>> >
>> >Or does this really matter as much as ordering the instructions so they
>> are
>> >optimized for the pipeline?
>> >
>>
>> There used to be, with every new IBM System/360 machine, a "Functional
>> Characteristics" publication stating "Instruction Times" in microseconds.
>> Here is one for the IBM System/360 Model 85:
>>
>>
>> http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf
>>
>> See page 27.
>>

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


Re: Instruction speeds

2019-08-13 Thread Charles Mills
Noo

That was what I was trying to say: you can no longer say "instruction X takes n 
cycles." You just cannot. That is why IBM no longer publishes such a thing. At 
best case an LR or an L take "no time at all" -- read what I wrote earlier. 
Worst case an LR takes a little while and an L takes a really long time. (How's 
that for technical precision?)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Tuesday, August 13, 2019 7:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Thanks Giliad. This is what I was searching for. I understand that the
timings in this document are very old and probably wildly inaccurate for
today's Z systems, but would it be on a relative scale? Would a LR be twice
the speed of a L?



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 10:28 AM Giliad Wilf <
00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman 
> wrote:
>
> >Hi everyone,
> >
> >I did some searching, but I didn't find anything that really discussed
> this
> >on the topic that I'm interested. Is there anything published that
> compares
> >the cycle times of the most used instructions?
> >
> >For example; moving an address between areas of storage. I would assume
> >that executing a LOAD and STORE would be much quicker than executing a
> MVC.
> >
> >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> >WORD.
> >
> >Or does this really matter as much as ordering the instructions so they
> are
> >optimized for the pipeline?
> >
>
> There used to be, with every new IBM System/360 machine, a "Functional
> Characteristics" publication stating "Instruction Times" in microseconds.
> Here is one for the IBM System/360 Model 85:
>
>
> http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf
>
> See page 27.
>
> --
> 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

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


Re: [SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Brian Chapman
Mike,

I believe the difference is related to the fact that branch instructions
require a base register and jump does not.



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 10:40 AM Mike Shaw  wrote:

> On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> > ..>
> > JUMPs are faster than BRANCHes.
> > .
>
> I don't know what you mean by that Chris.
>
> The various types of Jump instructions are just extended mnemonics for
> various types of Branch instructions. JNE generates the same machine
> instruction as BNE, etc.
>
> Do you mean the combined compare and jump instructions like CLGRJ?
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
> --
> 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: Instruction speeds

2019-08-13 Thread Brian Chapman
Thanks Giliad. This is what I was searching for. I understand that the
timings in this document are very old and probably wildly inaccurate for
today's Z systems, but would it be on a relative scale? Would a LR be twice
the speed of a L?



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 10:28 AM Giliad Wilf <
00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman 
> wrote:
>
> >Hi everyone,
> >
> >I did some searching, but I didn't find anything that really discussed
> this
> >on the topic that I'm interested. Is there anything published that
> compares
> >the cycle times of the most used instructions?
> >
> >For example; moving an address between areas of storage. I would assume
> >that executing a LOAD and STORE would be much quicker than executing a
> MVC.
> >
> >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> >WORD.
> >
> >Or does this really matter as much as ordering the instructions so they
> are
> >optimized for the pipeline?
> >
>
> There used to be, with every new IBM System/360 machine, a "Functional
> Characteristics" publication stating "Instruction Times" in microseconds.
> Here is one for the IBM System/360 Model 85:
>
>
> http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf
>
> See page 27.
>
> --
> 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


[SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Mike Shaw

On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
..> 
JUMPs are faster than BRANCHes.

.


I don't know what you mean by that Chris.

The various types of Jump instructions are just extended mnemonics for 
various types of Branch instructions. JNE generates the same machine 
instruction as BNE, etc.


Do you mean the combined compare and jump instructions like CLGRJ?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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


Re: Instruction speeds

2019-08-13 Thread Giliad Wilf
On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman  wrote:

>Hi everyone,
>
>I did some searching, but I didn't find anything that really discussed this
>on the topic that I'm interested. Is there anything published that compares
>the cycle times of the most used instructions?
>
>For example; moving an address between areas of storage. I would assume
>that executing a LOAD and STORE would be much quicker than executing a MVC.
>
>Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
>WORD.
>
>Or does this really matter as much as ordering the instructions so they are
>optimized for the pipeline?
>

There used to be, with every new IBM System/360 machine, a "Functional 
Characteristics" publication stating "Instruction Times" in microseconds.
Here is one for the IBM System/360 Model 85:

http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf

See page 27.

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


Re: Instruction speeds

2019-08-13 Thread Brian Chapman
Thanks everyone for your input. I learned a lot from these responses. I
actually meant to write ADD HALFWORD IMMEDIATE in my original email. I was
surprised to hear about LA. I had assumed that direct register manipulation
was the fastest.

On the topic of cache, how do I know that my literal pool is actively
cached at execution of a certain instruction? What would cause the hardware
to move my literal pool out of cache?


Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 10:17 AM Charles Mills  wrote:

> I second everything Chris Blaicher says. You just cannot say how long an
> instruction takes. Let me give you an example. (The example is based on
> theoretical concepts and has not been tested or benchmarked.)
>
> Let's say you had some tight loop that was executed many thousands or
> millions of times. Let's say you were to insert into the code somewhere the
> following instruction: L R0,=F'1', and let's assume that R0 is not in use
> at that point so this addition does not change the logic of the program.
>
> If the insertion were between some compare and an immediately following
> conditional jump or branch, and the literal pool were already in the data
> cache, then the impact of the added instruction might literally be zero.
> The processor could execute it entirely while it was waiting for the
> condition code to "settle" anyway. You might in a benchmark see absolutely
> no discernible change. So it would be fair to say that the LOAD took no
> time at all.
>
> On the other hand if you inserted it at some other point in the code,
> where the literal pool was not in the cache already, or worse, was always
> at that point in the flow cached for write access on some other processor,
> then the impact might be quite noticeable (assuming enough executions of
> the loop -- on a human scale of time, ANY instruction takes no noticeable
> time at all).
>
> With regard to your specific questions, I think of a L/ST sequence as
> being faster than an MVC for four aligned bytes, but I am not certain that
> is true. (MUCH faster? I seriously doubt it.) Other factors such as those
> discussed in my little example above are much more significant.
>
> I am told that LA is "worse" than other "increment" instructions because
> it involves an index register. The instruction to use to increment a
> register is undoubtedly AHI for reasons that I believe Chris mentions. AH
> (or A) is certainly the worst of the lot because it involves storage access.
>
> My (admittedly grossly oversimplified) rule of thumb when coding is
> "instructions take no time at all; memory accesses take forever."
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 5:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Instruction speeds
>
> Hi everyone,
>
> I did some searching, but I didn't find anything that really discussed this
> on the topic that I'm interested. Is there anything published that compares
> the cycle times of the most used instructions?
>
> For example; moving an address between areas of storage. I would assume
> that executing a LOAD and STORE would be much quicker than executing a MVC.
>
> Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> WORD.
>
> Or does this really matter as much as ordering the instructions so they are
> optimized for the pipeline?
>
> --
> 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: Instruction speeds

2019-08-13 Thread Charles Mills
I second everything Chris Blaicher says. You just cannot say how long an 
instruction takes. Let me give you an example. (The example is based on 
theoretical concepts and has not been tested or benchmarked.)

Let's say you had some tight loop that was executed many thousands or millions 
of times. Let's say you were to insert into the code somewhere the following 
instruction: L R0,=F'1', and let's assume that R0 is not in use at that point 
so this addition does not change the logic of the program.

If the insertion were between some compare and an immediately following 
conditional jump or branch, and the literal pool were already in the data 
cache, then the impact of the added instruction might literally be zero. The 
processor could execute it entirely while it was waiting for the condition code 
to "settle" anyway. You might in a benchmark see absolutely no discernible 
change. So it would be fair to say that the LOAD took no time at all.

On the other hand if you inserted it at some other point in the code, where the 
literal pool was not in the cache already, or worse, was always at that point 
in the flow cached for write access on some other processor, then the impact 
might be quite noticeable (assuming enough executions of the loop -- on a human 
scale of time, ANY instruction takes no noticeable time at all).

With regard to your specific questions, I think of a L/ST sequence as being 
faster than an MVC for four aligned bytes, but I am not certain that is true. 
(MUCH faster? I seriously doubt it.) Other factors such as those discussed in 
my little example above are much more significant.

I am told that LA is "worse" than other "increment" instructions because it 
involves an index register. The instruction to use to increment a register is 
undoubtedly AHI for reasons that I believe Chris mentions. AH (or A) is 
certainly the worst of the lot because it involves storage access.

My (admittedly grossly oversimplified) rule of thumb when coding is 
"instructions take no time at all; memory accesses take forever."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume
that executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
WORD.

Or does this really matter as much as ordering the instructions so they are
optimized for the pipeline?

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


Re: Instruction speeds

2019-08-12 Thread Christopher Y. Blaicher
There is no instruction cycle time table.  There are some general guidelines 
you can follow.

Don't overload cache.  Locality of reference for instructions and data is 
important.

The machine will do out-of-order instruction processing, but there are limits.  
If you load a register don't use it as a base register in the next instruction, 
if you can help it.

MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up to about 
32K.

JUMPs are faster than BRANCHes.

Don’t use instructions that set the condition code, unless you need it.

Millicode instructions have startup and shutdown overheads.  Many times you can 
go faster using open code to do what a millicode instruction does.

Here is one that has nothing to do with an instruction - Don't assign CPs from 
different drawers to an LPAR, that includes ZIIPs.  Task switching across 
drawers kills cache and kills performance.  You will lose hundreds, if not 
thousands, of cycles.

There are some articles on the net that go over processor design and cache 
design.  The processor designs will give you a hint to the number of stages an 
instruction goes through.  Pipeline delays are what you try to avoid.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 8:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this on 
the topic that I'm interested. Is there anything published that compares the 
cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume that 
executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF WORD.

Or does this really matter as much as ordering the instructions so they are 
optimized for the pipeline?

--
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: Instruction speeds

2019-08-12 Thread Mike Schwab
1. Speed within the highest level cache are publish, along with the
slowdown for lower levels of cache.  Paging in speeds are not covered.
2. Varies between processors.
3. If you can avoid base and index registers, you can gain quite a bit of
speed by avoiding address arithmetic.  And I think the have a greater than
4k of addressability range.

On Mon, Aug 12, 2019, 19:48 Brian Chapman  wrote:

> Hi everyone,
>
> I did some searching, but I didn't find anything that really discussed this
> on the topic that I'm interested. Is there anything published that compares
> the cycle times of the most used instructions?
>
> For example; moving an address between areas of storage. I would assume
> that executing a LOAD and STORE would be much quicker than executing a MVC.
>
> Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> WORD.
>
> Or does this really matter as much as ordering the instructions so they are
> optimized for the pipeline?
>
> --
> 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: Instruction speeds

2019-08-12 Thread Jesse 1 Robinson
This question touches a nerve. In my very first job in IT, I was tasked to 
(re)write a program that tabulated the contents of a large master file. The 
idea was to examine each record and record its 'type' in a table. This was 
1978. I was fresh out of programming school. Sort of starry eyed, I guess. 

I found a manual with instruction timings and settled on the this sequence to 
increment each bucket:

   L  R1,COUNTER
   LA   R1,1(,R1)
   STR1,COUNTER 

I can tell you that the program ran like a bat out hell. I was an application 
programmer trainee who heard from the sysprog staff that they used my program 
to benchmark new hardware! After I had moved on to other opportunities, I 
reflected on a huge oversight. In 1980--before the advent of XA--this logic 
would fail utterly beyond 16M records in any bucket. I never heard what 
happened, but I came to believe that outright speed was the wrong metric. Be 
careful to set the right goal. 


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this on 
the topic that I'm interested. Is there anything published that compares the 
cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume that 
executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF WORD.

Or does this really matter as much as ordering the instructions so they are 
optimized for the pipeline?


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


Re: Instruction speeds

2019-08-12 Thread CM Poncelet
I have always used 'immediate' instructions (AHI etc.) when possible, as
they are embedded in the instruction code and need no data fetches from
L2 cache.


On 13/08/2019 01:48, Brian Chapman wrote:
> Hi everyone,
>
> I did some searching, but I didn't find anything that really discussed this
> on the topic that I'm interested. Is there anything published that compares
> the cycle times of the most used instructions?
>
> For example; moving an address between areas of storage. I would assume
> that executing a LOAD and STORE would be much quicker than executing a MVC.
>
> Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> WORD.
>
> Or does this really matter as much as ordering the instructions so they are
> optimized for the pipeline?
>
> --
> 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