Ada95 speed

Ada95 speed

[Clifford J. Nelson]

Ten years ago a Mandelbrot set computation and display on a 1200x700
screen with eight bit color took six seconds in C on a MacIIfx.

The following computations (leaving out all the with statements that you
need for the Mac) take ten seconds on an iMac 266 MHertz Mac OS 8.5.1
with the CodeBuilder Ada95 GNU from Tenon. I think it should run ten
times faster.

Is Ada95 slow in order to be safe?
Is GNU Ada95 slower than most Adas?
Is the iMac slow? Mac OS 8.5.1 slow?  CodeBuilder?
Why does it take so long?

Program follows--------

with Ada.Numerics.Complex_Types;
use Ada.Numerics.Complex_Types;

procedure Mandel is

-- Initialize procedure goes here for windRect.bottom and windRect.top

procedure Display(Mag : in Float) is
    It : Integer;
    X, Y : Float;
    C, Z : Complex;
    Num_Iters : constant := 64;
    Vertical_Maximum : constant Short_Integer := windRect.bottom;
    Horizontal_Maximum : constant Short_Integer := windRect.Right;
    Ver_Size : constant Float := Float(Vertical_Maximum + 1);
    Hor_Size : constant Float := Float(Horizontal_Maximum + 1);
    StartY : constant Float := -Mag * Ver_Size;
    StartX : constant Float := -Mag * Hor_Size;
    Step : constant Float :=  2.0 * Mag ;

  begin
   Y := StartY;
   for Y_Pos in windRect.top..windrect.bottom - 1 loop
      X := StartX;
      for X_Pos in windRect.left..windRect.right loop
        Z := (X, Y); -- Complex value; standard Ada 95!
        C := Z;
        for I in 0..Num_Iters loop
          It := I;
          exit when (abs( Z)) > 2.0;
          Z := Z * Z + C; -- Complex arithmetic
        end loop;
    -- draw pixel here in color depending on variable It.
    X := X + Step;
    end loop;
   Y := Y + Step;
   end loop;
  end Display;

begin -- Main body of program Mandel
  Initialize;
   Display(0.0025); -- draw the fractal!
  loop
    exit when Events.Button;
  end loop;
end Mandel;

Re: Ada95 speed

[David Starner]

"Clifford J. Nelson" wrote:
> 
> Ten years ago a Mandelbrot set computation and display on a 1200x700
> screen with eight bit color took six seconds in C on a MacIIfx.
> 
> The following computations (leaving out all the with statements that you
> need for the Mac) take ten seconds on an iMac 266 MHertz Mac OS 8.5.1
> with the CodeBuilder Ada95 GNU from Tenon. I think it should run ten
> times faster.

Was the code identical? I've had two Mandelbrot generators on the same
system, and one took hours and one took seconds to do the Mandelbrot.
Since the later was carefully and extensively tuned (cf. Fractint), I
get the impression that the comparision code may have been similarily
tuned. 

>           exit when (abs( Z)) > 2.0;

This line is probably the problem. The C code probably never did a sqrt;
most likely, the code looked like (z.i* z.i + z.r * z.r) > 4.0. Do the
same thing in Ada, and you'll probably see a huge improvement.

Re: Ada95 speed

[Clifford J. Nelson]

David Starner wrote:

> "Clifford J. Nelson" wrote:
> >
> > Ten years ago a Mandelbrot set computation and display on a 1200x700
> > screen with eight bit color took six seconds in C on a MacIIfx.
> >
> > The following computations (leaving out all the with statements that you
> > need for the Mac) take ten seconds on an iMac 266 MHertz Mac OS 8.5.1
> > with the CodeBuilder Ada95 GNU from Tenon. I think it should run ten
> > times faster.
>
> Was the code identical? I've had two Mandelbrot generators on the same
> system, and one took hours and one took seconds to do the Mandelbrot.
> Since the later was carefully and extensively tuned (cf. Fractint), I
> get the impression that the comparision code may have been similarily
> tuned.

Maybe not, but I think it showed 256 colors not just 64 like mine.

>
>
> >           exit when (abs( Z)) > 2.0;
>
> This line is probably the problem. The C code probably never did a sqrt;
> most likely, the code looked like (z.i* z.i + z.r * z.r) > 4.0. Do the
> same thing in Ada, and you'll probably see a huge improvement.

Yes! By a factor of five. Thanks. Here is the program again. It should run on
any Ada system I guess.

with Ada.Numerics.Complex_Types;
with Calendar;
with Ada.Text_io;
use Ada.Numerics.Complex_Types;
use Calendar;
use Ada.Text_io;

procedure timetest is

Ch : String (1..2);
procedure Display(Mag : in Float) is
    It : Integer;
    X, Y : Float;
    C, Z : Complex;
    Num_Iters : constant := 64;
    Vertical_Maximum : constant Short_Integer := 700;
    Horizontal_Maximum : constant Short_Integer := 1200;
    Ver_Size : constant Float := Float(Vertical_Maximum + 1);
    Hor_Size : constant Float := Float(Horizontal_Maximum + 1);
    StartY : constant Float := -Mag * Ver_Size;
    StartX : constant Float := -Mag * Hor_Size;
    Step : constant Float :=  2.0 * Mag ;

  begin
   Put(Duration'Image(Seconds(Clock)));
   Y := StartY;
   for Y_Pos in 0..700  loop
      X := StartX;
      for X_Pos in 0..1200 loop
        Z := (X, Y); -- Complex value; standard Ada 95!
        C := Z;
        for I in 0..Num_Iters loop
          It := I;
          exit when (Z.Re * Z.Re + Z.Im * Z.Im) > 4.0;
          Z := Z * Z + C; -- Complex arithmetic
        end loop;
    -- draw pixel here in color depending on variable It.
    X := X + Step;
    end loop;
   Y := Y + Step;
   end loop;
    Put(Duration'Image(Seconds(Clock)));
  end Display;

begin -- Main body of program timetest
   Display(0.0025); -- draw the fractal!
  Get(Ch);
end timetest;

Re: Ada95 speed

[Tucker Taft]

Clifford J. Nelson (cnelson9@gte.net) wrote:

: Ten years ago a Mandelbrot set computation and display on a 1200x700
: screen with eight bit color took six seconds in C on a MacIIfx.

: The following computations (leaving out all the with statements that you
: need for the Mac) take ten seconds on an iMac 266 MHertz Mac OS 8.5.1
: with the CodeBuilder Ada95 GNU from Tenon. I think it should run ten
: times faster.

: Is Ada95 slow in order to be safe?

There is nothing in this code that would require any
constraint checks.  You could put a "pragma Suppress(all_checks);"
at the top of your source file to verify this.

: Is GNU Ada95 slower than most Adas?

Not particularly.

: Is the iMac slow? Mac OS 8.5.1 slow?  CodeBuilder?

The iMac is certainly much master than the MacIIfx in general,
at least for pure computation.

Probably the time is dominated by the drawing of the pixels.
The only mildly complicated numeric operation in the code below is
the call on "abs" for a complex number.  That involves 2 multiplies
and a square-root.

It would be useful to see where the time is going.  Chances are that
the generated code is running much faster, and the time is all spent
in the graphics routines drawing pixels.

: Why does it take so long?

My bet is on the graphic output routines.  The code generated 
by the Ada compiler is probably taking an immeasurably small amount 
of time.  Try changing the program so that it only does the computation.
Then add back in the graphics output.  Measure the difference in
execution time...

: Program follows--------

: with Ada.Numerics.Complex_Types;
: use Ada.Numerics.Complex_Types;

: procedure Mandel is

: -- Initialize procedure goes here for windRect.bottom and windRect.top

: procedure Display(Mag : in Float) is
:     It : Integer;
:     X, Y : Float;
:     C, Z : Complex;
:     Num_Iters : constant := 64;
:     Vertical_Maximum : constant Short_Integer := windRect.bottom;
:     Horizontal_Maximum : constant Short_Integer := windRect.Right;
:     Ver_Size : constant Float := Float(Vertical_Maximum + 1);
:     Hor_Size : constant Float := Float(Horizontal_Maximum + 1);
:     StartY : constant Float := -Mag * Ver_Size;
:     StartX : constant Float := -Mag * Hor_Size;
:     Step : constant Float :=  2.0 * Mag ;

:   begin
:    Y := StartY;
:    for Y_Pos in windRect.top..windrect.bottom - 1 loop
:       X := StartX;
:       for X_Pos in windRect.left..windRect.right loop
:         Z := (X, Y); -- Complex value; standard Ada 95!
:         C := Z;
:         for I in 0..Num_Iters loop
:           It := I;
:           exit when (abs( Z)) > 2.0;
:           Z := Z * Z + C; -- Complex arithmetic
:         end loop;
:     -- draw pixel here in color depending on variable It.
:     X := X + Step;
:     end loop;
:    Y := Y + Step;
:    end loop;
:   end Display;

: begin -- Main body of program Mandel
:   Initialize;
:    Display(0.0025); -- draw the fractal!
:   loop
:     exit when Events.Button;
:   end loop;
: end Mandel;


--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada95 speed

[Clifford J. Nelson]

Tucker,

 It takes ten seconds to do the computations alone. And another eleven
seconds to plot the pixels for a total of 21 seconds.

    Cliff Nelson

Tucker Taft wrote:

> Clifford J. Nelson (cnelson9@gte.net) wrote:
>
> : Ten years ago a Mandelbrot set computation and display on a 1200x700
> : screen with eight bit color took six seconds in C on a MacIIfx.
>
> : The following computations (leaving out all the with statements that you
> : need for the Mac) take ten seconds on an iMac 266 MHertz Mac OS 8.5.1
> : with the CodeBuilder Ada95 GNU from Tenon. I think it should run ten
> : times faster.
>
> : Is Ada95 slow in order to be safe?
>
> There is nothing in this code that would require any
> constraint checks.  You could put a "pragma Suppress(all_checks);"
> at the top of your source file to verify this.
>
> : Is GNU Ada95 slower than most Adas?
>
> Not particularly.
>
> : Is the iMac slow? Mac OS 8.5.1 slow?  CodeBuilder?
>
> The iMac is certainly much master than the MacIIfx in general,
> at least for pure computation.
>
> Probably the time is dominated by the drawing of the pixels.
> The only mildly complicated numeric operation in the code below is
> the call on "abs" for a complex number.  That involves 2 multiplies
> and a square-root.
>
> It would be useful to see where the time is going.  Chances are that
> the generated code is running much faster, and the time is all spent
> in the graphics routines drawing pixels.
>
> : Why does it take so long?
>
> My bet is on the graphic output routines.  The code generated
> by the Ada compiler is probably taking an immeasurably small amount
> of time.  Try changing the program so that it only does the computation.
> Then add back in the graphics output.  Measure the difference in
> execution time...
>
> : Program follows--------
>
> : with Ada.Numerics.Complex_Types;
> : use Ada.Numerics.Complex_Types;
>
> : procedure Mandel is
>
> : -- Initialize procedure goes here for windRect.bottom and windRect.top
>
> : procedure Display(Mag : in Float) is
> :     It : Integer;
> :     X, Y : Float;
> :     C, Z : Complex;
> :     Num_Iters : constant := 64;
> :     Vertical_Maximum : constant Short_Integer := windRect.bottom;
> :     Horizontal_Maximum : constant Short_Integer := windRect.Right;
> :     Ver_Size : constant Float := Float(Vertical_Maximum + 1);
> :     Hor_Size : constant Float := Float(Horizontal_Maximum + 1);
> :     StartY : constant Float := -Mag * Ver_Size;
> :     StartX : constant Float := -Mag * Hor_Size;
> :     Step : constant Float :=  2.0 * Mag ;
>
> :   begin
> :    Y := StartY;
> :    for Y_Pos in windRect.top..windrect.bottom - 1 loop
> :       X := StartX;
> :       for X_Pos in windRect.left..windRect.right loop
> :         Z := (X, Y); -- Complex value; standard Ada 95!
> :         C := Z;
> :         for I in 0..Num_Iters loop
> :           It := I;
> :           exit when (abs( Z)) > 2.0;
> :           Z := Z * Z + C; -- Complex arithmetic
> :         end loop;
> :     -- draw pixel here in color depending on variable It.
> :     X := X + Step;
> :     end loop;
> :    Y := Y + Step;
> :    end loop;
> :   end Display;
>
> : begin -- Main body of program Mandel
> :   Initialize;
> :    Display(0.0025); -- draw the fractal!
> :   loop
> :     exit when Events.Button;
> :   end loop;
> : end Mandel;
>
> --
> -Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
> Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
> AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada95 speed

[Larry Kilgallen]

In article <3740C535.7C6200A8@gte.net>, "Clifford J. Nelson" <cnelson9@gte.net> writes:

> The following computations (leaving out all the with statements that you
> need for the Mac) take ten seconds on an iMac 266 MHertz Mac OS 8.5.1
> with the CodeBuilder Ada95 GNU from Tenon. I think it should run ten
> times faster.
> 
> Is Ada95 slow in order to be safe?
> Is GNU Ada95 slower than most Adas?
> Is the iMac slow? Mac OS 8.5.1 slow?  CodeBuilder?
> Why does it take so long?

Where is it spending its time ?

Faced with a particular performance problem, there is nothing like
measurement to tell you the source of the problem.

Larry Kilgallen

Re: Ada95 speed

[Florian Weimer]

"Clifford J. Nelson" <cnelson9@gte.net> writes:

> Ten years ago a Mandelbrot set computation and display on a 1200x700
> screen with eight bit color took six seconds in C on a MacIIfx.

You obviously used a different algorithm.

>           exit when (abs( Z)) > 2.0;

This statement is executed approximately 6 million times.  Calculating
the absolute value of a complex number involves taking a square root.
This is a very expensive operation and dominates the running time by far.

I'd suggest to square both sides of the inequation and use:

          exit when (Z.Re * Z.Re + Z.Im * Z.Im) > 4.0;

I suppose your C code does exactly that because C hasn't got built-in
complex types, so this optimization is more obvious.

Re: Ada95 speed

[Tom Moran]

>screen with eight bit color took six seconds in C on a MacIIfx.

>The following computations (leaving out all the with statements that you
>need for the Mac) take ten seconds on an iMac 266 MHertz Mac OS 8.5.1
  How fast does the original C code run on the iMac?  That would be
the only fair comparison of hardware.  
  A cleverly done fractal program will usually run *much* faster than
the first, simplest, implemenation of the algorithm.  If your app's
speed is bottlenecked by one small section of code it's always a good
idea to see if asm for that little bit would make a worthwhile
difference.  

Re: Ada95 speed

[Clifford J. Nelson]

Tom Moran wrote:

>
>   How fast does the original C code run on the iMac?  That would be
> the only fair comparison of hardware.

I don't have the original code. I'm just guessing what the minimum
computations have to be.

>
>   A cleverly done fractal program will usually run *much* faster than
> the first, simplest, implemenation of the algorithm.  If your app's
> speed is bottlenecked by one small section of code it's always a good
> idea to see if asm for that little bit would make a worthwhile
> difference.

The computation of the integer matrix ought to execute much faster without
using asm. Memory mapped video graphics on four hundred dollar eight bit
computers fifteen years ago could have done the graphics at least one
hundred times faster than my new computer if they had had the RAM. There are
very cryptic operating system techniques to graph quickly, but, I have
resolved to learn as little as possible about any operating system .

   Cliff Nelson

Re: Ada95 speed

[Tom Moran]

> six seconds in C on a MacIIfx

>four hundred dollar eight bit
>computers fifteen years ago
  I don't think a MacIIfx cost $400 new and it certainly wasn't an 8
bit computer.  If you really want price/performance, perhaps you
should get a machine a few years old for nearly zero price.  ;)

Re: Ada95 speed

[Clifford J. Nelson]

Tom Moran wrote:

> > six seconds in C on a MacIIfx
>
> >four hundred dollar eight bit
> >computers fifteen years ago
>   I don't think a MacIIfx cost $400 new and it certainly wasn't an 8
> bit computer.  If you really want price/performance, perhaps you
> should get a machine a few years old for nearly zero price.  ;)

It would have taken less than one third of a second on an eight bit four
hundred dollar computer with memory mapped video five years before the
MacIIfx existed to plot the pixels after the color numbers were
computed.

   Cliff Nelson

Re: Ada95 speed

[Tom Moran]

>It would have taken less than one third of a second on an eight bit four
>hundred dollar computer with memory mapped video five years before the
>MacIIfx existed to plot the pixels after the color numbers were
>computed.
Ah, that's what you were referring to.
BTW,I've noticed over a long time that  computer scaling is such that
for any given CPU speed, the RAM is of that size that takes
approximately one second to zero out.  So your referenced machine
would have used a major fraction of its RAM as video memory.

Re: Ada95 speed

[Robert I. Eachus]

tmoran@bix.com wrote:

> >In those days, I was as big a fan of APL for the kind of work I was doing
> >as I am of Ada today.
> There is more joy in heaven over one sinner who repents ... ;)

   What?  Do you have something against APL?  For certain jobs it is
still the best language around.  I still use it to prototype
algorithms--even when the final implementation is in Ada.  A few years
ago I spent a few days debugging and tuning an algorithm in APL, then
spent several months documenting, implementing, and tuning in Ada.  I
probably could have spent twice as long doing it all in Ada.  There was
a huge amount of algorithmic design required--the problem involved
solving transportation problems on large sparse matrices.  I ended up
demonstrating that the problem could be solved in milliseconds instead
of hours.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada95 speed

[tmoran]

>> There is more joy in heaven over one sinner who repents ... ;)
>
>  What?  Do you have something against APL?  For certain jobs it is
  Uncle!  ";)" was a smiley.  I didn't intend to start an APL flame
war in c.l.a.!

Re: Ada95 speed

[tmoran]

> IBM introduced the System 3, Model 6 in the spring of 1971.  It ran
> Basic -- compiled? I don't recall.  It wasn't exactly PC size; it was
> about the size of a desk, with up to 64kb of virtual memory, 16k of real
> memory.
>The 5100 was an 8-bit microcomputer which came out in 1975.  You could get
>a model which ran BASIC or ALP (selectable with a rocker switch).
>It ran Syatem 370 microcode, and cost about $25,000.
  I'm inclined to think 'microcomputer' meant 'built around a
single chip CPU', eg, like the 8080 et al.  If the CPU was a board,
I'd call it a minicomputer.  Granted, the 5100 was small enough
to easily carry, but a lot happened between 1971 and 1975.  By
'75, as I recall, Wang et al were installing minicomputers running
Basic interpreters in lots of small businesses.

> HP ran a time sharing service about the same time that included Basic
> on HP-3000's.
  I recall using Basic over a teletype in the early '60s.  I don't
think it was compiled, however.  Was Basic on the HP-3000 compiled?
If not, what *compiled* Basic was in use by physicists (ie, not just
computer research use) in *1971*?

Re: Ada95 speed

[David C. Hoos, Sr.]

<tmoran@bix.com> wrote in message news:7jd72e$fja@lotho.delphi.com...
> >The 5100 was an 8-bit microcomputer which came out in 1975.  You could
get
> >a model which ran BASIC or APL (selectable with a rocker switch).
> >It ran Syatem 370 microcode, and cost about $25,000.

>   I'm inclined to think 'microcomputer' meant 'built around a
> single chip CPU', eg, like the 8080 et al.  If the CPU was a board,
> I'd call it a minicomputer.  Granted, the 5100 was small enough
> to easily carry, but a lot happened between 1971 and 1975.

Well, IBM's own literature (which I no longer have) called it a
microcomputer.
I remember well, because I was building equipment for automation of some
manufacturing and testing processes for analog electronic components, using
the available technology of the time, so I was studying all on which I could
get my hands.

The systems I built used what DEC called PDP-16, a family of hardware
components with which you could build customized systems.  We used binary
data to drive this equipment which was read from a Mylar 8-channel punched
tape which was generated by the 5100 via its RS-232 port.

In those days, I was as big a fan of APL for the kind of work I was doing
as I am of Ada today.

Re: Ada95 speed

[tmoran]

>In those days, I was as big a fan of APL for the kind of work I was doing
>as I am of Ada today.
There is more joy in heaven over one sinner who repents ... ;)

Re: Ada95 speed

[Robert Dewar]

In article <7jer69$j8n@lotho.delphi.com>,
  tmoran@bix.com wrote:
> >In those days, I was as big a fan of APL for the kind of work
I was doing
> >as I am of Ada today.
> There is more joy in heaven over one sinner who repents ... ;)


Actually, Ada does not BEGIN to compare in ease of use to APL
for programs for which APL is well suited. Ultimately Ada is
still an efficiency-oriented lowish level language, and cannot
compete for ease of expression with true very high level
languages like APL. That's not a criticism of Ada, just a
reminder that Ada is NOT the only useful language in the world
(and you should recognize this even if you are an Ada fan :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada95 speed

[David C. Hoos, Sr.]

Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:7jf27g$94g$1@nnrp1.deja.com...
> In article <7jer69$j8n@lotho.delphi.com>,
>   tmoran@bix.com wrote:
> > >In those days, I was as big a fan of APL for the kind of work
> I was doing
> > >as I am of Ada today.
> > There is more joy in heaven over one sinner who repents ... ;)
>
>
> Actually, Ada does not BEGIN to compare in ease of use to APL
> for programs for which APL is well suited. Ultimately Ada is
> still an efficiency-oriented lowish level language, and cannot
> compete for ease of expression with true very high level
> languages like APL. That's not a criticism of Ada, just a
> reminder that Ada is NOT the only useful language in the world
> (and you should recognize this even if you are an Ada fan :-)
>
As Robert correctly points out, the key is the suitableness of the
language to the problem being solved.

I was using APL for ad hoc solutions to engineering problems,
and if I were still doing that kind of work, I'd probably still
be doing it in APL.

It doesn't take much to realize that a language which has matrix
inversion as a primitive, is a pretty high-level language.

It also had a nice way of dealing with equality tests for
floating point values.  A system variable called "fuzz" could
be set to specify the magnitude of the relative difference
below which the two values would be considered equal.

But, since this is not comp.lang.apl or alt.lang.apl, I'd
probably best not keep this thread going.

Re: Ada95 speed

[Robert Dewar]

In article <hXL7XKJs#GA.194@newstoo.hiwaay.net>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> It doesn't take much to realize that a language which has
> matrix inversion as a primitive, is a pretty high-level
> language.

That's actually a poor example, any language can add a
matrix inversion function easily enough, and you are implying
that all you are talking about is syntactic sugar.

But in fact, the "very-high-level-ness" of APL is much deeper,
involving higher order operators, and a very dynamic view of
data and memory. If you tried to make an APL package, it is
in these areas that you would have fundamental difficulties.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada95 speed

[Brian Rogoff]

On Mon, 7 Jun 1999, Robert Dewar wrote:
> In article <7jer69$j8n@lotho.delphi.com>,
>   tmoran@bix.com wrote:
> > >In those days, I was as big a fan of APL for the kind of work
> I was doing
> > >as I am of Ada today.
> > There is more joy in heaven over one sinner who repents ... ;)
> 
> Actually, Ada does not BEGIN to compare in ease of use to APL
> for programs for which APL is well suited. Ultimately Ada is
> still an efficiency-oriented lowish level language, and cannot
> compete for ease of expression with true very high level
> languages like APL. That's not a criticism of Ada, just a
> reminder that Ada is NOT the only useful language in the world
> (and you should recognize this even if you are an Ada fan :-)

Yes, I refer to Ada as a systems programming language, with much the 
same meaning (efficiency oriented lowish level language) as you use 
here. 

While I agree that there will always be a gap between Ada and the like and
true VHLLs, I wonder if we can close the gap much more than has been done 
so far. For example, downward closures and/or CLU/Sather style iterators
could be fit into an Ada-like language without requiring garbage collection, 
and would greatly increase the ease of expression of some constructs.

-- Brian

Re: Ada95 speed

[tmoran]

>several real time operating systems for various microcomputers
>for Honeywell at the time (amazingly some of this equipment is
>still in use at United Airlines counters). These were not
>expensive computers, they cost a couple of thousand dollars.
  Were these machines widely available in 1971, or custom
creations for a few high-volume applications?

Re: Ada95 speed

[Robert Dewar]

In article <7jd72l$fja@lotho.delphi.com>,
  tmoran@bix.com wrote:
> >several real time operating systems for various
microcomputers
> >for Honeywell at the time (amazingly some of this equipment
is
> >still in use at United Airlines counters). These were not
> >expensive computers, they cost a couple of thousand dollars.
>   Were these machines widely available in 1971, or custom
> creations for a few high-volume applications?
>

They were COTS products made initially by Incoterm, an offshoot
from Raytheon, that was subsequently purchased by Honeywell.
Tens to hundreds of thousands of these were sold into all kinds
of environments, some large customers, some small (an example
customer: the railroads who used them for freight control, and
as I have mentioned, several airlines who used them for
reservations).

The software was typically custom created, like specialized PC
applications today, but the hardware was absolutely standard.

I created a complete operating system and utilities for these
machines. I think it has the distinction of being the first
widely used operating system that took a whole screen display
view of the user terminal, rather than being teletype command
line inspired. I know several users of that system (called
Incoterm/FMS) who found it painful to move to Unix later on :-)

There were many neat little ideas in that operating system (it
was by the way the first instance of the sequence of editors
that I wrote, ending up with DAED for the PC).

And it certainly was nice to get to do a complete operating
system for a small machine (from the task switching kernel
and debugger up through editors, indexed file systems, and
assemblers) including writing all the documentation. Ah, the
old days :-)

Robert


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada95 speed

[tmoran]

>Today's operating systems must manage resource sharing, etc., so
>we're not really comparing like with like here.
  Certainly in 1971 there were plenty of multitasking, resource
sharing, graphic display running, computers around.  Of course
they cost a million bucks but then they also were much less
powerful than a modern Mac or PC.  And given how long it takes
just to *start* a modern editor (or other program), one can be
forgiven for wondering whether there's been much net improvement.

Re: Ada95 speed

[Robert Dewar]

In article <7jafeo$6ps@lotho.delphi.com>,
  tmoran@bix.com wrote:
> Certainly in 1971 there were plenty of multitasking,
> resource
> sharing, graphic display running, computers around.  Of course
> they cost a million bucks but then they also were much less
> powerful than a modern Mac or PC.  And given how long it takes
> just to *start* a modern editor (or other program), one can be
> forgiven for wondering whether there's been much net
> improvement.

First, you don't go far enough, there were plenty of
multitasking, resource sharing, graphic display running
computers around and they did NOT cost a million bucks.

Microcomputers were not invented when IBM introduced the PC!

There are many many data points, but for example, I wrote
several real time operating systems for various microcomputers
for Honeywell at the time (amazingly some of this equipment is
still in use at United Airlines counters). These were not
expensive computers, they cost a couple of thousand dollars.

As to the time used to start a modern editor, this is an apples
and oranges comparison. As computers have got faster, we expect,
and indeed come to take for granted, FAR greater functionality.
Consider for example just the fact that your "modern" editor
can use arbitrary non-mono-spaced fonts. That takes a huge
amount of computing power, but we can afford it these days.

Yes, we waste a lot of computing power these days, in two ways.

1. Implementing features that are nice to have, but very
expensive in computing resources.

2. Making life easier for maintainers and programmers (e.g. by
using high level and very high level languages, scripting
languages, shell scripts etc).

Sure, the old software still runs, and it runs AMAZINGLY fast
(my old trusty PC editor DVED is amazingly fast, but really
who cares if the amount of processing per keystroke has gone
down from 10 milliseconds to 20 microseconds?????

Now, there is, as there ALWAYS has been, junk software that
takes far too long to do what it needs to do. It is sometimes
impossible to figure out why something takes so long.

Furthermore, the phenomenon of the programmer getting further
from the machine means that you have a lot of VERY incompetent
programmers, roaming around at a high semantic level without
the foggiest notion of the consequences of their actions.

Even with a relatively low level language like Ada I am amazed
how FEW Ada programmers have a clear idea of the machine
language they are generating, and use ferociously inefficient
constructions without the slightest awareness that this is the
case.

But in the old days, I often saw people write absolutely
appalling assembly language, so there is no immunity here from
incompetence :-)






Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada95 speed

[Ehud Lamm]

On Sat, 5 Jun 1999, Robert Dewar wrote:

> 
> But in the old days, I often saw people write absolutely
> appalling assembly language, so there is no immunity here from
> incompetence :-)
> 
I reacll reading somewhere a quote from Sir Clive Sinclair to the effect
that as computers grow faster programmers bacmae lass and less
professional, and stopped being aware of how things really work.

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
http://www2.cybericites.com/e/ehud

Re: Ada95 speed

[Clifford J. Nelson]

I could have answered my own questions if I had had the patience.

a) Is Ada95 slow in order to be safe?

 No. It's fast even when it tries to be safe.

b) Is GNAT-for-the-Mac slow? CodeBuilder 1.1?

 No. It's fast.

But, the operating systems for low end computers in 1999 are awkward to
program in. More so than fifteen years ago, especially for graphics.

Here are timing tests in Mathematica and Ada95.

Mma Version 3.0.1  gives 0.1 seconds.

GNAT Ada95 gives 0.066 seconds.

See:
http://forum.swarthmore.edu/epigone/geometry-research/brydilyum

In[1]:=
<<RBFields.m

Out[1]=
{"E"}

In[2]:=
a = B[makezero[Table[1,{96}]]];

In[3]:=
t = B[N[makezero[Range [96]]]];

In[4]:=
First[Timing[vt = t/t-a]]

Out[4]=
0.1*Second

In[5]:=
VectorDistance[First[vt]]

Out[5]=
1.197930643570543*^-13

Now Ada95.

with bnumbers;
with Calendar;
with Ada.Text_io;
use Calendar;
use Ada.Text_io;
use bnumbers;

procedure testbnumber is
 T : duration;
 V : real;
 N : constant integer := 97;
 A,B,C : bnumber(1..N);

 begin
 for I in 1..N-1 loop
 A(I) := 1.0;
 B(I) := real(I);
 end loop;
 A(N) := real(-N+1);
 B(N) := real(-(N*(N-1))/2);
 T := Seconds(Clock);
 C := B / B - A;
 T := Seconds(Clock) - T;
for I in C'range loop
put(real'image(C(I)));
end loop;
 V := vectordistance(C);
 Put(" It took " & Duration'Image(T) & " seconds. " & " V = " &
real'image(V));
 end testbnumber;

package bnumbers is

type real is digits 15;

type bnumber is array (positive range <>)  of real;

type coords is array(positive range <>) of real;

function "+" (X : bnumber; Y : bnumber) return bnumber;
function "-" (X : bnumber; Y : bnumber) return bnumber;
function "*" (X : bnumber; Y : bnumber) return bnumber;
function "/" (X : bnumber; Y : bnumber) return bnumber;
function "abs" (X : bnumber) return real;
function vectordistance (X : bnumber) return real;
function ptos(X : coords) return bnumber;
function abssq (X : bnumber) return real;

pragma inline("+");
pragma inline("-");
pragma inline("*");
pragma inline("/");
pragma inline("abs");
pragma inline(abssq);
pragma inline(vectordistance);
pragma inline(ptos);

end bnumbers;

with realfunctions;
use realfunctions;


Package body bnumbers is


function "+" (X : bnumber; Y : bnumber) return bnumber is
Z : bnumber(X'range);
begin
for I in X'range loop
Z(I) := X(I)+Y(I);
end loop;
return Z;
end "+";
pragma inline("+");

function "-" (X : bnumber; Y : bnumber) return bnumber is
Z : bnumber(X'range);
begin
for I in X'range loop
Z(I) := X(I)-Y(I);
end loop;
return Z;
end "-";

pragma inline("-");

function "*" (X : bnumber; Y : bnumber) return bnumber is
XJ : Integer;
T,TT: real;
len : constant integer := X'length;
Z : bnumber(1..len);
D : constant real := real(-len);
begin
TT := 0.0;
for I in 1..len-1 loop
T := 0.0;
for J in 1..len loop
XJ :=   I + len  - J;
if XJ > len then
T := T + X(XJ - len ) * Y(J);
else
T := T + X(XJ) * Y(J);
end if;
end loop;
T := T / D;
Z(I) := T;
TT := TT + T;
end loop;
Z(len) := -TT;
return Z;
end "*";

pragma inline("*");

function "/" (X : bnumber; Y : bnumber) return bnumber is
T : real := 0.0;
len : constant integer := X'length;
TL : constant real := real(-len);
Z,W : bnumber(1..len);
begin
 for I in 1 .. len - 1 loop
  Z(I) := Y((2 * I) mod len);
 end loop;
 Z(len) := Y(len);
 if (len > 3) then
  W(len) := Y(len);
  for I in 3..len-1 loop
   for J in 1.. len-1 loop
    W(J) := Y((J * I) mod len);
   end loop;
  Z := W * Z;
  end loop;
 end if;
 for J in 1..len loop
  T := T + Y((len) + 1 - J) * Z(J) ;
 end loop;
 for I in 1..len loop
  Z(I) := TL * Z(I) / T;
 end loop;
 Z := X * Z;
 return Z;
end "/";

pragma inline("/");

function "abs" (X : bnumber) return real is
T : real := 0.0;
begin
for I in X'range loop
T := X(I)*X(I) +T;
end loop;
return sqrt(T/2.0);
end "abs";

function abssq (X : bnumber) return real is
T : real := 0.0;
begin
for I in X'range loop
T := X(I)*X(I) +T;
end loop;
return T/2.0;
end abssq;


function vectordistance (X : bnumber) return real is
T : real := 0.0;
begin
for I in X'range loop
T := (abs(X(I))) +T;
end loop;
return (T/2.0);
end vectordistance;

function uni(val : real; ival,length  : integer) return bnumber is
Y : bnumber(1..length);
begin
for I in 1..ival-1 loop
 Y(I) := val;
 end loop;
Y(ival) := real(- (ival - 1)) * val;
for I in ival+1..length loop
Y(I) := 0.0;
end loop;
return Y;
end uni;

pragma inline(uni);

function tri(x : integer) return real is
begin
return sqrt(real((x * (x - 1))/2));
end tri;

pragma inline(tri);

function ptos(X : coords) return bnumber is
L : constant integer := X'length +1;
T : bnumber(1..L);

begin
T := uni(X(1),2,L);
for I in 3..L loop
T := T + uni(X(I-1)/tri(I),I,L);
end loop;
return T;
end ptos;





pragma inline("abs");
pragma inline(vectordistance);
pragma inline(ptos);

end bnumbers;

with Ada.Numerics.Generic_Elementary_Functions;
with bnumbers;
package realfunctions is
  new Ada.Numerics.Generic_Elementary_Functions (bnumbers.real);

Re: Ada95 speed

[William Starner]

Ehud Lamm wrote:
> 
> On Sat, 5 Jun 1999, Robert Dewar wrote:
> 
> >
> > But in the old days, I often saw people write absolutely
> > appalling assembly language, so there is no immunity here from
> > incompetence :-)
> >
> I reacll reading somewhere a quote from Sir Clive Sinclair to the effect
> that as computers grow faster programmers bacmae lass and less
> professional, and stopped being aware of how things really work.
> 
> Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
> http://www2.cybericites.com/e/ehud

On the other hand, portable programming is something a professional programmer
is supposed to do, and being aware of how things work on your system won't
always help on other systems. (I remember an example of matrix code, where
optimizing for Cray's vector functions slowed it down on the Mac by causing page
faults much more often.) 

I could assume this number library I'm writting will only be used on ix86 Linux
systems with Gnat 3.11p/GCC 2.8.1, but hopefully it will be used on Crays and
Suns and whereever. I've got to do some basic profiling, but writing directly to
that combination will hurt when it's run on any other hardware, or in worst
case, upon upgrading the compiler.

--
Please don't email me - billeug@worldnet.att.net is not my account.
David Starner - dstarner98@aasaa.ofe.org (alternately dvdeug@hotmail.com)
If you wish to strive for peace of soul, then believe; if you wish to be a
devotee of truth, then inquire. -- Friedrich Nietzsche

Re: Ada95 speed

[Ehud Lamm]

On Sat, 5 Jun 1999, William Starner wrote:

> 
> On the other hand, portable programming is something a professional programmer
> is supposed to do, and being aware of how things work on your system won't
> always help on other systems. (I remember an example of matrix code, where
> optimizing for Cray's vector functions slowed it down on the Mac by causing page
> faults much more often.) 
> 

I'll be the last one to dismiss portability. Just mentioned a nice quote. 
I'd say that profrssionalism is knowing the tradeoffs and knowing how to
decide between them.

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

Re: Ada95 speed

[David Botton]

As computers become faster and the number of reusable pieces increase,
the number of technologists vs. engineers increase. As it should be.

I suspect the day is coming quick that non-programmers will drag and
drop every IS need they have.

David Botton


Ehud Lamm wrote:
> 
> On Sat, 5 Jun 1999, Robert Dewar wrote:
> 
> >
> > But in the old days, I often saw people write absolutely
> > appalling assembly language, so there is no immunity here from
> > incompetence :-)
> >
> I reacll reading somewhere a quote from Sir Clive Sinclair to the effect
> that as computers grow faster programmers bacmae lass and less
> professional, and stopped being aware of how things really work.
> 
> Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
> http://www2.cybericites.com/e/ehud

Re: Ada95 speed

[Ehud Lamm]

It's good I've never thought of myself as a "programmer".

Indeed even today people who can be described as "just" programmers are of
very low market value. But we don't yet have very good terms to describe
the high end of the spectrum. This is why IT jobs have so many meaningless
titles...

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

On Sun, 6 Jun 1999, David Botton wrote:

> As computers become faster and the number of reusable pieces increase,
> the number of technologists vs. engineers increase. As it should be.
> 
> I suspect the day is coming quick that non-programmers will drag and
> drop every IS need they have.
> 
> David Botton
> 

Re: Ada95 speed

[Robert Dewar]

In article
<Pine.A41.3.96-heb-2.07.990606192604.12724A-100000@pluto.mscc.hu
ji.ac.il>,
  Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:
> It's good I've never thought of myself as a "programmer".
>
> Indeed even today people who can be described as "just"
programmers are of
> very low market value. But we don't yet have very good terms
to describe
> the high end of the spectrum. This is why IT jobs have so many
meaningless
> titles...


Actually I consider myself a programmer. That is I write
programs for computers, that's a job description of a
programmer. However, doing this job well requires a LOT
of interacing skills.

I suspect you are using the word programmer to mean what
I would refer to as a coder :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada95 speed

[Ehud Lamm]

> I suspect you are using the word programmer to mean what
> I would refer to as a coder :-)
> 

I am fond of this distinction too. "Coder" is really demeaning...
But even "programmer", which is much better really doesn't cover it. Some
expect that if there is a programmer, he must be getting his orders from
a "designer" etc. Indeed some of these distinctions are losing their
applicability in hightech "startup" companies.
But really, doesn't "Computer Maven" sound better :-)

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
http://www2.cybericites.com/e/ehud

Re: Ada95 speed

[tmoran]

> I knew physicists in 1971 who wrote programs in compiled basic for
> micro computers.
  What compiled BASIC was that, and what microcomputers (in 1971)?

Re: Ada95 speed

[Al Christians]

tmoran@bix.com wrote:
> 
> > I knew physicists in 1971 who wrote programs in compiled basic for
> > micro computers.
>   What compiled BASIC was that, and what microcomputers (in 1971)?


IBM introduced the System 3, Model 6 in the spring of 1971.  It ran
Basic -- compiled? I don't recall.  It wasn't exactly PC size; it was
about the size of a desk, with up to 64kb of virtual memory, 16k of real
memory.

IBM's desktop machine (microcomputer(?)), the 5100, (which ran APL) 
came along about 2 or 3 years later.

HP ran a time sharing service about the same time that included Basic
on HP-3000's.

Al

Re: Ada95 speed

[David C. Hoos, Sr.]

Al Christians <achrist@easystreet.com> wrote in message
news:375989C4.2AE9AD5@easystreet.com...
> tmoran@bix.com wrote:
> >
> > > I knew physicists in 1971 who wrote programs in compiled basic for
> > > micro computers.
> >   What compiled BASIC was that, and what microcomputers (in 1971)?
>
>
> IBM introduced the System 3, Model 6 in the spring of 1971.  It ran
> Basic -- compiled? I don't recall.  It wasn't exactly PC size; it was
> about the size of a desk, with up to 64kb of virtual memory, 16k of real
> memory.
>
> IBM's desktop machine (microcomputer(?)), the 5100, (which ran APL)
> came along about 2 or 3 years later.
>
The 5100 was an 8-bit microcomputer which came out in 1975.  You could get
a model which ran BASIC or ALP (selectable with a rocker switch).
It ran Syatem 370 microcode, and cost about $25,000.
It was a desktop machine with a CRT of about 6" diagonal size. (80x24
if I remember correctly).

> HP ran a time sharing service about the same time that included Basic
> on HP-3000's.
>
> Al

Re: Ada95 speed

[Tom Moran]

>>Is Ada95 slow in order to be safe?

>With run-time checks, yes; without them, no.
>-gnatp suppresses all.
  On Win95, I see a very modest difference between "-O3" and "-gnatp
-O3" on this Mandelbrot code.

Re: Ada95 speed

[Gautier]

> >>Is Ada95 slow in order to be safe?

> >With run-time checks, yes; without them, no.
> >-gnatp suppresses all.

>   On Win95, I see a very modest difference between "-O3" and "-gnatp
> -O3" on this Mandelbrot code.

The main suppressed checks are for conversions, discrete range checks,
array bound checks etc.; there are no standard checks for floating
point operations (are there ?) - this could explain your observation.
But -O2 or -O3 could help... and even, in that case, the choice
of a good algorithm and the removal of the hidden Sqrt helps surely
even more...
 
-- 
Gautier

Re: Ada95 speed

[Robert Dewar]

In article <3741B203.4890880B@Maths.UniNe.CH>,
  Gautier <Gautier.deMontmollin@Maths.UniNe.CH> wrote:

> and the removal of the hidden Sqrt helps surely
> even more...
>
> --
> Gautier

Don't assume that a square root is necesarily that expensive.
On some architectures, square root is comparable in speed
to a floating-point division, not so terrible ....


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: Ada95 speed

[Clifford J. Nelson]

Here is the program again with all the crazy Mac operating system stuff.
The graphics are one hundred times to slow as far as I'm concerned, and
the other computations are about ten times slower than I expected. The
"computer revolution" has been smashed by performance problems and you
will have to "jump through hoops" and "thread needles" to get the
performance implied by the advertised clock speeds of new computers and
"compiled" languages.

Sorry, but, I just had to get that off my chest. The emperor has no
cloths.

   Cliff Nelson

CodeBuilder command:

macmake -O2 mandel

with
  Events,        --
  Fonts,         --InitFonts
  OSUtils,       --{SysEnvirons, GetDateTime}
  QuickDraw,     --{SetCPixel}
  QuickDrawText, --{DrawString}
  SegLoad,       --{ExitToShell}
  Types,         --{Rect}
  Windows;       --{InitWindows, NewCWindow}
with Ada.Numerics.Complex_Types;
use Ada.Numerics.Complex_Types;
use type Quickdraw.GrafPtr;

procedure Mandel is
  windRect  : aliased Types.Rect;
  seconds   : aliased Types.UInt32;
  -- Initialize everything for the program, make sure we can run.
  procedure Initialize is
    mainPtr  : Quickdraw.WindowPtr;
    error    : Types.OSErr;
    theWorld : aliased OSUtils.SysEnvRec;
  begin
    -- check for color Quickdraw? On a PowerPC!?
    error := OSUtils.SysEnvirons(1, theWorld'Access);
    if not theWorld.hasColorQD then
      OSUtils.SysBeep(50);
      SegLoad.ExitToShell;
    end if;

    -- Initialize all the needed managers.
    Quickdraw.InitGraf(Quickdraw.qd.thePort'Access);
    Fonts.InitFonts;
    Windows.InitWindows;
    QuickDraw.InitCursor;

    -- Open a new color window somewhat smaller than the screen
    windRect := QuickDraw.qd.screenBits.bounds;
    QuickDraw.InsetRect (windRect'access, 0, 0);
    MainPtr := Windows.NewCWindow(Types.nil, windRect'access, "Mandel
Land",
      true, Windows.documentProc, Windows.FrontMost, false, 0);
    QuickDraw.SetPort(MainPtr);            -- set window to current
grafport
    windRect := MainPtr.portRect;          -- use the window's portRect
  end Initialize;

  procedure Display is
    ballColor : aliased QuickDraw.RGBColor;
    X, Y : Float;
    Secs : Long_Integer;
    C, Z : Complex;
    NumberofColors : constant := 97;
    MaxColor : constant := (2 ** 16) - 1;
    Itadjuster : constant := ((2 ** 33) - 1) / NumberofColors;
    Vertical_Size : constant Short_Integer := windRect.bottom -
windRect.top;
    Horizontal_Size : constant Short_Integer := windRect.Right -
windRect.left;
    Ver_Size : constant Float := Float(Vertical_Size );
    Hor_Size : constant Float := Float(Horizontal_Size );
    Mag : constant Float := 2.01 / Hor_Size;
    StartY : constant Float := -Mag * Ver_Size;
    StartX : constant Float := -Mag * Hor_Size;
    Step : constant Float :=  2.0 * Mag ;

  begin
   OSUtils.GetDateTime (seconds'Access);
   Secs := Long_Integer(seconds);
   Y := StartY;
   for Y_Pos in windRect.top..windrect.bottom - 1 loop
      X := StartX;
      for X_Pos in windRect.left..windRect.right loop
        Z := (X, Y); -- Complex value; standard Ada 95!
        C := Z;

        for I in 0..NumberofColors loop
          if (Z.Re * Z.Re + Z.Im * Z.Im) > 4.0  then
           ballColor.red   := Types.UInt16(Itadjuster * I);
           ballColor.green := Types.UInt16(Itadjuster * (I ** 3));
           ballColor.blue  := Types.UInt16(Itadjuster * (I ** 2));
           Quickdraw.SetCPixel(Short_Integer(X_Pos),
Short_Integer(Y_Pos),
           ballColor'Access);
           exit;
          end if;
         Z := Z * Z + C; -- Complex arithmetic
        end loop;
    X := X + Step;
    end loop;
   Y := Y + Step;
   end loop;
   OSUtils.GetDateTime (seconds'Access);
   Secs := Long_Integer(seconds) - Secs;
   Quickdraw.MoveTo(windRect.left + 10,
      windRect.top + 40);
   ballColor.red   := Types.UInt16(MaxColor);
   ballColor.green := Types.UInt16(MaxColor);
   ballColor.blue  := Types.UInt16(MaxColor);
   Quickdraw.RGBForeColor(ballColor'Access);
   Quickdrawtext.DrawString("It took " & Long_Integer'Image(Secs) & "
seconds.");
   Quickdraw.MoveTo(windRect.left + 10,
      windRect.bottom - 40);
   Quickdrawtext.DrawString("Click mouse botton to quit.");
  end Display;

begin -- Main body of program Mandel
  Initialize;
   Display; -- draw the fractal!
  loop
    exit when Events.Button;
  end loop;
end Mandel;

Re: Ada95 speed

[Tucker Taft]

Clifford J. Nelson wrote:
> 
> Here is the program again with all the crazy Mac operating system stuff.
> The graphics are one hundred times to slow as far as I'm concerned, and
> the other computations are about ten times slower than I expected. The
> "computer revolution" has been smashed by performance problems and you
> will have to "jump through hoops" and "thread needles" to get the
> performance implied by the advertised clock speeds of new computers and
> "compiled" languages.
> 
> Sorry, but, I just had to get that off my chest. The emperor has no
> clothes.

You still have a call on Quickdraw inside your inner loop.  You
should time the program with the calls on Quickdraw commented out,
and then compare the time with the calls uncommented.  That way
you can separate out the amount of time spent in the computations
versus the amount spent inside Quickdraw and friends.  My guess
is that you will find that almost all of the time is inside Quickdraw
and friends.  If it turns out that the computation is the slow
part, then I would have to believe that the floating point is somehow
being simulated, rather than executed by hardware (though on a PowerPC,
that doesn't make much sense).

> 
>    Cliff Nelson
> ...
>         for I in 0..NumberofColors loop
>           if (Z.Re * Z.Re + Z.Im * Z.Im) > 4.0  then
>            ballColor.red   := Types.UInt16(Itadjuster * I);
>            ballColor.green := Types.UInt16(Itadjuster * (I ** 3));
>            ballColor.blue  := Types.UInt16(Itadjuster * (I ** 2));
>            Quickdraw.SetCPixel(Short_Integer(X_Pos),
> Short_Integer(Y_Pos),
>            ballColor'Access);
>            exit;
>           end if;
>          Z := Z * Z + C; -- Complex arithmetic
>         end loop;
> ...
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada95 speed

[Tom Moran]

> My guess
>is that you will find that almost all of the time is inside Quickdraw
>and friends
  A quick translation to Win95, storing the image in an array, then
displaying that at the end, and using either ObjectAda or Gnat 3.11p,
seems to run at a comparable speed on my Pentium 200.  

Re: Ada95 speed

[Tom Moran]

>comparable speed on my Pentium 200
Sorry, I should have been more specific.
The 1200x700, 64 Iteration max, program runs in 3.3 seconds on a P200
with just one other (the message loop) task, plus Win95 background,
running.  I compiled it with just the -O4 optimization option and did
not turn off checking (which doesn't seem to make much difference).

Re: Ada95 speed

[Tom Moran]

>The 1200x700, 64 Iteration max, program runs in 3.3 seconds on a P200
<egg on face>
That was 1200 vertical by 700 horizontal.  The 1200 horizontal by 700
vertical (the original poster's case) runs in just over 1 second on
the P200, so I assume it should take a comparable time on a 266MHz
iMac, which would indeed make it 10 times as fast as the first posting
suggested.

Re: Ada95 speed

[James E. Hopper]

In article <3743D5BB.37152F94@gte.net>, Clifford J. Nelson
<cnelson9@gte.net> wrote:

> Here is the program again with all the crazy Mac operating system stuff.
> The graphics are one hundred times to slow as far as I'm concerned, and
> the other computations are about ten times slower than I expected. The
> "computer revolution" has been smashed by performance problems and you
> will have to "jump through hoops" and "thread needles" to get the
> performance implied by the advertised clock speeds of new computers and
> "compiled" languages.
> 
> Sorry, but, I just had to get that off my chest. The emperor has no
> cloths.
> 
>    Cliff Nelson
> 


Cliff,

When we did the codebuilder port i played with this program, and
optimized it just a bit.  at one point i had it running at least and
order of magnitude faster than you have here.  I could have done much
more  for instance the 5 fold increase someone gave you with the
compuation of the square root was something i never tried so i guess
that would make my original optimized version about 50 times faster
than your current (i am including the graphics in my comparisions)  The
code to do this optimizing totally obsured the basic algorithm.  we
decided as i recall to put stupid dumb code in as we were trying to
give code that beginners to mac programming could learn from rather
than the fastest cleverist fractal algorithms and code around.  

your comment that new machines are not faster than old because you have
to do clever tricks to make them work is way off the mark.  unless you
went through it you have NO idea what gyrations we went through to make
code run fast on those older machines.  My head aches when i think what
i went through getting fast code to run on the old 8 bit processors ;-) 
If anything i have found programmers today are much lazier about
algorithms because they can get away with it more than they used to. 
your whole premise rests on the aburd comparison of comparing this
simple algorith with an unknowns algorithm from years ago.  unless you
can present the source code for your comparison point there is no
validity in your comparison!

Jim

Re: Ada95 speed

[Clifford J. Nelson]

"James E. Hopper" wrote:

> In article <3743D5BB.37152F94@gte.net>, Clifford J. Nelson
> <cnelson9@gte.net> wrote:
>
> > Here is the program again with all the crazy Mac operating system stuff.
> > The graphics are one hundred times to slow as far as I'm concerned, and
> > the other computations are about ten times slower than I expected. The
> > "computer revolution" has been smashed by performance problems and you
> > will have to "jump through hoops" and "thread needles" to get the
> > performance implied by the advertised clock speeds of new computers and
> > "compiled" languages.
> >
> > Sorry, but, I just had to get that off my chest. The emperor has no
> > cloths.
> >
> >    Cliff Nelson
> >
>
> Cliff,
>
> When we did the codebuilder port i played with this program, and
> optimized it just a bit.  at one point i had it running at least and
> order of magnitude faster than you have here.  I could have done much
> more  for instance the 5 fold increase someone gave you with the
> compuation of the square root was something i never tried so i guess
> that would make my original optimized version about 50 times faster
> than your current (i am including the graphics in my comparisions)  The
> code to do this optimizing totally obsured the basic algorithm.  we
> decided as i recall to put stupid dumb code in as we were trying to
> give code that beginners to mac programming could learn from rather
> than the fastest cleverist fractal algorithms and code around.
>

This code is not the algorithm that comes with the fractal  demo program of
CodeBuilder 1.1 which incidentally doesn't work at all (error 84). The
Mandelbrot demo that comes with CodeBuilder is based on the "Manhattan
distance" instead of the straight line Euclidean distance. None of the
mac-specific demo programs work except sillyballs and hello.

>
> your comment that new machines are not faster than old because you have
> to do clever tricks to make them work is way off the mark.  unless you
> went through it you have NO idea what gyrations we went through to make
> code run fast on those older machines.  My head aches when i think what
> i went through getting fast code to run on the old 8 bit processors ;-)
> If anything i have found programmers today are much lazier about
> algorithms because they can get away with it more than they used to.
> your whole premise rests on the aburd comparison of comparing this
> simple algorith with an unknowns algorithm from years ago.  unless you
> can present the source code for your comparison point there is no
> validity in your comparison!
>
> Jim

I will include the corrected program in full below. I say the graphics should
work fifty times faster and the color numbers should to be computed much
faster. I challenge you to make it run that fast without "jumping through
hoops" and "threading needles". And I assert that slow execution times of
programs like this are deliberate sabotage of the so called "computer
revolution".

   Cliff Nelson

pragma suppress(all_checks);
with
  Events,        --
  Fonts,         --InitFonts
  OSUtils,       --{SysEnvirons, GetDateTime}
  QuickDraw,     --{SetCPixel}
  QuickDrawText, --{DrawString}
  SegLoad,       --{ExitToShell}
  Types,         --{Rect}
  Windows;       --{InitWindows, NewCWindow}
with Ada.Numerics.Long_Long_Complex_Types;
use Ada.Numerics.Long_Long_Complex_Types;
use type Quickdraw.GrafPtr;

procedure Mandel is
  windRect : aliased Types.Rect;
  seconds   : aliased Types.UInt32;
  -- Initialize everything for the program, make sure we can run.
  procedure Initialize is
    mainPtr  : Quickdraw.WindowPtr;
    error    : Types.OSErr;
    theWorld : aliased OSUtils.SysEnvRec;
  begin
    -- check for color Quickdraw? On a PowerPC!?
    error := OSUtils.SysEnvirons(1, theWorld'Access);
    if not theWorld.hasColorQD then
      OSUtils.SysBeep(50);
      SegLoad.ExitToShell;
    end if;

    -- Initialize all the needed managers.
    Quickdraw.InitGraf(Quickdraw.qd.thePort'Access);
    Fonts.InitFonts;
    Windows.InitWindows;
    QuickDraw.InitCursor;

    -- Open a new color window somewhat smaller than the screen
    windRect := QuickDraw.qd.screenBits.bounds;
   -- QuickDraw.InsetRect (windRect'access, 0, 0);
    MainPtr := Windows.NewCWindow(Types.nil, windRect'access, "Mandel Land",
      true, Windows.documentProc, Windows.FrontMost, false, 0);
    QuickDraw.SetPort(MainPtr);   -- set window to current grafport
    windRect := MainPtr.portRect; -- use the window's portRect
  end Initialize;

  procedure Display is
    ballColor : aliased QuickDraw.RGBColor;
    pichan : QuickDraw.PicHandle;
    X, Y : long_long_float;
    Secs : Long_Integer;
    C, Z : Complex;
    NumberofColors : constant := 97;
    MaxColor : constant := (2 ** 16) - 1;
    Itadjuster :  constant  := ((2 ** 33) - 1) / NumberofColors;
    Vertical_Size : constant Short_Integer := windRect.bottom - windRect.top;

    Horizontal_Size : constant Short_Integer := windRect.Right -
windRect.left;
    Ver_Size : constant long_long_float := long_long_float(Vertical_Size );
    Hor_Size : constant long_long_float := long_long_float(Horizontal_Size );

    Mag : constant long_long_float := 2.01 / Hor_Size;
    StartY : constant long_long_float := Mag * Ver_Size;
    StartX : constant long_long_float := -Mag * Hor_Size;
    Step : constant long_long_float :=  2.0 * Mag ;

  begin
   OSUtils.GetDateTime (seconds'Access);
   Secs := Long_Integer(seconds);
   Y := StartY;
   for Y_Pos in windRect.top..windrect.bottom loop
    X := StartX;
    for X_Pos in windRect.left..windRect.right loop
     Z := (X, Y); -- Complex value; standard Ada 95!
     C := Z;
     for I in 0..NumberofColors loop
      if (Z.Re * Z.Re + Z.Im * Z.Im) > 4.0  then
       ballColor.red   := Types.UInt16(Itadjuster * I);
       ballColor.green := Types.UInt16(Itadjuster * (I ** 3));
       ballColor.blue  := Types.UInt16(Itadjuster * (I ** 2));
       -- QuickDraw.Index2Color(Itadjuster *  I,ballColor'Access);
       -- Quickdraw.SetCPixel(X_Pos, Y_Pos,ballColor'Access);
       Quickdraw.MoveTo(X_Pos,Y_Pos);
       Quickdraw.RGBForeColor(ballColor'Access);
       Quickdraw.Line(0,0);
       exit;
      end if;
      Z := Z * Z + C; -- Complex arithmetic
      end loop;
    X := X + Step;
    end loop;
   Y := Y - Step;
   end loop;
   OSUtils.GetDateTime (seconds'Access);
   Secs := Long_Integer(seconds) - Secs;
   Quickdraw.MoveTo(windRect.left + 10,
      windRect.top + 40);
   ballColor.red   := Types.UInt16(MaxColor);
   ballColor.green := Types.UInt16(0);
   ballColor.blue  := Types.UInt16(0);
   Quickdraw.RGBForeColor(ballColor'Access);
   Quickdrawtext.DrawString("It took " & Long_Integer'Image(Secs) & "
seconds.");
   Quickdraw.MoveTo(windRect.left + 10,
      windRect.bottom - 40);
   Quickdrawtext.DrawString("Click mouse button to quit.");
  end Display;

begin -- Main body of program Mandel
 Initialize;
 Display; -- draw the fractal!
 loop
  exit when Events.Button;
 end loop;
end Mandel;

Re: Ada95 speed

[James E. Hopper]

> 
> This code is not the algorithm that comes with the fractal  demo program of
> CodeBuilder 1.1 which incidentally doesn't work at all (error 84). The
> Mandelbrot demo that comes with CodeBuilder is based on the "Manhattan
> distance" instead of the straight line Euclidean distance. None of the
> mac-specific demo programs work except sillyballs and hello.
> 

yes there was an error on the cd, the resource forks of some of the
demo programs (the ones you say don't work) were damaged before the cd
was cut.  the proper examples are on tenons ftp site as john matthews
has already told you.  i don't understand why you are perpetuating this
idea that the demo apps are somehow wrong.  i have run all of the demo
programs with 4.1.1 except the one that has tasking.  that is a problem
right now that i am still working to corect in standalone mac apps.
tasking works fine in unix apps.


> I will include the corrected program in full below. I say the graphics should
> work fifty times faster and the color numbers should to be computed much
> faster. I challenge you to make it run that fast without "jumping through
> hoops" and "threading needles". And I assert that slow execution times of
> programs like this are deliberate sabotage of the so called "computer
> revolution".
> 


Of course i used cleaver tricks, jumped through hoops etc to get it to
run faster.  every computer programmer who wanted performacs since day
one has done that.  you take the example of a program from the past
which you have NO information on how many hoops it jumped through, and
compare it to your source code.  the only legitimate comparison that
could be made to support your argument is to take the original source
and compile and run it for your IIfx and the newer powerpc examples.  i
took your code that had the graphis out of it, and it runs in about 1.5
seconds on my 300mhz beige g3 machine with your unmodified source code. 
you compare that to an unknown algorithm taking 10 seconds on a IIfx. 
theres no resonable comparison or conclusions that can be made from
such a bogus pair of numbers.  instead compile your code for the IIfx
(there is a gnat for 68k macs though an older version) and see how fast
it runs, then compare that to the current 450mhz g3s.  that would still
have the problem of difference in compiler versions but we could at
least discuss that comparison.

also realize that you are running your example on a unix that is
sharing time with the macOS.  you don't know how much time is being
taken by MacOS in the background from your program while its running.

in short you have zero evidence that there is any "slow execution
times" in this example becuase you have nothing valid to compare it to!


jim

Re: Ada95 speed

[Robert Dewar]

In article <3753AA13.3F144877@gte.net>,
  cnelson9@gte.net wrote:

> And I assert that slow execution times of
> programs like this are deliberate sabotage of the so called
> "computer revolution".
>
>    Cliff Nelson

Surely a smiley is missing here. It is impossible to believe
that this is a serious statement. The trouble on CLA is that
some people DO post the most extraordinary claims, so it is
sometimes hard to be sure that people are trying to be funny!


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada95 speed

[Clifford J. Nelson]

Robert Dewar wrote:

> In article <3753AA13.3F144877@gte.net>,
>   cnelson9@gte.net wrote:
>
> > And I assert that slow execution times of
> > programs like this are deliberate sabotage of the so called
> > "computer revolution".
> >
> >    Cliff Nelson
>
> Surely a smiley is missing here. It is impossible to believe
> that this is a serious statement. The trouble on CLA is that
> some people DO post the most extraordinary claims, so it is
> sometimes hard to be sure that people are trying to be funny!
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

It's no joke. And the ramifications are profound.

   Cliff Nelson

Re: Ada95 speed

[Robert Dewar]

In article <37582BB9.62270E6D@gte.net>,
  cnelson9@gte.net wrote:
> It's no joke. And the ramifications are profound.

Sorry, I see no profound ramifications, except that you have
some VERY peculiar ideas, and absolutely NO data or even
vaguely convincing anecdotes to back them up. I must conclude
that this whole thread you started is a troll, and it is time
to kill it :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada95 speed

[Clifford J. Nelson]

"James E. Hopper" wrote:

> [snip]
>
> your comment that new machines are not faster than old because you have
> to do clever tricks to make them work is way off the mark.  unless you
> went through it you have NO idea what gyrations we went through to make
> code run fast on those older machines.  My head aches when i think what
> i went through getting fast code to run on the old 8 bit processors ;-)
> If anything i have found programmers today are much lazier about
> algorithms because they can get away with it more than they used to.
> your whole premise rests on the aburd comparison of comparing this
> simple algorith with an unknowns algorithm from years ago.  unless you
> can present the source code for your comparison point there is no
> validity in your comparison!
>
> Jim

Jim,

I haven't been programming micro computers for the last ten years. I have
been using Mathematica since about 1989. See:
http://forum.swarthmore.edu/epigone/geometry-research/brydilyum

From 1976 to 1989 I programmed a few micro computers and I remember just
storing the result of some computations in memory, and then setting the video
pointer to that area of memory. It took a few micro seconds to display the
result of the computations. All my experience with desk top computers
contradicts yours. They were very easy to program efficiently. Now that I
have something to program I find that the computers don't live up to
expectations anymore.

    Cliff Nelson

Re: Ada95 speed

[James E. Hopper]

In article <3753DA33.F2E088A0@gte.net>, Clifford J. Nelson
<cnelson9@gte.net> wrote:

> 
> I haven't been programming micro computers for the last ten years. I have
> been using Mathematica since about 1989. See:
> http://forum.swarthmore.edu/epigone/geometry-research/brydilyum
> 
> From 1976 to 1989 I programmed a few micro computers and I remember just
> storing the result of some computations in memory, and then setting the video
> pointer to that area of memory. It took a few micro seconds to display the
> result of the computations. All my experience with desk top computers
> contradicts yours. They were very easy to program efficiently. Now that I
> have something to program I find that the computers don't live up to
> expectations anymore.
> 
>     Cliff Nelson

you can do the same thing with the mac if you know what your are doing,
in fact its pretty transparent.  what i did on my version a couple
years ago is just what the gentleman with the pc pointed out, i created
an array, stored results in it, blitted it to the screen.  the blit
took a few milliseconds.  the entire display process was similarly
fast.  if i wanted to get faster yet, i could have allocated my array
on the video card like you are suggesting you could do with old micros,
and then you even save the milliseconds for the blit.  just because its
not obvious to the most unqualified observer doesnt make it that hard. 
mac programmers have been doing this kind of thing for years from 12
year olds on up.

i HAVE spent the last 25 years programming everthing from your micros,
to desktop machines to super computers.  your point has NO validity in
my experience.  if you know what you are doing, programs worked faster
then as they do now, if you didnt they worked slower.  

you seem to want to compare a time when you knew what you were doing
(using micros) to a time when you know far less using desktop machines. 
thats not a fair comparision.  i know for a fact that only people who
knew a lot about programming could get the old micros to do anythign
useful.  a mathemitician or physisist or other tech specialist who
tried to use them tended to bounce hard unless they spent a lot of time
studying them.  

given that i am one of those self same physicists who spent a great
deal of time as a grad student learning to use the old 8 bit single
board computers (while watching my professors fail at it) i know what i
am talking about.

jim

Re: Ada95 speed

[Clifford J. Nelson]

"James E. Hopper" wrote:

> In article <3753DA33.F2E088A0@gte.net>, Clifford J. Nelson
> <cnelson9@gte.net> wrote:
>
> >
> > I haven't been programming micro computers for the last ten years. I have
> > been using Mathematica since about 1989. See:
> > http://forum.swarthmore.edu/epigone/geometry-research/brydilyum
> >
> > From 1976 to 1989 I programmed a few micro computers and I remember just
> > storing the result of some computations in memory, and then setting the video
> > pointer to that area of memory. It took a few micro seconds to display the
> > result of the computations. All my experience with desk top computers
> > contradicts yours. They were very easy to program efficiently. Now that I
> > have something to program I find that the computers don't live up to
> > expectations anymore.
> >
> >     Cliff Nelson
>
> you can do the same thing with the mac if you know what your are doing,
> in fact its pretty transparent.  what i did on my version a couple
> years ago is just what the gentleman with the pc pointed out, i created
> an array, stored results in it, blitted it to the screen.  the blit
> took a few milliseconds.  the entire display process was similarly
> fast.  if i wanted to get faster yet, i could have allocated my array
> on the video card like you are suggesting you could do with old micros,
> and then you even save the milliseconds for the blit.  just because its
> not obvious to the most unqualified observer doesnt make it that hard.
> mac programmers have been doing this kind of thing for years from 12
> year olds on up.
>

If it were "pretty transparent" for people "from 12 year olds on up" I am sure
that you would have just posted the program. But, you will probably not post the
program because everyone could then see my point.

>
> i HAVE spent the last 25 years programming everthing from your micros,
> to desktop machines to super computers.  your point has NO validity in
> my experience.  if you know what you are doing, programs worked faster
> then as they do now, if you didnt they worked slower.
>
> you seem to want to compare a time when you knew what you were doing
> (using micros) to a time when you know far less using desktop machines.
> thats not a fair comparision.  i know for a fact that only people who
> knew a lot about programming could get the old micros to do anythign
> useful.  a mathemitician or physisist or other tech specialist who
> tried to use them tended to bounce hard unless they spent a lot of time
> studying them.
>
> given that i am one of those self same physicists who spent a great
> deal of time as a grad student learning to use the old 8 bit single
> board computers (while watching my professors fail at it) i know what i
> am talking about.
>
> jim

A "micro computer" and a "desktop computer" are the same thing. I new physicists
in 1971 who wrote programs in compiled basic for micro computers. All versions of
the basic language were compiled, not interpreted. They all had matrix math
primitives built in. But, when the so called computer revolution of commercially
sold micro computers (i.e. desktop computers) came, all versions of the basic
language were interpreted, not compiled, and did not have matrix math primitives
built in. My computer instructor said that "job security programming" which was
the art of writing tricky cryptic code to make oneself indispensable was a thing
of the past. He could not have guessed that it hadn't even started. He had not
seen the operating systems like Mac OS and Windows and unix!

   Cliff Nelson

Re: Ada95 speed

[Clifford J. Nelson]

"Clifford J. Nelson" wrote:

> [snip]

> I new physicists in 1971 who wrote programs in compiled basic for micro computers.

correction:  I knew physicists in 1971 who wrote programs in compiled basic for
micro computers.

Debugging what I write is like finding missing commas in Fortran.

   Cliff Nelson

Re: Ada95 speed

[James E. Hopper]

I did find that you are right (and wrong ;-) ) about fractals. there is
nothing wrong with the code, just a change in how tenon handled libs.
to make it work make an alias of the two folders

Tenon Kernel Libraries

Tenon Application Libraries

move these aliases into system folder/extensions

the fractal app will now run.  the original app runs with display in
about 3 seconds, with 1200 wide x 700 high its about 10 seconds.  if i
get a minute i will try sticking your algorithm into it to see how it
works.

jim

Re: Ada95 speed

[Clifford J. Nelson]

"James E. Hopper" wrote:

> I did find that you are right (and wrong ;-) ) about fractals. there is
> nothing wrong with the code, just a change in how tenon handled libs.
> to make it work make an alias of the two folders
>
> Tenon Kernel Libraries
>
> Tenon Application Libraries
>
> move these aliases into system folder/extensions
>
> the fractal app will now run.  the original app runs with display in
> about 3 seconds, with 1200 wide x 700 high its about 10 seconds.  if i
> get a minute i will try sticking your algorithm into it to see how it
> works.
>
> jim

and then stand on your right leg , rub your head with your left hand , and
jump through yet another hoop. No thanks.

Re: Ada95 speed

[James E. Hopper]

I guess if you find it to complex to simply make the system libraries
visiable to the program you are right, computers today are to complex
for you.  

but i programmed single board computers, and pdl 8, pdp 11, pdp 15, ...
etc way back, and to say they were simpler than today is ABSURD!! The
hoops you jumped though compared to today were HUGE!  Heck, i had to
swrite my own floating point math package for the pdp 11 in assembly,
and my own graphics primitives on the pdp 15, and on the commodore 64. 


if you are so in love with basic, there are 2 or 3 different basic
compiler for the mac available i belive.  try one of those.



In article <37553205.2EB31CA3@gte.net>, Clifford J. Nelson
<cnelson9@gte.net> wrote:

> "James E. Hopper" wrote:
> 
> > I did find that you are right (and wrong ;-) ) about fractals. there is
> > nothing wrong with the code, just a change in how tenon handled libs.
> > to make it work make an alias of the two folders
> >
> > Tenon Kernel Libraries
> >
> > Tenon Application Libraries
> >
> > move these aliases into system folder/extensions
> >
> > the fractal app will now run.  the original app runs with display in
> > about 3 seconds, with 1200 wide x 700 high its about 10 seconds.  if i
> > get a minute i will try sticking your algorithm into it to see how it
> > works.
> >
> > jim
> 
> and then stand on your right leg , rub your head with your left hand , and
> jump through yet another hoop. No thanks.

Re: Ada95 speed

[Clifford J. Nelson]

"James E. Hopper" wrote:
>>>You stupid!
>>No, You supid!
>No, You stupid!
No, You stupid!

Re: Ada95 speed

[John B. Matthews, M.D.]

In article <37556F9E.D7AA9901@gte.net>, cnelson9@gte.net wrote:

> "James E. Hopper" wrote:
> >>>You stupid!
> >>No, You supid!
> >No, You stupid!
> No, You stupid!

Mr. Hopper never wrote that.  Both he and I have gone out of our way to
help you, but it appears you'd rather quibble.

Your loss.

John

Re: Ada95 speed

[Clifford J. Nelson]

"John B. Matthews, M.D." wrote:

> In article <37556F9E.D7AA9901@gte.net>, cnelson9@gte.net wrote:
>
> > "James E. Hopper" wrote:
> > >>>You stupid!
> > >>No, You supid!
> > >No, You stupid!
> > No, You stupid!
>
> Mr. Hopper never wrote that.  Both he and I have gone out of our way to
> help you, but it appears you'd rather quibble.
>
> Your loss.
>
> John

Now it's  my turn.

No, You quibble!

Re: Ada95 speed

[Gautier]

Clifford J. Nelson wrote:

> "James E. Hopper" wrote:
> >>>You stupid!
> >>No, You supid!
> >No, You stupid!
> No, You stupid!

What an argument. Don't kill yourselves!
The main problem is with Mac OS.

With all these resource forks, hidden data types,
opaque system, it's still more suited for word processing
than Ada programming... Even usage of Web or networks
is handicaped by that file typing (using it every day).
An iMac with Mac OS 8.5, 96MB RAM is as slow as a 486 DX 33 when
network or files are involved. No command line or programming
environment that come built-in.

Maybe Mac OS XXIII will improve that but I have doubts...

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Ada95 speed

[John B. Matthews, M.D.]

In article <37558947.A1C12CA9@Maths.UniNe.CH>, Gautier
<Gautier.deMontmollin@Maths.UniNe.CH> wrote:

> Clifford J. Nelson wrote:

  [spam deleted]

> The main problem is with Mac OS.

MacOS 8.x isn't UNIX, but Mac OS X is!
 
> With all these resource forks, hidden data types,
> opaque system, it's still more suited for word processing
> than Ada programming... Even usage of Web or networks
> is handicaped by that file typing (using it every day).

I use MacOS 8.x in a mixed Solaris/IRIX/BSD/95/98/NT environment every day;
no problem. I run GANT everywhere.

> An iMac with Mac OS 8.5, 96MB RAM is as slow as a 486 DX 33 when
> network or files are involved. No command line or programming
> environment that come built-in.

Nonsense. Even my Mac 8600 is a better X server than my Pentium II. For
programming, Applescript comes in the box and MPW is free. Of course, my
favorite CLI for Ada 95 is under Tenon's excellent MachTen or CodeBuilder
products. Without question, the Mac file system is a tad slow for UNIX
style programming. That's why Tenon bundles a fast file system that
improves things dramatically.

> Maybe Mac OS XXIII will improve that but I have doubts...

Mac OS X should be more to your liking; will you be porting GNAT?

> -- 
> Gautier
> 
> --------
> http://members.xoom.com/gdemont/

John

Re: Ada95 speed

[Robert Dewar]

In article <3753DA33.F2E088A0@gte.net>,
  cnelson9@gte.net wrote:

> It took a few micro seconds to display the
> result of the computations.

No, that's obviously wrong, presumably this is a misprint
for milliseconds (remember that the scan speed of typical
displays of the period was 30-60Hz)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Ada95 speed

[Clifford J. Nelson]

Robert Dewar wrote:

> In article <3753DA33.F2E088A0@gte.net>,
>   cnelson9@gte.net wrote:
>
> > It took a few micro seconds to display the
> > result of the computations.
>
> No, that's obviously wrong, presumably this is a misprint
> for milliseconds (remember that the scan speed of typical
> displays of the period was 30-60Hz)
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

It it right. It took a few micro seconds while the video mapped memory
pointer was updated. Am I the only one who remembers this stuff?

   Cliff Nelson

Re: Ada95 speed

[David C. Hoos, Sr.]

Clifford J. Nelson wrote in message <37582CA5.987F1E85@gte.net>...
>
>
>Robert Dewar wrote:
>
>> In article <3753DA33.F2E088A0@gte.net>,
>>   cnelson9@gte.net wrote:
>>
>> > It took a few micro seconds to display the
>> > result of the computations.
>>
>> No, that's obviously wrong, presumably this is a misprint
>> for milliseconds (remember that the scan speed of typical
>> displays of the period was 30-60Hz)
>>
>> Sent via Deja.com http://www.deja.com/
>> Share what you know. Learn what you don't.
>
>It it right. It took a few micro seconds while the video mapped memory
>pointer was updated. Am I the only one who remembers this stuff?
>
Well, I guess it depends on what is meant by "display."  Even if the memory
pointer were instantaneously updated, the display would have taken 16.67
milliseconds to scan the video memory to render it visible.

Furthermore, all that aside, those machines were typically only capable of
running one process -- i.e., no multitasking, and hence could allow a
program full access to the hardware.

Today's operating systems must manage resource sharing, etc., so
we're not really comparing like with like here.

Re: Ada95 speed

[Ole-Hjalmar Kristensen]

"Clifford J. Nelson" <cnelson9@gte.net> writes:

> Robert Dewar wrote:
> 
> > In article <3753DA33.F2E088A0@gte.net>,
> >   cnelson9@gte.net wrote:
> >
> > > It took a few micro seconds to display the
> > > result of the computations.
> >
> > No, that's obviously wrong, presumably this is a misprint
> > for milliseconds (remember that the scan speed of typical
> > displays of the period was 30-60Hz)
> >
> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.
> 
> It it right. It took a few micro seconds while the video mapped memory
> pointer was updated. Am I the only one who remembers this stuff?
> 
>    Cliff Nelson
> 
I think he's simply pointing out that while the pointer swap might
take a few microseconds, you would not actually see it until the video
screen had been updated a few milliseconds later :-)

-- 
E pluribus Unix

Re: Ada95 speed

[Robert I. Eachus]

"James E. Hopper" wrote:
 
> your comment that new machines are not faster than old because you have
> to do clever tricks to make them work is way off the mark.  unless you
> went through it you have NO idea what gyrations we went through to make
> code run fast on those older machines.

   A number of tricks not mentioned here:

   Where the map is "smooth" outside the Mandelbrot set, follow the
boundaries of the area and don't compute the enclosed points.  (But you
have to find a closed boundary.)

   For points that are inside the set, it helps to terminate the
iteration, not just at a set number of iterations, but if you compute a
value inside the head or body of the "bug."  Actually, inside circles
which are entirely inside the set.  Remember the entire set is
connected.

   Another method, which is handy for when you are focused into a very
tiny area of the set, is to compute the derivitive of the function at a
point then trace countour lines that way.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada95 speed

[Gautier]

Robert Dewar wrote:

> > and the removal of the hidden Sqrt helps surely
> > even more...

> Don't assume that a square root is necesarily that expensive.
> On some architectures, square root is comparable in speed
> to a floating-point division, not so terrible ....

OK - but it might be useful to mention to uninformed readers
that generally floating-point division is still terribly slower than
a multiplication or an addition, so in that case a Sqrt less could
improve things.

Here is an excerpt from the Intel(R) Pentium(TM) clock cycle table:

FADD [reg,reg]          fadd                            3, 1
FADD memreal            fadd shortreal                  3, 1
FADDP reg,ST            faddp st(6),st                  3, 1
FIADD memint            fiadd int16                     7, 4

FMUL [reg,reg]          fmul st(5),st                   3, 1
FMULP reg,ST            fmulp st(6),st                  3, 1
FIMUL memint            fimul warray[di]                7, 4

FDIV [reg,reg]          fdiv st(5),st                   39                    
      
FDIV memreal            fdiv longreal                   39
FDIVP reg,ST            fdivp st(6),st                  39
FIDIV memint            didiv warray[di]                42

FDIVR [reg,reg]         fdivr st(5),st                  39                    
      
FDIVR memreal           fdivr longreal                  39
FDIVRP reg,ST           fdivrp st(6),st                 39
FIDIVR memint           didivr warray[di]               42

FSQRT                   fsqrt                           70

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Ada95 speed

[Robert Dewar]

In article <3741aa37.3892645@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >>Is Ada95 slow in order to be safe?
>
> >With run-time checks, yes; without them, no.
> >-gnatp suppresses all.
>   On Win95, I see a very modest difference between "-O3" and
"-gnatp
> -O3" on this Mandelbrot code.


Well written code that involves heavy loops, e.g. over arrays,
often has minimal costs imposed by runtime checks.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---