Mail Archives: opendos/1997/05/15/13:32:33
On Thu, 15 May 1997, Jonathan E. Brickman wrote:
> No, it's not. When I was programming regularly, most of the
> calculations I had to be prepared for in GUI, image-manipulation,
> sound-related, database-related, and almost every other area were
> pushing it in 16 bits. I don't know about you, but most
> of the files on my machine are more than 65,536 bytes long,
> and my hard disk is considerably larger than that. Given
> this, 32-bit calculation becomes an immense advantage,
> because one clock tick on a 32-bit CPU can often replace four
> or more clock ticks on a 16-bit CPU.
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. It *is* an advantage, but not
that much. What does the length of the files on your machine has to do
with processors? Most program still read in files byte-per-byte, so as
long as you have a processor with at least 8 bit register, you're ok.
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.
> Wrong. Windows 95 uses 32-bit calculation in much of
> its processing. Not all, but much. And nearly all
> of the apps on my machine run on NT 4 as well, which means
> they use 32-bit functionality in most cases. Not all,
> but most. BeOS and apps will probably replace everything
> I use now, in a year or two; and then, my CPU
> and OS will be 32-bit, and my filesystem 64-bit.
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!)!
> Given a really decent OS for both platforms, the
> same amount of RAM, and comparable CPU horsepower,
> the 16-bit system will run more or less half as
> fast as the 32-bit system. The problem is,
> decent OSes and comparable CPUs don't really
> exist to support such a comparison. I would
> be very interested in seeing performance
> comparisons between an 8 MHz 80286 and an 8 MHz
> 386 running Minix. I'll bet it's about
> a 1:3 performance ratio, when Minix is
> optimized for each platform.
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!
Pierre Phaneuf
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." - Edsger W. Dijkstra.
"You can't prove anything about a program written in C or FORTRAN. It's
really just Peek and Poke with some syntactic sugar." - Bill Joy.
- Raw text -