Mail Archives: djgpp/1994/11/06/07:01:57
> System 4K 32K
> ===================
> Native 21 16 Turbo-C compiler - 16 bit code
> X32 22 17 Watcom C 9.5 with X32 DOS extender
> DOS4GW 24 21 Watcom C 9.5 with DOS4GW DOS extender
> DJGPP 27 27 GCC with GO32 ( 1.12.maint2 )
> ===================
> This is running on a 100MHz Pentium, 48Mbytes RAM using a SCSI hard
> drive running QEMM 7.03 with DPMI services.
Did you try both with and without ``nodpmi'' in the GO32 environment
variable? Any difference in timings?
> I think the results show that the 4k buffer is not the only reason
> for slow file i/o with GCC. There's probably some inefficiency in
> the real mode interrupt call to DOS too.
>
> Any comments ?
What I would like to point out is that performance penalty for using
DJGPP is really not so bad. I mean, when reading a 32MByte file,
does it really hurts that much to wait for another 7 or 10 *seconds*
for the program to run? Remember, unless you are running something
like wc, your program will have to actually *do something* with
those 32MByte of data, which will also take *some* time.
So, yes, we should make DJGPP faster (enlarging the transfer buffer
will probably give the most of the boost), but should we be too
concerned with what it delivers right now? I doubt it. Admittedly,
there are applications I could think of that would like the maximum
possible speed of I/O operations, but they should know from the
onset that the speed of real-mode I/O cannot be reached from
DOS-extended programs (due to the necessity of moving the data from/to
low memory), even if all other inefficiencies are sorted out.
And these applications are most probably a minority.
What would *really* be e big win is writing something like 32bit disk
access in Windows. Quite a project, I would say. I don't see how
somebody other tham MS would succeed here, because this requires
such intimate relationship with the DOS (undocumented) internals.
- Raw text -