From: "Stephen Howe" 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