Re: Ada95 speed

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 <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.---

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

[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

[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]

>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

[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

[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

[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]

> 
> 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

[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

[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 <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

[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

[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

[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

[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 (wandering off topic slightly)

[Larry Kilgallen]

In article <dale-0306991227270001@dale.cs.rmit.edu.au>, dale@cs.rmit.edu.au (Dale Stanbrough) writes:
> Gautier wrote:
> 
> " 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..."
> 
> What a _bizzare_ claim. Let's see if we can get Mr Gautier to
> actually come up with some proof for his hypothesis (but don't 
> hold your breath people. Bigots are rarely interested in 
> _proving_ anything).

Oh, no.  Let's _not_ get him to pursue this inappropriate rathole any
further.  I am probably a bigger Macintosh fan than anyone who follows
this newsgroup, but I purposefully avoid following platform advocacy
groups because for me it is a waste of time.

Larry Kilgallen

Re: Ada95 speed (wandering off topic slightly)

[Dale Stanbrough]

Gautier wrote:

" 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..."

What a _bizzare_ claim. Let's see if we can get Mr Gautier to
actually come up with some proof for his hypothesis (but don't 
hold your breath people. Bigots are rarely interested in 
_proving_ anything).

It is probably useful to remember that the word processing does
require a program, and that program is written in a language, and
that language is probably C or C++. You are saying that what you
seem to describe as a 'hostile programming environment' is 
unsuited to Ada


So let's spell it out nice and simply...

   Could you explain exactly what features in C or
   C++ lend themselves to programming in this environment, that
   precludes the use of Ada (a language designed to be used in
   embedded systems of all things!).



---Off topic items follow, please ignore------------------------

" Even usage of Web or networks
  is handicaped by that file typing (using it every day)."


Darn, I thought that if I used my Mac I would be able to use the
internet. Now i know better! I probably can't even reply to news
postings...


"An iMac with Mac OS 8.5, 96MB RAM is as slow as a 486 DX 33 when
  network or files are involved."


A rather strange claim. I wonder what "slow when files are involved"
means. Certainly I don't think that the file system of the Mac OS is
anything great by any means, but this seems like a rather strange
claim. Have you ever _really_ conducted proper timing comparisons,
with the two machines side by side (i.e. not just having fond memories
of the "old days")?


"No command line or programming environment that come built-in."

You do have applescript, which is a programming environment, last 
time I looked. My PC at home doesn't have a programming environment
at all. I must say that i don't really miss not having a command line
for 99% of the work i do.


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

Do you even know what Mac OS X _is_?

Dale

Re: Ada95 speed (wandering off topic slightly)

[Aidan Skinner]

On Thu, 3 Jun 1999 11:06:03 GMT, Larry Kilgallen
<kilgallen@eisner.decus.org> wrote: 

>further.  I am probably a bigger Macintosh fan than anyone who follows
>this newsgroup, but I purposefully avoid following platform advocacy

I prefer macs more than you prefer macs? ;)

- Aidan (who, one day, will get a mac and will then be happy, except
that he won't be able to switch weapons as easily in QII ;>)
-- 
http://www.skinner.demon.co.uk/aidan/
Horses for courses, tac-nukes to be sure.

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

[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

[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

[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

[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

[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.