how can program determine: # of cores, execution core, core cps

maxreason · 12-13-2012, 12:36 AM

My application needs to determine the following information at runtime. Except for item #1 (which should not change during execution), my application needs to determine these values regularly (not just once).

#1: number of CPU cores.
#2: current speed of core #n.
#3: which core #n is executing this code.

My application is C and assembly-language, so a solution available in either C or assembly-language is fine. The code to determine #2 and #3 must be fast and efficient, because it executes during crucial routines. To read /proc/cpuinfo and parse the contents is much too slow (and I'm not sure the contents are always accurate and up-to-date at any given instant).

NOTE: My application already executes and saves the machine instruction that contains the current clock-cycle, and computes elapsed times in clock cycles based on these counts. This information is also useful, but does not let my application compute elapsed time in nanoseconds (or picoseconds) without a way to determine the frequency (in cps) each core (or at least the current core) is running at each instant.

Thanks!

PS: Do questions like this belong in this forum, or in "software"?

jv2112 · 12-13-2012, 04:47 AM

cat /proc/cpuinfo --- #1.

maxreason · 12-14-2012, 02:05 AM

Thanks, but that approach is too slow for my purposes. I guess you only read the title of my post, as my original message states /proc/cpuinfo is not fast enough (and may not always produce current information for variable information like cpu frequency).

Quote:

Originally Posted by jv2112

cat /proc/cpuinfo --- #1.

sundialsvcs · 12-14-2012, 05:18 AM

That's the only option that you've got, and no, it might not produce up-to-the-bleeem info for real-time situations.

I frankly don't think that your program's "needs" are realistically obtainable. I think you're going to have to find a different algorithm ... not "to obtain the data you're asking for," but rather, "to do without it."

maxreason · 12-14-2012, 04:32 PM

Quote:

Originally Posted by sundialsvcs

That's the only option that you've got, and no, it might not produce up-to-the-bleeem info for real-time situations.

I frankly don't think that your program's "needs" are realistically obtainable. I think you're going to have to find a different algorithm ... not "to obtain the data you're asking for," but rather, "to do without it."

You are certain? So you are saying there is no programmatic way to access each item of information in /proc/cpuinfo separately? I suppose I can capture and save the cpu-clock-counter AND a time-of-day value each time the function is called, then compute it myself. That would at least get more-and-more accurate as long as the core frequency didn't change recently, and if the core frequency did change since last time, that should at least be detectable (though the core frequency would be a blend of "before the change" and "current frequency".

As far as you know, does your comment also apply to item #3? Is there no way for code to determine which core it is currently executing on?

Also, is #-of-cores stated within the cpuid info somewhere? Otherwise, how is this determined?

syg00 · 12-14-2012, 06:40 PM

The data are all available in kernel-space. It is exposed in various ways - /proc/ being one of them. Some of it is not exposed at all.
If the current (user-space) data are insufficient for your needs, you'll need to write your own kernel module - then you can present however you want.