home *** CD-ROM | disk | FTP | other *** search
- I ran some benchmarks with the Independent JPEG Group's JPEG software,
- version 3. I ran a DOS 8086 version, a DOS386 version, a DOS386 version
- using flat memory addressing, and an OS/2 version (also flat memory).
- The first two were compiled with Intel C, the latter two were compiled
- with ports of gcc 2.1). This version of JPEG uses no floating point math.
-
- I used four JPEG images that had come over USENET in the past few weeks.
- They were magellan.jpg, solarmax.jpg, titan2.jpg, and blacktip.jpg.
-
- My machine is a 386/33 with 32k cache and 8MB of RAM.
-
- I ran DOS and DOS386 trials under DOS 5.0 with a 1MB ram disk. In no
- trial did swapping occur (the DOS386 version will write temporary files
- to disk if it runs out of RAM). This program does very little disk i/o
- so writes to the ram disk made a minimal, if not negligible, impact on
- the final times.
-
- I ran the OS/2 trials with nothing else running except OS/2 itself.
- I freed up as much memory as possible (I wanted to compare CPU time)
- by removing DOS support and booting to the command line, not the WPS.
- As with the DOS versions, I ran everything off a 1MB ram disk. No
- swapping occured during any trial.
-
- First I converted each of these images to GIF format using djpeg -G.
- I ran each image and binary three times and averaged the times (all
- trials were within 0.5 seconds).
-
- The average times and time ratios, with OS/2 set at 100%, follow:
-
- +-----------------------------------------------------------------------+
- | djpeg \ OS | OS/2 (flat) | DOS386 flat | DOS 386 | DOS |
- |--------------+-------------+-------------+-------------+--------------|
- | magellan.jpg | 32.9s 100% | 33.3s 101% | 39.5s 120% | 59.7s 181% |
- | solarmax.jpg | 28.3s 100% | 28.4s 100% | 35.0s 124% | 52.7s 186% |
- | titan2.jpg | 33.0s 100% | 33.2s 101% | 41.2s 125% | 61.6s 187% |
- | blacktip.jpg | 66.0s 100% | 65.8s 100% | 78.0s 118% | 117.8s 178% |
- |--------------+-------------+-------------+-------------+--------------|
- | average | 100% | 100% | 122% | 183% |
- +-----------------------------------------------------------------------+
-
- I then converted the GIFs back to JPEGs using the default settings
- on cjpeg (i.e. no switches). Same comments apply as with djpeg.
-
- +-----------------------------------------------------------------------+
- | cjpeg \ OS | OS/2 (flat) | DOS386 flat | DOS 386 | DOS |
- |--------------+-------------+-------------+-------------+--------------|
- | magellan.jpg | 26.4s 100% | 26.7s 101% | 28.5s 108% | 63.6s 241% |
- | solarmax.jpg | 21.3s 100% | 21.3s 100% | 23.1s 108% | 51.2s 240% |
- | titan2.jpg | 25.2s 100% | 25.3s 100% | 27.4s 109% | 60.7s 241% |
- | blacktip.jpg | 54.2s 100% | 54.4s 100% | 58.5s 108% | 131.4s 242% |
- |--------------+-------------+-------------+-------------+--------------|
- | average | 100% | 100% | 108% | 241% |
- +-----------------------------------------------------------------------+
-
- I guess a flat address space DOES make a difference.
-
- (yes, I know the average percent should be weighted according to
- the amount of time each file took. I didn't feel like complicating
- things that much.)
-
- When I ran the trials off my hard disk with a cache set up, all times
- were about 5% slower. This will obviously vary with your hardware,
- but it means that a segmented addressing scheme can cause more of a
- performance hit than accessing the input and output files on hard disk
- through a cache.
- --
- April 29, 1992
- John H. Kim
- jokim@jarthur.claremont.edu