delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/01/04/17:19:09

From: "Stephen Howe" <SPAMGUARDstephen DOT howe AT teamsybase DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Why did ID choose DJGPP for Quake?
Date: Tue, 4 Jan 2000 19:55:58 -0000
Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom
Lines: 62
Message-ID: <84tj7t$si3$1@soap.pipex.net>
References: <199912312332 DOT RAA15911 AT lakdiva DOT slt DOT lk>
NNTP-Posting-Host: tnagbgate71.tnagb.com
X-Trace: soap.pipex.net 947015741 29251 194.202.213.71 (4 Jan 2000 19:55:41 GMT)
X-Complaints-To: abuse AT uk DOT uu DOT net
NNTP-Posting-Date: 4 Jan 2000 19:55:41 GMT
X-Newsreader: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Kalum Somaratna aka Grendel wrote in message
<199912312332 DOT RAA15911 AT lakdiva DOT slt DOT lk>...
On 31 Dec 99, at 0:01, Stephen Howe wrote:

>>>> It varies Andrew. It would better to check the types of optimisation
each
>>>> compiler does.

>>Actually Stephen, IMHO what appears to be fast code from a
>>human point of view may fail miserably when it is actually run and
>>put to the test.

>>So one way would be to run a small computationally intensive
>>bechmark program (does anyone have any ideas?) compiled under
>>WatcomC++ 11(or whatever is the latest version) and DJGPP/GCC
>>2.952 with full optimizations and see which performs better. And
>>maybe we can publish the results on this forum for everyone to see.

Your right. But I would be looking separately at

(i) integer optimisation
(ii) fp optimisation
(iii) space and time saving optimisations
(iv) loop optimisations
(v) stack lifetime optimisations
(vi) tail optimisations
etc.

You will find that it wins on some tests and does badly on others. I am
aware of it strengths and its weaknesses from having used it for 13 years.
My ideal C & C++ compiler and tools would be a combination from all the PC
compilers that is on the market.

Speaking honestly, there are a number of areas where the compiler &
libraries could be improved. For instance, the 32-bit maths libraries are
built assuming that your executables (32-bit DOS, Win32, OS/2 etc) could be
running on a 386+287 combination which implies fwait opcodes. Well how many
people are running on that combination? Not many, I bet. For everyone
running 486 or better, these can be removed. So that means numerical maths
tests could be faster on Pentiums if the libraries wer built differently.

>>
Whether real/protected mode switches ought to be taken into
account will also have to be considered.

Actually IMHO a test of how fast the mode switching routines are
would really indicate how good a protected mode environment
really is specially for a real mode OS like DOS(the quality of the
compiler also plays a part true enough).
>>

At this point are you talking about 32-bit DOS? If so, would you not mostly
be measuring the DOS extenders performance (Tenberry, Causeway, PMODE/W,
DOS32 etc) rather than the compiled code? That would be tricky to factor
out. DOS4GW 2.01 _is_ faster than DOS4GW 1.97 (this is the version that
comes with Watcom), I have measured it.

Stephen Howe



- Raw text -


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