wayne@csri.toronto.edu (Wayne Hayes) (11/27/90)
About 3 months ago Bruce suggested a really short patch to the kernel that vastly improved performance when there were multiple tasks actively running. He warned that there were possible conflicts and that it actually had a bug and was a kludge until something else could be done. Has anyone else that intalled that patch had any suspicious crashes? Until I added that patch, Minix had *never* crashed on me, but while I was doing the 386 upgrade last weekend it crashed 3 times in 2 days during heavy disk activity, and again today when I was tar'ring up some files. That was the last straw, I went back to the old method, even though the system sure seems a heck of alot slower now. Would it be any better if we added the task as the *second* in the queue rather than first? (The old way has it added last, I think.) I really miss the fast feel (and it's only been a few hours), but the crashes are even more annoying. --- Well, I got the 386 version of gcc from plains today. Wow what a huge compiler. gcc-cc1 has 490K text, 1.2M stack for a total of 1.7M memory. Basically I can't run anything else on my 4 Meg 386/33 or else gcc runs out of memory (well I guess I could chmem it smaller for smaller programs...) I recompiled a few choice commands. Compress (16-bit) needs about the same stack space, but the object is 3 times larger (50K) than bcc's (17K). It runs about 40% faster. (This is the standard Minix compress with AZTEC undefined so I get 16 bits. I don't understand why there's another version floating around when the original minix one works fine???) Comic(1) is the big surprise. It runs about 25% faster, the object is 53K (bcc==33K), but bcc's only needs 16K of stack where gcc's comic needs a whopping 135K!!! I have *no* idea why the gcc version of comic needs 8 times as much stack space as the bcc version. As has been said, gcc assumes you have Big $$$, Big Machine, Big Memory, etc, etc. If you have the disk space and memory, it's definitely worth it. Note that there's an error in the readme file on plains. It tells you to 'mv crt0.o gnulib /usr/local/lib/gcc/gnulib', which looks to me like you have gnulib in the directory ..../gcc/gnulib. But you just want crt0.o in .../gcc and gnulib also in .../gcc, as a file (not a directory). -- "Dad, what should I be when I grow up?" "Honest." -- Robert M. Pirsig, _Zen and the Art of Motorcycle Maintenence_. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525
jms@cs.vu.nl (Jan-Mark) (11/28/90)
In article ... wayne@csri.toronto.edu (Wayne Hayes) writes: > > Comic(1) is the big surprise. It runs about 25% faster, the object > is 53K (bcc==33K), but bcc's only needs 16K of stack where gcc's comic > needs a whopping 135K!!! I have *no* idea why the gcc version of comic > needs 8 times as much stack space as the bcc version. As has been said, > gcc assumes you have Big $$$, Big Machine, Big Memory, etc, etc. If you > have the disk space and memory, it's definitely worth it. > COMIC has a ``#ifdef __BCC__'', there for the difference in memory space and speed. Try ``comic -V'' with both versions. COMIC has a speed vs. memory tradeoff. (Whereas compress has a compression rate vs. memory tradeoff.) So COMIC is faster if you compile it with 256x256 (=128K) hash table. If you can use gcc, (and thus have the Big $$$, Big Machine, Big Memory, etc, etc.) 135K shouldn't be a problem for your system. If you want the same hash table size (and speed) with (32-bit) bcc, add (yet an other) #ifdef in COMIC to distinguish between the 32- and 16- bit version of bcc. The COMIC 1.3 has it in it. If I reach COMIC 2.0 (more SM-DOS suffix support) I'll post it to some source newsgroups (and comp.os.minix). Jan-Mark. > > Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525 -- (:> jms (_) ========""======