To: Martin AT snsystems DOT co DOT uk Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Re: Disk I/O rates with DJGPP Date: Sun, 06 Nov 94 12:11:40 +0200 From: "Eli Zaretskii" > 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.