<div dir="ltr"><div class="gmail_extra">Hi all,<br><br><div class="gmail_quote">On Fri, Dec 6, 2013 at 3:29 AM, Jean-Yves Tinevez <span dir="ltr"><<a href="mailto:jean-yves.tinevez@pasteur.fr" target="_blank">jean-yves.tinevez@pasteur.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all<br>
<br>Each frame of a movie can be processed concurrently: I generate a task for each frame, and can feed this task to any interface we are discussing right now. For this, I do not need to know how many threads are allocated to the service: it will decide how to process the tasks I generated.<br>

<br>
By there are many algorithms in imglib2 that can process a single image in a multithreaded way, by splitting it into small pieces. For instance, you can compute the Gauss convolution on 2 threads, and it will split the source image in 2. For this, the algorithm needs to have some info on the "multitasking resources" available right? If you have 24 workers, and that each worker receives one frame to segment, the segmenter needs to know it is unwise to split the source image over several extra workers. No?<br>

<br>
How is this achieved in real world applications?<br></blockquote><div>I think we're in a lucky sweet spot where the size of our data is big and the number of processors is small. I think you want to amortize the cost of enqueueing the work, thread signaling and thread context switching over a pretty big chunk of data - and that's operating-system and processor-specific in my experience, so it's best to benchmark. If I remember correctly, as an example, Ilastik 0.5 breaks its images into chunks of 10K pixels and runs perhaps 100 filters on each, plus a random-forest evaluation. In that case, the large-grain operation makes the optimization question pretty moot since the computation is so expensive (and doing the chunking at the top level might be a good design choice).</div>
<div><br></div><div>It would be kind of cool if the service could give you an idea of the cost of running one future and of the size of the thread pool. This is notoriously difficult to measure, but a rough cut might be to find the minimum time from enqueing a future until its execution and multiply that by 2. If you knew the cost of running your algorithm on N pixels, you could figure out how to slice it. It would also be kind of cool if your imglib data container (or some helper class that encapsulated this expertise) could give you a collection of iterators appropriate for the cost of your operation and the thread service it would be run on.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
best<br>
jy<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
--<br>
Please avoid top-posting, and please make sure to reply-to-all!<br>
<br>
Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel" target="_blank">http://groups.google.com/group/fiji-devel</a><br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups "Fiji-devel" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:fiji-devel%2Bunsubscribe@googlegroups.com">fiji-devel+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank">https://groups.google.com/groups/opt_out</a>.<br>
</font></span></blockquote></div><br></div></div>