Mail Archives: opendos/1997/05/15/14:33:07
> It's more like instead of taking 10 clock ticks to move 16 bit, it is 17
> clock ticks to move 32 bit in a single shot.
No, that's not what I'm talking about. I'm talking about a 32-bit
MOV on a 386 taking the same number of ticks as a 16-bit MOV on
an 8086. And I'm also talking about a 32-bit ADD on a 386 taking
the same number of ticks as a 16-bit ADD on an 8086.
> What does the length of the files on your machine has to do
> with processors?
An enormous amount. An 8-MHz 8086 will take far longer to
read a 1-megabyte file from the same SCSI hard drive
than an 8-MHz 80386, because the 8086 must read the
file 16 bits at a time, and the 386 can read the file 32
bits at a time. Furthermore, file position calculation
can be done in 32-bit math on the 386, whereas the 8086 must either
use 16-bit math with bank switching or use multiple operations
to produce 32-bit math. Either way, performance drops
drastically. This is why color GUI just doesn't work really well on
a 10 MHz 8086, and should work quite well on a 10 MHz 386
(given a decent OS; Linux is not, for GUI).
> Most programs still read in files byte-per-byte,
Nope. No matter what a program does, if the program is written
well it asks the OS to read all at once the largest block of data that
is useful to the program. Even Microsoft Access does that.
If the OS is optimized properly, it is optimized for the
maximum bit-width of the hardware. That's why 32-bit disk
access improves things an amazing amount under Windows 3.11
and a SCSI drive, and doesn't do much at all for an old
IDE.
> Regarding file size, I can handle 64-bit integers with 100% 16-bit code
> that'll run perfectly on a 286 or less. They *are* slower than 16-bit
> integers, but I *never* had to use 64-bit integers! I *do* have to use
> 32-bit integers with 16-bit instructions (slower than 16-bit integers
> too), but only when I manage file size or file position, which isn't
> performance critical.
Not performance critical for your applications, I believe.
Not performance critical at all, wrong. File size and
position calculation is viciously critical when reading,
say, a 512K GIF image, or a ten megabyte database, or a really
big formatted-text document, or a mail spool containing
500 messages.
> Oh yes, but be reminded one of the core DLL in Windows 95 (the
> MSGSRV32.DLL, message server) is 16 bit, thus needing thunking to be
> accessed and stuff... What do you mean by a 64-bit file system? If you are
> refering to the integer size used in the structures, ext2 uses 64-bit
> integers. You can have a multi-terabyte file (if you've got the storage!)!
That's why I am ever so slowly moving towards NT 4
for my main machine. When my hardware is adequate I probably will.
The new BeOS file system does indeed support truly
enormous files, and partitions, and disks. Rather
interesting to me, particularly in re: huge
search engines and the like.
> It's actually not that much. What I experience (as a programmer) is that
> 32-bit protected mode gives me all the memory I need (want a 4 MB array?
> here you go!), and performance gain when I do a blt using 32-bit
> instructions (which I can do in real mode too). I remember the "flat real
> mode" (AKA "voodoo mode"), that let you in on a single segment as large as
> your memory, while in real mode (no memory protection to slow you down!).
> It *screamed*, but was just that: voodoo. Not exactly kasher... ;-)
> Wouldn't run on many machines caused problems with EMM386 or Windows (read
> "froze")... SmartDrive was using "voodoo mode" a couple of versions ago!
I believe it. Those are some of the bigger reasons why I have
not bothered to keep up with DOS and Windows programming. When
the OS is a pile of misbegotten dirt, I look for people who
already know where the gold is. Luckily, lots of people do.
Jonathan E. Brickman River City Computing, Inc. (913) 232-6663
http://www.cjnetworks.com/~rivercity brickman AT cjnetworks DOT com
It seems to me that men usually think more about carburetors, and women
think more about doors. I think the world needs really good carburetors...and
really good doors.
- Raw text -