Libcu++ monotonically increasing clock in host code

From Time Library — libcudacxx 2.5 documentation , “We have a monotonically increasing clock in host code”:

While we have a monotonically increasing clock in host code, and our system clock (PTX’s %globaltimer) is monotonically increasing in device code, it is not guaranteed that the host clocks and the device clocks are monotonically increasing with respect to each other, due to how PTX’s %globaltimer is initialized.

But cuda::std::system_clock is not monotonically increasing, and cuda::std::chrono::high_resolution_clock is an alias for the former.

std::chrono::system_clock is a clock that track real-world time. In the C++ Standard, it is unspecified whether or not this clock is monotonically increasing. In our implementation, it is not.

The only monotonic clock mentioned in the (non-cuda) std::chrono is steady_clock , which is omitted from cuda::std::chrono. Standard library header <chrono> (C++11) - cppreference.com

To what construction does “we have a monotonically increasing clock in host code” refer?

they are referring to std::chrono::steady_clock

It is available in host code.

It is monotonic.

It does not appear that steady_clock is available in host code for me.

I get the following compilation error when attempting to use steady_clock in the the main() function of a .cu file. The same code compiles fine when I change “cuda::std::chrono::steady_clock” to “cuda::std::chrono::system_clock”.

error: namespace “cuda::std::__4::chrono” has no member “steady_clock”
cuda::std::chrono::steady_clock steadyClock;

This is on build cuda_12.4.r12.4/compiler.34097967_0 on Windows 10

nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2024 NVIDIA Corporation
Built on Thu_Mar_28_02:30:10_Pacific_Daylight_Time_2024
Cuda compilation tools, release 12.4, V12.4.131
Build cuda_12.4.r12.4/compiler.34097967_0

The documentation lists steady_clock in the “Omissions” section with this note

As such, today we do not provide std::chrono::steady_clock, as we cannot easily provide an efficient implementation that is truly heterogeneous and conforms to the specification.

Its not in cuda::std

Its in std::

That paragraph you excerpted is speaking in terms of hypotheticals. A starting point for a heterogeneous steady clock would be to have a steady clock in host code, and a steady clock in device code, and then additional work would be needed to create a heterogeneous steady clock out of those.

“We have a steady clock in host code” refers to the idea that hypothetically, if we were interested in building a heterogeneous steady clock, we have one that we could start with, in std::chrono. And we have one on the device side (%globaltimer). But the combination is the rub as discussed there. Since it was elected not to create a heterogeneous steady clock out of the building blocks, it is therefore necessary that no cuda::std implementation of steady_clock be provided, because that would suggest it is heterogenous.

1 Like

Thanks for the clarification.

Does this mean that if I want to use an std::chrono::steady_timer to time cuda kernels, I will have to start compiling my cuda code as a library rather than executable, then linking it into a non-cuda executable which can access normal (non-cuda) std, and do all the timing inside the non-cuda exe? Or is there some way to access non-cuda std::chrono inside a .cu file? My current understanding is that non-cuda std library is inaccessible to nvcc.

where is that defined? Did you mean std::chrono::steady_clock ?

If you are using std::chrono in host code, there should be no issue. The limitation for std:: applies to device code. When you say “time cuda kernels”, I assume you are referring to host-based timing methods.

You can find plenty of examples scattered around the web of people using std::chrono in host code that is compiled by nvcc. Here is one example. Here is another. Here is an example that uses std::chrono::steady_clock.

(I guess if it were me, I would just give it a try.)

Thank you, that clears everything up.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.