Mail Archives: opendos/1997/05/30/10:48:04
On Thu, 15 May 1997, Yves Bellefeuille wrote:
> > 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.
>
> Let's see if I can explain about "32-bit disk access".
[SNIP]
Yeah, you tried but failed.
[SNIP]
> So the deal with 32-bit disk access isn't really that you can read
> data twice as fast if you read it 32 bits at a time rather than 16
> bits at a time. Rather, the significance is that you're no longer
> using BIOS and stopping the entire system every time you read
> something on a disk. A single user might not see a big difference, but
> it's crucial on a multi-user system.
32bit disk access DOES read data twice as fast because the data
is transfered from the hard disk to the computer (or vica versa)
32bits at a time, and not 16 bits. Since 32 = 16 * 2, the data
is recieved twice as fast.
Just to prove a point, I ran a hard disk speed testing utility
(SYSCHK) in plain old pure MSDOS 6.22. No multitasker, or
windows or OS2 or Linux or anything, just pure MSDOS. I got a
1100kb per second. I then enabled the 32bit disk access
feature in my CMOS and reran SYSCHK. My data transfer rate
jumped from 1100kb to 1800k. I then disabled 32bit access and
installed the 32bit driver that came with my HD (for DOS of
course). I got even higher results with this driver. (Which
didn't surprise me since it came from the HD vendor). My
transfer rate was 2050kb per second. My machine has minimal
drivers installed, and is not on a network.
In Linux, my system was getting 1900kbps approx as reported from
hdparm, and now approx 2800kbps with 32bit access turned on.
Here is a screenshot:
First, my drive configuration:
2 capslock:~# hdparm -v /dev/hda
/dev/hda:
multcount = 8 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 523/32/63, sectors = 1055020, start = 0
As you can see, 32 bit is off.
Now the speed test:
2 capslock:~# hdparm -t /dev/hda
/dev/hda:
Timing buffer-cache reads: 32 MB in 3.10 seconds =10.32 MB/sec
Timing buffered disk reads: 16 MB in 8.50 seconds = 1.88 MB/sec
The 10.32 is timed through the cache so it is not indicative of
anything other than my system memory speed. The 1.88 is direct
16bit reads from the disk.
Now we'll enable 32bit mode:
2 capslock:~# hdparm -c 1 /dev/hda
/dev/hda:
setting 32-bit I/O support flag to 1
I/O support = 1 (32-bit)
Now we'll run the speed test again:
2 capslock:~# hdparm -t /dev/hda
/dev/hda:
Timing buffer-cache reads: 32 MB in 3.22 seconds = 9.94 MB/sec
Timing buffered disk reads: 16 MB in 5.42 seconds = 2.95 MB/sec
As you can see, the 32bit access in this case made disk transfer
speed more than 50% faster. This isn't twice as fast due to
other limitations and overheads in the system, but 50% is
DEFINATELY a significant improvement!! This means that my
programs load 50% faster, store 50% faster, etc. I have verified
this by doing my own testing as well. In fact my own testing
shows speed increases of closer to 90% in C programs doing
standard I/O.
Would you still rather have a 16bit OS and 16 bit programs for
your computer? A 32bit computer sensibly runs 32bit programs
faster than 16bit ones. What's more is that allmost all
386/486/586 and higher processors are OPTIMIZED for 32bit
software and leave the 16bit parts of the processor fairly
unoptimized. This means that 32bit software will run even faster
on these processors. For details and benchmarks go to:
http://www.amd.com http://www.intel.com http://www.cyrix.com
Also, take a wander over to http://www.x86.org and
http://delorie.com
If 32 weren't faster, then it would not be being used. Same goes
for video cards too. 32 bits means that you write 4 pixels
instead of 2...
> So once again "32-bit" is generally better than "16-bit", but not as
> much as the hype implies, and perhaps not enough to matter to the
> average user.
What do you mean by better? 32bit programs and OS's are faster
than what could be done equivalently in 16bit code/data. This is
a fact. For that matter, 64bit is that much more faster than
32bit. It is significantly faster that the only big drawback to
writing 32bit code is that it won't run on 16 bit 286's and
lesser. If this level of compatibility is of concern, then code
16 bit, or create 2 separate programs - one 16bit, and one 32. Or
in the case of an OS, create a 16bit version and a 32bit version
- which is exactly what will happen to OpenDOS. Getting rid of
those 64k segments VERY significantly speeds up programs,
especially graphical programs that can use the linear framebuffer
from 32bit mode instead of 64k banks and bank switching. In my
own coding, I've found this to be up to 10 times faster.
About the "average user" comment - the average user, uses a
program and that is it. Generally they fit into 1 of 3
categories, those that don't care, and those that want 32bit
because they both know, and have seen the benifits, and 3 those
that want 32bit programs because the number 32 is bigger than the
number 16.
Well, regardless of what the users cares, 32bits is still faster
so the user who uses 32bit software will get higher performance
on their *32bit* computer. Makes sense. Those that couldn't be
bothered, regardless will still have faster programs by using 32
bit ones.
One more final point about your last comment is that it is the
PROGRAMMER who is in control of creating the application, and
most coders want fast programs. If given the choice, they will
chose 32bit for speed and efficiency so long as it doesn't
require a big headache to code. In most cases it doesn't take
anything extra to code. Therefore the end user comment is
irrelevant. It is up to the programmer, and regardless of the
opinion of the user, benchmarks and profilers prove that 32bit is
faster. Anyone who disagrees is hopelessly fooling themselves.
Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris
Computer Consultant | Coming soon: dynamic-IP-freedom...
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
Email: mharris at blackwidow.saultc.on.ca <-- Spam proof address
URL: Caldera http://www.caldera.com
- Raw text -