Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!zephyr.ens.tek.com!tekgen!sail!toma From: toma@sail.LABS.TEK.COM (Tom Almy) Newsgroups: comp.lang.modula2 Subject: Re: TopSpeed 3.0 First Impressions Message-ID: <9755@sail.LABS.TEK.COM> Date: 20 Jun 91 16:11:20 GMT References: Reply-To: toma@sail.LABS.TEK.COM (Tom Almy) Organization: Tektronix, Inc., Beaverton, OR. Lines: 122 In article Modula2 List writes: >On Tue, 18 Jun 91 21:11:21 GMT Tom Almy said: >>I just received my "free" upgrade, and used the half price coupon for >>Top Speed C. Some first impressions: >>6. The WNDDEMO program comes in both Modula and C versions, and the C version >> is *much* faster. It is also about 10% smaller. Again the optimization >> bias is leaning even more toward C and away from Modula. >Could you run a couple of simple tests (like time to do n printf's >against time to do n WrStr's)? I'm interested in just how bad this >bias is. Well I though it unfair to compair WrStr with printf, but WrStr with fputs should be ok: I compared the Top Speed Modula-2 with C. I wrote a program that wrote 10000 copies of "This is a test of writing speed" to the display. The result: Language Size Speed Modula-2 2854 21.1 sec C 3116 20.6 I then tried writing to a file. Since Modula-2 is unbuffered by default, while C is buffered by default, I did the test (now for 1000 copies) both unbuffered and both buffered with buffer size 1024. Language Size Speed Modula-2 Nobuf 5620 1.64 Modula-2 Buf 6525 6.81 (NOT a misprint!) C Nobuf 4654 12.58 C Buffered 4750 0.93 It looks like Modula-2 is really buffered, somewhere, and that for some reason explicitly specifying a buffer actually slows it down. At any rate, the TopSpeed C is a clear win of TopSpeed Modula-2. Incidentally, the C Buffered code took 1.48 seconds to execute with Borland C, with a file size of 6294, making the TopSpeed C product look very good. Here are the sources for the buffered file versions: MODULE test; IMPORT FIO; IMPORT Storage; CONST BufferSize = 1024 + FIO.BufferOverhead; VAR i:CARDINAL; dummy: FIO.File; buffer: ADDRESS; BEGIN dummy := FIO.Create("test.out"); Storage.ALLOCATE(buffer,BufferSize); FIO.AssignBuffer(dummy, buffer); FOR i := 0 TO 1000 DO FIO.WrStr(dummy,"This is a test of writing speed"); FIO.WrLn(dummy); END; END test. #include void main() { int i; FILE *dummy = fopen("test.out","w"); setvbuf(dummy, NULL, _IOFBF, 1024); for (i = 0; i <= 1000; i++) { fputs("This is a test of writing speed\n",dummy); } } >>I have a number of additional programs to compile, but it looks like this >>version is a step backwards in code size and execution speed. And it takes >>11 Megs of my disk! >Is that just the M2 compiler or both the C and M2 compilers? Both, but I couldn't install even the M2 compiler on my home system which had only 2 meg free before erasing the old. >>I will try the C compiler on some "gut buster" code I've got here, and will >>also see how it works with Microsoft Windows. I only wish they hadn't gone >>the multi-langage route. I'm afraid this is going to be another "the jack of >>all trades is master of none" package. Well the results are in! The large C program (XLISP) compiled without a hitch to an executable about 10% smaller than that of Borland, Zortech, or Microsoft, but it was also about 10% slower than any of those. Compilation speed was much better than Microsoft or Zortech, but much worse than Borland (these with all optimizations on). The Windows test was another story. The simple example program I had (About2 from the Petzold book) would not compile correctly when modified as per the TopSpeed manual. I looked at the TopSpeed sample program and discovered that it was set up slightly differently (in the DEF/EXP file and the project file) than the book said. I changed the About2 accordingly and it compiled. The executable was 2k smaller than Borland C. Unfortunately it did some funny things with the system resources when I ran it. >I feel that the multi-language route is fine, but they just have a >decidedly poor implementation (mainly involving 'language bleed' where >none is needed or wanted). Yes, if they pulled it off, just having a common environment for different languages, even if one never did mixed language programming, would have been great. But I just don't have the time to fool around with this when I have other already working compilers. I'm going to check the crashing graphics code on another machine, and if it fails give JPI a call. If this doesn't pan out, I'll remove the whole mess from my system and just use version 1 -- it worked! Tom Almy toma@sail.labs.tek.com Standard Disclaimers Apply -- Tom Almy toma@sail.labs.tek.com Standard Disclaimers Apply