🚀 go-pugleaf

In article <505@bilver.UUCP> alex@bilver.UUCP (Alex Matulich) writes:
>Can someone help me with a puzzling problem?
>
>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
   ^^^^^^^  only creates 16-bit code....
>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 --
	16-bit code on 386 can you say lame duck (read below....)
>actually a few seconds longer than my Amiga.  All source code was the same!
>
>5)  I know the 80386 has special modes of operation, incompatible with
>    previous chips, that allow it to run at its full potential.  Is this
>    the reason my program isn't running at its rightful speed?  Are these
	Yes partly, 1) 32-bit inst in real mode 2) 32-bit Protected mode
>    special modes accessible when using DOS?  If so, how?

Alex,
   the reason your program ran 'slow' on the 386 is because you compiled it
for a 286 (at best) LARGE model, a large model on a x86 means all addresses
have segment offset, haveing the x86 load segments is very 'expensive'
time wise (i normally use a small model & put large data out in far memory...)
(on a 286 or below memory accesses are restricted to 64K segments so any thing
larger then 64K (128K if you count code & data...) needs new segment) 
I don't know of any compilers (in turbo C price range) that will handle 
386 specific instructions.  Yes you can get 386 compilers but all the 
ones i know of need a 386 *nix or DOS Extenders (can you say a grand $$)
there is hope, MASM & TASM (& others...) support 386 instructions.
if you can find the 'busy' work, you could recode the busy stuff in 386
assembler (real mode) which would have a nice speed up (40% is what pkzip
claims) then the 386 'should' blow the pants off of YOUR 14mhz 68000,

    **** I AM NOT REFERING TO 680x0's IN GENERAL JUST HIS CASE!!!!! ****

the other possiblility under dos is DOS Extenders, but like i mentioned 
above the cost $$$$, ( i know my budget says NO ;-) which allow
one to write FULL 32 bit programs (nice, about the same as YOUR 32-bit
addressing mode)  A DOS Extended puts the processor in Protected mode for
your program to run, handles the interface to DOS, returns to DOS when 
your programs 'exits'.

		I hope this helps.....
			Jay
-- 
		Jay B. Harlow	<harlow@plains.nodak.edu>
	uunet!plains!harlow (UUCP)	harlow@plains (Bitnet)

Of course the above is personal opinion, And has no bearing on reality...

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

In article <MARK.90Mar2090318@acsdev.uucp> mark@acsdev.uucp (Mark Grand) writes:
+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.

Another possibility is that you are using different floating point
conventions in the two programs.  I would be surprised if the 386 did
not make up for the pointer dereferencing penalty over the 68000 just
with faster and more efficient execution of the rest of the code,
especially if it is number crunching bound.

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.  

I am curious if this is the case, let me know.

Bernard Littau    VM Radiological Sciences        Telephone: (916) 752-4014
                  School of Veterinary Medicine   Internet:  vmrad@ucdavis.edu
                  University of California        BITNET:    vmrad@ucdavis
                  Davis, CA 95616                 UUCP: ucbvax!ucdavis!vmrad

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

In article <4451@cbnewsl.ATT.COM> afg@cbnewsl.ATT.COM (andrew.goldberg) writes:
>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....
>
> 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.

There is also the Metaware HighC compilers which generate very
good FP code. Using Microway or Metaware on highly intensive math
stuff will generate much better speeds (even using the FP
emulator).

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

Thanks for the mention Andy. BTW if anybody reading this is developing
commercial products, call Weitek for information regarding our developer
program. It offers significant discounts on products. {end of commercial}

Again, don't forget Metaware... >>

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

Wellll.... except that both Microway and Metaware give you ways to 
prohibit the float promotion or use the ANSI control of what gets
promoted to doubles. Most of the CAD/CAM people in the DOS world are
now using one of these two compilers.


>
>		Andy Goldberg


-----
Bill Brothers				ISV Support Specialist
brothers@weitek.COM			Voice (408) 738-8400
{sun,pyramid}!weitek.COM!brothers	Compuserve: 73757,1443

From article <3666@plains.UUCP>, by harlow@plains.UUCP (Jay B. Harlow):
> In article <505@bilver.UUCP> alex@bilver.UUCP (Alex Matulich) writes:
>>Can someone help me with a puzzling problem?
>>
>>In my current C programming project, I have written some functions that
>>perform statistical things on 400 separate data sets (linear regressions,
>>.....
>>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
>    ^^^^^^^  only creates 16-bit code....
>>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 --
> 	16-bit code on 386 can you say lame duck (read below....)
>>actually a few seconds longer than my Amiga.  All source code was the same!
>>
>>5)  I know the 80386 has special modes of operation, incompatible with
>>    previous chips, that allow it to run at its full potential.  Is this
>>    the reason my program isn't running at its rightful speed?  Are these
> 	Yes partly, 1) 32-bit inst in real mode 2) 32-bit Protected mode
>>    special modes accessible when using DOS?  If so, how?
> 
> Alex,
>    the reason your program ran 'slow' on the 386 is because you compiled it
> for a 286 (at best) LARGE model, a large model on a x86 means all addresses
> have segment offset, haveing the x86 load segments is very 'expensive'
> time wise (i normally use a small model & put large data out in far memory...)
>........ more on small models

The only fair test here is to do the test with large model.  While it
is true that the 80x86 processors will let you execute code in a small
model architecture,  this is only applicable to fairly small applications
( I know this is relatively speaking, and that 10 years ago 64k of code
was a fairly large application).  The 680x0 family architecture ALWAYS
fetches long word addresses (32 bits), so the most fair comparision
is the x86 large model.

BTW, this very feature (large linear address space) on the 68k family is
what makes it a somewhat more desirable processor to program on (no
segments to wory about).  On the other hand, the segmented architecture
lends itself to being able to develop position independent code easier.

rick
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
rick odle		texas instruments industrial systems division
(615) 461-2371  	johnson city, tn  37601          __   .  _     /__,
uucp:		mcnc!rti!tijc02!rdo031                  (    (  (__  /  (
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-