Re: Once upon a time......

[P H]

IBM did make an attempt to 'offload' some workloads from z to Intel and System 
p with the zBX. There weren't many takers for this. My 2 cents worth - using 
the I/O drawers may impact power/cooling requirements and other infrastructure 
within the z frame(s). Having onboard 'accelerators' on the z chip seems to be 
the current trend.

Regards

Parwez Hamid​

From: IBM Mainframe Discussion List  on behalf of 
Dave Jones 
Sent: 21 August 2022 19:17
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Once upon a time..

IBM was known for making some really nice scientific number-crunching systems. 
The 7090-7094, the S/360-195 and the follow-on s/370-195, the array processor 
3838 and the vector instruction set supported by the 30xx models come to mind. 
Over time, and with the rise of the Intel-based chips and their floating point 
capabilities, IBM decided not to pursue that market any more.
Now I am wondering if, perhaps, the time is right for IBM to re-consider that 
decision. On modern z processors, we already have IEEE floating point 
instructions in the hardware, Linux (a popular options for Intel-base 
number-crunch systems), and support for PCI.e IBM is already allowing 3rd-party 
SSD drives to be attached and accessed by the o/s. What if we were able to 
connect a number, say, 40, of GPU cards (like the Nvida Tesla 1000) to a z box. 
Have the I/O system pass the GPU card directly an LPAR running on the system. 
Porting the CUDO drives over to Linux (or z/OS, or CMS for that matter) does 
not appear to be that difficult and the hardware changes should be transparent 
to the o/s. Linux already supports a large number of scientific. software 
applications, runs the latest versions of popular scientific languages 
(FORTRAN, C/C++, Python). I believe the IBM z would be well-suited to this, as 
the density of cards in the PCIe cages is far greater than the density that 
could be obtained in normal PCs. This, combined with the strong sysplex 
clustering ability of z/OS (or SSI on z/VM) could allow the system Z platform 
to pack more computing power into a smaller footprint than a comparable 
Intel-based Linux cluster system, while being easier to use as programs would 
not have to be rewritten to take advantage of the system's clustering. It might 
be an easy sell on it's energy-reduction assets alone, since everyone is now 
worried about how much energy data-centers now consume.

Thoughts/comments/objections welcome, of course. Full disclosure: this idea was 
first suggested to me by Enzo Damato after his tour of the POK lab.
DJ

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Carmen Vitullo]

"Now if someone could loan me a z15 or z16 we might be able to try this outselves. 
:-)"

Once upon a time IBM would do this, maybe not a z15 but a z16 if the 
project was viable.


for 2 POC projects I was involved in we used a 4340 or a 41 I forget, as 
a CADCAM  CATIA processor used only for an Electronic Mock up POC 
project, and then another one to replace our spinning DASD with an RVA 
subsystem.


it would be nice if IBM still did this, or maybe they do?

Carmen

On 8/22/2022 12:40 PM, Dave Jones wrote:

Seems we may be closer than we thought to getting this done. There is already a 
whole chapter in the CP Planning and Administration Guide (Chapter 17. Using 
PCIe Functions for z/VM Guests) showing how to set up a device on the PCI.e bus.
Now if someone could loan me a z15 or z16 we might be able to try this 
outselves. :-)
DJ

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Dave Jones]

Seems we may be closer than we thought to getting this done. There is already a 
whole chapter in the CP Planning and Administration Guide (Chapter 17. Using 
PCIe Functions for z/VM Guests) showing how to set up a device on the PCI.e 
bus. 
Now if someone could loan me a z15 or z16 we might be able to try this 
outselves. :-)
DJ

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Dave Jones]

Many thanks for sharing everyone's thoughts on this matter. I think that there 
are a lot of applications that could benefit from having access to the 
capabilities of a GPU or two (or ten:-), maybe not as a replacement or 
competitor for large Intel-based supercomputers, of course. Applications like 
data mining and ML have numerical requirement too, I believe.

See here for more details on  client-provided SSD devices attached to a z 
system:

https://www.ibm.com/docs/en/zvm/7.1?topic=exploitation-apar-support-adapter-nvme

Take care.
DJ

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Timothy Sipples]

"Funny you should mention it." On April 5, 2022, IBM announced the IBM z16 with 
new IBM Telum Processors. Every main processor chip on the IBM z16 is equipped 
with a new AI accelerator section. Here's the list of operations supported on 
the AI accelerator:

LSTM Activation
GRU Activation
Fused Matrix Multiply, Bias op
Fused Matrix Multiply (w/ broadcast)
Batch Normalization
Fused Convolution, Bias Add, Relu
Max Pool 2D
Average Pool 2D
Softmax
Relu
Tanh
Sigmoid
Add
Subtract
Multiply
Divide
Min
Max
Log

The AI accelerator is expressly designed for real-time, low latency inferencing 
at massive scale (transactions and batch) — for example payment card fraud 
prevention. More information is available here: 
https://ibm.github.io/ai-on-z-101/

You can already attach GPUs to IBM zSystems and LinuxONE servers via network 
connections, and typically they'd be used for model training. If you have some 
other use cases in mind then please let IBM know preferably via an official 
channel.

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[kekronbekron]

Maybe not for zOS, but I personally think Linux on Z (with DPM fully "featured 
out" for automatic machine management)
can be a beast.
If only IBM or independent reviewers ran actual comparisons of costs, density, 
etc.

zDNN on z16 chip is "ok", but do note that this is again a whole bunch of years 
where new developers / vendors have to switch to writing compatible code.
I think the main purpose of zDNN is to stop data going out of MF for all the 
analytics & new stuff.

One of the biggest things with GPU farm is that they're not busy all of the 
time.
Seen posts from many** on Twitter saying the same.
So justifying the cost of them just sitting there is... tough.
An alternative of using cloud GPUs means moving your data around... not exactly 
simple, considering the minefield of cloud ingress/egress costs & billing in 
general.

Something like WLM to manage up to 20 GPU PCIe cards on Z can make it 
manageable.

So... although zOS may never see it.
Mainframes running Linux on Z with GPUs seems valuable.
IBM does have an array or two with NVIDIA GPUs onboard - in the Spectrum line - 
for analytics & AI workloads.

many = noteworthy voices of people in the GPU compute space, doing ML or 
analytics.

- KB

--- Original Message ---
On Monday, August 22nd, 2022 at 2:58 AM, Charles Mills  wrote:


> You would offload a lot of the (expensive) Z cycles to the GPU, right?
> 
> Still, I agree, hard for me to see this flying. It pains me to say this, but
> we just don't seem to hear people saying "I would love to put business
> process 'X' on the mainframe." Don't flame me -- I love the Z and the
> mainframe has been very, very good to me -- but what we hear mostly it seems
> is "I would love to get this business process OFF the mainframe."
> 
> Although, isn't @Dave's idea more or less what IBM has done with AI and the
> z16? Coupled specialized processors to a Z?
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Phil Smith III
> Sent: Sunday, August 21, 2022 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Once upon a time..
> 
> Dave Jones wrote about attaching GPU cards to a Z to make it a super-number
> cruncher.
> 
> 
> 
> What's the problem you're trying to solve? Cheap Intel MIPS being too
> inexpensive? Seriously, I've never heard anyone say "I'd put this
> numeric-intensive application on zSystems but they're just too slow". No,
> they say "Intel cycles are cheap: let's use an array with GPU cards
> attached".
> 
> 
> 
> There might be a use case or two, but I'd be (pleasantly!) astonished to
> find more than a handful.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Phil Smith III]

Charles wrote, in part: Although, isn't @Dave's idea more or less what IBM
has done with AI and the
z16? Coupled specialized processors to a Z?
>Although, isn't @Dave's idea more or less what IBM has done with AI and the
>z16? Coupled specialized processors to a Z?

 

Seems like it, though I'm unconvinced that there's a there THERE, either. I
sure hope there is, but the same sort of arguments are going to apply. I haz
a sad but I think the train has left the station.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Joel C. Ewing]

Correction: Just realized the z Decimal Floating point is also based on 
the IEEE 754 Standard as well, so "IEEE floating point" also includes 
decimal floating point and encompasses all the Decimal Floating Point 
formats and arithmetic instructions too.      Joel C. Ewing


On 8/21/22 17:29, Joel C. Ewing wrote:
Actually "IEEE floating point" is rather specific. z-architecture now 
supports the original Hex Floating Point (HFP) data formats, plus the 
newer Binary Floating Point (BFP) and Decimal Floating Point (DFP) 
formats.  BFP is based on IEEE binary floating point standards, and 
should be compatible with formats and computations on Intel and other 
platforms that support that standard.  The reference would be to all 
instructions that compute with BFP numeric formats, which should 
produce results that are consistent across all supporting 
architectures. On z-architecture, "IEEE floating point"≡ "binary 
floating point".


The semantics of some cross-platform programming languages (Java) 
explicitly require floating point data and operations to adhere to the 
IEEE binary standard.  That required inefficient software emulation 
prior to the availability of hardware BFP support on z machines and 
was another barrier to porting applications with floating point data 
to z-architecture platforms.


    Joel C. Ewing

On 8/21/22 16:10, Grant Taylor wrote:

On 8/21/22 12:17 PM, Dave Jones wrote:
Now I am wondering if, perhaps, the time is right for IBM to 
re-consider that decision. On modern z processors, we already have 
IEEE floating point instructions in the hardware, Linux (a popular 
options for Intel-base number-crunch systems), and support for PCI.e 
IBM is already allowing 3rd-party SSD drives to be attached and 
accessed by the o/s.


Which "floating point" instruction are you referring to?  My 
understanding is that there are many.


My understanding is that Intel CPUs also have many different floating 
point instructions in the hardware.


What if we were able to connect a number, say, 40, of GPU cards 
(like the Nvida Tesla 1000) to a z box. Have the I/O system pass the 
GPU card directly an LPAR running on the system.


I would wonder about the ratio of GPUs to systems for failure domain.

40 GPUs per system vs 8 GPUs per system.  If there is a system 
failure, the former takes out all of the GPUs while the latter takes 
out 1/5 of the GPUs.


Porting the CUDO drives over to Linux (or z/OS, or CMS for that 
matter) does not appear to be that difficult and the hardware 
changes should be transparent to the o/s.


That sounds like programming effort in the porting whereas the 
requisite programs already exist on the Open Systems side.


Linux already supports a large number of scientific. software 
applications, runs the latest versions of popular scientific 
languages (FORTRAN, C/C++, Python).


I believe the IBM z would be well-suited to this, as the density of 
cards in the PCIe cages is far greater than the density that could 
be obtained in normal PCs.


I question the veracity of that statement.

There are multiple commercially available systems that will hold 
eight GPUs in a 3 RU server.  That means that it would be possible to 
put 104 GPUs in a standard 40 RU cabinet.


The last time I checked, the smallest IBM Z would fit in a standard 
19" cabinet, but it took up a considerable amount of the cabinet.  So 
how many I/O drawers ~> GPUs are you going to fit in that cabinet 
with the CEC(s)?


Then there's the fact that in most of the GPU based computing that 
I've seen, a disproportionate amount of the computing is done by the 
GPU and the CPU does little more than shuffle data around.  In some 
ways, the GPU might be thought of like the processor and the CPU 
thought of like I/O controllers.  SO with this in mind, just how much 
CPU is needed for an I/O controller?  Is it really worth consuming 
more RUs that can be dedicated to more GPUs?


This, combined with the strong sysplex clustering ability of z/OS 
(or SSI on z/VM) could allow the system Z platform to pack more 
computing power into a smaller footprint than a comparable 
Intel-based Linux cluster system, while being easier to use as 
programs would not have to be rewritten to take advantage of the 
system's clustering.


Despite z/OS having impressive clustering abilities, I don't think 
that GPU based computing would take advantage of it.


It might be an easy sell on it's energy-reduction assets alone, 
since everyone is now worried about how much energy data-centers now 
consume.


I don't have any numbers to back it up, but I question the veracity 
of that.


Thoughts/comments/objections welcome, of course. Full disclosure: 
this idea was first suggested to me by Enzo Damato after his tour of 
the POK lab.


I believe that putting GPUs in the mainframe would be very 
interesting. And would probably have some interesting applications.  
But I don't think that using a mainframe to drive GPUs is going to be 
the next big 

Re: Once upon a time......

[Joel C. Ewing]

Actually "IEEE floating point" is rather specific. z-architecture now 
supports the original Hex Floating Point (HFP) data formats, plus the 
newer Binary Floating Point (BFP) and Decimal Floating Point (DFP) 
formats.  BFP is based on IEEE binary floating point standards, and 
should be compatible with formats and computations on Intel and other 
platforms that support that standard.  The reference would be to all 
instructions that compute with BFP numeric formats, which should produce 
results that are consistent across all supporting architectures. On 
z-architecture, "IEEE floating point"≡ "binary floating point".


The semantics of some cross-platform programming languages (Java) 
explicitly require floating point data and operations to adhere to the 
IEEE binary standard.  That required inefficient software emulation 
prior to the availability of hardware BFP support on z machines and was 
another barrier to porting applications with floating point data to 
z-architecture platforms.


    Joel C. Ewing

On 8/21/22 16:10, Grant Taylor wrote:

On 8/21/22 12:17 PM, Dave Jones wrote:
Now I am wondering if, perhaps, the time is right for IBM to 
re-consider that decision. On modern z processors, we already have 
IEEE floating point instructions in the hardware, Linux (a popular 
options for Intel-base number-crunch systems), and support for PCI.e 
IBM is already allowing 3rd-party SSD drives to be attached and 
accessed by the o/s.


Which "floating point" instruction are you referring to?  My 
understanding is that there are many.


My understanding is that Intel CPUs also have many different floating 
point instructions in the hardware.


What if we were able to connect a number, say, 40, of GPU cards (like 
the Nvida Tesla 1000) to a z box. Have the I/O system pass the GPU 
card directly an LPAR running on the system.


I would wonder about the ratio of GPUs to systems for failure domain.

40 GPUs per system vs 8 GPUs per system.  If there is a system 
failure, the former takes out all of the GPUs while the latter takes 
out 1/5 of the GPUs.


Porting the CUDO drives over to Linux (or z/OS, or CMS for that 
matter) does not appear to be that difficult and the hardware changes 
should be transparent to the o/s.


That sounds like programming effort in the porting whereas the 
requisite programs already exist on the Open Systems side.


Linux already supports a large number of scientific. software 
applications, runs the latest versions of popular scientific 
languages (FORTRAN, C/C++, Python).


I believe the IBM z would be well-suited to this, as the density of 
cards in the PCIe cages is far greater than the density that could be 
obtained in normal PCs.


I question the veracity of that statement.

There are multiple commercially available systems that will hold eight 
GPUs in a 3 RU server.  That means that it would be possible to put 
104 GPUs in a standard 40 RU cabinet.


The last time I checked, the smallest IBM Z would fit in a standard 
19" cabinet, but it took up a considerable amount of the cabinet.  So 
how many I/O drawers ~> GPUs are you going to fit in that cabinet with 
the CEC(s)?


Then there's the fact that in most of the GPU based computing that 
I've seen, a disproportionate amount of the computing is done by the 
GPU and the CPU does little more than shuffle data around.  In some 
ways, the GPU might be thought of like the processor and the CPU 
thought of like I/O controllers.  SO with this in mind, just how much 
CPU is needed for an I/O controller?  Is it really worth consuming 
more RUs that can be dedicated to more GPUs?


This, combined with the strong sysplex clustering ability of z/OS (or 
SSI on z/VM) could allow the system Z platform to pack more computing 
power into a smaller footprint than a comparable Intel-based Linux 
cluster system, while being easier to use as programs would not have 
to be rewritten to take advantage of the system's clustering.


Despite z/OS having impressive clustering abilities, I don't think 
that GPU based computing would take advantage of it.


It might be an easy sell on it's energy-reduction assets alone, since 
everyone is now worried about how much energy data-centers now consume.


I don't have any numbers to back it up, but I question the veracity of 
that.


Thoughts/comments/objections welcome, of course. Full disclosure: 
this idea was first suggested to me by Enzo Damato after his tour of 
the POK lab.


I believe that putting GPUs in the mainframe would be very 
interesting. And would probably have some interesting applications.  
But I don't think that using a mainframe to drive GPUs is going to be 
the next big thing in GPU heavy computing.


Also, look at all the BitCoin (et al.) miners out there that use PCIe 
expanders (fan-out) to connect many GPUs to a single CPU. I've seen 
GPU to CPU ratios ten to one or greater.  So, again, the CPU workload 
isn't where the demand is.  I also think that the CPU workload is what 
the 

Re: Once upon a time......

[Bill Johnson]

The mainframe workload continues to increase and will continue to increase for 
decades.


Sent from Yahoo Mail for iPhone


On Sunday, August 21, 2022, 5:29 PM, Charles Mills  wrote:

You would offload a lot of the (expensive) Z cycles to the GPU, right?

Still, I agree, hard for me to see this flying. It pains me to say this, but
we just don't seem to hear people saying "I would love to put business
process 'X' on the mainframe." Don't flame me -- I love the Z and the
mainframe has been very, very good to me -- but what we hear mostly it seems
is "I would love to get this business process OFF the mainframe."

Although, isn't @Dave's idea more or less what IBM has done with AI and the
z16? Coupled specialized processors to a Z?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Sunday, August 21, 2022 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Once upon a time..

Dave Jones wrote about attaching GPU cards to a Z to make it a super-number
cruncher.

 

What's the problem you're trying to solve? Cheap Intel MIPS being too
inexpensive? Seriously, I've never heard anyone say "I'd put this
numeric-intensive application on zSystems but they're just too slow". No,
they say "Intel cycles are cheap: let's use an array with GPU cards
attached".

 

There might be a use case or two, but I'd be (pleasantly!) astonished to
find more than a handful.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Charles Mills]

You would offload a lot of the (expensive) Z cycles to the GPU, right?

Still, I agree, hard for me to see this flying. It pains me to say this, but
we just don't seem to hear people saying "I would love to put business
process 'X' on the mainframe." Don't flame me -- I love the Z and the
mainframe has been very, very good to me -- but what we hear mostly it seems
is "I would love to get this business process OFF the mainframe."

Although, isn't @Dave's idea more or less what IBM has done with AI and the
z16? Coupled specialized processors to a Z?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Sunday, August 21, 2022 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Once upon a time..

Dave Jones wrote about attaching GPU cards to a Z to make it a super-number
cruncher.

 

What's the problem you're trying to solve? Cheap Intel MIPS being too
inexpensive? Seriously, I've never heard anyone say "I'd put this
numeric-intensive application on zSystems but they're just too slow". No,
they say "Intel cycles are cheap: let's use an array with GPU cards
attached".

 

There might be a use case or two, but I'd be (pleasantly!) astonished to
find more than a handful.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Grant Taylor]

On 8/21/22 12:17 PM, Dave Jones wrote:
Now I am wondering if, perhaps, the time is right for IBM to 
re-consider that decision. On modern z processors, we already have IEEE 
floating point instructions in the hardware, Linux (a popular options 
for Intel-base number-crunch systems), and support for PCI.e IBM is 
already allowing 3rd-party SSD drives to be attached and accessed by 
the o/s.


Which "floating point" instruction are you referring to?  My 
understanding is that there are many.


My understanding is that Intel CPUs also have many different floating 
point instructions in the hardware.


What if we were able to connect a number, say, 40, of GPU cards (like 
the Nvida Tesla 1000) to a z box. Have the I/O system pass the GPU 
card directly an LPAR running on the system.


I would wonder about the ratio of GPUs to systems for failure domain.

40 GPUs per system vs 8 GPUs per system.  If there is a system failure, 
the former takes out all of the GPUs while the latter takes out 1/5 of 
the GPUs.


Porting the CUDO drives over to Linux (or z/OS, or CMS for that matter) 
does not appear to be that difficult and the hardware changes should 
be transparent to the o/s.


That sounds like programming effort in the porting whereas the requisite 
programs already exist on the Open Systems side.


Linux already supports a large number of scientific. software 
applications, runs the latest versions of popular scientific languages 
(FORTRAN, C/C++, Python).


I believe the IBM z would be well-suited to this, as the density of 
cards in the PCIe cages is far greater than the density that could 
be obtained in normal PCs.


I question the veracity of that statement.

There are multiple commercially available systems that will hold eight 
GPUs in a 3 RU server.  That means that it would be possible to put 104 
GPUs in a standard 40 RU cabinet.


The last time I checked, the smallest IBM Z would fit in a standard 19" 
cabinet, but it took up a considerable amount of the cabinet.  So how 
many I/O drawers ~> GPUs are you going to fit in that cabinet with the 
CEC(s)?


Then there's the fact that in most of the GPU based computing that I've 
seen, a disproportionate amount of the computing is done by the GPU and 
the CPU does little more than shuffle data around.  In some ways, the 
GPU might be thought of like the processor and the CPU thought of like 
I/O controllers.  SO with this in mind, just how much CPU is needed for 
an I/O controller?  Is it really worth consuming more RUs that can be 
dedicated to more GPUs?


This, combined with the strong sysplex clustering ability of z/OS (or 
SSI on z/VM) could allow the system Z platform to pack more computing 
power into a smaller footprint than a comparable Intel-based Linux 
cluster system, while being easier to use as programs would not have 
to be rewritten to take advantage of the system's clustering.


Despite z/OS having impressive clustering abilities, I don't think that 
GPU based computing would take advantage of it.


It might be an easy sell on it's energy-reduction assets alone, since 
everyone is now worried about how much energy data-centers now consume.


I don't have any numbers to back it up, but I question the veracity of that.

Thoughts/comments/objections welcome, of course. Full disclosure: 
this idea was first suggested to me by Enzo Damato after his tour of 
the POK lab.


I believe that putting GPUs in the mainframe would be very interesting. 
And would probably have some interesting applications.  But I don't 
think that using a mainframe to drive GPUs is going to be the next big 
thing in GPU heavy computing.


Also, look at all the BitCoin (et al.) miners out there that use PCIe 
expanders (fan-out) to connect many GPUs to a single CPU.  I've seen GPU 
to CPU ratios ten to one or greater.  So, again, the CPU workload isn't 
where the demand is.  I also think that the CPU workload is what the 
mainframe brings to the table.


I think this is an interesting thought experiment.  But I don't think 
that it will compete in the market.  Partially because if it would, I 
suspect that it would be doing so already.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Phil Smith III]

Dave Jones wrote about attaching GPU cards to a Z to make it a super-number
cruncher.

 

What's the problem you're trying to solve? Cheap Intel MIPS being too
inexpensive? Seriously, I've never heard anyone say "I'd put this
numeric-intensive application on zSystems but they're just too slow". No,
they say "Intel cycles are cheap: let's use an array with GPU cards
attached".

 

There might be a use case or two, but I'd be (pleasantly!) astonished to
find more than a handful.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Seymour J Metz]

What gives you that idea? The 7090 and 7094 preceded the S/360, and the 
supercomputing link from that page lists machines back to 1954.

Not that IBM was the only fish in that pond (-;


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, August 21, 2022 2:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Once upon a time..

On Sun, 21 Aug 2022 13:17:41 -0500, Dave Jone wrote:

>IBM was known for making some really nice scientific number-crunching systems.
>
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fthought-leadership%2Fsummit-supercomputer%2Fdata=05%7C01%7Csmetz3%40gmu.edu%7Cd4f95add4e294a865b8108da83a6640f%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637967047914284409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=RrSonqwPzD1Tcv0TxhlAYyT5l0zGFWkodgmufQ1vPSA%3Dreserved=0>
(But almost a decade old.)

Does "nice" mean to you "360-compatible"?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Once upon a time......

[Paul Gilmartin]

On Sun, 21 Aug 2022 13:17:41 -0500, Dave Jone wrote:

>IBM was known for making some really nice scientific number-crunching systems. 
> 
>

(But almost a decade old.)

Does "nice" mean to you "360-compatible"?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Once upon a time......

[Dave Jones]

IBM was known for making some really nice scientific number-crunching systems. 
The 7090-7094, the S/360-195 and the follow-on s/370-195, the array processor 
3838 and the vector instruction set supported by the 30xx models come to mind. 
Over time, and with the rise of the Intel-based chips and their floating point 
capabilities, IBM decided not to pursue that market any more. 
Now I am wondering if, perhaps, the time is right for IBM to re-consider that 
decision. On modern z processors, we already have IEEE floating point 
instructions in the hardware, Linux (a popular options for Intel-base 
number-crunch systems), and support for PCI.e IBM is already allowing 3rd-party 
SSD drives to be attached and accessed by the o/s. What if we were able to 
connect a number, say, 40, of GPU cards (like the Nvida Tesla 1000) to a z box. 
Have the I/O system pass the GPU card directly an LPAR running on the system. 
Porting the CUDO drives over to Linux (or z/OS, or CMS for that matter) does 
not appear to be that difficult and the hardware changes should be transparent 
to the o/s. Linux already supports a large number of scientific. software 
applications, runs the latest versions of popular scientific languages 
(FORTRAN, C/C++, Python). I believe the IBM z would be well-suited to this, as 
the density of cards in the PCIe cages is far greater than the density that 
could be obtained in normal PCs. This, combined with the strong sysplex 
clustering ability of z/OS (or SSI on z/VM) could allow the system Z platform 
to pack more computing power into a smaller footprint than a comparable 
Intel-based Linux cluster system, while being easier to use as programs would 
not have to be rewritten to take advantage of the system's clustering. It might 
be an easy sell on it's energy-reduction assets alone, since everyone is now 
worried about how much energy data-centers now consume. 

Thoughts/comments/objections welcome, of course. Full disclosure: this idea was 
first suggested to me by Enzo Damato after his tour of the POK lab.
DJ

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN