🚀 go-pugleaf

In article <INFO-M2%91062009222665@UCF1VM.BITNET> Modula2 List <INFO-M2%UCF1VM.BITNET@ucf1vm.cc.ucf.edu> 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 <stdio.h>

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