Suggestion for new features

[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

 

[Roedy Green]

Comments, please?

I have written code that merely determines CPU type. See
http://mindprod.com/products.html#SNIFF

It is hairy stuff, especially for the older cpus. You would likely
have to perform timing experiments to discover cache sizes. Only BIOS
tends to know such things. Other programs running will screw up your
experiments.

You might just throw up your hands and ask the user to provide a
properties file. He may have the information from other sources. He
further could experiment with different tweaking values to see which
actually gave the best results (even if they were not strictly true.)

You might also run a separate utility written in C that attempts to
discover cache sizes. This lets people on any platform use your code,
even if there is no corresponding discovery utility. Your utility then
has interest outside the Java community.

See http://mindprod.com/jgloss/tweakable.html

 

[Mikko Tommila]

At least Sun's Java SDK 1.4.2 is only supported on Pentium processors or
later, so determining cache sizes with the cpuid instruction shouldn't be
that a big problem. Although, I don't know if other processor families than
x86 have capabilities to easily determine cache sizes (SPARC, PA-RISC,
Alpha, PowerPC, etc.).

What I'm doing currently is exactly what you suggested: specifying the cache
sizes in a properties file. However I'm interested in determining the cache
sizes via a standard Java API, without having to write native code or use a
separate utility. I submitted a RFE to Sun for this feature addition but
they first wanted me to post a message to a newsgroup to get some comments
from other Java developers.

Mikko Tommila

 

[Chris Uppal]

Alternatively, a separate class could be used for this information
(e.g. java.lang.CPUInfo), to avoid cluttering the java.lang.Runtime
class.

That would seem a better solution. In the first place it's easy for a JVM that
cannot determine the info to return null. In the second it becomes possible
for subclasses of CPUInfo to be able to provide info that is specific to a
particular processor family. E.g. you wouldn't want CPUInfo.supportsMMX() as a
method of a generic CPUInfo class (especially not one defined by Sun ;-).

-- chris

 

[pete kirkham]

Alternatively, a separate class could be used for this information (e.g.
java.lang.CPUInfo), to avoid cluttering the java.lang.Runtime class.

I'd have though that System.getProperty("cpu.cache.size") would be the
place for it.


Pete