rnollman@maxzilla.encore.com (Richard Nollman) (05/02/91)
Thanks to everybody who responded to my 249 hours to generate MANDELBROT image on 286 posting. I thought I would post responses to date. I think I will take the unanimous advice and buy a coprocessor. My original posting is summarized in the first response. From rogerhef@matt.ksu.ksu.edu Wed May 1 14:17:02 1991 In comp.sys.ibm.pc.hardware you write: >Recently, using FRACTINT,I generated a Mandelbrot image on my 286 >clone that took 239 hours. I set the number of iterations to 1000 >(for those of you who are familiar with FRACTINT). The floating point >flag was turned on by FRACTINT and I do not have a math coprocessor. I >told a friend about it and he was puzzled. He has a 386 and the most >time a Mandelbrot image took to generate was about 14 hours and this >was deep into the set (billions magnification). I saved my image on >diskette and gave it to him. He generated the exact same image on his >computer in about 3 hours. We surmised that the cumulative effect of >many different factors accounted for the large difference in >calculation times. Given the differences in our machines (shown >below), does the time difference make sense? (We are trying to >determine if there is something in FRACTINT that may be configured >incorrectly on my machine). > my 286 his 386 > ------ ------- > 8 mghz 33 mghz > no cachex 64K cache > 16-bit I/O bus 32-bit I/O bus > no math coprocessor math coprocessor > 249 hours to 3 hours to calculate > calculate >Where should I best spend my money to upgrade (best bang for buck)? >Where am I losing the most processing speed? In FRACTINT with on my machine (386SX with a coprocessor) using floating point off, (integers only) it is about 2x as fast as with the coprocessor turned on. If you had a coprocessor it should speed up the calculations by 5-15 times, since this is flocting point intensive. Your friends machine is about 6 times faster than yours with no coprocessor. With his having a coprocessor it is about 60-100 times faster than yours on floating point. If you had a coprocessor it would put yours his machine only about 6-10 times faster. With floating point on the coprocessor it the big difference. If you run both programs with floating point off the difference will be considerably less extreame. -- Rogerhef@Matt.ksu.ksu.edu Roger Heflin EECE Grad Student (913) 532-5600 ************** From chao@CS.UCLA.EDU Wed May 1 14:30:08 1991 >Where should I best spend my money to upgrade (best bang for buck)? >Where am I losing the most processing speed? Math coprocessor. Get AMD287 for under $100. -- Chia-Chi Chao chao@cs.ucla.edu ..!ucbvax!cs.ucla.edu!cha ************** From SPG@ALPHA.SUNQUEST.COM Wed May 1 15:03:27 1991 OK, If one assumes that 33MHz is ~4 times faster than 8Mhz and that a 386 is >2 times faster than a 286 executing the same instructions at the same speed, then there's _still_ a factor of 10 hiding somewhere. A factor of 10 _is_ pretty likely if there's a lot of floating point math which can be offloaded to the co-processor. >Where should I best spend my money to upgrade (best bang for buck)? >Where am I losing the most processing speed? Off-hand I'd suggest a co-processor, but you probably won't see a 10 times decrease in run-time, because the co-processor for your machine will (most likely) be slower than your friend's. Go for a complete system upgrade... ;-) It might be worthwhile, If you're _really_ dedicating a machine to one task for 10 days straight. $0.02 Steve ************** From sp4@reef.cis.ufl.edu Wed May 1 18:20:22 1991 Those sound like reasonable numbers to me! His machine in just clock cycles is about 4 times as fast. The 386 is a bit faster than the 286, he has a cache, larger data bus, AND a coprocessor. The math coprocessor is probably the absolute biggest difference. If you wanted to generate fast Mandlebrot graphics the best investment would be the coprocessor! sp4@reef.cis.ufl.edu ************** From mark@typhoon.ucar.EDU Wed May 1 18:25:01 1991 > my 286 his 386 > ------ ------- > 8 mghz 33 mghz This is a big one. That's a factor of four right there -- that cuts the ~250 hours to ~60 hours. > no cachex 64K cache The cache basically allows the '386 to take full advantage of its clock speed. Not having one won't affect the '286 as much. > 16-bit I/O bus 32-bit I/O bus Not so much the I/O bus, but the register size, will affect things when you're in the realm where you're doing integer math. '386s, with their 32 bits, win here. The only I/O Fractint is doing is to the screen, and that *isn't* your limiting factor. > no math coprocessor math coprocessor This is another big one -- I imagine it could easily account for a factor of four to six in speed, accounting for the rest of the discrepancy. >Where should I best spend my money to upgrade (best bang for buck)? >Where am I losing the most processing speed? If you want to keep your current machine, a coprocessor would help a bunch. If you're planning on going to a '386, things will improve, though it'll cost more. (If you're rich, do both!) >Thanks. No sweat. -- -- Mark Bradford (bradfrd2@ncar.ucar.edu) <> To err is human, to moo bovine. "I'm not a squid, but I play one on the net." **************** From sstrazdu@hopi.intel.com Wed May 1 19:29:54 1991 Your numbers are worse than I would have expected, but they seem reasonable. For a program like Fractint a Math Coprocessor will make a HUGE difference. The program is spending almost all its time doing floating point calculations. If you want to run Fractint fast but a coprocessor, but if you want to run everything faster you will need to upgrade to a 386 or 486. Here's one more thing to think about. You're 286 with a 287 will probably run Fractint as fast as a 386SX with no coprocessor, but the 386SX will run most programs (those which don't use a lot of floating point) faster. **************** From kdorff@NMSU.Edu Thu May 2 02:37:04 1991 Don't feel so distraught. The problem is LACK OF COPROCESSOR. There was a fractint image that I created long ago, before I got a coprocessor, and these were the times: Image on 8mhz XT, no copper Image in 8mhz XT, copper 23 hours 18 minutes Same configuration, same machine, only difference was the coprocessor. Kevin *************** That last posting says it all. Thanks again. Rich Nollman
ntaib@silver.ucs.indiana.edu (Nur Iskandar Taib) (05/02/91)
>Don't feel so distraught. The problem is LACK OF COPROCESSOR. There >was a fractint image that I created long ago, before I got a >coprocessor, and these were the times: > > Image on 8mhz XT, no copper Image in 8mhz XT, copper > 23 hours 18 minutes > >Same configuration, same machine, only difference was the coprocessor. Reminds me of my experience with Grapher. Screen drawing would take 2 1/2 minutes without 8087, 4 seconds with. Amazing. But I hear that 287s don't give as dramatic an increase. -- ------------------------------------------------------------------------------- Iskandar Taib | The only thing worse than Peach ala Internet: NTAIB@AQUA.UCS.INDIANA.EDU | Frog is Frog ala Peach Bitnet: NTAIB@IUBACS ! -------------------------------------------------------------------------------
brian@cunixf.cc.columbia.edu (Brian Hoffman) (05/03/91)
I can't believe that 30 hosers responded to your question about Fractint and not a single one (as far as I can tell) got it right. Your question was basically this: why is fractint much faster on a 33-386 than on my 12-286. The lame answer was this: get a math coprocessor. The real reason is found on the first page of the fractint documentation. Fractint was written to be 386 specific. The program uses the advanced 386 specific calls in a way that does very fast INTEGER MATH. On a 286,the program approximates the 386 functions, but it runs much slower. In general, fractint runs faster on a 386 because it was written that way. A math coprocessor will NOT help because fractint uses integer math. However, it is possible to tell fractint to use a math coprocessor, and this will indeed speed up calculations on your 286. But this was not the source of the discrepancy you noticed originally. -brian ______ she's staring as the lights are curling off into the dark. and the fuel tank's erupting underneath a rain of sparks. and the birds all leave the tree down in the corner of the park. with his neck bent back on the top of the seat, he looks so relaxed despite the heat.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (05/07/91)
In article <1991May2.224345.434@cunixf.cc.columbia.edu> brian@cunixf.cc.columbia.edu (Brian Hoffman) writes: | I can't believe that 30 hosers responded to your question about Fractint | and not a single one (as far as I can tell) got it right. Sorry, they were about right, you are wrong on this one. | Your question was basically this: why is fractint much faster on a 33-386 | than on my 12-286. | | The lame answer was this: get a math coprocessor. Yes. as the originally posting very carefully noted, FRACTINT turned on the float flag, as it should when it runs out of bits for the fixed point math it uses when it can. | In general, fractint runs faster on a 386 because it was written that way. | A math coprocessor will NOT help because fractint uses integer math. This is correct, in many cases f.p. won't help. However, it does not use integer math, it uses fixed point. Not the same, as a numerical analyst to explain. | However, it is possible to tell fractint to use a math coprocessor, and this | will indeed speed up calculations on your 286. But this was not the source | of the discrepancy you noticed originally. I'm pretty sure you're wrong on this one, too. The early versions ran faster on a 286 in fixed point mode, but it depends on what's being done. Someonbe said that recent versions of fractint use the 386 32 bit stuff, not correct, the original program was called something like fract386, and ONLY ran on a 386. Later emulation was added. My advice: a 386SX-20 board for about $600 with memory, and a Cyrix 387SX for about $220. Worlds faster, particularly on the stuff which *doesn't* use the 387. I really suggest the Cyrix, it's up to 2x faster than Intel, cheaper, and lower power. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
david@kessner.denver.co.us (David Kessner) (05/08/91)
In article <3859@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >| In general, fractint runs faster on a 386 because it was written that way. >| A math coprocessor will NOT help because fractint uses integer math. > > This is correct, in many cases f.p. won't help. However, it does not >use integer math, it uses fixed point. Not the same, as a numerical >analyst to explain. They are the same in one important respect: It uses the integer math part of the CPU rather than the floating point unit. While numerically they are different, as far as the CPU is concerned they are the same. >| However, it is possible to tell fractint to use a math coprocessor, and this >| will indeed speed up calculations on your 286. But this was not the source >| of the discrepancy you noticed originally. > > I'm pretty sure you're wrong on this one, too. The early versions ran >faster on a 286 in fixed point mode, but it depends on what's being >done. It's not a matter of telling fractint to use the FPU since it AUTOMATICALLY uses it if it is doing floating point and you have a FPU. There are too many variables as to why the 386 was faster, there's no one reason. Amung them: The difference in clock speed, the 386 registers, one used floating point, the other integer. > Someonbe said that recent versions of fractint use the 386 32 bit >stuff, not correct, the original program was called something like >fract386, and ONLY ran on a 386. Later emulation was added. I said it uses the 386's 32 bit registers. That's not to say that it REQUIRES a 386. It doesnt, but uses it's features if you do have one. >bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) -- David Kessner - david@kessner.denver.co.us | do { 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | . . . If you cant flame MS-DOS, who can you flame? | } while( jones);