That all depends how it allocates tile memory. If it mallocs tile by tile
then they could be anywhere, including separate pages. If it mallocs a
large block (system page size) and then divides it into tiles itself then
those tiles are *likely* to reside on the same page - which is what matters
mo
Allocating batches of tiles to each thread and dynamically re-allocating
them should a thread finish early will complicate the code and will only
provide very marginal speed improvement. (Each thread will have to obtain a
lock on a work queue to get its next tile either way but the proposed scheme
ignore as I have not had the
opportunity of yet to review the code.
-Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sven
Neumann
Sent: Monday, 21 February 2005 11:01 AM
To: David Bonnell
Cc: Gimp-developer@lists.xcf.berkeley.edu
Subject: Re: [Gimp
It sounds like the granularity of parallelism is too fine. That is, each
"task" is too short and the overhead of task dispatching (your task queue
processing, the kernels thread context switching, any IPC required, etc.) is
longer then the duration of a single task.
I hit the same problem a decad
On Fri, 14 Sep 2001, NunoACHenriques wrote:
> I run the gimp-script-fu-server (Gimp 1.2.1 for Linux) and I have a C
> program that opens a TCP socket to it (port 10008). I get connected but when
> I send a simple command like "(set! x)" the server shutdown the socket?!...
> :-( What am I do
