Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

That does not compute.


devel / comp.lang.c++ / Re: clock_gettime behavior with CLOCK_THREAD_CPUTIME_ID

SubjectAuthor
* clock_gettime behavior with CLOCK_THREAD_CPUTIME_IDJehangir Iqbal
`- Re: clock_gettime behavior with CLOCK_THREAD_CPUTIME_IDBonita Montero

1
clock_gettime behavior with CLOCK_THREAD_CPUTIME_ID

<dffa5e17-a536-4c39-a818-215bf4e36f95n@googlegroups.com>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=115&group=comp.lang.c%2B%2B#115

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:1899:b0:3f0:ad19:fa11 with SMTP id v25-20020a05622a189900b003f0ad19fa11mr8615418qtc.11.1683929393328;
Fri, 12 May 2023 15:09:53 -0700 (PDT)
X-Received: by 2002:a05:622a:2cf:b0:3f3:64f9:d119 with SMTP id
a15-20020a05622a02cf00b003f364f9d119mr9512655qtx.0.1683929393096; Fri, 12 May
2023 15:09:53 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Fri, 12 May 2023 15:09:52 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=54.240.197.238; posting-account=qQL34woAAAAmuwJDBoCE5szsX00hBZz6
NNTP-Posting-Host: 54.240.197.238
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <dffa5e17-a536-4c39-a818-215bf4e36f95n@googlegroups.com>
Subject: clock_gettime behavior with CLOCK_THREAD_CPUTIME_ID
From: jehangir.iqbal@gmail.com (Jehangir Iqbal)
Injection-Date: Fri, 12 May 2023 22:09:53 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 69
 by: Jehangir Iqbal - Fri, 12 May 2023 22:09 UTC

Hi,

I have been working on RocksDB (https://github.com/facebook/rocksdb) and I am running into a problem while building the binaries on Amazon Linux EC2 instance of type i3.8xlarge.

There is a class called Performance Context. It provides time spent in nano seconds in different operations.

There are some unit tests that test this functionality. The functionality uses the following code to calculate the nano seconds spent in the thread.

uint64_t CPUNanos() override {
struct timespec ts;
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts);
return static_cast<uint64_t>(ts.tv_sec) * 1000000000 + ts.tv_nsec;
}

On EC2 instance of type i3.8xlarge, some times the time reported is 0 nano seconds. The operation has gone through disk and memory operations so I know the time is not really 0 nano seconds.

I assumed that this is happening because the thread is switched between CPUs. To confirm my assumption, I have wrote a simple program as shown below

#include <iostream>
#include <time.h>
#include <sched.h>
#include <unistd.h>
#include <utility>

uint64_t getNanoSecCPUTime() {
struct timespec ts;
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts);
return static_cast<uint64_t>(ts.tv_sec) * 1000000000 + ts.tv_nsec;
}

int main() {

auto iterations = 10'000;
auto count = 0;
auto nanoSec = getNanoSecCPUTime();
for (int i = 0; i < iterations; i++) {
auto newNanoSec = getNanoSecCPUTime();

for (auto k=0; k<1'000;k++) {
auto assign = k;
}

if (nanoSec == newNanoSec) {
std::cout << nanoSec << ":" << newNanoSec << std::endl;
count++;
}
nanoSec = newNanoSec;
}
std::cout << "Matched " << count << " times." << std::endl;
}

This program checks that how many times the nano seconds are reported as same between two calls. It has variable output, sometimes the nanoseconds match 3000+ times, sometimes they match 10 times etc.

I have taken all the CPUs offline using this command for CPU from 1 to 31

echo 0 > /sys/devices/system/cpu/cpuN/online

After that the program never reports any matching values.

I have following questions
* Is it possible that there is genuinely zero nano seconds passed between two calls?
* Is the call to clock_gettime with CLOCK_THREAD_CPUTIME_ID is a reliable way to measure thread time. If not, what can be done?

Note: If I replace CLOCK_THREAD_CPUTIME_ID with CLOCK_MONOTONIC, rocks DB build passes all unit tests and also my program passes as well.

Re: clock_gettime behavior with CLOCK_THREAD_CPUTIME_ID

<u3o485$244ur$1@dont-email.me>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=116&group=comp.lang.c%2B%2B#116

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bonita.Montero@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: clock_gettime behavior with CLOCK_THREAD_CPUTIME_ID
Date: Sat, 13 May 2023 15:44:38 +0200
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <u3o485$244ur$1@dont-email.me>
References: <dffa5e17-a536-4c39-a818-215bf4e36f95n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 13 May 2023 13:44:37 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="306cda98f230979d1a3a1604e4d86cd4";
logging-data="2233307"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX193KPX4GhGLVIrrqmgyQWiSK2+KXqBQ7Lw="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0
Cancel-Lock: sha1:MHr+K7FOk/wqMRDphv+zegppwU4=
In-Reply-To: <dffa5e17-a536-4c39-a818-215bf4e36f95n@googlegroups.com>
Content-Language: de-DE
 by: Bonita Montero - Sat, 13 May 2023 13:44 UTC

Use high_resolution_clock. On Windows and Linux this indirectly bases
on x86's RDTSC. On Windows it unfortunately bases on QueryPerformance
Counter() which has 100ns-resolution although QueryPerformanceCounter()
bases on RDTSC if the TSC is invariant, like with every x86-CPU of the
last two decades.
With the runtimes of MSVC, clang++ and g++ you could even use steady
_clock, which uses duration<int64_t, nano>.

Am 13.05.2023 um 00:09 schrieb Jehangir Iqbal:
> Hi,
>
> I have been working on RocksDB (https://github.com/facebook/rocksdb) and I am running into a problem while building the binaries on Amazon Linux EC2 instance of type i3.8xlarge.
>
> There is a class called Performance Context. It provides time spent in nano seconds in different operations.
>
> There are some unit tests that test this functionality. The functionality uses the following code to calculate the nano seconds spent in the thread.
>
> uint64_t CPUNanos() override {
> struct timespec ts;
> clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts);
> return static_cast<uint64_t>(ts.tv_sec) * 1000000000 + ts.tv_nsec;
> }
>
> On EC2 instance of type i3.8xlarge, some times the time reported is 0 nano seconds. The operation has gone through disk and memory operations so I know the time is not really 0 nano seconds.
>
> I assumed that this is happening because the thread is switched between CPUs. To confirm my assumption, I have wrote a simple program as shown below
>
> #include <iostream>
> #include <time.h>
> #include <sched.h>
> #include <unistd.h>
> #include <utility>
>
> uint64_t getNanoSecCPUTime() {
> struct timespec ts;
> clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts);
> return static_cast<uint64_t>(ts.tv_sec) * 1000000000 + ts.tv_nsec;
> }
>
> int main() {
>
> auto iterations = 10'000;
> auto count = 0;
> auto nanoSec = getNanoSecCPUTime();
> for (int i = 0; i < iterations; i++) {
> auto newNanoSec = getNanoSecCPUTime();
>
> for (auto k=0; k<1'000;k++) {
> auto assign = k;
> }
>
> if (nanoSec == newNanoSec) {
> std::cout << nanoSec << ":" << newNanoSec << std::endl;
> count++;
> }
> nanoSec = newNanoSec;
> }
> std::cout << "Matched " << count << " times." << std::endl;
> }
>
> This program checks that how many times the nano seconds are reported as same between two calls. It has variable output, sometimes the nanoseconds match 3000+ times, sometimes they match 10 times etc.
>
> I have taken all the CPUs offline using this command for CPU from 1 to 31
>
> echo 0 > /sys/devices/system/cpu/cpuN/online
>
> After that the program never reports any matching values.
>
> I have following questions
> * Is it possible that there is genuinely zero nano seconds passed between two calls?
> * Is the call to clock_gettime with CLOCK_THREAD_CPUTIME_ID is a reliable way to measure thread time. If not, what can be done?
>
> Note: If I replace CLOCK_THREAD_CPUTIME_ID with CLOCK_MONOTONIC, rocks DB build passes all unit tests and also my program passes as well.
>
>
>
>
>
>


devel / comp.lang.c++ / Re: clock_gettime behavior with CLOCK_THREAD_CPUTIME_ID

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor