* Re: Ada95 speed [not found] <374182F2.B10AD449@Maths.UniNe.CH> @ 1999-05-18 0:00 ` Tom Moran 1999-05-18 0:00 ` Gautier 1999-05-19 0:00 ` Robert Dewar 0 siblings, 2 replies; 36+ messages in thread From: Tom Moran @ 1999-05-18 0:00 UTC (permalink / raw) >>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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-18 0:00 ` Ada95 speed Tom Moran @ 1999-05-18 0:00 ` Gautier 1999-05-19 0:00 ` Robert Dewar 1999-05-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 36+ messages in thread From: Gautier @ 1999-05-18 0:00 UTC (permalink / raw) > >>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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-18 0:00 ` Gautier @ 1999-05-19 0:00 ` Robert Dewar 1999-05-20 0:00 ` Clifford J. Nelson 1999-05-31 0:00 ` Gautier 0 siblings, 2 replies; 36+ messages in thread From: Robert Dewar @ 1999-05-19 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-19 0:00 ` Robert Dewar @ 1999-05-20 0:00 ` Clifford J. Nelson 1999-05-20 0:00 ` Tucker Taft 1999-05-31 0:00 ` James E. Hopper 1999-05-31 0:00 ` Gautier 1 sibling, 2 replies; 36+ messages in thread From: Clifford J. Nelson @ 1999-05-20 0:00 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-20 0:00 ` Clifford J. Nelson @ 1999-05-20 0:00 ` Tucker Taft 1999-05-20 0:00 ` Tom Moran 1999-05-31 0:00 ` James E. Hopper 1 sibling, 1 reply; 36+ messages in thread From: Tucker Taft @ 1999-05-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-20 0:00 ` Tucker Taft @ 1999-05-20 0:00 ` Tom Moran 1999-05-20 0:00 ` Tom Moran 0 siblings, 1 reply; 36+ messages in thread From: Tom Moran @ 1999-05-20 0:00 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-20 0:00 ` Tom Moran @ 1999-05-20 0:00 ` Tom Moran 1999-05-21 0:00 ` Tom Moran 0 siblings, 1 reply; 36+ messages in thread From: Tom Moran @ 1999-05-20 0:00 UTC (permalink / raw) >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). ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-20 0:00 ` Tom Moran @ 1999-05-21 0:00 ` Tom Moran 0 siblings, 0 replies; 36+ messages in thread From: Tom Moran @ 1999-05-21 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-20 0:00 ` Clifford J. Nelson 1999-05-20 0:00 ` Tucker Taft @ 1999-05-31 0:00 ` James E. Hopper 1999-06-01 0:00 ` Clifford J. Nelson ` (2 more replies) 1 sibling, 3 replies; 36+ messages in thread From: James E. Hopper @ 1999-05-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-31 0:00 ` James E. Hopper @ 1999-06-01 0:00 ` Clifford J. Nelson 1999-06-01 0:00 ` James E. Hopper ` (2 more replies) 1999-06-01 0:00 ` Ada95 speed Clifford J. Nelson 1999-06-03 0:00 ` Robert I. Eachus 2 siblings, 3 replies; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-01 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-01 0:00 ` Clifford J. Nelson @ 1999-06-01 0:00 ` James E. Hopper 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` Robert Dewar 1999-06-02 0:00 ` James E. Hopper 2 siblings, 1 reply; 36+ messages in thread From: James E. Hopper @ 1999-06-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-01 0:00 ` James E. Hopper @ 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-04 0:00 ` Clifford J. Nelson 0 siblings, 1 reply; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-02 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` Clifford J. Nelson @ 1999-06-04 0:00 ` Clifford J. Nelson 0 siblings, 0 replies; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-04 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-01 0:00 ` Clifford J. Nelson 1999-06-01 0:00 ` James E. Hopper @ 1999-06-02 0:00 ` Robert Dewar 1999-06-04 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` James E. Hopper 2 siblings, 1 reply; 36+ messages in thread From: Robert Dewar @ 1999-06-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` Robert Dewar @ 1999-06-04 0:00 ` Clifford J. Nelson 1999-06-04 0:00 ` David C. Hoos, Sr. 1999-06-04 0:00 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-04 0:00 ` Clifford J. Nelson @ 1999-06-04 0:00 ` David C. Hoos, Sr. 1999-06-04 0:00 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 36+ messages in thread From: David C. Hoos, Sr. @ 1999-06-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-04 0:00 ` Clifford J. Nelson 1999-06-04 0:00 ` David C. Hoos, Sr. @ 1999-06-04 0:00 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 36+ messages in thread From: Ole-Hjalmar Kristensen @ 1999-06-04 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-01 0:00 ` Clifford J. Nelson 1999-06-01 0:00 ` James E. Hopper 1999-06-02 0:00 ` Robert Dewar @ 1999-06-02 0:00 ` James E. Hopper 1999-06-02 0:00 ` Clifford J. Nelson 2 siblings, 1 reply; 36+ messages in thread From: James E. Hopper @ 1999-06-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` James E. Hopper @ 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` James E. Hopper 0 siblings, 1 reply; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-02 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` Clifford J. Nelson @ 1999-06-02 0:00 ` James E. Hopper 1999-06-02 0:00 ` Clifford J. Nelson 0 siblings, 1 reply; 36+ messages in thread From: James E. Hopper @ 1999-06-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` James E. Hopper @ 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` John B. Matthews, M.D. 1999-06-02 0:00 ` Gautier 0 siblings, 2 replies; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-02 0:00 UTC (permalink / raw) "James E. Hopper" wrote: >>>You stupid! >>No, You supid! >No, You stupid! No, You stupid! ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` Clifford J. Nelson @ 1999-06-02 0:00 ` John B. Matthews, M.D. 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` Gautier 1 sibling, 1 reply; 36+ messages in thread From: John B. Matthews, M.D. @ 1999-06-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` John B. Matthews, M.D. @ 1999-06-02 0:00 ` Clifford J. Nelson 0 siblings, 0 replies; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-02 0:00 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` John B. Matthews, M.D. @ 1999-06-02 0:00 ` Gautier 1999-06-02 0:00 ` John B. Matthews, M.D. 1999-06-03 0:00 ` Ada95 speed (wandering off topic slightly) Dale Stanbrough 1 sibling, 2 replies; 36+ messages in thread From: Gautier @ 1999-06-02 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` Gautier @ 1999-06-02 0:00 ` John B. Matthews, M.D. 1999-06-03 0:00 ` Ada95 speed (wandering off topic slightly) Dale Stanbrough 1 sibling, 0 replies; 36+ messages in thread From: John B. Matthews, M.D. @ 1999-06-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed (wandering off topic slightly) 1999-06-02 0:00 ` Gautier 1999-06-02 0:00 ` John B. Matthews, M.D. @ 1999-06-03 0:00 ` Dale Stanbrough 1999-06-03 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 36+ messages in thread From: Dale Stanbrough @ 1999-06-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed (wandering off topic slightly) 1999-06-03 0:00 ` Ada95 speed (wandering off topic slightly) Dale Stanbrough @ 1999-06-03 0:00 ` Larry Kilgallen 1999-06-04 0:00 ` Aidan Skinner 0 siblings, 1 reply; 36+ messages in thread From: Larry Kilgallen @ 1999-06-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed (wandering off topic slightly) 1999-06-03 0:00 ` Larry Kilgallen @ 1999-06-04 0:00 ` Aidan Skinner 0 siblings, 0 replies; 36+ messages in thread From: Aidan Skinner @ 1999-06-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-31 0:00 ` James E. Hopper 1999-06-01 0:00 ` Clifford J. Nelson @ 1999-06-01 0:00 ` Clifford J. Nelson 1999-06-01 0:00 ` James E. Hopper 1999-06-02 0:00 ` Robert Dewar 1999-06-03 0:00 ` Robert I. Eachus 2 siblings, 2 replies; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-01 0:00 UTC (permalink / raw) "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; ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-01 0:00 ` Ada95 speed Clifford J. Nelson @ 1999-06-01 0:00 ` James E. Hopper 1999-06-02 0:00 ` Robert Dewar 1 sibling, 0 replies; 36+ messages in thread From: James E. Hopper @ 1999-06-01 0:00 UTC (permalink / raw) > > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-01 0:00 ` Ada95 speed Clifford J. Nelson 1999-06-01 0:00 ` James E. Hopper @ 1999-06-02 0:00 ` Robert Dewar 1999-06-04 0:00 ` Clifford J. Nelson 1 sibling, 1 reply; 36+ messages in thread From: Robert Dewar @ 1999-06-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-02 0:00 ` Robert Dewar @ 1999-06-04 0:00 ` Clifford J. Nelson 1999-06-05 0:00 ` Robert Dewar 0 siblings, 1 reply; 36+ messages in thread From: Clifford J. Nelson @ 1999-06-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-06-04 0:00 ` Clifford J. Nelson @ 1999-06-05 0:00 ` Robert Dewar 0 siblings, 0 replies; 36+ messages in thread From: Robert Dewar @ 1999-06-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-31 0:00 ` James E. Hopper 1999-06-01 0:00 ` Clifford J. Nelson 1999-06-01 0:00 ` Ada95 speed Clifford J. Nelson @ 1999-06-03 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 36+ messages in thread From: Robert I. Eachus @ 1999-06-03 0:00 UTC (permalink / raw) "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... ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-19 0:00 ` Robert Dewar 1999-05-20 0:00 ` Clifford J. Nelson @ 1999-05-31 0:00 ` Gautier 1 sibling, 0 replies; 36+ messages in thread From: Gautier @ 1999-05-31 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Ada95 speed 1999-05-18 0:00 ` Ada95 speed Tom Moran 1999-05-18 0:00 ` Gautier @ 1999-05-19 0:00 ` Robert Dewar 1 sibling, 0 replies; 36+ messages in thread From: Robert Dewar @ 1999-05-19 0:00 UTC (permalink / raw) 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.--- ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~1999-06-05 0:00 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <374182F2.B10AD449@Maths.UniNe.CH> 1999-05-18 0:00 ` Ada95 speed Tom Moran 1999-05-18 0:00 ` Gautier 1999-05-19 0:00 ` Robert Dewar 1999-05-20 0:00 ` Clifford J. Nelson 1999-05-20 0:00 ` Tucker Taft 1999-05-20 0:00 ` Tom Moran 1999-05-20 0:00 ` Tom Moran 1999-05-21 0:00 ` Tom Moran 1999-05-31 0:00 ` James E. Hopper 1999-06-01 0:00 ` Clifford J. Nelson 1999-06-01 0:00 ` James E. Hopper 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-04 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` Robert Dewar 1999-06-04 0:00 ` Clifford J. Nelson 1999-06-04 0:00 ` David C. Hoos, Sr. 1999-06-04 0:00 ` Ole-Hjalmar Kristensen 1999-06-02 0:00 ` James E. Hopper 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` James E. Hopper 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` John B. Matthews, M.D. 1999-06-02 0:00 ` Clifford J. Nelson 1999-06-02 0:00 ` Gautier 1999-06-02 0:00 ` John B. Matthews, M.D. 1999-06-03 0:00 ` Ada95 speed (wandering off topic slightly) Dale Stanbrough 1999-06-03 0:00 ` Larry Kilgallen 1999-06-04 0:00 ` Aidan Skinner 1999-06-01 0:00 ` Ada95 speed Clifford J. Nelson 1999-06-01 0:00 ` James E. Hopper 1999-06-02 0:00 ` Robert Dewar 1999-06-04 0:00 ` Clifford J. Nelson 1999-06-05 0:00 ` Robert Dewar 1999-06-03 0:00 ` Robert I. Eachus 1999-05-31 0:00 ` Gautier 1999-05-19 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox