From: "John M. Aldrich" Newsgroups: comp.os.msdos.djgpp Subject: Re: WATCOM or DJGPP Date: Thu, 14 May 1998 19:13:12 -0400 Organization: Two pounds of chaos and a pinch of salt. Lines: 41 Message-ID: <355B7A88.2E7C@cs.com> References: <6jdm0i$fle AT sjx-ixn1 DOT ix DOT netcom DOT com> NNTP-Posting-Host: ppp145.cs.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Matthew Conte wrote: > > Watcom 11.0 is a turd, but 10.6 still beats out PGCC / GCC in optimization. > GCC is probably one of the least efficient compilers out there (Turbo C++ > beats it in many respects), but it is what I use because it's free and > there's plenty of on-line tech support... =) If you have benchmarks for this, we'd like to see them. From my limited experience and the much greater experience of many others here, DJGPP beats out just about every commercial compiler in speed of generated code, as long as you compare apples and apples (same target architecture, same optimizations, etc.). For example, Turbo C generates 16-bit code, so comparing it with DJGPP is silly. Also, DJGPP programs have a necessary static load time that's used in doing all the startup work (some of which can be disabled). However, if you want to compare load times, try using the copy of unzip386.exe in pub/simtelnet/gnu/djgpp/ on SimTel. I tried it out just for kicks and it seemed to take at least 3 seconds to do whatever Borland's tacked-on extender had to do. On the other hand, I built InfoZIP's zip and unzip for myself with DJGPP and they run like lightning; they actually seem to be slightly faster than pkzip/pkunzip 2.04g although I haven't timed them. If you are going to run around accusing DJGPP of being slow, at least provide some evidence of it! A user recently complained about DJGPP's time() function being 200 times slower than Linux's, giving a sample program and some fairly vague figures to back it up. I took his code, compiled it, tested it, profiled it, and tried using different timing functions. I sped it up over a thousand times just by using clock() instead of time() (which in DJGPP requires a PM<->RM mode switch, costing several hundred cycles). So post your results. Who knows, you may turn up a bug that needs to be fixed. -- --------------------------------------------------------------------- | John M. Aldrich | "Democracy is based on the assumption| | aka Fighteer I | that a million men are wiser than one| | mailto:fighteer AT cs DOT com | man. How's that again? I missed | | http://www.cs.com/fighteer | something." - Lazarus Long | ---------------------------------------------------------------------