Mail Archives: djgpp/1994/11/06/20:21:39
> What I would like to point out is that performance penalty for using
> DJGPP is really not so bad. (27 seconds vs 16 seconds)
Well, I disagree. It's like taking that nice new high speed SCSI drive
and turning it into an MFM drive when running under DJGPP. That's why
I plan to make sure the best performance we know how will be available
in V2 with nothing more than a stubedit. (BTW, it is more than just
the transfer buffer size, but that is a big factor).
> 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.
Copying the memory is a small overhead (almost neglible). The mode
swaps from protected to real to protected are the bottleneck. The big
transfer buffer also reduces the number of these needed.
> 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.
While I have such code, maintaining this is a nightmare. If you need
the high performance this badly, you need a new Operating System. I
would suggest OS/2 or Linux. Native GCC is available for both.
- Raw text -