I adapted configure.ac and properly compiled it. I am sure that my configure.ac is wrong (flags placed in wrong places and probably not proper behaviour when one does not have openmp lid-devel installed), so, somebedy please fix it. It at least compiled here in my machine.

I tested it and it worked ok, but I have no idea how to benchmark it. I removed the logging code that was windows-only.

here is my version of the patch, I hope it helps.

On Tue, Nov 18, 2008 at 2:45 PM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
MenTaLguY wrote:
> This looks reasonable for the most part.  As long as you're sticking to
> manipulating data in the buffers and not manipulating the object model
> from the OMP threads, you shouldn't hit any of the threading problems
> that I would ordinarily be concerned about.

Exactly, that's the idea.

> I'm not sure about having a minimum of 8 threads, though

It's not a minimum, it's a maximum :) min(8,x) returns the minimum of 8
and x, so 8 is the largest value it will return.

> -- on a system
> with many less CPUs than that you're just losing by adding more threads.
> For a wholly CPU-bound task like this, the number of threads to use
> should be the number of CPUs.

I agree completely, that's why I tried using the default of
omp_get_num_procs(). As this doesn't work properly on my system (as far
as I can tell) I recommend setting it through the preferences though.
However, hopefully this will work better with future versions of GCC
(perhaps it will even work on Linux, as GCC has had OpenMP support for a
bit longer there).

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Inkscape-devel mailing list