
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi JY,<div><br></div><div>exactly. That's what I meant when I wrote</div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>One thing that I'm missing with the ExecutorService is getting an estimate of many worker threads there are. This is useful to guide a heuristic of how many tasks a problem should be split.</div><div>We now just use <span style="font-family: Monaco; font-size: 11px; ">Runtime.getRuntime().availableProcessors()</span> for that purpose, but it would be nice to have something better. </div></div></blockquote></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Maybe I wasn't being clear enough.</div><div><br></div><div>Usually (also in the Gauss) I split the task into number of subtasks that is a multiple of the number available workers.</div><div>The reasoning behind this is that the workers might finish a task at different speeds. This can be caused by other stuff (even outside the JVM) using resources. Or it can be caused by simply the tasks being more or less demanding. For instant in spot detection, probably a frame that is completely black will finish a bit earlier than a normal frame.</div><div>So if there are N workers and N tasks, N-1 workers are waiting for the slowest task to finish. Splitting into more tasks, once a worker is finished, it will just pick the next unprocessed task.</div><div>With very many tasks, I guess there is a point where the task management overhead is slowing it down, so a reasonable heuristic is required (to be defined:-)</div><div><br></div><div>best regards,</div><div>Tobias</div></div></div><div><br><div><div>On Dec 6, 2013, at 9:29 AM, Jean-Yves Tinevez <<a href="mailto:jean-yves.tinevez@pasteur.fr">jean-yves.tinevez@pasteur.fr</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi all<br><br>Ok thank you very much this is inspiring. <br><br>I see the discussion is still going on and that we (the team) did not reach a definitive conclusion yet. <br><br>I just want to add a question item to the discussion: <br>Sometimes you need to have information on the multithreading configuration that has been set upstream.<br><br>For instance, taking the example of TrackMate spot detection:<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>best<br>jy</blockquote></div><br></div></body></html>