delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/12/25/03:51:17

To: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
Cc: wrh AT placer1 DOT wimsey DOT com, djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Math Emulator
Date: Sun, 25 Dec 94 10:03:11 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>

> I don't really understand why there's such a large performance hit,
> since most compilation is digital in nature, but it may be that the
> disk is fairly slow (28ms vs 14ms on the office machine).  It might be

Any disk cache installed?  If it is, then the disk access time
should have only a small effect on the compilation time.

Did you check the BIOS settings on the SX?  Vendors sometimes
set them at ``safe'' values which might include unnecessary
wait states etc.  I doubt it would explain a fourfold increase
in runtime, though.  Overall, I'm amazed at the effect of the
fp processor on what I would assume does no floating point.

acmq AT alpha DOT coe DOT ufrj DOT br (Antonio Carlos Moreirao de Queiroz) writes:
> And this with 50 MHz 486 machines...
> I cant't imagine what a compiler is doing when it takes so much
> time to compile something. Some gross inefficiency is evident.
> My approach in developing programs to be compiled with djgpp
> (or any other C compiler... All are too inefficient) is to develop
> everything in Turbo Pascal and then translate to C when only small
> details are missing. It is faster...

Turbo Pascal 3, no doubt ;-).  On a 50 MHz 486DX should compile
at about 250 lines/second when optimizations are enabled.  That
would make Ghostscript what, about 2 1/4 *million* lines??  I
would say there indeed *is* something grossly inefficient in the
way that machine is configured, Steve.  Could it be the multitasking
or something else DV/X-connected?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019