[linux-mm-cc] Testing the effect of CompCache on Image processing
baghdadi
baghdadi13 at gmail.com
Sat Jul 12 05:56:09 EDT 2008
Hello,
I performed some tests on using compcache to enhance image processing
applications, tests show a little performance enhancement, which encourages
me to continue and more tests :
--------------------------------------------------------------------------------------------------------------------
Libjpeg Tests
Image processing Performance Improvements using CompCache
Author : Baghdadi Riyadh,
==========================================================
[Introduction]
--------------
System resources have been for a long time the most important obstacle for
image processing, not only because memories are not large enough to hold
huge images, but alos becuase of the gap in speed between memories and CPUs;
Image Processing applications are known to be intensive-memory and
intensive-CPU consummers, and this lead us to think about reducing the gap
between CPU speed and memory speed,
One novel solution is the usage of memory compression, to enlarge memory
capacities, and at the same time reduce I/O and thus give the CPU the
possibility to achive more in less time; (no need for waiting).
In the next test we focus on comparing between two systems, one with
CompCache activated and the other with CompCache disactivated; Our goal is
to show how much the usage of compcache will nhance image processing
performance.
2. Environment:
---------------
* Hardware:
For tests we used a Desktop Computer with
CPU : Intel E2180 2.00GHz CPU, (Core2 Duo)
RAM : 256MB,
Swap : 1GB,
Disk : 250GB SATAII disk (7200rpm);
* Software:
Linux Distro : Ubuntu Hardy Heron (8.04)
kernel version: 2.6.26-rc8
CompCache patch:
patch_compcache_with_notify_support_2.6.26-rc8;
3. Tests :
----------
In this test we use Libjpeg utilities for image processing (we focus on
convertion images from JPEG to BMP), to evalute the effect of using
compcache on this type of applications;
The Independent JPEG Group's JPEG library (Libjpeg) [1] is a library for
handling JPEG files, it contains tools that convert from JPEG format to
other formats (cjpeg & djpeg tools);
we use djpeg tool to convert a JPEG 5785 x 8429 DirectClass 8-bit file, of
size 42.3974mb, from JPEG format to BMP;
To put more pressur on memoy we launch many instances (many processes) of
djpeg at the same time, and this cause an intensive demand for memory,
memory gets full quickly and the system start using swap partition (in our
case it uses the compcache).
djpeg -bmp -outfile test.out.bmp test.jpg &
we launch 2 instances of djpeg;
* Results with compcache notactivated :
Instance | Reel time | CPU time in sec | System CPU time | faults
------------------------------------------------------------------
instance1| 21.45 | 6.89 | 0.53 | 1819
-----------------------------------------------------------------
Instance2| 21.50 | 7.75 | 0.63 | 2099
-----------------------------------------------------------------
Average | 21.47 | 7.32 | 0.58 | 1959
-----------------------------------------------------------------
* when compcache was activated wee have these results :
Instance | Reel time | CPU time in sec | System CPU time | faults
------------------------------------------------------------------
instance1| 20.23 | 6.72 | 1.00 | 2426
-----------------------------------------------------------------
Instance2| 20.23 | 6.77 | 0.86 | 2461
-----------------------------------------------------------------
Average | 20.23 | 6.81 | 1.71 | 3522
-----------------------------------------------------------------
this test shows a little improvements when using compcache;
-----------------------------------------------------------------
The next test focus on how much compcache can make the system able to run
more processes then an other ordinary system; we launch here (exactly as
previous tests) many instances of djpeg and see if all processes success to
run until they finish their job;
* compcache is not activated, we load 8 instances of djpeg at the same time,
to convert the test file from jpeg to bmp;
This test shows that a system with 220MB of RAM fails to run 8 instances of
djpeg at the same time, after a short time (28 sec) the memory becomes full
and the OOM killer stops the first two instances of djpeg to free some
memory,
It is the job of the Linux "oom killer" to sacrifice one or more processes
in order to free up memory for the system when all else fails;
* compcache is now activated, we repeat the same test;
By Using compcache the system could run successfully all the 8 processes,
and no process were killed; This shows clearly that compcache increased the
capacity of the system by 25%, making it able to run up to 8 instances of
djpeg instead of 6 instances.
4.Using the test script :
------------------------
USAGE : decompress_jpeg_file <FILE> <N>
where N is the number of times for decompressing <FILE> to a bmp file,
results are thrown to /dev/null, and results of the test are sent to a log
file with the same name with the test file :$FILE.log
-results are ready to be plotted;
- use a jpeg image of very big size (i used one with 42mb)
5. Conclusion :
---------------
Using CompCache we could speed up JPEG conversion and enhance the system
maximum cappacity for running processes by 25% and thus the system could run
25% more processes whereas without compcache the OOM killer was called;
6.References :
--------------
[1]. The Independent JPEG Group's JPEG library for JPEG manipulation
http://www.ijg.org/
--------------------------------------------------------------------------------------------------------------------------------------------
the script used for test is attached, and also a text copy for this message;
Next step is to get better performance numbers, I'll try also the next time
to record the CompCache behaviour so that we can better see what's going on,
Regards, Baghdadi Riyadh,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/linux-mm-cc/attachments/20080712/e4afd2e6/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decompress_jpeg_file
Type: application/octet-stream
Size: 1520 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/linux-mm-cc/attachments/20080712/e4afd2e6/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LibJPEG tests
Type: application/octet-stream
Size: 5381 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/linux-mm-cc/attachments/20080712/e4afd2e6/attachment-0001.obj
More information about the linux-mm-cc
mailing list