On Mon, 2 Jun 2014 11:45:38 -0700 Ed Jaffe edja...@phoenixsoftware.com
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
Binyamin Dissen wrote:
On Mon, 2 Jun 2014 11:45:38 -0700 Ed Jaffe edja...@phoenixsoftware.com
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
...@sbcglobal.net
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 IBM-MAIN@LISTSERV.UA.EDU
On 6/1/2014 7:51 PM, Peter Relson wrote:
I believe the answer
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
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
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
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
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
In
ofe6b203a0.45aeb620-on85257cea.0082e0b5-85257cea.00831...@us.ibm.com,
on 06/01/2014
at 07:51 PM, Peter Relson rel...@us.ibm.com 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.)
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 width of
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Lloyd leful...@sbcglobal.net
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
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
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 can
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.
--
For IBM-MAIN
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
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
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,
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 quadword)
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
19 matches
Mail list logo
