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 <IBM-MAIN@LISTSERV.UA.EDU> 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 <IBM-MAIN@LISTSERV.UA.EDU> on 
> behalf of Christopher Y. Blaicher <cblaic...@syncsort.com>
> 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 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


The information contained in this message is confidential, protected from
disclosure and may be legally privileged.  If the reader of this message is
not the intended recipient or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any disclosure, distribution, copying, or any action taken or action
omitted in reliance on it, is strictly prohibited and may be unlawful.  If
you have received this communication in error, please notify us immediately
by replying to this message and destroy the material in its entirety,
whether in electronic or hard copy format.  Thank you.

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

Reply via email to