M
Mikko Tommila
I'm suggesting adding new methods to the J2SE API to retrieve some CPU and
cache related parameters.
The CPU / cache info should be retrieved from java.lang.Runtime similarly
like the number of processors and memory size.
At least the following information would need to be provided:
- number of cache levels (e.g. 1, 2, 3)
- size of cache on each cache level, in bytes (e.g. 256 kB)
- cache line size of each cache level (e.g. 32 bytes)
- associativity of the cache (e.g. 2-way, 4-way, 8-way)
Many mathematical and other memory-intensive algorithms benefit greatly from
knowing these values accurately, for example matrix multiplication
algorithms.
Writing native code for every CPU out there would be very time-consuming. It
would be useful to have this information available via a standard API.
The methods could be added directly to the java.lang.Runtime class, e.g.
int cacheLevels()
int cacheSize(int level)
int cacheLineSize(int level)
int cacheAssociativity(int level)
Alternatively, a separate class could be used for this information (e.g.
java.lang.CPUInfo), to avoid cluttering the java.lang.Runtime class. It
would have the additional benefit that different numbers could be returned
for different CPUs, in case the machine has multiple heterogeneous
processors (although I guess this is very rare). In this case the Runtime
class would have just one new method:
CPUInfo getCPUInfo(int cpu)
And then the methods listed above would be in the CPUInfo class.
Additionally, it would be nice to have methods to specify for processes and
threads, which CPUs they can use (in a multi-CPU machine). This can improve
performance slightly in some cases, as cache thrashing can be minimized. At
least the Win32 API has such functions (SetProcessAffinityMask,
SetThreadAffinityMask). For example, the following methods could be added to
the java.lang.Process and java.lang.Thread classes:
boolean[] getCPUAffinityMask()
void setCPUAffinityMask(boolean[])
The argument type could be int or long but then only 32 or 64 CPUs could be
supported. Or the type could be java.util.BitSet but that would probably be
too weird.
Comments, please?
Mikko Tommila
cache related parameters.
The CPU / cache info should be retrieved from java.lang.Runtime similarly
like the number of processors and memory size.
At least the following information would need to be provided:
- number of cache levels (e.g. 1, 2, 3)
- size of cache on each cache level, in bytes (e.g. 256 kB)
- cache line size of each cache level (e.g. 32 bytes)
- associativity of the cache (e.g. 2-way, 4-way, 8-way)
Many mathematical and other memory-intensive algorithms benefit greatly from
knowing these values accurately, for example matrix multiplication
algorithms.
Writing native code for every CPU out there would be very time-consuming. It
would be useful to have this information available via a standard API.
The methods could be added directly to the java.lang.Runtime class, e.g.
int cacheLevels()
int cacheSize(int level)
int cacheLineSize(int level)
int cacheAssociativity(int level)
Alternatively, a separate class could be used for this information (e.g.
java.lang.CPUInfo), to avoid cluttering the java.lang.Runtime class. It
would have the additional benefit that different numbers could be returned
for different CPUs, in case the machine has multiple heterogeneous
processors (although I guess this is very rare). In this case the Runtime
class would have just one new method:
CPUInfo getCPUInfo(int cpu)
And then the methods listed above would be in the CPUInfo class.
Additionally, it would be nice to have methods to specify for processes and
threads, which CPUs they can use (in a multi-CPU machine). This can improve
performance slightly in some cases, as cache thrashing can be minimized. At
least the Win32 API has such functions (SetProcessAffinityMask,
SetThreadAffinityMask). For example, the following methods could be added to
the java.lang.Process and java.lang.Thread classes:
boolean[] getCPUAffinityMask()
void setCPUAffinityMask(boolean[])
The argument type could be int or long but then only 32 or 64 CPUs could be
supported. Or the type could be java.util.BitSet but that would probably be
too weird.
Comments, please?
Mikko Tommila