Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

getting system info in c++ linux

88 views
Skip to first unread message

kushal bhattacharya

unread,
Aug 27, 2017, 9:25:29 AM8/27/17
to
Hi,
Is there any api function in c or c++ which can fetch cpu info showing system statistics individually if possible like cpu usage ,total ram ,free ram number of cpus etc?
Thanks

Markus Raab

unread,
Aug 27, 2017, 3:52:48 PM8/27/17
to
Hi,
There is no portable way. On Linux, for RAM and CPUs:

long sysconf(int name), with name as:


- _SC_PHYS_PAGES
The number of pages of physical memory. Note that it is
possible for the product of this value and the value of _SC_PAGESIZE to
overflow.

- _SC_AVPHYS_PAGES
The number of currently available pages of physical memory.

- _SC_NPROCESSORS_CONF
The number of processors configured.

- _SC_NPROCESSORS_ONLN
The number of processors currently online (available)

should help.

For more stats you might need to parse /proc/loadavg and similar..

best regards,

Gareth Owen

unread,
Aug 27, 2017, 4:12:17 PM8/27/17
to
It's often easiest to read and parse the text output provided through
the /proc filesystem

/proc/meminfo will give you the RAM
/proc/cpuinfo will tell you about CPU numbers/speed etc
/proc/loadavg will give global system load

Per CPU stats are a bit trickier, but generally require reading
/proc/stat a few times

Chris M. Thomasson

unread,
Aug 27, 2017, 4:52:32 PM8/27/17
to
You can get the number of cpus:

http://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency

It is very basic information, and not going to help wrt creating a
topographic map of NUMA nodes. We basically need some OS specific
information here.

Jorgen Grahn

unread,
Aug 28, 2017, 10:24:42 AM8/28/17
to
(See replies from others.)

What do you want it for? It is IME usually not helpful for a program
to read that information and take actions based on it. And displaying
it to the user ... the user probably has a way to read it already, if
she's interested.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

red floyd

unread,
Aug 28, 2017, 12:26:13 PM8/28/17
to
On 8/27/2017 6:25 AM, kushal bhattacharya wrote:
Again, this is system specific, and it doesn't matter if it's C, C++,
Pascal, Ada, Java, or whatever...

You need to ask in a newsgroup dedicated to your OS of choice.


kushal bhattacharya

unread,
Aug 29, 2017, 2:15:09 AM8/29/17
to
thanks but its the api function of c or c++ if present that i am interested in mainly.Parsing it from the system utility output would be a bit complex i think.So,if there is any api function of it in C or C++ that would be really good

Ian Collins

unread,
Aug 29, 2017, 2:19:49 AM8/29/17
to
Please wrap!

No, there aren't any portable APIs. Reading and parsing files in /proc
is our best bet on Linux.

--
Ian

Reinhardt Behm

unread,
Aug 29, 2017, 2:55:20 AM8/29/17
to
Or simply look at the source of top. This program shows all you are looking
for. There you can find out how it has been done for years and it probably
uses /proc.

--
Reinhardt

kushal bhattacharya

unread,
Aug 29, 2017, 6:28:54 AM8/29/17
to
thanks and sorry i didnt understand about the wrappping part

Chris M. Thomasson

unread,
Aug 30, 2017, 4:55:56 PM8/30/17
to
Just brainstorming here, fwiw:

Since C++ has std::thread::hardware_concurrency, well, what about
thinking of creating something like:

std::thread::hardware_concurrency_tree

That returns information in the form of a tree structure that describes,
or encodes the way the system actually arranges the number of cpu's
returned from std::thread::hardware_concurrency? You basically get a
root node that has all of the NUMA nodes in the "system".

So, crudely and quickly, for instance, if there are 2 NUMA nodes, it
gives you a linked list NL with two items, each of which are a NUMA
node. Each node in NL represents a CPU item; each CPU item has multiple
nodes representing its virtual cores VCPU; each VCPU has its
"hyper-threading" cores on each VCPU; and down to per-thread...

Afaict, this is zooming down from the high level at 2 NUMA nodes, into
the per-thread leaves. The "fractal" zoom ends in a tree where
terminating leaves are thread nodes. I guess we can go one level deeper
and add n fibers to each per-thread leaf, transform the thread leaf into
a fiber leaf, in a sense. Humm... The overall layout for NUMA down to
thread and/or fiber has always sounded sort of "fractal in nature" to me.

My crude rational for a possible proposal would be:

We have std::thread::hardware_concurrency. This is good information,
however its not very useful wrt mapping out the system. An additional
and optional function just might be in order:

std::thread::hardware_concurrency_tree, or something.

That gives deeper information on how the result of
std::thread::hardware_concurrency is arranged.

Also, what about:

std::thread::hardware_memory_tree

that gives various cache line sizes and how they are padded, and
arranged in the NUMA tree.

Combine this with optional thread affinity masking, and a program in C
and/or C++ can combine this with standard atomics to create highly
scaleable, low level, systems.

Imvvvho, something like:

std::thread::hardware_concurrency_tree

is probably "low-level enough" for C or C++ wrt providing aid to a
programmer that wants to use threading and atomics effectively, and
continue to use the standard wrt gaining the cache line size to properly
pad and align their structures in memory: We do not want any
false-sharing, damn it!

;^)

kushal bhattacharya

unread,
Sep 1, 2017, 5:46:27 AM9/1/17
to
thanks for the info man i needed this :)

Vir Campestris

unread,
Sep 1, 2017, 4:53:58 PM9/1/17
to
On 30/08/2017 21:55, Chris M. Thomasson wrote:
> So, crudely and quickly, for instance, if there are 2 NUMA nodes, it
> gives you a linked list NL with two items, each of which are a NUMA
> node. Each node in NL represents a CPU item; each CPU item has multiple
> nodes representing its virtual cores VCPU; each VCPU has its
> "hyper-threading" cores on each VCPU; and down to per-thread...
<etc>

The trouble with this kind of thing is anticipating what kind of data
you need, and how to future proof it. Do you care about ARM's big-LITTLE
architecture? Other kinds of more asymmetric processor systems? When
does NUMA become a network?

Remember that this must work on everything from FreeDOS to VM/370...

Andy
0 new messages