Mail Archives: opendos/1997/05/30/10:48:08
On Thu, 15 May 1997, Yves Bellefeuille wrote:
> > 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.
>
> First, 32 bits refers to the size of the data, not to the speed of the
> calculations. Saying it's "twice as fast" is a complete misconception.
> It's like saying that if you make a door twice as wide, you can move
> through it twice as fast. Sometimes you can, but not always! ;-)
32 bits can refer to many various things. Size of data
read/written from registers at a time, 32bit addressing, 32bit
data transfer to/from disk, etc...
> Here are some real-world examples. Higher scores are better.
>
>
> PKUnzip PGP
>
> DOS programs under
> DOS 6.2 1,00 1,00
>
>
> This is the basemark. I've run PKUnzip (from PKZip for DOS) and PGP for
> DOS (16-bit) on my system.
>
>
> Unzip PGP
>
> OS/2 programs under
> DOS/2 Warp 3 0,76 1,65
>
>
> Now I'm using Info-Zip for OS/2 instead of PKZip for DOS, and PGP for
> OS/2 instead of PGP for DOS. Unzip is actually slower than before.
> This may be because Info-Zip isn't programmed as efficiently as PKZip,
> or because the compiler used wasn't efficient. Even though I'm now
> using a 32-bit program, real life variations are completely cancelling
> any theoretical advantages and giving me a slower result. PGP, on the
> other hand, is much faster than before.
This is hardly a comparison. Get the 16 bit version of INFOZIP
for DOS, and the 32 bit version of INFOZIP for DOS, and the OS2
version. Now try zipping and unzipping the same stuff with all
3. You'll find that the 32bit versions are much faster which
makes perfect sense. It is impossible to compare PKZIP in DOS
fairly with INFOZIP/32 in OS2 since it isn't the same code
executing. You might as well compare PKZIP to FDISK for OS2 as
it would be about as useful a comparison.
> Unzip PGP
>
> Linux programs under
> Linux 2 1,02 2,39
If you're comparing these to the DOS and OS2 values I'm assuming
that you timed the operations with a computer timer or a manual
stopwatch of some kind. If so, you also have to keep in mind
that when Linux boots up, there are 50 million system daemons and
stuff in memory so they cut into processing time. Also, are you
taking into effect the effects of the other OS overheads? What
about drive cache's?
You see, comparing programs between OS's is useless due to the
varying overheads interfering with the calculations, shared libs
or static, etc, etc, etc...
The only valid comparison IMHO is between a pure 16bit DOS
program, and a 32bit DOS program. Even then, it would vary from
compiler to compiler.
Take a small program coded in assembly. Write it totally in 16
bit code/data. Now write it in assembly using DPMI and 32bit for
everything. Assume that the program accesses 3 megs of data.
What will be faster? This is a no-brainer. The argument is
over.
> Now I'm using Info-Zip for Linux and PGP for Linux. Unzip is very
> slightly faster than under DOS. PGP is much faster than under DOS and
> even faster than under OS/2.
UNZIP runs faster under Linux on my idle system than in DOS.
I'm using the 32bit versions in both cases. I don't have
PGP though.
> So although 32-bit systems and programs are usually somewhat faster
> than 16-bit systems and programs, real-life results vary quite a bit,
> depending on the application, the skill of the programmer, and the
> quality of the compiler.
And how many other programs are running in the OS. Again your
comparisons are between apples and oranges.
> Experiment on your own system with 16-bit and 32-bit programs. For
> example, compare the speed of PKZip for DOS with the speed of WinZip
> for Windows 95. Or choose any other application with 16-bit and 32-bit
> versions.
PKZIP for DOS and WINZIP for '95 are 2 completely different
programs. They both create zipfiles, but that is the only
similarity. No basis for comparison between 16 and 32bit
code/data. 32bit code and data is always faster than 16 bit.
Comparing the 2 in this respect is useless. Now when you take it
down to details in coding, it may be true inside a given routine
of a program that a 16bit MOV is faster than a 32bit MOV for some
reason or another. No big deal, code a 16bit MOV. It's still a
32bit app.
> The real advantage of 32-bit systems is portability. Only Inter CPUs
> run in 16-bit mode; all other processors will only run in 32-bit mode.
> That's another story, though.
The real advantage of 32bit OS's and apps are speed, protection,
efficiency. Portability has nothing to do with it. It is
perfectly possible to write a program portably that compiles
without modification on a 16bit OS/compiler as well as a
32bit/OS/compiler.
I don't know what you mean about inter cpu's since we haven't
brought multiprocessing or parallel processing into it, and I
don't see how it fits into the conversation anyways. We're
talking about DOS.
I know of many different 8, 16 and 32 bit processors from a
variety of different manufacturers. (80x86/88, 68k, 68xx, 65xx,
85xx, Alpha, MIPS, Sparc, etc....) What is your point?
Are you saying that if a 16bit DEC Alpha existed and ran a 16 bit
OS that it would be faster than the current 64bit alpha running a
64bit OS?
I think you are gravely misled by 16 vs 32 bit performance.
> Yves Bellefeuille See homepage for best freeware for DOS and Win 3.1x
> Ottawa, Canada Finger, homepage or key-server for PGP key
> an448 AT freenet DOT carleton DOT ca Francais / English / Esperanto
You should have took more computer classes instead of learning
Esperanto, then you'd have spent the time more constructively and
know why 32bit performance is faster.
:o) (sorry, I couldn't resist)
TTYL
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
Download OpenDOS, then: CDD C:\^DEL /ZS MSDOS.SYS IO.SYS \DOS\*.*
- Raw text -