Re: Is there a significant performance penalty for non-aligned operands?

Binyamin Dissen wrote: On Mon, 2 Jun 2014 11:45:38 -0700 Ed Jaffe wrote: :>NIL and OIL are not required on z196 and higher machines. NI and OI now :>do the necessary serialization. Do I understand correctly? NI/OI do the same serialization that CS does? That two OI's issued on two processor

Re: Is there a significant performance penalty for non-aligned operands?

On Mon, 2 Jun 2014 11:45:38 -0700 Ed Jaffe wrote: :>NIL and OIL are not required on z196 and higher machines. NI and OI now :>do the necessary serialization. Do I understand correctly? NI/OI do the same serialization that CS does? That two OI's issued on two processors will guarantee the resul

Re: Is there a significant performance penalty for non-aligned operands?

ject: Re: Is there a significant performance penalty for non-aligned operands? Charles Mills wrote: > Pardon my ignorance: what exactly is a "cache line"? The caches are divided into 256-byte increments called "cache lines" in current processors. ---

Re: Is there a significant performance penalty for non-aligned operands?

On 6/2/2014 9:06 AM, Paul Gilmartin wrote: On Mon, 2 Jun 2014 11:47:17 -0400, John Eells wrote: The caches are divided into 256-byte increments called "cache lines" in current processors. (The exact number is probably subject to change.) Modern processors implement instructions a program ca

Re: Is there a significant performance penalty for non-aligned operands?

On 6/2/2014 8:01 AM, Skip Robinson wrote: Early in my career I developed a habit when writing ASM code. In 'working storage', code DS/DC fields in this order unless some other structural sequence is required: double words first, then full words, half words, and finally character (C or X) fields o

Re: Is there a significant performance penalty for non-aligned operands?

Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Lloyd To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/01/2014 06:12 PM Subject: Re: Is there a significant performance penalty for non-aligned operands? Sent by:IBM Mainframe Discussion List On

Re: Is there a significant performance penalty for non-aligned operands?

On Mon, 2 Jun 2014 11:47:17 -0400, John Eells wrote: >Charles Mills wrote: >> Pardon my ignorance: what exactly is a "cache line"? > >The caches are divided into 256-byte increments called "cache lines" in >current processors. > (The exact number is probably subject to change.) Is this also the

Re: Is there a significant performance penalty for non-aligned operands?

In , on 06/01/2014 at 07:51 PM, Peter Relson said: >I believe the answer is "no", all other things being equal. What about the performance of Load versus ICM for nonaligned data? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: Is there a significant performance penalty for non-aligned operands?

Charles Mills wrote: Pardon my ignorance: what exactly is a "cache line"? The caches are divided into 256-byte increments called "cache lines" in current processors. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com

Re: Is there a significant performance penalty for non-aligned operands?

> Pardon my ignorance: what exactly is a "cache line"? http://en.wikipedia.org/wiki/CPU_cache For purposes of this alignment discussion, the cache line size on IBM mainframes has been 256 (x'100') bytes for at least all of the z/Architecture machines, and I think even for several generations be

Re: Is there a significant performance penalty for non-aligned operands?

On 6/2/2014 11:01 AM, Skip Robinson wrote: Early in my career I developed a habit when writing ASM code. In 'working storage', code DS/DC fields in this order unless some other structural sequence is required: double words first, then full words, half words, and finally character (C or X) fields

Re: Is there a significant performance penalty for non-aligned operands?

Pardon my ignorance: what exactly is a "cache line"? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, June 02, 2014 8:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there a significant p

Re: Is there a significant performance penalty for non-aligned operands?

> Once upon a time IIRC there was a significant performance penalty for > non-aligned operands (loading a fullword from an address not evenly > divisible by four, etc.). Does that still exist for modern Z processors? > (Once upon a time it didn't work at all, but that's AFH, to use an acronym I >

Re: Is there a significant performance penalty for non-aligned operands?

o: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/01/2014 06:12 PM Subject: Re: Is there a significant performance penalty for non-aligned operands? Sent by:IBM Mainframe Discussion List On 6/1/2014 7:51 PM, Peter Relson wrote: > I believe the answer is "no", all o

Re: Is there a significant performance penalty for non-aligned operands?

On 6/1/2014 7:51 PM, Peter Relson wrote: I believe the answer is "no", all other things being equal. But if one of those "other things" is that the non-aligned operand spans cache lines whereas an aligned one would not, then the answer could be a huge "yes". Things such as doubleword (or quadwo

Re: Is there a significant performance penalty for non-aligned operands?

I believe the answer is "no", all other things being equal. But if one of those "other things" is that the non-aligned operand spans cache lines whereas an aligned one would not, then the answer could be a huge "yes". Things such as doubleword (or quadword) consistency could not be relied upon

Re: Is there a significant performance penalty for non-aligned operands?

there a significant performance penalty for non-aligned operands? There is a performance penalty. I have measured it for aligned and unaligned signed halfword, i.e., signed binary fixed(15,0), in compiled PL/I code and found that it is usually about 13%, which may be trivial or important depending

Re: Is there a significant performance penalty for non-aligned operands?

There is a performance penalty. I have measured it for aligned and unaligned signed halfword, i.e., signed binary fixed(15,0), in compiled PL/I code and found that it is usually about 13%, which may be trivial or important depending upon context. More important in multiple-CP environments, I thi

Is there a significant performance penalty for non-aligned operands?

Once upon a time IIRC there was a significant performance penalty for non-aligned operands (loading a fullword from an address not evenly divisible by four, etc.). Does that still exist for modern Z processors? (Once upon a time it didn't work at all, but that's AFH, to use an acronym I learned thi