minow@decvax.UUCP (Martin Minow) (05/13/87)
In article <942@batcomputer.tn.cornell.edu>, Moshe Braner asks about
MWC V2.0 compiler performance. Here are some very informal numbers.
Configuration: compiler, editor, linker, temp files, and libc.a in ramdisk;
sources, #include files, objects, and gem/vdi libraries on disk. (1040ST
with one floppy, 512K ramdisk).
Source file 18930 bytes, 728 lines (+ 5 #include files).
0:44 Compilation, detect syntax error, restart Microemacs
0:09 Microemacs reads source and error file and points to bad line.
1:21 Exit editor (after writing file) and successfully compile source.
2:08 Link the 8 object modules with the various libraries, writing
a 32 Kbyte program.
While these numbers are greater than the "20 seconds for a small program"
Moshe reports, note that these numbers are for a large source file,
part of a large program.
Martin Minow
decvax!minowbraner@batcomputer.tn.cornell.edu (braner) (05/13/87)
[] OK, I finally sat down and timed Megamax compiling a large program. System: 1040STf (1 meg, internal floppy drive unused), 576K RAMdisk (_everything_ done there), Megamax v1.1, micro-C-Shell. Program: 22K (1000 lines, _not_ heavily commented) C source plus some #include files, 3 external precompiled (.o) modules. Final (executable) program size 45K. Program mostly does FP calcs. Timings (in seconds): 6 Enter microEMACS, read source, write source 20 compile 35 link --- 61 total Compare with about 220 for MWC compiling a smaller program, as posted. Megamax v2.0 (promised "soon") will supposedly have a faster linker. - Moshe Braner Disclaimer: I have no affiliation with Megamax except as a customer. There are many infuriating bugs in the Megamax C Language system, v1.1 (some of which I posted) - as there are in all the other systems... The current Megamax FP lib is _terried bya
minow@decvax.UUCP (Martin Minow) (05/14/87)
In article <995@batcomputer.tn.cornell.edu>, Moshe Braner, compares the performance of Megamax and MWC: >... >Timings (in seconds): >... > 61 total > >Compare with about 220 for MWC compiling a smaller program, as posted. Moshe noted that everything was kept in RAM. Persons comparing the performance of the two systems should note that my timings for MWC kept sources, objects, #include files, some libraries, and the output .prg on floppy disk. Also, I built the program using make, which would have affected the performance somewhat. After juggling my ramdisk a bit, I tried compiling Dumas' UUDECODE.C (5861 bytes) with everything (source, include, and libraries) in ramdisk. The total compile->.prg took 25 seconds. While it's always fun to play "my computer's faster than your computer," there are other more important points to note: the quality of the code, and the accuracy of the translation. At times, I've noted that some I/O libraries are very small and fast, but don't quite handle all the strange error cases. So, unless things are *very* far apart, you shouldn't put much weight on raw speed. Martin Minow decvax!minow
braner@batcomputer.UUCP (05/15/87)
[] I am sort of a RAM freak (and don't have a hard disk), and even with the RAMdisk I look for better performance. The point of my "Megamax is faster than MWC" posting was that (as far as I know) one cannot use MWC completely in RAMdisk (for more than miniscule jobs, anyway). That makes SUCH a difference in performance (from the programmer's point of view: the time to compile and link) that it is a very qualitative issue. (You can always compile your final code with the compiler that generates better code.) Thanks for the advice people sent me about using the clipboard and other AES calls for interprocess communications. That's not what I asked, though. I want something that can be used from a SMALL program (no GEM!), and that does it all in RAM (no files!). Any RAM locations free for such things? (Jwahar Bammi told me the 768 bytes above the screen area are "free" but warned not to use them...) - Moshe Braner