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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
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 <IBM-MAIN@LISTSERV.UA.EDU> 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Vernooij, Kees (ITOP NM) - KLM <kees.verno...@klm.com>
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 <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

Reply via email to