missing a function to get the id of the cpu the hardware is running on

69 views
Skip to first unread message

roug...@gmail.com

unread,
Jan 9, 2017, 12:32:09 PM1/9/17
to ISO C++ Standard - Discussion
Dear list,

i am not sure if this is the correct place to post this question...but let's try

let's imagine i have a code of the type

Matrix scratchspace(100,100); //to be used as scratchspace
int my_size = 1000000;
std::vector a(my_size);
for(int i=0; i<a.size(); ++i)
{
          a[i] = f(i, scratchspace); //do something using the scratchspace
}


making this loop parallel using openmp would be as simple as

#pragma omp parallel for firstprivate(scratchspace) ----> here a copy of scratchspace is allocated per every available hardware thread
for(int i=0; i<a.size(); ++i)
{
          a[i] = f(i, scratchspace); //do something using the scratchspace
}


in order to do this using c++17 this would look like

for_each_n(par,0,a.size(), [scratchspace](int i) {a[i] = f(i, scratchspace);} )

this however would imply copying scratchspace once per every "i" obviously with a great overhead.


in order to avoid this and emulate the firstprivate behaviour one could do

std::vector<Matrix> tls_scratchspace(std::thread::hardware_concurrency(), scratchspace);
for(int i=0; i<a.size(); ++i)
{
          int cpu_id = sched_cpu();
          a[i] = f(i,  tls_scratchspace[cpu_id]); //do something using the scratchspace
}

unfortunately this is not possible to do since to my understanting there is no portable way in the standard to do get the id of the core on which the thread is currently running

can anyone explain me what is the rationale of this?

a similar function is available in OpenMP, OpenCL, CUDA ... in all of the threading apis i know of. Shouldn't the same feature also be available in the std lib?

regards

Riccardo Rossi


Thiago Macieira

unread,
Jan 9, 2017, 12:49:15 PM1/9/17
to std-dis...@isocpp.org
On segunda-feira, 9 de janeiro de 2017 09:32:09 PST roug...@gmail.com wrote:
> unfortunately this is not possible to do since to my understanting there is
> no portable way in the standard to do get the id of the core on which the
> thread is currently running

Remove the "portable" word and you've got your answer.

There's no way to get the ID of the core your thread is running on, period.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

Riccardo Rossi

unread,
Jan 9, 2017, 1:01:35 PM1/9/17
to std-dis...@isocpp.org
Well, glibc's

sched_getcpu()

Would do for example...And there is a similar función for windows

Please be didactic...
The fact that there is no way to do It ... is it by design? If so...why?

Riccardo




--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-discussion/Gg9RNC8xgUs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

Thiago Macieira

unread,
Jan 9, 2017, 1:56:37 PM1/9/17
to std-dis...@isocpp.org
On segunda-feira, 9 de janeiro de 2017 19:01:31 PST Riccardo Rossi wrote:
> Well, glibc's
>
> sched_getcpu()
>
> Would do for example...And there is a similar función for windows

It doesn't work because the information is stale by the time you've got it.
Unless you've pinned your thread to a given vCPU, the OS scheduler is allowed
to de-schedule your thread and re-schedule it elsewhere.

On Linux, you'd need the sched_setaffinity call, which is documented to require
CAP_SYS_NICE privileges.

> Please be didactic...
> The fact that there is no way to do It ... is it by design? If so...why?

Reply all
Reply to author
Forward
0 new messages