[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Aug 16 09:12:43 1995 
Subject:Re: Pop-11 language changes 
From:A . Sloman 
Volume-ID:950817.02 

Julian writes about changes to Pop-11 in Poplog V15.0

I have just installed a beta test Poplog V15 on the new Digital Alpha
servers in the Birmingham central computing service, and it was
generally trouble free. Moreover, it is VERY fast.

For example my standard simple benchmark tests give the following
results for maximum speeds (not necessarily average or generally
attainable speeds):

                       D     E      F    G     H       I     J      K

                      Sun*  Sun    Sun  Sun   Sun     Sun    HP    DEC
                      SS2   SS/    SS10 SS10  SS10    Ross   HP-UX Alpha
                            672    /30   /41   /52    HS66   735  OSF/1
                                             Sol2.3   mhz
-------------------------------------------------------------------
Prolog test KLips    117.0  134.8 203.3 238   295     354    387  1550
(Simple reverse)
-------------------------------------------------------------------
Pop-11 Factorial(1000)
three times (Secs)
    recursive         0.81  0.75  0.55  0.46  0.42   0.38    0.11  0.03
    iterative         0.78  0.71  0.51  0.45  0.40   0.38    0.11  0.03
-------------------------------------------------------------------
Floating point
    single (secs)     0.38  0.38  0.21  0.19  0.17   0.13    0.13  0.03
    double            0.43  0.41  0.25  0.22  0.18   0.16    0.17  0.03
------------------------------------------------------------------------------------

* Replacing SS2 processor with Weitek chip gave
    177 Klips, Factorial: 0.5, 0.45 secs, Float: 0.23, 0.3 secs
    I.e. not quite SS10/30

I must change the precision of the output times for the arithmetic
tests, or increase the number of iterations.

I am quite worried about the implications of the changes to Pop-11. I
agree that that's how Pop-11 should have been in the first place, but it
is very dangerous to have two coexisting semantic interpretations for
exactly the same syntax, where the difference depends on some global
switch that may be quite out of sight when one looks at a procedure
definition. Would it not have been better to have new syntax for the
case were input and output locals were to default to lvars?

Aaron