🚀 go-pugleaf

In article <6933@ucdavis.ucdavis.edu>, vmrad@pollux (Bernard Littau) writes:
> In article <MARK.90Mar2090318@acsdev.uucp> mark@acsdev.uucp (Mark Grand) writes:
> +In article <505@bilver.UUCP> alex@bilver.UUCP (Alex Matulich) writes:
> +
> +   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.

		Actually, to me it sounds like you need a 32-bit
		compiler for your 386.  You are comparing an Amiga
		compiler that gets the most out of the 68000 with a PC
		compiler that was not intended for the 386.  I use
		Microway's C compiler and see about a factor of two
		improvement.

		If you want more speed buy a Weitek chip, which the 
		AT&T 6386/25 will accept.  The 25 MHz Weitek goes for about
		$1300 and will give you another factor of 5 or so, if
		you do not use transcendental functions.  The Microway
		C compiler, among others, supports the Weitek.
> 
> C is a poor math language in general.  Lattice may well have
> implemented a single precision floating point library, while the 386
> based C is using double.  You might try forcing both machines to use
> double and see if this makes a difference.
> I have seen cases where the same program takes longer to execute in
> single mode than double.  This is due to the overhead of converting
> single to double, doing the calculation in double, and converting back
> to single.  

		?huh? While your comments about single vs. double are
		right on the money, what's all this about C being a "poor
		math language" ?  Math code in any language typically
		compiles down to a list of calls to the
		coprocessor.  The trick here, as in any language, is to make
		sure accesses to the coprocessor are by macro, not subroutine
		call.  Most compilers I have worked with will give you the
		choice at compile time.

		Andy Goldberg
		AT&T Bell Laboratories
		Parsippany, New Jersey
		...att!vilya!afg
		afg%vilya@att.com

		PS.  I was a C fan even before coming to AT&T. - A