Dear all,
I can get the number of threads by call("ij.Prefs.getThreads")) in macro. However, I can’t get available processors by cores = call("java.lang.Runtime.getRuntime().availableProcessors()"); Is this wrong ? Best regards, Hidenao Yamada -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Hidenao,
the macro 'call' statement only works for a single method evaluation. For Runtime.getRuntime().availableProcessors() you need Java, Javascript or another language that can access Java objects and do operations with them. You can do it with an 'eval' statement from a macro, however: cores=eval("js", "Runtime.getRuntime().availableProcessors()"); n=parseInt(cores); print(n); Note that 'eval' returns a string. If you want to do any calculations with it you need 'parseInt' to convert it into a number. Michael ________________________________________________________________ On 25.05.20 13:08, Yamada Hidenao wrote: > Dear all, > > I can get the number of threads by call("ij.Prefs.getThreads")) in macro. > However, I can’t get available processors by > cores = call("java.lang.Runtime.getRuntime().availableProcessors()"); > Is this wrong ? > > Best regards, > Hidenao Yamada > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Nice Michael,
but interestingly, the result is not the number of physical cores but that of the number of possible threads, i.e. quite often the number of physical cores times two. This value however, can also be access by: n = call( "ij.util.ThreadUtil.getNbCpus" ); print(n); Not sure if there is a way to get the number of physical cores. Best Herbie :::::::::::::::::::::::::::::::::::::::::::: Am 25.05.20 um 14:39 schrieb Michael Schmid: > cores=eval("js", "Runtime.getRuntime().availableProcessors()"); > n=parseInt(cores); > print(n); -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Herbie,
yes, with hyperthreading (Intel's name for simultaneous multithreading) Runtime.getRuntime().availableProcessors() reports *more* than the number of physical cores. I think that this makes sense because typically there is still some performance gain when parallelizing code into as many threads as there are simultaneous threads (with hyperthreading, twice the number of physical CPU cores). On linux, you can get more information from the /proc/cpuinfo file; on Windows you may try wmic CPU Get NumberOfCores,NumberOfLogicalProcessors I did not find a way to determine the number of physical processors in an way that does not depend on the operating system. Michael ________________________________________________________________ On 25.05.20 15:22, Herbie wrote: > Nice Michael, > > but interestingly, the result is not the number of physical cores but > that of the number of possible threads, i.e. quite often the number of > physical cores times two. > > This value however, can also be access by: > > n = call( "ij.util.ThreadUtil.getNbCpus" ); > print(n); > > Not sure if there is a way to get the number of physical cores. > > Best > > Herbie > > :::::::::::::::::::::::::::::::::::::::::::: > Am 25.05.20 um 14:39 schrieb Michael Schmid: >> cores=eval("js", "Runtime.getRuntime().availableProcessors()"); >> n=parseInt(cores); >> print(n); -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Guys,
Thank you two for this issue. Now I can access the number of available processor in macro, and set the threads as follows call("ij.Prefs.setThreads", nThreads); Best regards, Hidenao Yamada -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
good day Hidenao Yamada,
AFAIK the IJ-macro way to *set* the number of possible threads is: run("Memory & Threads...", "maximum=5000 parallel=8 run"); where "maximum" defines the RAM-size for ImageJ and "parallel" the number of threads. Regards Herbie :::::::::::::::::::::::::::::::::::::::::::: Am 25.05.20 um 21:42 schrieb Yamada Hidenao: > Hi Guys, > > Thank you two for this issue. > Now I can access the number of available processor in macro, and set the threads as follows > > call("ij.Prefs.setThreads", nThreads); > > Best regards, > Hidenao Yamada > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Herbie, Hidenao,
> run("Memory & Threads...", "maximum=5000 parallel=8 run"); > call("ij.Prefs.setThreads", nThreads); both works! The 'call' method leaves the other settings of the Edit>Options>Memory&Threads untouched. In the 'run' method, one could omit the "maximum=5000" to leave the maximum RAM unchanged, but I am not aware of any possibility to leave the checkboxes untouched in a 'run' command untouched. (Here, the checkboxes are "Keep multiple undo buffers", "Run garbage collector on status bar click") @Hidenao: Just out of curiosity, since I did much of the parallelization: Is there a specific reason for changing the number parallel threads? Did you find a performance improvement by changing this setting from the default? The RankFilters (mean, minimum, maximum, median, remove outliers) use fewer threads for small images to avoid the extra overhead of multithreading exceeding the gain in processing speed by parallelization, and since ImageJ 1.52r, the same should be true for Gaussian Blur. Of course, the balance between parallelization gain and extra overhead is machine specific, so the built-in code will never find the perfect setting. Best wishes, Michael -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Michael,
>Did you find a performance improvement by changing this setting from the default? Yes, I found 64-theading (AMD Ryzen ThreadRipper 3970x) cause the overhead of multithreading when I running my own plugin-filter. So I need to limit the number parallel threads down to only 8 threads in my case. Best regards, Hidenao Yamada -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Free forum by Nabble | Edit this page |