Tom Jennings
     Fido 125/1
     30 Sept 85

                  NEC 'V' Series Processors: A review

             I purchased a NEC V30 (the 8086 replacement; the V20
     is the 8088 replacement) this past month, and was a bit
     disappointed with the results I got.

             The V20 is actually an 8088 pin compatible 80188
     minus the onboard IO devices, and V30 ditto 8086. The
     instructions marked "Enhanced" in the NEC documentation are
     the new, Intel, 8018x instructions; the ones marked "Unique"
     are unique to the NEC series. I have not compared clock
     cycles V30 vs. 80186, etc, but I would bet they are the
     same.

             I was told of wondrous speed increases, though the
     range was given as "5 - 80%", which of course means down in
     the 5% range is what you get; this is of course what I
     found.

             I have a Multibuss based machine running an Intel
     SBC86/12A processor card, which uses an 8086, and modified
     to run at 7.3MHz. I run MSDOS 3.05 on it. I use it for all
     my work, including compiling Fido, documentation, etc. I use
     the Lattice compiler, which is a fine program though on the
     slow side. I figured that if I could get a real life 20%
     speed increase I'd be very happy.

             It is not possible to do "seat of the pants" testing
     with something like this; you have to set up SOME sort of
     test.  I did all testing on an empirical basis.  I do not
     use the Seive of Erasthenes, bubble sorts, or other arcane
     things day to day.  I edit, compile, and other things like
     most everyone else.

             One thing I do not do is use spreadsheets or other
     "math intensive" programs. The V series chips will NOT
     necessarily speed up programs that use (or could use) the
     8087 coprocessor. You will hear that the V series chips are
     substantially faster doing "math" than the Intel parts.
     This is absolutely true, however, you will rarely see the
     advertised speed increases supposedly possible.

             The reason for the less than advertised speed
     increase is that even in a program such as a spreadsheet,
     the number of non-math instructions (jumps, logical
     operations, bit testing, register and stack manipulation,
     etc) that any CPU does far outnumbers the math type
     instructions (multiply and divide mostly).  Even if multiply
     and divide took zero time, your programs would not take zero
     minutes to execute.

             This is not to say that there are not isolated
     incidents; this means that plugging in this chip, or any
     other real or fictional device, will not get you monstrous
     speed increases.

             The tests I did are admittedly systems oriented
     tasks, though they are very applicable to estimating the
     performance you will get in normal, daily use. The tests are
     as follows:

     (a)     Fido Compile. This consisted of a Lattice compile of
     a number of Fido BBS modules, ones that it was convenient
     (and easily repeatable) to cause a recompile. (I use a MAKE
     type system, and I need to fool it.) This test was the "all
     around" test; Lattice seems to spend less than 1/4th its
     time doing disk IO, mostly it seems to be "working" with the
     program source in memory. Lattice is a predominantly compute
     bound program.

     (b)     LISTGEN NODELIST.256. This is definitely compute
     bound; compiled BASIC string manipulation.

     (c)     ZAPLOAD FIDO_FID.EXE F FOO.HEX . ZAPLOAD is a
     program that generates Intel HEX format. (ASCII
     representation of a file.) It should be IO bound, but is not
     due to poor programming. (What can I say?)

     (d)     SCAVENGE A: SCAVENGE reads all blocks of a disk and
     maps out bad sectors. My A: is a 10 meg hard disk, an
     extremely fast one. This is definitely IO bound, with very
     optimal drivers. This is a "control" test, and should not
     vary, since the speed of executions is limited by the disk
     not the processor.

     (e)     Assemble the Multibuss BIOS. The BIOS of my
     Multibuss box is about 20 .ASM source files. MASM.EXE is
     very definitely compute bound. (Which by the way is the
     worst assembler anyone will ever see. It should be IO
     bound!)

             I performed these five tests first with the 8086
     installed, then after replacing the 8086 with the V30. No
     other changes were made. Timing was done by a special
     program that keeps a millisecond counter that I use for
     general benchmarking, and is highly accurate and repeatable.
     here are the results:

     TEST                    8086            V30     Change
     (a) Compile Fido BBS    43:10           40:53   5.5%
     (b) Listgen             04:23           04:08   6.0%
     (c) Zapload             08:36           08:42   -1.1%
     (d) Scavenge            04:14           04:14   0%
     (e) Assemble BIOS       05:23           05:07   5.2%

             The results are pretty clear, and are verifiable.
     SCAVENGE is SCAV23X.COM, LISTGEN is John Warren's program,
     ZAPLOAD should be out there somewhere, Lattice and MASM you
     can find.

             I cannot account for the ZAPLOAD test.  It should
     not have slowed down. It may be an anomaly.

             Anyone who uses MASM knows that it is terribly slow,
     and for some unknown reason compute bound. (An assembler?!)
     It is written in Microsoft Pascal, so I guess that's it.

             An 8087 will NOT speed up when using the V30/V20
     series.  It runs at its own clock rate.


     Ref: FidoNews 2-34 (07-Oct-1985)
     http://195.226.109.55/jhassler/wif/doks/fnews/fido234.txt
     By: Tom Jennings