On 1/21/2014 5:24 PM, Jim Mulder wrote:
From a hardware design engineer:
quote
All hardware instructions perform at the same speed in 64-bit mode or
31-bit mode. I assume the AMODE(31) and AMODE(64) he is referring to
only affects the addressing mode, but the exact same instruction
sequences
On Fri, Jan 24, 2014 at 4:58 PM, Ed Jaffe edja...@phoenixsoftware.comwrote:
On 1/21/2014 5:24 PM, Jim Mulder wrote:
From a hardware design engineer:
quote
All hardware instructions perform at the same speed in 64-bit mode or
31-bit mode. I assume the AMODE(31) and AMODE(64) he is
On 1/24/2014 4:20 PM, John McKown wrote:
On Fri, Jan 24, 2014 at 4:58 PM, Ed Jaffe edja...@phoenixsoftware.comwrote:
Perhaps JG's assertion is actually about grande instructions vs normal
instructions. Our benchmarks show grande instructions are ever-so-slightly
(2%) slower than their
In
CAE1XxDGxrBsij_=UFO=UzZ0DSdGupE_=QWr=y5dggtju9d3...@mail.gmail.com,
on 01/21/2014
at 07:44 PM, John Gilmore jwgli...@gmail.com said:
and it may be that what we have here is a misunderstanding of my
language.
Or it may be your ignorance.
Let me begin with a little history. On System/360
The hardware designer Jim Mulder quotes says
begin extract
I assume the AMODE(31) and AMODE(64) he is referring to only affects
the addressing mode, but the exact same instruction sequences are used
in both cases. If different code sequences are being used, then all
bets are off.
/end extract
This thread has been curiously silent about one characteristic of
routines/instructions executed above the bar. Unsurprisingly, they
are measurably faster than their analogues executed below it.
z/Architecture is 64-bit architecture
From subsequent appends, I know that, despite what John wrote,
On 1/22/2014 12:57 AM, Itschak Mugzach wrote:
64 bit addressing execution is faster if less access to real memory is
required to fetch the next instruction. This is what quadword promise,
is'It? the performance gain is also depend on the logic of the program
(if commands sequenced well with less
On Wed, Jan 22, 2014 at 6:58 AM, Steve Comstock st...@trainersfriend.comwrote:
On 1/22/2014 12:57 AM, Itschak Mugzach wrote:
64 bit addressing execution is faster if less access to real memory is
required to fetch the next instruction. This is what quadword promise,
is'It? the performance
Well, I don't know about your coffee, but if the next instruction is not in
the high speed buffer... it is time for a coffee break for your processor
;-)
On Wed, Jan 22, 2014 at 3:53 PM, John McKown
john.archie.mck...@gmail.comwrote:
On Wed, Jan 22, 2014 at 6:58 AM, Steve Comstock
I detect here a hint of confusion: The choice of 64-bit memory
addressing is independent of the choice of size of individual data
objects and independent of the width of internal hardware data paths
either within the processor or to/from memory or I/O channels. The only
thing to which 64-bit
On 22/01/2014 23:35, John Gilmore wrote:
It is of course possible to write snippets of code using only modal
instructions in such a way that the exact same instruction sequences
are used in both cases; but it is almost never appropriate to do so;
and I did not do, or say that I had done, that.
That's not something to be proud of, but it is a practical reality.
IMHO, that's likewise not something to be ashamed of. It simply proves that the
large majority of application have no need for storage above the bar. It's
mainly something for programs and subsystems that gain performance
to your
architecture.
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Monday, January 20, 2014 4:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fw: Dataspace versus common area above the bar
Memory objects
, January 20, 2014 9:02:55 AM
Subject: Re: Dataspace versus common area above the bar
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
...@austin.rr.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, January 20, 2014 5:43:10 PM
Subject: Re: Dataspace versus common area above the bar
Because I've used memory objects for so long, I have not had a reason for
IARVSERV. I read both the description in the macro reference and in the
authorized
This thread has been curiously silent about one characteristic of
routines/instructions executed above the bar. Unsurprisingly, they
are measurably faster than their analogues executed below it.
z/Architecture is 64-bit architecture
This is not, of course, their only or even their most important
On Tue, 21 Jan 2014 15:42:20 -0500, John Gilmore wrote:
This thread has been curiously silent about one characteristic of
routines/instructions executed above the bar. Unsurprisingly, they
are measurably faster than their analogues executed below it.
z/Architecture is 64-bit architecture
Is
On Tue, Jan 21, 2014 at 2:42 PM, John Gilmore jwgli...@gmail.com wrote:
This thread has been curiously silent about one characteristic of
routines/instructions executed above the bar. Unsurprisingly, they
are measurably faster than their analogues executed below it.
z/Architecture is 64-bit
No, I was saying, I thought, something very different. To be clear,
the execution of an AMODE(64) routine using the instructions natural
to it, is in general faster than the execution of anits AMODE(31) or,
a fortiori, AMODE(24) functional equivalent.
John Gilmore, Ashland, MA 01721 - USA
Thanks for the clarification. That makes sense to me. The hardware is not
masking off the unused bits. I totally misread the first paragraph. I
also wonder if an AGR is faster than a simple AG. Unless the CPU has both
64 and 32 bit ALUs, it would make sense that the native 64 bit would be
faster.
No, I was saying, I thought, something very different. To be clear,
the execution of an AMODE(64) routine using the instructions natural
to it, is in general faster than the execution of anits AMODE(31) or,
a fortiori, AMODE(24) functional equivalent.
AMODE does not affect performance.
On 2014-01-21 15:42, John Gilmore wrote:
This thread has been curiously silent about one characteristic of
routines/instructions executed above the bar. Unsurprisingly, they
are measurably faster than their analogues executed below it.
z/Architecture is 64-bit architecture
One caveat to that
Thank you Peter Relson.my wife is glad she is not alone ...
Hank, PD Tools, IBM Australia
IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on
21/01/2014 10:19:56 AM:
...
I have seen Peter Relson type (fast) while he was
looking at me and carrying on a conversation.
I think it is the new instructions that don't use base or index
registers, instead a +/- 32K offset.
On Tue, Jan 21, 2014 at 5:02 PM, Jim Mulder d10j...@us.ibm.com wrote:
No, I was saying, I thought, something very different. To be clear,
the execution of an AMODE(64) routine using the
I think it is the new instructions that don't use base or index
registers, instead a +/- 32K offset.
functional equivalent, and why you think they are faster?
AMODE does not affect performance. Can you explain
which instructions you think are faster than some
Relative addressing
Jim Mulder wrote:
begin extract
AMODE does not affect performance. Can you explain which instructions
you think are faster than some functional equivalent, and why you
think they are faster?
/end extract
and it may be that what we have here is a misunderstanding of my
language. Let me begin
begin extract
AMODE does not affect performance. Can you explain which instructions
you think are faster than some functional equivalent, and why you
think they are faster?
/end extract
and it may be that what we have here is a misunderstanding of my
language. Let me begin with a little
algorithms.
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Tuesday, January 21, 2014 7:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fw: Dataspace versus common area above the bar
begin extract
AMODE does
One caveat to that statement is as follows, from the POps:
The performance of CDSG on some models may
be significantly slower than that of CSG. WHEN
QUADWORD CONSISTENCY IS NOT REQUIRED BY THE PROGRAM,
alternate code sequences should be used.
(my caps)
CDSG was implemented in millicode on the
64 bit addressing execution is faster if less access to real memory is
required to fetch the next instruction. This is what quadword promise,
is'It? the performance gain is also depend on the logic of the program
(if commands sequenced well with less brunch instructions).
ITschak
On Wed, Jan
Hello,
I just wanted to sound people out about converting a dataspace to a common
area above the bar. The main interest is the effect it would have on CPU
usage.
To put it into context, the dataspace is used for a set of tables which are
used by the application programs. There are around eight
On Mon, Jan 20, 2014 at 3:38 AM, John Blythe Reid
johnblyther...@gmail.comwrote:
Hello,
I just wanted to sound people out about converting a dataspace to a common
area above the bar. The main interest is the effect it would have on CPU
usage.
To put it into context, the dataspace is used
Hi John,
No, all the applications are AMODE(31). The assembler routine currently
temporarily changes to AR mode on each call to access the dataspace. The
ALET is stored in the CSA when the dataspace is created so the assembler
routine picks it up from there. if we go ahead and put the tables
On 2014-01-20 04:38, John Blythe Reid wrote:
I just wanted to sound people out about converting a dataspace to a common
area above the bar. The main interest is the effect it would have on CPU
usage.
To put it into context, the dataspace is used for a set of tables which are
used by the
Hi John:
My advise is to benchmark ... And it might be different on different machines.
So if 64-bit runs better in your current machine, don't through away your old
AR code, because it might be useful in your DR site or a new machine.
My advise is to benchmark because I found myself more
: Dataspace versus common area above the bar
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
Hi John:
My advise is to benchmark ... And it might be different on different
machines. So if 64-bit runs better in your current machine, don't through
away your old AR code
.
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gord Tomlin
Sent: Monday, January 20, 2014 10:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataspace versus common area above the bar
On 2014-01-20 04:38, John Blythe Reid wrote:
I
I just wanted to sound people out about converting a dataspace to a
common
area above the bar. The main interest is the effect it would have on CPU
usage.
To put it into context, the dataspace is used for a set of tables which
are
used by the application programs. There are around eight
Memory objects are much more flexible than data spaces. Data spaces are
limited to 2GB. Memory objects are only limited by the auxiliary
storage.
Memory objects can be guarded and can also be page protected. Data
spaces
cannot. Code can execute in memory object but not in data spaces. I
Memory objects are much more flexible than data spaces. Data spaces are
limited to 2GB. Memory objects are only limited by the auxiliary
storage.
Memory objects can be guarded and can also be page protected. Data
spaces
cannot. Code can execute in memory object but not in data spaces. I
Jim.
You also meant TARGET_VIEW=HIDDEN, not TAGET_V IEW=HIDDEN.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
Could additional potential CPU efficiencies be gained from creating the
memory objects with 1Mb large pages (or 2Gb if they are REALLY big!)?
On 20 January 2014 22:40, John Gilmore jwgli...@gmail.com wrote:
Jim.
You also meant TARGET_VIEW=HIDDEN, not TAGET_V IEW=HIDDEN.
John Gilmore,
You also meant TARGET_VIEW=HIDDEN, not TAGET_V IEW=HIDDEN.
Unfortunately, even with 34 years in the programming business,
I have never mastered typing skills. At my mother's
insistence, I did take a 6-week summer school class in
touch typing in 1974, but it didn't do me much good - I
still
Could additional potential CPU efficiencies be gained from creating the
memory objects with 1Mb large pages (or 2Gb if they are REALLY big!)?
1Mb pages can reduce the number of TLB misses, along with the
cache effects of fetching the DAT table entries to resolve the
TLB misses. Keep in mind
: Dataspace versus common area above the bar
Memory objects are much more flexible than data spaces. Data spaces
are limited to 2GB. Memory objects are only limited by the auxiliary
storage.
Memory objects can be guarded and can also be page protected. Data
spaces
cannot. Code can execute in memory
45 matches
Mail list logo
