[Image-SIG] PIL speed in single/multi threaded apps

[kevin_cazabon at hotmail.com]

Actually, those results match what I saw pretty well.  Thanks for the
comparison!

With the "standard" PIL, one thread was fastest, and there was a slight
slowdown with additional threads (805, 758, 755, 755).

With the "modified" PIL, all tests were faster than the "standard" library,
three threads was the fastest, two and four were slightly less than three.
(why three was fastest I don't know... it's only a dual processor machine!)

FYI, all the tests I ran were the average of 3 runs, and the 3 runs were
pretty consistent in all cases.  I'm going to repeat the tests with the
standard/modified library on a single-CPU machine to see if there's any
benefit to "normal" PIL users too.  I'm hoping that the 14% improvement I
saw in the single-thread test will hold true.

Kevin.


----- Original Message ----- 
From: "Rob Managan" <managan at llnl.gov>
To: <image-sig at python.org>
Sent: Thursday, August 07, 2003 9:43 AM
Subject: Re: [Image-SIG] PIL speed in single/multi threaded apps


> >Hi everyone;
> >
> >I've been doing a lot of multi-threaded GUI apps that use PIL lately, and
> >was looking for ways to improve performance, especially when rapidly
> >updating images being displayed on the screen after color changes.
> >
> >I decided to try to enable true multi-threading in the PIL core library
to
> >see what effects it had on performance.  Basically, although Python has
> >multi-threading, unless an extension library explicitly "allows" other
> >threads to run while it's busy doing intensive tasks, only one thread
runs
> >at a time.  So, even on a multi-CPU computer (or a Pentium 4 with
> >hyperthreading), you don't really get the benefit of true
multi-threading.
> >
> >So, I modified the geometry.c source file to add "Py_BEGIN_ALLOW_THREADS"
> >and "Py_END_ALLOW_THREADS" blocks around the intensive tasks within the
> >resize mechanisms to see what would happen.  I then wrote a test script
that
> >used multiple threads to simultaneously resize images, and I counted how
> >many times I could resize an image in 30 seconds.  (see the script at the
> >end for details).
> >
> >Here are the results, they're very interesting!  These were done with the
> >"standard" PIL 1.1.4 binary and my modified version, both on a dual-CPU
> >Athlon MP-1200 computer with 512MB RAM.
> >
> >1 Thread:  original:  805 resizes (max 60% CPU usage)
> >1 Thread:  modified:  920 resizes (max 75% CPU usage)
> >
> >2 Threads: original:  758 resizes (max 60% CPU usage)
> >2 Threads: modified:  1185 resizes (max 100% CPU usage)
> >
> >3 Threads:  original: 755 resizes (max 60% CPU usage)
> >3 Threads:  modified:  1205 resizes (max 100% CPU usage)
> >
> >4 Threads:  original:  755 resizes (max 60% CPU usage)
> >4 Threads:  modified:  1194 resizes (max 100% CPU usage)
> >
>
> The results for the standard PIL are not universal.
>
> On a Dual 450 Mhx G4 running OSX 10.2.6 I get
>
> 1 thread : 469
> 2 threads: 466
> 3 threads: 453
>
> So I get a slight slow down with multiple threads.
> -- 
> *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*-
> Rob Managan               email managan at llnl.gov
> LLNL                      phone: 925-423-0903
> P.O. Box 808, L-095       FAX:   925-422-3389
> Livermore, CA  94551-0808
>
>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>