Heck, just 30 year mortgages required printing 2000 in 1970.

On Wed, Aug 14, 2019 at 7:49 AM Pommier, Rex <rpomm...@sfgmembers.com> 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 <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



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

Reply via email to