since hyperthreading and multi-core CPUs are becoming more and more
common, I think we should put a little more focus on making use of
these features. For that reason, I have made --enable-mp the default
in CVS HEAD and also changed the gimprc preference so that GIMP uses 2
processors. This default doesn't have necessarily have to make it into
the next stable release. The main concern now should be to make sure
that it works at all.

I had a look at the current implementation and also cleaned up the
code a little. We are talking about app/base/pixel-processor.[ch].
There seems to be room for improvement. I'd like to hack on this
myself but my time is limited, so I thought I'd ask if someone else
would like to take this job. So here are some ideas of what could be

- Port the thread code to g_thread functions to make it more portable.

  That would probably be necessary since we don't want to maintain our
  own thread abstraction layer. It would mean that we would have to
  call g_thread_init(). I am not sure if that would introduce any
  noticeable overhead on systems that only use a single CPU. Might be
  worth to investigate that.

- Use GThreadPool instead of continuously starting new threads.

  Creating a thread has a considerable overhead. The current
  implementation continuously creates new threads that finish after
  they have done their job. GLib provides a GThreadPool that would
  probably fit nicely here.

As you can see, this is a rather small task coding-wise. It would
however be good to also do some benchmarking to find out how much
overhead is introduced by using the threaded pixel-processor. We don't
want to make things worse for single-CPU systems.

Any volunteers?

Gimp-developer mailing list

Reply via email to