Mail Archives: djgpp/1994/04/02/07:27:42
CC: alane%wozzle AT imageek DOT york DOT cuny DOT edu
Dear Mr. Eldridge!
Regarding compilation speed of djgpp I still beleive that the suggested
comparison makes sense:
>> In order to get a ROUGH estimate of the delays accumulated by
>> switching between real/protected mode (and the eventual
>> inefficiencies of the os) it would be interesting to see mesurements
>> taken on the same hardware once under djgpp and once under LINUX or
>> any other 32bit os with gcc available.
> Well, let's see why this this comparison would be meaningless (I am
> writing this on a Linux system :):
I think that this attack ('meaningless') is not supported by your explications.
> 0. I'm mostly going to talk about disk i/o, since that is where the
> majority of DOS calls get made, and (I'm speculating) that's where the
> most likely bottleneck is.
Ad 0:
Of course the facts you mentioned are slowing down djgpp. However, I am
convinced that compiling speed is mostly determined by the compiler itself.
> 1. DOS is single tasking, Linux is multitasking. So any Linux
> measurements would of course be biased by the system load.
Ad1:
Should I really have explicitely stated that while taking these measurements
under LINUX the compilation must be the only important task running ??
> 2. DOS does synchronous i/o (wait for completion), whereas Linux does
> async i/o, where a process blocks until completion. If another process
> is running at a higher priority, the Linux process might not come back
> immediately upon the i/o finishing.
Ad 2:
When follwing above advice, this effect will not be of big importance.
> 3. DJ has to use the DOS file system for paging. Linux supports VM in
> the kernel. Linux wins big here.
Ad 3:
In order to see good compilation times the system should be equipped with at
least 16MB of ram so that paging rarely occurs.
> 4. It's pretty predictable how DJGPP will page, based on available
> RAM. Linux will page based on total system needs.
Ad 4:
If following above rule 3, this can be neglected.
> 5. Finally, Linux has a gigantic buffer cache (typically around 4-5Meg
> on a 16Meg machine) so disk i/o may not go to the disk; disk i/o on
> DOS always goes to the disk, and swapping to a RAM disk is stupid. This
> combined with (3) and (4) make it really useless to look at the time
> disk i/o takes.
Ad 6:
I run djgpp on a 32MB system with 8M smartdrive cache and 2M ramdisk for temps
so that your above comment does not fit. But gcc is still much slower.
> If you wanted to really measure real v. prot. mode, what you would ....
===== ^^^^^^^^^^ I never said that. Of course switching between modes, the file
system, the os, the disk transfer rate, availability of chaches etc. etc.
influence the measurement.
While single target compilers like bcc et al are considerably faster than
djgpp, I speculate that gcc under linux will NOT be THAT much faster and this
would prove my conclusion that the major bottlenek is gcc itself.
> And another point: mode switching isn't the only bottleneck. Consider
> that all disk i/o requests have to be copied between lower and upper
> memory and done in small blocks (4096 I think it is, with the current
> go32). Memcpy is a very expensive call on most systems, and doing i/o
> in small chunks is also very expensive.
> Summary: There are many variables in play, and to eliminate it to even
> a manageable few would be a daunting task.
No doubt about that.
> FWIW It might be interesting to see what happened if all the
> filesystem code were in libc.a, and only BIOS calls went to real mode
> to access the disk hardware. I think it would be a win. If anybody
> knows where to find a freeware DOS filesystem, speak out.
My first guess ist an improvment below 10% of compilation times. I conlcude
this from the effect found by doubling the 4K buffer size, which definitely cut
by half the number of access operations...
Kind regards!
Hans_Ellenberger AT p14 DOT lemas DOT chg DOT imp DOT com
- Raw text -