Re: Why is zSeries so CPU poor?

2006-07-20 Thread 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?

2006-07-20 Thread 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?

2006-07-20 Thread 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?

2006-07-20 Thread 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?

2006-07-20 Thread 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?

2006-07-20 Thread 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?

2006-07-20 Thread Jeffrey D. Smith
===
-Original Message-
From: McKown, John [EMAIL PROTECTED]
Sent: 7/20/2006 9:13 AM
To: IBM-MAIN@BAMA.UA.EDU 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?

2006-07-20 Thread 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?

2006-07-20 Thread 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?

2006-07-20 Thread Jeffrey D. Smith
==
-Original Message-
From: Gerhard Postpischil [EMAIL PROTECTED]
Sent: 7/20/2006 3:53 PM
To: IBM-MAIN@BAMA.UA.EDU 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


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

2006-07-19 Thread McKown, John
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


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

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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?

2006-07-19 Thread 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

Re: Why is zSeries so CPU poor?

2006-07-19 Thread 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 http://patriot.net/~shmuel/resume/brief.html 
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?

2006-07-19 Thread Shmuel Metz (Seymour J.)
In
![EMAIL PROTECTED],
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 http://patriot.net/~shmuel/resume/brief.html 
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?)

2006-07-19 Thread 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 http://patriot.net/~shmuel/resume/brief.html 
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?)

2006-07-19 Thread 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 http://patriot.net/~shmuel/resume/brief.html 
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?)

2006-07-19 Thread 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