Re: Why is zSeries so CPU poor?

[Edward Jaffe]

Kuredjian, Michael wrote:

Does IBM make a co-processor add-in that can provide an assist for the JVM 
overhead?
  


zAAPs

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Kuredjian, Michael]

Does zLinux have a kernel patch that allows it to offload the JVM to this 
co-proc when running in an LPAR?

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Edward Jaffe
Sent: Wednesday, July 19, 2006 1:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?


Kuredjian, Michael wrote:
> Does IBM make a co-processor add-in that can provide an assist for the JVM 
> overhead?
>   

zAAPs

-- 
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Goforth, Mark]

zAAPs do not work under zLinux.  They only work under zOS.
As for Java, the more appropriate question might be why is it so
inefficient? 


This email and any files attached with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  If you have received this email in error delete this message
and notify the sender at 402-341-0500.  If you are not the named
recipient you should not disseminate, distribute or copy this email or
any attachment.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Kuredjian, Michael
Sent: Wednesday, July 19, 2006 12:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?

Does zLinux have a kernel patch that allows it to offload the JVM to
this co-proc when running in an LPAR?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Wednesday, July 19, 2006 12:48 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> Kuredjian, Michael wrote:
> > Does IBM make a co-processor add-in that can provide an 
> assist for the JVM overhead?
> >   
> 
> zAAPs

Except that a zAAP is not really a Java CPU. It is a regular CPU, with
some microcode changes to remove specific abilities. From what little I
can gather, it is actually the z/OS dispatcher, in conjunction with the
Java JVM, which restricts the zAAP from doing any non-Java "general
purpose" work.

It might be "interesting" to actually somehow have an Opteron, pSeries,
or Xeon processor in the zSeries frame with some sort of "interconnect"
so that the code on the zSeries could run those instruction. A terror to
program, I'd bet. But technically interesting (to me at least).

I would love to get a peek at one of those. I wonder how long it might
be for somebody to figure out what "magic" the JVM does to mark its work
a "zAAP capable" to the z/OS dispatcher so that non-Java work could run
on it. Of course, I would bet that doing this would be a violation of
the T&Cs for the processor. Also, I'll bet that there is some sneaky
code in z/OS to try to detect this. E.g. if the program does an SVC or
PC or ???, then an abend occurs instead of actually doing the function
desired. I know that I'd certainly put those checks in.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Kuredjian, Michael]

It's an interpreted language.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Goforth, Mark
Sent: Wednesday, July 19, 2006 1:56 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?


zAAPs do not work under zLinux.  They only work under zOS.
As for Java, the more appropriate question might be why is it so
inefficient? 


This email and any files attached with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  If you have received this email in error delete this message
and notify the sender at 402-341-0500.  If you are not the named
recipient you should not disseminate, distribute or copy this email or
any attachment.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Kuredjian, Michael
Sent: Wednesday, July 19, 2006 12:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?

Does zLinux have a kernel patch that allows it to offload the JVM to
this co-proc when running in an LPAR?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kuredjian, Michael
> Sent: Wednesday, July 19, 2006 12:53 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> Does zLinux have a kernel patch that allows it to offload the 
> JVM to this co-proc when running in an LPAR?

No. a zAAP can only be used by a z/OS system. Not z/VM, z/Linux, z/VSE,
or z/TPF. 

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kuredjian, Michael
> Sent: Wednesday, July 19, 2006 12:59 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> It's an interpreted language.

Again, not really. The Java source code is actually compiled to a binary
form which is called "Java Byte Code". This byte code is similar in
nature to a normal processor's instruction set. 
I guess you could say that the JVM "inteprets" the byte code. But I
think of it more like the JVM includes a byte code emulator (like the
old 1401 emulator). But, from what I can tell,the Java byte code doesn't
match the zSeries instruction set very well. So it is relatively
inefficient.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Kuredjian, Michael]

Correct. The byte code generated by the Java compiler isn't understandable by 
any machine except the Java Virtual Machine. The JVM "interprets" this object 
code and relays the calls to those found in the host system's API. Out of 
curiosity, how does C++ perform on zOS?

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of McKown, John
Sent: Wednesday, July 19, 2006 2:03 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?


> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kuredjian, Michael
> Sent: Wednesday, July 19, 2006 12:59 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> It's an interpreted language.

Again, not really. The Java source code is actually compiled to a binary
form which is called "Java Byte Code". This byte code is similar in
nature to a normal processor's instruction set. 
I guess you could say that the JVM "inteprets" the byte code. But I
think of it more like the JVM includes a byte code emulator (like the
old 1401 emulator). But, from what I can tell,the Java byte code doesn't
match the zSeries instruction set very well. So it is relatively
inefficient.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Roy Hewitt]

McKown, John wrote:

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Kuredjian, Michael

Sent: Wednesday, July 19, 2006 12:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?


Does zLinux have a kernel patch that allows it to offload the 
JVM to this co-proc when running in an LPAR?


No. a zAAP can only be used by a z/OS system. Not z/VM, z/Linux, z/VSE,
or z/TPF. 



But why would it need zAAPs?  it has IFLs

Roy

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Jeffrey D. Smith]

===
-Original Message-
From: "McKown, John" <[EMAIL PROTECTED]>
Sent: 7/19/2006 11:58 AM
To: "IBM-MAIN@BAMA.UA.EDU" 
Subject: Re: Why is zSeries so CPU poor?

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Wednesday, July 19, 2006 12:48 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> Kuredjian, Michael wrote:
> > Does IBM make a co-processor add-in that can provide an 
> assist for the JVM overhead?
> >   
> 
> zAAPs

Except that a zAAP is not really a Java CPU. It is a regular CPU, with
some microcode changes to remove specific abilities. From what little I
can gather, it is actually the z/OS dispatcher, in conjunction with the
Java JVM, which restricts the zAAP from doing any non-Java "general
purpose" work.

It might be "interesting" to actually somehow have an Opteron, pSeries,
or Xeon processor in the zSeries frame with some sort of "interconnect"
so that the code on the zSeries could run those instruction. A terror to
program, I'd bet. But technically interesting (to me at least).

I would love to get a peek at one of those. I wonder how long it might
be for somebody to figure out what "magic" the JVM does to mark its work
a "zAAP capable" to the z/OS dispatcher so that non-Java work could run
on it. Of course, I would bet that doing this would be a violation of
the T&Cs for the processor. Also, I'll bet that there is some sneaky
code in z/OS to try to detect this. E.g. if the program does an SVC or
PC or ???, then an abend occurs instead of actually doing the function
desired. I know that I'd certainly put those checks in.

--
John McKown
===

I doubt that IBM could remove generally documented machine
instructions or system services. The JVM is allowed to call
JNI (Java Native Interface) routines, written in any language
(usually C), which are allowed by definition to use any
operating system services and any machine dependent features.


Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DR
LONGMONT, CO 80501
303-774-9381 direct
303-709-8153 cell
303-484-6170 fax

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[McKown, John]

> 
> I doubt that IBM could remove generally documented machine
> instructions or system services. The JVM is allowed to call
> JNI (Java Native Interface) routines, written in any language
> (usually C), which are allowed by definition to use any
> operating system services and any machine dependent features.
> 
> 
> Jeffrey D. Smith

If so, then I wonder what causes a "machine check" when you try to IPL
z/OS on an IFL. Yes, I did it out of curiousity. And I know that an IFL
is not a zAAP. But it is another "speciality engine" (I think that's the
term IBM uses). I have read that some things cannot be handled by a zAAP
such as timer and I/O interrupts. There must be something "special"
about them to disallow this (or maybe the control regs for the processor
are set to disable them, I guess is a possibility).

Then the question becomes: Does the JVM tell the z/OS dispatcher move
the work from the zAAP to a general CPU while doing a JNI call? Or does
it leave it on the zAAP? I don't know. If it leaves it on the zAAP, then
I'd really push to "wrap" a lot of COBOL code as a JNI from Java. I
could then run the majority of my applications on a zAAP and get some
nice performance!

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Edward Jaffe]

McKown, John wrote:

No. a zAAP can only be used by a z/OS system. Not z/VM, z/Linux, z/VSE,
or z/TPF.
  


That's what I get for "jumping in" without reading the thread. Yes. zAAP 
works only with Java code running under z/OS ... not Linux for z or 
other operating systems.


I question the premise of this entire thread. System z CPU performance 
is not poor! It's state of the art technology!


When comparing the CPU consumption of z/OS traditional workloads vs Java 
or anything running under Linux for z, it can seem as if the CPU is too 
slow for those "new" workloads. But what you're really observing is 
another phenomenon altogether...


The roots of the z/OS operating system, middleware, ISV products, and 
applications are decades old and *highly* efficient. (Much of it still 
written in assembler language.) Remember, these systems ran reasonably 
well on processors with MIPS ratings in the single digits! Therefore, 
the CPU you purchase to run traditional z/OS workloads doesn't need to 
be very powerful at all compared to the CPU you need to run a Java- or 
Linux for z-based workloads, which are written in C and C++ to an 
entirely different design point.


The z9EC zAAPs and IFLs are 580 MIPS engines. Any "new" workload 
utilizing a sufficient number of those processors should perform quite well.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Ray Mullins]

That reminds me of the "next great thing" in the PC world (which then was
mostly Apple, with a few 8080 and z80 boxes thrown in) circa 1981 - UCSD
Pascal.  It created and ran byte code.  It was slower than (insert favorite
analogy here).  Those that forget history...

I don't care how optimized your interpreter or virtual machine or whatever
is - it's never gonna be faster than compiling to the native machine code.
That's why MANTIS was (and probably still is) so slow.  That's why Software
AG had to come out with the NATURAL Optimizing Compiler. (It's actually
pretty slick - the resulting byte/machine code object can run on z/OS,
z/VSE, z/VM or BS2000/OSD, and older versions could run on WANG VS.)

Later,
Ray

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of McKown, John
Sent: Wednesday July 19 2006 11:03
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Kuredjian, Michael
> Sent: Wednesday, July 19, 2006 12:59 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> It's an interpreted language.

Again, not really. The Java source code is actually compiled to a binary
form which is called "Java Byte Code". This byte code is similar in nature
to a normal processor's instruction set. 
I guess you could say that the JVM "inteprets" the byte code. But I think of
it more like the JVM includes a byte code emulator (like the old 1401
emulator). But, from what I can tell,the Java byte code doesn't match the
zSeries instruction set very well. So it is relatively inefficient.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Edward Jaffe]

McKown, John wrote:

Again, not really. The Java source code is actually compiled to a binary
form which is called "Java Byte Code". This byte code is similar in
nature to a normal processor's instruction set. 
I guess you could say that the JVM "inteprets" the byte code. But I

think of it more like the JVM includes a byte code emulator (like the
old 1401 emulator). But, from what I can tell,the Java byte code doesn't
match the zSeries instruction set very well. So it is relatively
inefficient.
  


The JIT compiles the byte code into ordinary object code.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Wednesday, July 19, 2006 1:41 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 

> 
> I question the premise of this entire thread. System z CPU 
> performance 
> is not poor! It's state of the art technology!
> 



> 
> -- 
> Edward E Jaffe

OK, then why is there such a perception that the zSeries is CPU
underpowered? It is because the other "servers" are, in reality, usually
"one trick ponies", doing only a single function whereas the zSeries is
usually doing literally 100s and even 1000s of functions concurrently?
E.g. on Windows, each IIS server is dedicated to a single application.
Each MS SQL database runs on its own dedicated server. And so on.

If it is the "one trick pony" that makes the Wintel (et al.) systems
look so good, I wonder how they will look when the "server
virtualization" really takes hold and a single physical Intel box is
"partitioned" into 10+ "servers", each running Windows 2003 Server. We
are starting on this road here. Our current CIO routinely disallows the
"buy a new server" mentality that our Windows-brethern have had around
here for the last 5+ years.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Jeffrey D. Smith]

-Original Message-
From: "McKown, John" <[EMAIL PROTECTED]>
Sent: 7/19/2006 12:23 PM
To: "IBM-MAIN@BAMA.UA.EDU" 
Subject: Re: Why is zSeries so CPU poor?



> 
> I doubt that IBM could remove generally documented machine
> instructions or system services. The JVM is allowed to call
> JNI (Java Native Interface) routines, written in any language
> (usually C), which are allowed by definition to use any
> operating system services and any machine dependent features.
> 
> 
> Jeffrey D. Smith

If so, then I wonder what causes a "machine check" when you try to IPL
z/OS on an IFL. Yes, I did it out of curiousity. And I know that an IFL
is not a zAAP. But it is another "speciality engine" (I think that's the
term IBM uses). I have read that some things cannot be handled by a zAAP
such as timer and I/O interrupts. There must be something "special"
about them to disallow this (or maybe the control regs for the processor
are set to disable them, I guess is a possibility).

Then the question becomes: Does the JVM tell the z/OS dispatcher move
the work from the zAAP to a general CPU while doing a JNI call? Or does
it leave it on the zAAP? I don't know. If it leaves it on the zAAP, then
I'd really push to "wrap" a lot of COBOL code as a JNI from Java. I
could then run the majority of my applications on a zAAP and get some
nice performance!

--
John McKown


I can only venture a guess that it is similar to a nullifying
program interrupt occurring for a "disabled" machine instruction.
The operating system sees the special program interrupt and schedules
the unit of work for redispatch on a CPU that has it installed. The
original crypto (and I think vector) instructions had a special
nullifying program interrupt X'01xx' that caused redispatch on the
correct CPU.

I haven't a clue when the operating system decides that it's ok
to move the work back to the original CPU.


Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DR
LONGMONT, CO 80501
303-774-9381 direct
303-709-8153 cell
303-484-6170 fax

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Ted MacNEIL]

>UCSD Pascal.  It created and ran byte code.  It was slower than

It was called p-code.
IIRC, didn't one of the JAVA 'inventors' have something to do with p-code 
development?

Also, at one time wasn't it called j-code?

When in doubt.
PANIC!!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
> Sent: Tuesday, July 18, 2006 7:00 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> >UCSD Pascal.  It created and ran byte code.  It was slower than
> 
> It was called p-code.
> IIRC, didn't one of the JAVA 'inventors' have something to do 
> with p-code development?
> 
> Also, at one time wasn't it called j-code?

Since we are recalling the past, IIRC there was some CPU designed and
manufactured to natively execute p-code. It didn't really make a very
good showing in the market.

To be totally off topic: I really liked what I read about the Intel iAPX
432. Built from the ground up to be object oriented only.

http://www.sasktelwebsite.net/jbayko/cpu7.html

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Edward Jaffe]

McKown, John wrote:

OK, then why is there such a perception that the zSeries is CPU
underpowered? It is because the other "servers" are, in reality, usually
"one trick ponies", doing only a single function whereas the zSeries is
usually doing literally 100s and even 1000s of functions concurrently?
  


Thankfully, I'm no psychologist. But, like any educated person, I'm well 
aware that perception and reality often have wholly insufficient overlap 
-- often because of how things are portrayed by the media.


For example, most "ordinary" people I run into are surprised to find out 
that mainframe computers are still being used in the 21st century. 
Before I set them straight, they are completely ignorant of the fact 
that Western Civilization _runs_ on mainframe computers! How could their 
perceptions be so wrong???


Then there are philosophy students that will argue, "Perception *is* 
Reality". I prefer to stick to bits and bytes myself...


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Ray Mullins]

Yeah, p-code.  That was what it was called.  Ran like crap on an Apple IIe.

I may still have the iAPX 432 POP-equivalent in a box somewhere.  It was an
interesting concept but alas turned into another one of those dead-ends. 

Maybe Intel or someone will resurrect the concept.

In any case, I'm not impressed with the speed of Java versus compiled code
on Windoze boxes.

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of McKown, John
Sent: Wednesday July 19 2006 12:42
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
> Sent: Tuesday, July 18, 2006 7:00 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> >UCSD Pascal.  It created and ran byte code.  It was slower than
> 
> It was called p-code.
> IIRC, didn't one of the JAVA 'inventors' have something to do with 
> p-code development?
> 
> Also, at one time wasn't it called j-code?

Since we are recalling the past, IIRC there was some CPU designed and
manufactured to natively execute p-code. It didn't really make a very good
showing in the market.

To be totally off topic: I really liked what I read about the Intel iAPX
432. Built from the ground up to be object oriented only.

http://www.sasktelwebsite.net/jbayko/cpu7.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Anne & Lynn Wheeler]

McKown, John wrote:

Since we are recalling the past, IIRC there was some CPU designed and
manufactured to natively execute p-code. It didn't really make a very
good showing in the market.

To be totally off topic: I really liked what I read about the Intel iAPX
432. Built from the ground up to be object oriented only.

http://www.sasktelwebsite.net/jbayko/cpu7.html


it was '79? or '81? asilomar acm sigops conference (i've lost my 
proceedings over the years and don't have ready reference)  the 432 
guys gave a talk. i remember them mentioning was that a lot of 
multiprocessor operation was hidden by the hardware ... you past process 
units to the "hardware" ... and it kept track of how many processors 
there were and which processes ran on which processors. it was 
interesting since i had done something similar for m'code '75 for VAMPs 
... a 5-way 370 smp project. ... misc. past postings mentioning VAMPs 
project:

http://www.garlic.com/~lynn/subtopic.html#bounce

today it would be considered slightly analogous to what happens with LPARs.

The other thing they mentioned in the sigops talk was that all this high 
-level function was dropped directly into 432 silicon ... and there was 
no way of patching it ... short of shipping brand new silicon. That 
characteristic was enuf to doom 432. i've got 3 old 432 intel books
http://www.garlic.com/~lynn/2000f.html#48 Famous Machines and Software 
that didn't


the above post lists the following i432 books (in my basement) ... along 
with quote from one of the intros mentioning b5000 from the 60s and also 
referencing s/38


Introduction to the iAPX 432 Architecture (171821-001) copyright 1981, Intel
iAPX 432 Object Primer (171858-001, Rev. B)
iAPX 432 Interface Processor Architecture Reference Manual (171863-001)



there have been some number of other past discussions comparing 432 and 
s/38 (aka as/400 precursor) ... as well as s/38 embodying several "FS" 
features

http://www.garlic.com/~lynn/subtopic.html#futuresys

attached from long ago and far away (talking about vamps smp work from 
1975). i had done dynamic adaptive resource management for cp67 as an 
undergraduate in the 60s and then rereleased the "resource manager" for 
vm370 on 11may76.


From: [EMAIL PROTECTED]
To: xxx
Date: 09/17/82--11:16:14

re: vamps;

I did all the design work & innovation for both the machine
architecture & operating system that made the number of real
processors relatively transparent

Dispatching & interruption was completely in the microcode (below the
machine interface). Essentially the number of processors were therefor
below the interface ... my feedback algorithms had to be beefed up to
allow for dynamically calculating the amount of CPU resources that
were currently available for consumption.

Turns out all the verbage in the Intel 432 document about number of
processors in a complex is transparent to the SCP. It can be
transparent from the standpoint of the dispatcher ... but the overall
resource allocation algorithms have to have a pretty good idea of the
amount of CPU resource available in the complex for doing a accurate
job.

... snip ...

misc. past posts mentioning 432
http://www.garlic.com/~lynn/2000d.html#57 iAPX-432 (was: 36 to 32 bit 
transition
http://www.garlic.com/~lynn/2000d.html#62 iAPX-432 (was: 36 to 32 bit 
transition

http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2001g.html#36 What was object oriented in 
iAPX432?
http://www.garlic.com/~lynn/2001k.html#2 Minimalist design (was Re: 
Parity - why even or odd)

http://www.garlic.com/~lynn/2002d.html#27 iAPX432 today?
http://www.garlic.com/~lynn/2002d.html#46 IBM Mainframe at home
http://www.garlic.com/~lynn/2002l.html#19 Computer Architectures
http://www.garlic.com/~lynn/2002o.html#5 Anyone here ever use the iAPX432 ?
http://www.garlic.com/~lynn/2002q.html#11 computers and alcohol
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003e.html#54 Reviving Multics
http://www.garlic.com/~lynn/2003e.html#55 Reviving Multics
http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
http://www.garlic.com/~lynn/2003m.html#23 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#47 Intel 860 and 960, was iAPX 432
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long 
boring, wandering story
http://www.garlic.com/~lynn/2004d.html#12 real multi-tasking, multi- 
programming
http://www.garlic.com/~lynn/2004e.html#52 Infiniband - practicalities 
for small clusters
http://www.garlic.com/~lynn/2004q.html#60 Will multicore CPUs have 
identical cores?
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have 
identical cores?

http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#64 Misuse of word "microcode"
http://www.garlic.com/~lynn

Re: Why is zSeries so CPU poor?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/19/2006
   at 10:48 AM, Edward Jaffe <[EMAIL PROTECTED]> said:

>zAAPs

Those are normal processors; they are not engineered to run Java byte
code more efficiently. They are essentially a marketing gimmick.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/19/2006
   at 11:40 AM, Edward Jaffe <[EMAIL PROTECTED]> said:

>I question the premise of this entire thread. System z CPU
>performance  is not poor! It's state of the art technology!

The issue isn't the quality of the engineering, it's economics of
scale. The zSeries processors are slow compared to comparably priced
chips made in much higher volumes.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Shmuel Metz (Seymour J.)]

In
,
on 07/19/2006
   at 11:44 AM, Ray Mullins <[EMAIL PROTECTED]> said:

>That reminds me of the "next great thing" in the PC world (which
>then was mostly Apple, with a few 8080 and z80 boxes thrown in)
>circa 1981 - UCSD Pascal.  It created and ran byte code.

ITYM P-code.

>is - it's never gonna be faster than compiling to the native machine
>code.

Never? BTDTGTTS. The 360/85, 370/165 and 370/168 simulated some
instructions in a single cycle.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Aaron Walker]

Here is an interesting Redbook which contrasts the zSeries processor design
with the pSeries processor when choosing a WebSphere solution:

http://www.redbooks.ibm.com/abstracts/redp3968.html

Aaron

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[R.S.]

Craddock, Chris wrote:

[...]

The memory model is also more complex, but then again people tend to
expect reliability rather than speed when they are messing with bank
balances. There's not a lot of point clocking the cpu faster than it can
eat data, so to a large extent the cpu is gated by the cache and memory
subsystem design.


The memory is not unique design. There are regular DIMMs inside the 
book. High quality, ECC, good brand, but still same technology as in PC. 
Memory controllers are probably completely different, but the "back-end" 
 (DIMMs) are not.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Hunkeler Peter (KIUB 34)]

>It's an interpreted language.

And its an OO language which has somewhat more overhead than
traditional non-OO languages.

Peter Hunkeler
CREDIT SUISSE 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Hunkeler Peter (KIUB 34)]

>Then the question becomes: Does the JVM tell the z/OS dispatcher 
>move the work from the zAAP to a general CPU while doing a JNI 
>call? Or does it leave it on the zAAP?

The JVM "marks" the task as being zAAP eligible or non-eligible.
The dispatcher puts zAAP eligible tasks on the zAAP work unit queue
and dispatches tasks from there on zAAPs (or GCPs in some cases). 

Don't ask me *how* it "marks" the task, I have no idea.

Peter Hunkeler
CREDIT SUISSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Craddock, Chris]

Radoslaw writes
> The memory is not unique design. There are regular DIMMs inside the
> book. High quality, ECC, good brand, but still same technology as in
PC.
> Memory controllers are probably completely different, but the
"back-end"
>   (DIMMs) are not.

The PARTS that are used in the box are pretty much the same as other
commodity parts. True enough.

The DESIGN of the way they are put together, the circuitry, EDC/ECC,
page-modes etc. are predicated on the TSO (ie "total store order" not
timesharing option) memory model and the z architecture storage
consistency rules documented in PoPs. 

The DESIGN of the z memory subsystem (and caches) is only distantly
related to the memory subsystem design in a commodity PC.

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[R.S.]

Craddock, Chris wrote:


Radoslaw writes


The memory is not unique design. There are regular DIMMs inside the
book. High quality, ECC, good brand, but still same technology as in


PC.


Memory controllers are probably completely different, but the


"back-end"


 (DIMMs) are not.



The PARTS that are used in the box are pretty much the same as other
commodity parts. True enough.

The DESIGN of the way they are put together, the circuitry, EDC/ECC,
page-modes etc. are predicated on the TSO (ie "total store order" not
timesharing option) memory model and the z architecture storage
consistency rules documented in PoPs. 


The DESIGN of the z memory subsystem (and caches) is only distantly
related to the memory subsystem design in a commodity PC.


This is matter of meaning. The back-end is almost the same as in PC. 
This modules are NOT significantly faster than in regular PC.
Probably "overall memory solution" is faster and more reliable than 
bunch of DIMMs - per analogia to disk systems. Single SCSI (or FC) drive 
 in modern DASD box is the same as in (better) PC. However the disk 
system is significantly more reliable (RAID), faster (cache) and more 
featured (i.e. remote copy).


From the other hand - is there so huge difference between DIMMs and 
zMemory ? Personally I doubt.
AFAIR (I could be wrong) the number of DIMMs suggest the total memory is 
simply sum of DIMM capacities. In other words: no "RAID-like" solution, 
probably some "cache-like" solution, probably faster and wider memory bus.


Regards
--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Bruce Black]

There are quite a few reasons, rather than just one single one. The
biggie IMO is that z architecture is demonically complex to implement in
silicon.
It has always amazed me that IBM is able to put out a new processor 
every year or two with little or no hardware logic errors.  I know from 
articles in the technical journals that they do extensive testing, but 
heck, in the software industry, we do extensive testing and we STILL 
have to put out a significant number of fixes.  Kudos to the hardware 
developers!


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Kuredjian, Michael]

How do we know the number of hardware design errors? With IA32, it's easier to 
discover these problems because the CPU is used by many people under many 
operating systems. IBM designs the OS and CPU, making it much easier to cover 
up any problems that do exist. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Bruce Black
Sent: Thursday, July 20, 2006 10:46 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Why is zSeries so CPU poor?


>
> There are quite a few reasons, rather than just one single one. The
> biggie IMO is that z architecture is demonically complex to implement in
> silicon.
It has always amazed me that IBM is able to put out a new processor 
every year or two with little or no hardware logic errors.  I know from 
articles in the technical journals that they do extensive testing, but 
heck, in the software industry, we do extensive testing and we STILL 
have to put out a significant number of fixes.  Kudos to the hardware 
developers!

-- 
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kuredjian, Michael
> Sent: Thursday, July 20, 2006 9:59 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> How do we know the number of hardware design errors? With 
> IA32, it's easier to discover these problems because the CPU 
> is used by many people under many operating systems. IBM 
> designs the OS and CPU, making it much easier to cover up any 
> problems that do exist. 

It depends on where the error is. If it is in some of the more exotic
instructions or facilities not normally used by a standard application
program, then you are likely correct. If the problem is that UNPK is
"broken", then everybody will notice. This was proven in the original
CMOS processor where the mantra was "don't use packed decimal, it
performs very slowly!" due to the fact that most of the packed decimal
instructions went from hardware to millicode.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Jeffrey D. Smith]

===
-Original Message-
From: "McKown, John" <[EMAIL PROTECTED]>
Sent: 7/20/2006 9:13 AM
To: "IBM-MAIN@BAMA.UA.EDU" 
Subject: Re: Why is zSeries so CPU poor?

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kuredjian, Michael
> Sent: Thursday, July 20, 2006 9:59 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Why is zSeries so CPU poor?
> 
> 
> How do we know the number of hardware design errors? With 
> IA32, it's easier to discover these problems because the CPU 
> is used by many people under many operating systems. IBM 
> designs the OS and CPU, making it much easier to cover up any 
> problems that do exist. 

It depends on where the error is. If it is in some of the more exotic
instructions or facilities not normally used by a standard application
program, then you are likely correct. If the problem is that UNPK is
"broken", then everybody will notice. This was proven in the original
CMOS processor where the mantra was "don't use packed decimal, it
performs very slowly!" due to the fact that most of the packed decimal
instructions went from hardware to millicode.

--
John McKown
===

When TRAP2/TRAP4 was first released on the P390 (sometime
around circa 1998-1999 IIRC), it was broken (storing into
the TRAPSA in the primary space instead of the home space).

We complained and IBM sent out a "fix". The P390 apparently
had some form of millicode that was easier to change compared
to changing silicon (or whatever passes for "silicon" in
a P390).


Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DR
LONGMONT, CO 80501
303-774-9381 direct
303-709-8153 cell
303-484-6170 fax

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Bruce Black]

How do we know the number of hardware design errors? With IA32, it's easier to discover these problems because the CPU is used by many people under many operating systems. IBM designs the OS and CPU, making it much easier to cover up any problems that do exist. 

IA32???

Nothing in the OS is going to cover up a CPU instruction which is 
malfunctioning.  I suppose that if a bad instruction caused a program 
check they could add code to intercept and correct it, but if it just 
gives bad results, tough.


I recently described in a posting a processor bug from some years back.  
They could not change the bad instruction in silicon but they put out a 
fix which replaced it with a millicode version that was MUCH slower than 
the silicon.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Tom Marchant]

On Thu, 20 Jul 2006 10:45:37 -0400, Bruce Black <[EMAIL PROTECTED]> 
wrote:

>>
>> There are quite a few reasons, rather than just one single one. The
>> biggie IMO is that z architecture is demonically complex to implement in
>> silicon.
>It has always amazed me that IBM is able to put out a new processor
>every year or two with little or no hardware logic errors.  I know from
>articles in the technical journals that they do extensive testing, but
>heck, in the software industry, we do extensive testing and we STILL
>have to put out a significant number of fixes.  Kudos to the hardware
>developers!
>
I agree completely.  With nearly 700 instructions defined in the POO, it's 
amazing that there are not more problems.

Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Gerhard Postpischil]

Jeffrey D. Smith wrote:

When TRAP2/TRAP4 was first released on the P390 (sometime
around circa 1998-1999 IIRC), it was broken (storing into
the TRAPSA in the primary space instead of the home space).


And I still wonder why they defined the traps the way they did - for my 
use it would have been easier to treat them as NOPR/NOP when trapping is 
off. That would allow debugging of LPA resident routines that don't fail 
when in a steplib (and I've had some of those).


Gerhard Postpischil
Bradford.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor?

[Jeffrey D. Smith]

==
-Original Message-
From: "Gerhard Postpischil" <[EMAIL PROTECTED]>
Sent: 7/20/2006 3:53 PM
To: "IBM-MAIN@BAMA.UA.EDU" 
Subject: Re: Why is zSeries so CPU poor?

Jeffrey D. Smith wrote:
> When TRAP2/TRAP4 was first released on the P390 (sometime
> around circa 1998-1999 IIRC), it was broken (storing into
> the TRAPSA in the primary space instead of the home space).

And I still wonder why they defined the traps the way they did - for my 
use it would have been easier to treat them as NOPR/NOP when trapping is 
off. That would allow debugging of LPA resident routines that don't fail 
when in a steplib (and I've had some of those).

Gerhard Postpischil
Bradford.
==

The TRAP2/TRAP4/RP facility is flawed, but still usable in
most cases.

TRAP should have the option to turn off automatically
the trap enablement bit and the option to store into
the trapsa with a key in the duct (or trapcb). The resume
program (RP) instruction should have a semi-privileged
option to turn on trap enablement, as well as setting the
key and state bits in the new psw.


Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DR
LONGMONT, CO 80501
303-774-9381 direct
303-709-8153 cell
303-484-6170 fax

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor? (was:RE: Linux - Our Saving Grace?)

[Binyamin Dissen]

On Wed, 19 Jul 2006 12:10:12 -0500 "McKown, John"
<[EMAIL PROTECTED]> wrote:

:>Just out of curiousity, why is the zSeries CPU so poor at CPU-intensive
:>workloads, like Java? Is it the "clock speed" of the circuitry? Is it
:>the complexity of the instructions? Is it the fact that the machine does
:>a lot of internal checking / checkpointing for reliability and recovery?

Is it really that "poor", or merely poor when compared to its I/O
capabilities?

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor? (was:RE: Linux - Our Saving Grace?)

[Kuredjian, Michael]

Does IBM make a co-processor add-in that can provide an assist for the JVM 
overhead?

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of McKown, John
Sent: Wednesday, July 19, 2006 1:10 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Why is zSeries so CPU poor? (was:RE: Linux - Our Saving Grace?)


Just out of curiousity, why is the zSeries CPU so poor at CPU-intensive
workloads, like Java? Is it the "clock speed" of the circuitry? Is it
the complexity of the instructions? Is it the fact that the machine does
a lot of internal checking / checkpointing for reliability and recovery?

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor? (was:RE: Linux - Our Saving Grace?)

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 07/19/2006
   at 01:29 PM, "Kuredjian, Michael" <[EMAIL PROTECTED]>
said:

>Does IBM make a co-processor add-in that can provide an assist for
>the JVM overhead?

No, but they provide an option to dedicate a processor to Java work at
a lower cost than processors allowed to run conventional workloads.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor? (was:RE: Linux - Our Saving Grace?)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 07/19/2006
   at 12:10 PM, "McKown, John" <[EMAIL PROTECTED]> said:

>Just out of curiousity, why is the zSeries CPU so poor at
>CPU-intensive workloads, like Java? Is it the "clock speed" of the
>circuitry? Is it the complexity of the instructions? Is it the fact
>that the machine does a lot of internal checking / checkpointing for
>reliability and recovery?

It's the fact that the processors are manufactured in low volumes.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is zSeries so CPU poor? (was:RE: Linux - Our Saving Grace?)

[Craddock, Chris]

> Just out of curiousity, why is the zSeries CPU so poor at
CPU-intensive
> workloads, like Java? Is it the "clock speed" of the circuitry? Is it
> the complexity of the instructions? Is it the fact that the machine
does
> a lot of internal checking / checkpointing for reliability and
recovery?

Well first of all, I would NOT say that performance is poor. Its just
not as good on certain types of workload and also tends to run at a
lower clock rate than some other machines. 

There are quite a few reasons, rather than just one single one. The
biggie IMO is that z architecture is demonically complex to implement in
silicon.

For a given clock rate and instruction architecture, the performance of
a cpu is fairly predictable - at least analytically. So the faster you
can clock it the faster it will execute instructions - all else being
equal. Also, for a given fab technology there is a theoretical upper
limit on the clock rate. Design complexity lowers the rate that can be
achieved. Z architecture ends up needing lots of gates and logic levels
and ultimately limits the clock frequency.  

The memory model is also more complex, but then again people tend to
expect reliability rather than speed when they are messing with bank
balances. There's not a lot of point clocking the cpu faster than it can
eat data, so to a large extent the cpu is gated by the cache and memory
subsystem design.

There are also significant performance differences and design trade-offs
based on the different workload mixes expected by the customer base. Z
architecture favors on-chip cache area over raw clock speed. The basis
of that idea is that when you run a general purpose mixed workload, you
will do a lot of context switching and less raw computing. 

The POWER RISC guys make a different trade off to get more raw
performance. So if you want to run a bomb simulation, you're better off
running it on a pSeries. If you want lots of address spaces running lots
of independent transactions the z may well be the better performer, even
on a per-engine basis! 

Millicode is (among other things) an effort to improve the speed/area
trade-off by removing logic from the silicon and replacing it with what
is effectively software. That moves the z design closer to the POWER
concept and I am guessing that trend will continue and the clock rates
will get closer to their technology limits. 

BTW> the POWER RISC designers and the z designers are the same people.
They flip-flop between hardware platforms for each generation of
processor technology. Technology leadership swaps back and forth between
z and p. The z9 is the more recent, and probably the technology leader
(for now) In raw compute power the pSeries will still win, but the z has
a more balanced overall design for mixed workload throughput.

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html