call getRuntime().availableProcessors() in macro

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

call getRuntime().availableProcessors() in macro

Yamada Hidenao
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
Reply | Threaded
Open this post in threaded view
|

Re: call getRuntime().availableProcessors() in macro

Michael Schmid
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
Reply | Threaded
Open this post in threaded view
|

Re: call getRuntime().availableProcessors() in macro

Herbie
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
Reply | Threaded
Open this post in threaded view
|

Re: call getRuntime().availableProcessors() in macro

Michael Schmid
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
Reply | Threaded
Open this post in threaded view
|

Re: call getRuntime().availableProcessors() in macro

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
Reply | Threaded
Open this post in threaded view
|

Re: call getRuntime().availableProcessors() in macro

Herbie
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
Reply | Threaded
Open this post in threaded view
|

Re: call getRuntime().availableProcessors() in macro

Michael Schmid
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
Reply | Threaded
Open this post in threaded view
|

Re: call getRuntime().availableProcessors() in macro

Yamada Hidenao
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