Xref: utzoo comp.sys.ibm.pc.programmer:228 comp.sys.ibm.pc:45614 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!ames!pacbell!acsdev!mark From: mark@acsdev.uucp (Mark Grand) Newsgroups: comp.sys.ibm.pc.programmer,comp.sys.ibm.pc Subject: Re: How is a 68000 as fast as an 80386?? Message-ID: Date: 2 Mar 90 09:03:18 GMT References: <505@bilver.UUCP> Sender: mark@acsdev.UUCP Followup-To: comp.sys.ibm.pc.programmer Distribution: na Organization: Premenos Lines: 28 In-reply-to: alex@bilver.UUCP's message of 28 Feb 90 00:30:19 GMT In article <505@bilver.UUCP> alex@bilver.UUCP (Alex Matulich) writes: In my current C programming project, I have written some functions that perform statistical things on 400 separate data sets (linear regressions, standard errors, etc). This number-crunching part takes about a minute to complete when I run it on my Amiga. My Amiga uses a 68000 running at 14 MHz (twice the normal cpu speed) and no math chip. The compiler is Lattice C 4.0 in 32-bit addressing mode (similar to the IBM "large" memory model). Naturally, I wanted more speed, so I ported the program to an AT&T 386WGS at work, which is a 25 MHz 80386 IBM compatible. I compiled it using Turbo C 2.0, large memory model. Then I watched in chagrined disbelief as that number-crunching section still took about a minute to execute -- actually a few seconds longer than my Amiga. All source code was the same! Sounds like you've discovered why Lattice charges more for their compiler. The Lattice compiler does some real optimizations. Turbo C does not do so much optimization. Another factor is the fact that you were using large model pointers. 32 bit pointers (unless you're in native 386 mode) have a higher speed penalty associated with them on a 386 than on a 68000. If there's any way for your data to be referenced using near pointers, you will be able to get more speed. -- ======== Mark Grand Premenos Corporation 415-827-3820 x307 1485 Enea Court Concord, CA 94520 ...!pacbell!acsdev!mark