Heck, just 30 year mortgages required printing 2000 in 1970. On Wed, Aug 14, 2019 at 7:49 AM Pommier, Rex <[email protected]> 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 <[email protected]> On Behalf Of > Vernooij, Kees (ITOP NM) - KLM > Sent: Wednesday, August 14, 2019 1:19 AM > To: [email protected] > 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:[email protected]] > > On Behalf Of Seymour J Metz > > Sent: 13 August, 2019 19:23 > > To: [email protected] > > 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 <[email protected]> on > > behalf of Christopher Y. Blaicher <[email protected]> > > Sent: Monday, August 12, 2019 9:32 PM > > To: [email protected] > > 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:[email protected]] > > On Behalf Of Brian Chapman > > Sent: Monday, August 12, 2019 8:48 PM > > To: [email protected] > > 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 [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] 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 > [email protected] 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
