akJFIF/PPC "LoadPic" Benchmark ============================== From Aminet:pix/misc 1) ACBIG.jpg 838120 2991x 477 24 Bit 2) Aldiana1.jpg 97683 1467x 990 24 Bit 3) browsers.jpg 291994 1280x1024 24 Bit 4) Circle.jpg 26166 640x 512 24 Bit 5) Landschaft.jpg 82131 640x 512 24 Bit 6) macros01.jpg 74277 640x 480 24 Bit From Aminet:pix/views 7) gw1.jpg 256423 600x 948 24 Bit 8) oxford2.jpg 406570 735x 696 24 Bit Test 1: Undithered Output ======================= Settings: * Dithering: None, 24 Bit Data (V43) * Fast Integer * Fancy Upsampling * Slow (well) Color Quantizing * 68k: progress bar on Times [sec]: 040-25 060-50 040-25/ 060-50/ PPC604-200 PPC604-200 1) 22.1514 7.6703 2.8813 2.1592 2) 17.4288 6.7460 2.1892 1.5921 3) 13.869 4.9217 1.9661 1.3208 4) 3.4878 1.2855 0.5339 0.3769 5) 4.262 1.5759 0.6092 0.4514 6) 3.9037 1.4662 0.5757 0.4194 7) 7.9957 2.8218 1.0762 0.8056 8) 7.1453 2.6251 2.0123 1.1333 ** DTM_WRITEPIXELARRAY has to be performed by the 68k always (ARK) Test 2: Dithered Output ======================= Settings: * Dithering: Floyd-Steinberg * Fast Integer * Fancy Upsampling * Slow (well) Color Quantizing * 68k: progress bar on Times [sec]: 040-25 060-50 040-25/ 060-50/ PPC604-200 PPC604-200 1) 41.8415 14.4938 6.3932 3.8398 2) 36.742 13.4708 5.6899 3.2168 3) 32.1639 11.2803 5.1569 2.8556 4) 9.281 3.2705 1.5033 0.8701 5) 10.8904 3.7887 1.6549 1.0228 6) 8.7364 3.1530 1.4571 0.8581 7) 15.2976 5.3497 2.569 1.4903 8) 7.1126 2.6095 2.0037 1.1258 ** WritePixelLine8() has to be performed by the 68k always (ARK) ================================================================================= Notes: * boards: 040-25 board was a CyberStormPPC run in 60ns mode plus FastAvec, running under OS 3.1, using picture.datatype V43.762 (CGfx) with ppc.library 44.20. 52 MB RAM available (20 MB conventional, 32 MB on the CS-PPC). Plugged into an A4000. Images loaded from an average-speed IDE drive. 060-50 board was a CyberStormPPC run in 60ns mode plus FastAvec, running under OS3.1, using picture.datatype V43.762 (CGfx) with ppc.library 45.20. 78 MB RAM available (14MB conventional, 64 MB on the CS-PPC). Plugged into an A4000. Images loaded from an average-speed SCSI drive. (Loading from RAM: does not make a big difference.) * why is the 060/PPC combo faster than the 040/PPC combo ? Perhaps because the 060 can process the I/O requests (aka OS calls) faster than the 040. Small differences may also be caused by using different hard drives - to minimize this, one could put the files into RAM: for example. But this wouldn't deliver real-life results. * the "larger" the images, the more the PPC can help increasing decoding speed; however, file size, image size and compression ratio of the JPEGs will influence the benchmark results, i.e. a small file with a high compression ratio may be more suitable for the PPC than a large file with only low compression (while keeping the image dimensions). Larger images, on the other hand may deliver better results than smaller images (keeping the compression factor constant). This benchmark does not check/proove this, we just tried "average" (accidental) images. * PPC loaders actually *can* be faster than the measured results may indicate. Problem is, that datatypes have to deal with bitmaps, which slows everything down. * "PicBench" is a program written by Jan Uerpmann It measures the execution time of image loading via datatypes.library, using NewDTObjectA() Options were : PicBench [FileName] NUM 20 QUIET * Feel free to send us your own performance results, e.g. for the Blizzard PPC boards and/or the 150/180/233 MHz 603/046 PPCs. ================================================================================= Send comments to: Andreas Kleinert (Andreas_Kleinert@t-online.de) (Author of akJFIF.datatype) Jan Uerpmann (J.Uerpmann@tu-bs.de) (Author of PicBench)