IBM mainframe 360/30 vs. iPad 2019

[Henko]

I remember making a large stress analisys program (Finite Element Method) in Fortran IV on the new IBM 360/30 mainframe in the late sixties. The process involved a large number of simultaneous linear equations to be solved. Intensive use of a hard disk (7.2 Mb) was necessary due to the limited amount of internal memory (64 KB).
It took more than 30 minutes of processing time before the first output on printer appeared. The mainframe was operated by the administrative dept., and more than once my job was killed by the operator, because "the job hung...". I ended up testing my program midnights, operating the mainframe myself and alone (those were the days).
The amount of floating point operations (FLOPS) in the main calculation was about 120.000.
That's about 17 msec/FLOP.

Let's compare with an everybody's iPad today.
The little program hereafter generates a 50x50 matrix with random coefficients.
The matrix is inverted, which takes somwhat more than 50^3 = 125.000 FLOPS.
In order to have a glance at the precision of sB, the inverse matrix is multiplied whith the original, which should produce the unity matrix (all diagonal elements equal one, all rest equal zero)
All in all, the number of FLOPS is about 140.000, the total processing time is 0.32 seconds.
That is 2.3 usec/FLOP, or about 7400 times faster than a 360/30.

Code: Select all

option base 1
n=50
dim matA(n,n),matAI(n,n),matI(n,n)
time reset
mat_rnd (n,n,matA,-10,10)          ' genrate 50x50 random matrix
mat_inv(n,matA,matAI)               ' calculate the inverse matrix
mat_mul(n,n,matA,matAI,matI)   ' multiply with the original
print time()
debug pause                                ' inspect precision of the unit matrix matI
end

' {matlib}

' produce a matrix with random elements between mini and maxi
'
def mat_rnd (n,m,mat(,),mini,maxi)
for i=1 to n
  for j=1 to m ! mat(i,j)=mini+(maxi-mini)*rnd(1) ! next j
next i
end def

' produce the inverse of square matrix a() giving matrix ainv()
' returns 1 on success, 0 if matrix is singular
'
def mat_inv (nvar,a(,),ainv(,))
dim w(nvar,2*nvar)                      
for i=1 to nvar                 
  for j=1 to nvar ! w(i,j)=a(i,j) ! w(i,j+nvar)=0  ! next j
  w(i,i+nvar)=1
  next i
for piv=1 to nvar
  fac=w(piv,piv) ! if fac=0 then return 0
  for j=piv to piv+nvar ! w(piv,j)=w(piv,j)/fac ! next j
  for i=1 to nvar
    if i<>piv then
      fac=w(i,piv)
      for j=piv to piv+nvar ! w(i,j)=w(i,j)-fac*w(piv,j) ! next j
      endif
    next i
  next piv
for i=1 to nvar
  for j=1 to nvar ! ainv(i,j)=w(i,j+nvar) ! next j
  next i
return 1
end def

' produce product of mata() and matb() giving matc()
'
def mat_mul (n,m,mata(,),matb(,),matc(,))
for i=1 to n
  for j=1 to n
    tot=0
    for k=1 to m ! tot=tot+mata(i,k)*matb(k,j) ! next k
    matc(i,j)=tot
    next j
  next i
end def

On inpection, it can be seen, that all (visible) diagonal elements are exactly 1, the (visible) non-diagonal elements wich should be zero, are all smaller than 1.E-13
After such an amount of calculations with cumulative error propagation, that may be called excellent IMNSHO.

[Mr. Kibernetik]

In new BASIC matrix operations will be built-in, something like:

Code: Select all

x = y * z

where X, Y and Z are arrays.
Serious math inspection will be very welcome
First version will appear on Mac.

[rbytes]

I ran the program multiple times and checked accuracy each time. It seemed that some of the zero results were larger than 1.E-13. However the way DEBUG PAUSE displays the matrices makes it difficult to be sure. So I made some code modifications to print the results to the screen.

I added this line after OPTION BASE 1

SET OUTPUT FONT SIZE 11


and substituted the following code for the function def mat_mul

Code: Select all

def mat_mul (n,m,mata(,),matb(,),matc(,))
for i=1 to n
  for j=1 to n
    tot=0
    for k=1 to m ! tot=tot+mata(i,k)*matb(k,j) ! next k

' the following line sets the tolerance for what values of tot should print as a 0

    if tot<1.E-13 then matc(i,j)=0  else matc(i,j)=tot
    print matc(i,j)&" ";
    next j
    print
  next i
end def

I reasoned that If all errors were less than 1.E-13, I would always see a perfect matrix printed, containing only 0s and 1s. That did happen occasionally, but often it didn't. Below are screenshots of three consecutive runs. You might think that accuracy is getting better with each run, but it is just randomness. If you keep running the program, you will again see a wide variation of errors that exceed 1.E-13 in the matrices, and some perfect ones. I don't mean to be picky. Even an accuracy better than 1.E-12 would be excellent.

[Dutchman]

I remember making a large stress analisys program (Finite Element Method) in Fortran IV on the new IBM 360/30 mainframe in the late sixties. The process involved a large number of simultaneous linear equations to be solved. Intensive use of a hard disk (7.2 Mb) was necessary due to the limited amount of internal memory (64 KB).
It took more than 30 minutes of processing time before the first output on printer appeared. The mainframe was operated by the administrative dept., and more than once my job was killed by the operator, because "the job hung...". I ended up testing my program midnights, operating the mainframe myself and alone (those were the days).
The amount of floating point operations (FLOPS) in the main calculation was about 120.000.
That's about 17 msec/FLOP.

Thank you for retrieving these memories.
I also have bad, but especially good memories of that time of punch cards and other inconveniences.
However, I no longer had any specifications, which is why I was so happy with your comparison with iPad.
Very enlightening.

[Henko]

Thank you for retrieving these memories.
I also have bad, but especially good memories of that time of punch cards and other inconveniences.
However, I no longer had any specifications, which is why I was so happy with your comparison with iPad.
Very enlightening.

Talking about inconveniences: before the 3th generation 360/30, i learned programming on a 2nd generation IBM 1620, which had punched papertape as I/O and intermediate storage.
You had to be able to "read" the 5-bit code on the tape, in order to make local corrections in it, using a little perforation tool and non-transparant tape. On that machine, after learning the (decimal) machine language and a kind of assembler, we used UTO (Uni of Toronto Ottawa) Fortran.
It was a two pass compiler, using three paper tape runs. Debugging was a hell.

[Henko]

@ rbytes,

I reasoned that If all errors were less than 1.E-13, I would always see a perfect matrix printed, containing only 0s and 1s. That did happen occasionally, but often it didn't. Below are screenshots of three consecutive runs. You might think that accuracy is getting better with each run, but it is just randomness. If you keep running the program, you will again see a wide variation of errors that exceed 1.E-13 in the matrices, and some perfect ones. I don't mean to be picky. Even an accuracy better than 1.E-12 would be excellent.

Nice mod for further analysis.
Even with 1.E-12 as bias, larger "errors" still occurred 3 times out of 10 runs.
With 1.E-11 as bias, all 10 runs did produce a clean unity matrix (but even that is not a 100% guaranty).
Yet it is a remarkable good precision result, as the matrix inversion calculation is structured in such a way that all intermediate calculation results are input for the successive calculations.

[GeorgeMcGinn]

I remember having to program punch card machines and other devices using Black wire boards with different colored and different length wires that acted as compascitors, resistors, switches, etc.

And Assembler F was the main language that OS/HASP was written in.

Some real good memories! (And don't forget the green cards, yellow cards, and the pads of printer layout sheets - and the COBOL coding forms!).

Thank you for retrieving these memories.
I also have bad, but especially good memories of that time of punch cards and other inconveniences.
However, I no longer had any specifications, which is why I was so happy with your comparison with iPad.
Very enlightening.

Talking about inconveniences: before the 3th generation 360/30, i learned programming on a 2nd generation IBM 1620, which had punched papertape as I/O and intermediate storage.
You had to be able to "read" the 5-bit code on the tape, in order to make local corrections in it, using a little perforation tool and non-transparant tape. On that machine, after learning the (decimal) machine language and a kind of assembler, we used UTO (Uni of Toronto Ottawa) Fortran.
It was a two pass compiler, using three paper tape runs. Debugging was a hell.

[GeorgeMcGinn]

I tried both programs and on my iPad Pro 10.5 Inch running iOS 10.3.3, rbytes code just says "Finished" and Henko's code it displays 0.276392.

I do not get the matrix rbytes gets.

[GeorgeMcGinn]

Talking about inconveniences: before the 3th generation 360/30, i learned programming on a 2nd generation IBM 1620, which had punched papertape as I/O and intermediate storage.
You had to be able to "read" the 5-bit code on the tape, in order to make local corrections in it, using a little perforation tool and non-transparant tape. On that machine, after learning the (decimal) machine language and a kind of assembler, we used UTO (Uni of Toronto Ottawa) Fortran.
It was a two pass compiler, using three paper tape runs. Debugging was a hell.

The only time I had to deal with Paper tape corrections was when I was programming on the DEC PDP 8/E, which used paper tape to install and run programs. I was in high school, and I remember that punch tool because the school was too cheap to buy tons and tons of rolls of paper tape, so I learned how to do it from my math teacher. Great memories of my early high school years. I was in ninth grade when I was first exposed to it.

[Henko]

I tried both programs and on my iPad Pro 10.5 Inch running iOS 10.3.3, rbytes code just says "Finished" and Henko's code it displays 0.276392.

I do not get the matrix rbytes gets.

Are you sure that you use the matrix multiply function adapted by rbytes? It must print the matrix!

Code: Select all

def mat_mul (n,m,mata(,),matb(,),matc(,))
for i=1 to n
  for j=1 to n
    tot=0
    for k=1 to m ! tot=tot+mata(i,k)*matb(k,j) ! next k

' the following line sets the tolerance for what values of tot should print as a 0

    if tot<1.E-11 then matc(i,j)=0  else matc(i,j)=tot
    print matc(i,j)&" ";
    next j
    print
  next i
end def