Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #87220 > unrolled thread

what is the best way to get microseconds of time on Windows in C or C++ ?

Back to article view | Back to comp.lang.c++

Contents

  what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-03 20:14 -0500
    Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-04 00:06 -0500
      Re: what is the best way to get microseconds of time on Windows in C or C++ ? Christian Gollwitzer <auriocus@gmx.de> - 2022-11-04 08:03 +0100
        Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-04 14:32 -0500
      Re: what is the best way to get microseconds of time on Windows in C or C++ ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-04 09:07 -0700
        Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-04 14:33 -0500
      Re: what is the best way to get microseconds of time on Windows in C or C++ ? Opus <ifonly@youknew.org> - 2022-11-06 20:53 +0100
        Re: what is the best way to get microseconds of time on Windows in C or C++ ? Michael S <already5chosen@yahoo.com> - 2022-11-06 14:30 -0800
          Re: what is the best way to get microseconds of time on Windows in C or C++ ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-11-07 07:48 +0100
            Re: what is the best way to get microseconds of time on Windows in C or C++ ? Michael S <already5chosen@yahoo.com> - 2022-11-07 04:11 -0800
              Re: what is the best way to get microseconds of time on Windows in C or C++ ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-11-08 18:30 +0100
                Re: what is the best way to get microseconds of time on Windows in C or C++ ? Michael S <already5chosen@yahoo.com> - 2022-11-08 15:37 -0800
                  Re: what is the best way to get microseconds of time on Windows in C or C++ ? Öö Tiib <ootiib@hot.ee> - 2022-11-09 06:14 -0800
                  Re: what is the best way to get microseconds of time on Windows in C or C++ ? Michael S <already5chosen@yahoo.com> - 2022-11-12 16:21 -0800
    Re: what is the best way to get microseconds of time on Windows in C or C++ ? Juha Nieminen <nospam@thanks.invalid> - 2022-11-04 07:35 +0000
      Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-04 14:24 -0500
        Re: what is the best way to get microseconds of time on Windows in C or C++ ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-04 19:50 +0000
          Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-04 15:16 -0500
        Re: what is the best way to get microseconds of time on Windows in C or C++ ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-04 15:05 -0700
          Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-04 17:35 -0500
            Re: what is the best way to get microseconds of time on Windows in C or C++ ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-04 15:56 -0700
            Re: what is the best way to get microseconds of time on Windows in C or C++ ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-04 16:15 -0700
            Re: what is the best way to get microseconds of time on Windows in C or C++ ? Michael S <already5chosen@yahoo.com> - 2022-11-06 14:41 -0800
              Re: what is the best way to get microseconds of time on Windows in C or C++ ? scott@slp53.sl.home (Scott Lurndal) - 2022-11-07 14:39 +0000
                Re: what is the best way to get microseconds of time on Windows in C or C++ ? Michael S <already5chosen@yahoo.com> - 2022-11-07 11:03 -0800
              Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-07 23:26 -0600
    Re: what is the best way to get microseconds of time on Windows in C or C++ ? Öö Tiib <ootiib@hot.ee> - 2022-11-04 01:23 -0700
      Re: what is the best way to get microseconds of time on Windows in C or C++ ? Juha Nieminen <nospam@thanks.invalid> - 2022-11-07 07:20 +0000
        Re: what is the best way to get microseconds of time on Windows in C or C++ ? Öö Tiib <ootiib@hot.ee> - 2022-11-07 07:11 -0800
    Re: what is the best way to get microseconds of time on Windows in C or C++ ? Michael S <already5chosen@yahoo.com> - 2022-11-04 03:12 -0700
      Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-04 14:35 -0500
    Re: what is the best way to get microseconds of time on Windows in C or C++ ? scott@slp53.sl.home (Scott Lurndal) - 2022-11-04 13:44 +0000
      Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-04 14:34 -0500
      Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-14 16:58 -0600
        Re: what is the best way to get microseconds of time on Windows in C or C++ ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-14 17:36 -0800
          Re: what is the best way to get microseconds of time on Windows in C or C++ ? Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-15 17:26 -0600
            Re: what is the best way to get microseconds of time on Windows in C or C++ ? Andreas <nospam@gmx.de> - 2022-11-16 13:15 +0100
    Re: what is the best way to get microseconds of time on Windows in C or C++ ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-04 20:49 +0100
    Re: what is the best way to get microseconds of time on Windows in C or C++ ? Manu Raju <MR@invalid.invalid> - 2022-11-20 21:30 +0000

Page 1 of 2  [1] 2  Next page →

#87220 — what is the best way to get microseconds of time on Windows in C or C++ ?

What is the best way to get microseconds of time on Windows in C or C++ 
?  I am currently using the following code to get the current time:

	std::time_t t = std::time (0);   // get time now
	std::tm * now = std::localtime ( & t);
	integer iyear = now -> tm_year + 1900;
	integer imonth = now -> tm_mon + 1;
	integer iday = now -> tm_mday;
	integer ihour = now -> tm_hour;
	integer imin = now -> tm_min;
	integer isec = now -> tm_sec;
	integer ihund = 0;

Thanks,
Lynn

[toc] | [next] | [standalone]

#87221

On 11/3/2022 8:51 PM, DFS wrote:
> On 11/3/2022 9:14 PM, Lynn McGuire wrote:
>> What is the best way to get microseconds of time on Windows in C or 
>> C++ ?  I am currently using the following code to get the current time:
>>
>>      std::time_t t = std::time (0);   // get time now
>>      std::tm * now = std::localtime ( & t);
>>      integer iyear = now -> tm_year + 1900;
>>      integer imonth = now -> tm_mon + 1;
>>      integer iday = now -> tm_mday;
>>      integer ihour = now -> tm_hour;
>>      integer imin = now -> tm_min;
>>      integer isec = now -> tm_sec;
>>      integer ihund = 0;
>>
>> Thanks,
>> Lynn
> 
> 
> https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
> 
> 
> I used it like this:
> ----------------------------------------------------------------
> LARGE_INTEGER frequency,start,end;
> 
> //calc elapsed time
> double elapsedtime(LARGE_INTEGER startingtimer)
> {
>    QueryPerformanceCounter(&end);
>    return (end.QuadPart - startingtimer.QuadPart) / 
> (double)frequency.QuadPart;
> }
> 
> 
> int main(void)
> {
> 
>      //turn on Windows program timing
>      QueryPerformanceFrequency(&frequency);
> 
>      //start timing a piece of code
>      QueryPerformanceCounter(&start);
>      ...
>      ...
>      printf(" %.4fs to execute\n",elapsedtime(start));
> 
> }
> ----------------------------------------------------------------

I forgot to add I would prefer a portable way if possible.  I suspect 
that is not possible though below the second resolution.

Thanks,
Lynn McGuire

[toc] | [prev] | [next] | [standalone]

#87222

HI Lynn,
Am 04.11.22 um 06:06 schrieb Lynn McGuire:
> On 11/3/2022 8:51 PM, DFS wrote:
>> On 11/3/2022 9:14 PM, Lynn McGuire wrote:
>>> What is the best way to get microseconds of time on Windows in C or 
>>> C++ ?  I am currently using the following code to get the current time:
>>>

>> ----------------------------------------------------------------
> 
> I forgot to add I would prefer a portable way if possible.  I suspect 
> that is not possible though below the second resolution.
> 

I fear it is not possible in a portable way. Here you can find some 
description about how Tcl has solved this issue especially for Windows:

https://core.tcl-lang.org/tips/doc/trunk/tip/7.md

The implementation is here:

https://github.com/tcltk/tcl/blob/main/win/tclWinTime.c

and here for Unix:

https://github.com/tcltk/tcl/blob/main/unix/tclUnixTime.c

(BSD licensed, in any case)

	Christian

[toc] | [prev] | [next] | [standalone]

#87237

On 11/4/2022 2:03 AM, Christian Gollwitzer wrote:
> HI Lynn,
> Am 04.11.22 um 06:06 schrieb Lynn McGuire:
>> On 11/3/2022 8:51 PM, DFS wrote:
>>> On 11/3/2022 9:14 PM, Lynn McGuire wrote:
>>>> What is the best way to get microseconds of time on Windows in C or 
>>>> C++ ?  I am currently using the following code to get the current time:
>>>>
> 
>>> ----------------------------------------------------------------
>>
>> I forgot to add I would prefer a portable way if possible.  I suspect 
>> that is not possible though below the second resolution.
>>
> 
> I fear it is not possible in a portable way. Here you can find some 
> description about how Tcl has solved this issue especially for Windows:
> 
> https://core.tcl-lang.org/tips/doc/trunk/tip/7.md
> 
> The implementation is here:
> 
> https://github.com/tcltk/tcl/blob/main/win/tclWinTime.c
> 
> and here for Unix:
> 
> https://github.com/tcltk/tcl/blob/main/unix/tclUnixTime.c
> 
> (BSD licensed, in any case)
> 
>      Christian

Thanks !

Lynn

[toc] | [prev] | [next] | [standalone]

#87232

Lynn McGuire <lynnmcguire5@gmail.com> writes:
> On 11/3/2022 8:51 PM, DFS wrote:
>> On 11/3/2022 9:14 PM, Lynn McGuire wrote:
>>> What is the best way to get microseconds of time on Windows in C or
>>> C++ ?  I am currently using the following code to get the current
>>> time:
>>>
>>>      std::time_t t = std::time (0);   // get time now
>>>      std::tm * now = std::localtime ( & t);
>>>      integer iyear = now -> tm_year + 1900;
>>>      integer imonth = now -> tm_mon + 1;
>>>      integer iday = now -> tm_mday;
>>>      integer ihour = now -> tm_hour;
>>>      integer imin = now -> tm_min;
>>>      integer isec = now -> tm_sec;
>>>      integer ihund = 0;
>>>
>>> Thanks,
>>> Lynn
>> 
>> https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
>> 
>> I used it like this:
>> ----------------------------------------------------------------
>> LARGE_INTEGER frequency,start,end;
>> //calc elapsed time
>> double elapsedtime(LARGE_INTEGER startingtimer)
>> {
>>    QueryPerformanceCounter(&end);
>>    return (end.QuadPart - startingtimer.QuadPart) /
>> (double)frequency.QuadPart;
>> }
>> 
>> int main(void)
>> {
>>      //turn on Windows program timing
>>      QueryPerformanceFrequency(&frequency);
>>      //start timing a piece of code
>>      QueryPerformanceCounter(&start);
>>      ...
>>      ...
>>      printf(" %.4fs to execute\n",elapsedtime(start));
>> }
>> ----------------------------------------------------------------
>
> I forgot to add I would prefer a portable way if possible.  I suspect
> that is not possible though below the second resolution.

The resolution of the time() function is unspecified (not even
implementation-defined).  In practice, time_t is almost universally an
integer type representing seconds since some epoch, usually 1970-01-01
00:00:00 UTC, but it could even be floating-point.

C11 adds the type struct timespec and the function timespec_get() which
gives a result with a resolution of 1 nanosecond.  A footnote in the
standard says:

    Although a struct timespec object describes times with nanosecond
    resolution, the available resolution is system dependent and may
    even be greater than 1 second.

The standard says that struct timespec has the following members:

    time_t tv_sec; // whole seconds — ≥ 0
    long tv_nsec; // nanoseconds — [0, 999999999]

which strongly implies that the resulution of time_t is 1 second, but
the standard still doesn't say so.  Possibly an implementation could use
different encodings for the time_t value from time() and the time_t
value from timespec_get(), though that's unlikely in practice.

clock() returns a value of type clock_t, which is typically double, but
that's also unspecified -- and it measures processor time, not wall
clock time.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#87238

On 11/4/2022 11:07 AM, Keith Thompson wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> On 11/3/2022 8:51 PM, DFS wrote:
>>> On 11/3/2022 9:14 PM, Lynn McGuire wrote:
>>>> What is the best way to get microseconds of time on Windows in C or
>>>> C++ ?  I am currently using the following code to get the current
>>>> time:
>>>>
>>>>       std::time_t t = std::time (0);   // get time now
>>>>       std::tm * now = std::localtime ( & t);
>>>>       integer iyear = now -> tm_year + 1900;
>>>>       integer imonth = now -> tm_mon + 1;
>>>>       integer iday = now -> tm_mday;
>>>>       integer ihour = now -> tm_hour;
>>>>       integer imin = now -> tm_min;
>>>>       integer isec = now -> tm_sec;
>>>>       integer ihund = 0;
>>>>
>>>> Thanks,
>>>> Lynn
>>>
>>> https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
>>>
>>> I used it like this:
>>> ----------------------------------------------------------------
>>> LARGE_INTEGER frequency,start,end;
>>> //calc elapsed time
>>> double elapsedtime(LARGE_INTEGER startingtimer)
>>> {
>>>     QueryPerformanceCounter(&end);
>>>     return (end.QuadPart - startingtimer.QuadPart) /
>>> (double)frequency.QuadPart;
>>> }
>>>
>>> int main(void)
>>> {
>>>       //turn on Windows program timing
>>>       QueryPerformanceFrequency(&frequency);
>>>       //start timing a piece of code
>>>       QueryPerformanceCounter(&start);
>>>       ...
>>>       ...
>>>       printf(" %.4fs to execute\n",elapsedtime(start));
>>> }
>>> ----------------------------------------------------------------
>>
>> I forgot to add I would prefer a portable way if possible.  I suspect
>> that is not possible though below the second resolution.
> 
> The resolution of the time() function is unspecified (not even
> implementation-defined).  In practice, time_t is almost universally an
> integer type representing seconds since some epoch, usually 1970-01-01
> 00:00:00 UTC, but it could even be floating-point.
> 
> C11 adds the type struct timespec and the function timespec_get() which
> gives a result with a resolution of 1 nanosecond.  A footnote in the
> standard says:
> 
>      Although a struct timespec object describes times with nanosecond
>      resolution, the available resolution is system dependent and may
>      even be greater than 1 second.
> 
> The standard says that struct timespec has the following members:
> 
>      time_t tv_sec; // whole seconds — ≥ 0
>      long tv_nsec; // nanoseconds — [0, 999999999]
> 
> which strongly implies that the resulution of time_t is 1 second, but
> the standard still doesn't say so.  Possibly an implementation could use
> different encodings for the time_t value from time() and the time_t
> value from timespec_get(), though that's unlikely in practice.
> 
> clock() returns a value of type clock_t, which is typically double, but
> that's also unspecified -- and it measures processor time, not wall
> clock time.

Thanks !

Lynn

[toc] | [prev] | [next] | [standalone]

#87269

Le 04/11/2022 à 06:06, Lynn McGuire a écrit :
> I forgot to add I would prefer a portable way if possible.  I suspect 
> that is not possible though below the second resolution.

You're asking specifically on Windows, and then you now want a portable 
solution. There isn't. But you could write your own compatibility layer, 
calling either Windows API functions or POSIX functions. This isn't 
rocket science. I've done that long ago and keep reusing it. There may 
of course be many third-party code/libraries doing just that if you 
don't want to do it yourself.

IME, using performance counters on Windows is the only sure way of 
getting proper resolution. Any third-party code will use them in one way 
or another. Why not do that yourself, it'll be only a few lines of code 
to write a compatibility layer.

[toc] | [prev] | [next] | [standalone]

#87271

On Sunday, November 6, 2022 at 9:54:11 PM UTC+2, Opus wrote:
> Le 04/11/2022 à 06:06, Lynn McGuire a écrit : 
> > I forgot to add I would prefer a portable way if possible.  I suspect 
> > that is not possible though below the second resolution.
> You're asking specifically on Windows, and then you now want a portable 
> solution. There isn't. But you could write your own compatibility layer, 
> calling either Windows API functions or POSIX functions. This isn't 
> rocket science. I've done that long ago and keep reusing it. There may 
> of course be many third-party code/libraries doing just that if you 
> don't want to do it yourself. 
> 
> IME, using performance counters on Windows is the only sure way of 
> getting proper resolution. Any third-party code will use them in one way 
> or another. Why not do that yourself, it'll be only a few lines of code 
> to write a compatibility layer.

Why do it it yourself?
I don't find it very likely that compatibility layer consisting of few lines
of code written by non-specialist will do a better job than compatibility
layer provided by standard C++ library, in particular one in 
std::chrono::stable_clock.

[toc] | [prev] | [next] | [standalone]

#87273

On 6 Nov 2022 23:30, Michael S wrote:
> On Sunday, November 6, 2022 at 9:54:11 PM UTC+2, Opus wrote:
>> Le 04/11/2022 à 06:06, Lynn McGuire a écrit :
>>> I forgot to add I would prefer a portable way if possible.  I suspect
>>> that is not possible though below the second resolution.
>> You're asking specifically on Windows, and then you now want a portable
>> solution. There isn't. But you could write your own compatibility layer,
>> calling either Windows API functions or POSIX functions. This isn't
>> rocket science. I've done that long ago and keep reusing it. There may
>> of course be many third-party code/libraries doing just that if you
>> don't want to do it yourself.
>>
>> IME, using performance counters on Windows is the only sure way of
>> getting proper resolution. Any third-party code will use them in one way
>> or another. Why not do that yourself, it'll be only a few lines of code
>> to write a compatibility layer.
> 
> Why do it it yourself?
> I don't find it very likely that compatibility layer consisting of few lines
> of code written by non-specialist will do a better job than compatibility
> layer provided by standard C++ library, in particular one in
> std::chrono::stable_clock.
  But here your belief is in direct conflict with reality.

The MinGW g++ chrono implementation has had (and probably still has) a 
dynamically varying resolution down to 1/30 second, extremely unusable.

- Alf

[toc] | [prev] | [next] | [standalone]

#87276

On Monday, November 7, 2022 at 8:48:43 AM UTC+2, alf.p.s...@gmail.com wrote:
> On 6 Nov 2022 23:30, Michael S wrote: 
> > On Sunday, November 6, 2022 at 9:54:11 PM UTC+2, Opus wrote: 
> >> Le 04/11/2022 à 06:06, Lynn McGuire a écrit : 
> >>> I forgot to add I would prefer a portable way if possible. I suspect 
> >>> that is not possible though below the second resolution. 
> >> You're asking specifically on Windows, and then you now want a portable 
> >> solution. There isn't. But you could write your own compatibility layer, 
> >> calling either Windows API functions or POSIX functions. This isn't 
> >> rocket science. I've done that long ago and keep reusing it. There may 
> >> of course be many third-party code/libraries doing just that if you 
> >> don't want to do it yourself. 
> >> 
> >> IME, using performance counters on Windows is the only sure way of 
> >> getting proper resolution. Any third-party code will use them in one way 
> >> or another. Why not do that yourself, it'll be only a few lines of code 
> >> to write a compatibility layer. 
> > 
> > Why do it it yourself? 
> > I don't find it very likely that compatibility layer consisting of few lines 
> > of code written by non-specialist will do a better job than compatibility 
> > layer provided by standard C++ library, in particular one in 
> > std::chrono::stable_clock.
> But here your belief is in direct conflict with reality. 
> 
> The MinGW g++ chrono implementation has had (and probably still has) a 
> dynamically varying resolution down to 1/30 second, extremely unusable. 
> 
> - Alf

> The MinGW g++ chrono implementation has had (and probably still has) a 
> dynamically varying resolution down to 1/30 second, extremely unusable. 

MinGW is obsolete since long ago, close to 10 years.
It is replaced by MSYS2/Mingw64. 
Mingw64 had (has?) various problems with implementations of 
std::chrono::high_resolution_clock and, may be (not sure) 
of std::chrono::system_clock. But I don't suggest any of those.
I suggest std::chrono::steady_clock. It has reasonable
implementations on all x86-64 systems that I ever tested.

Anyway, it seems to me that OPs attitude is toward using
the most popular C++ tools on any given platform, i.e. MSVC on
Windows, LLVM/clang (via Xcode) on Mac and gcc on Linux.
Portability to more exotic tools+OS combinations is not required.

[toc] | [prev] | [next] | [standalone]

#87291

On 7 Nov 2022 13:11, Michael S wrote:
> On Monday, November 7, 2022 at 8:48:43 AM UTC+2, alf.p.s...@gmail.com wrote:
>> On 6 Nov 2022 23:30, Michael S wrote:
>>> On Sunday, November 6, 2022 at 9:54:11 PM UTC+2, Opus wrote:
>>>> Le 04/11/2022 à 06:06, Lynn McGuire a écrit :
>>>>> I forgot to add I would prefer a portable way if possible. I suspect
>>>>> that is not possible though below the second resolution.
>>>> You're asking specifically on Windows, and then you now want a portable
>>>> solution. There isn't. But you could write your own compatibility layer,
>>>> calling either Windows API functions or POSIX functions. This isn't
>>>> rocket science. I've done that long ago and keep reusing it. There may
>>>> of course be many third-party code/libraries doing just that if you
>>>> don't want to do it yourself.
>>>>
>>>> IME, using performance counters on Windows is the only sure way of
>>>> getting proper resolution. Any third-party code will use them in one way
>>>> or another. Why not do that yourself, it'll be only a few lines of code
>>>> to write a compatibility layer.
>>>
>>> Why do it it yourself?
>>> I don't find it very likely that compatibility layer consisting of few lines
>>> of code written by non-specialist will do a better job than compatibility
>>> layer provided by standard C++ library, in particular one in
>>> std::chrono::stable_clock.
>> But here your belief is in direct conflict with reality.
>>
>> The MinGW g++ chrono implementation has had (and probably still has) a
>> dynamically varying resolution down to 1/30 second, extremely unusable.
>>
>> - Alf
> 
>> The MinGW g++ chrono implementation has had (and probably still has) a
>> dynamically varying resolution down to 1/30 second, extremely unusable.
> 
> MinGW is obsolete since long ago, close to 10 years.
> It is replaced by MSYS2/Mingw64.

Oh my. I just don't care to write MinGW64, it's a bit of a mouthful and 
in general very unnecessary. Most people understand.

But to be precise you're comparing the compiler/tool project MinGW with 
the compiler distribution and Unix-like eco-system MSYS2. MSYS2 provides 
one distro of MinGW64. Nuwen (that's STL at Microsoft, or if you like, 
prince Nuwen from the Vernor Vinge novels) another. There are others.

The project that provides the basic sources that they all use is the 
MingW64 project, <url: https://www.mingw-w64.org/>.


> Mingw64 had (has?) various problems with implementations of
> std::chrono::high_resolution_clock and, may be (not sure)
> of std::chrono::system_clock. But I don't suggest any of those.
> I suggest std::chrono::steady_clock. It has reasonable
> implementations on all x86-64 systems that I ever tested.

The MinGW (that is, MinGW64) g++ implementation was not reasonable, and 
probably isn't today either.

> 
> Anyway, it seems to me that OPs attitude is toward using
> the most popular C++ tools on any given platform, i.e. MSVC on
> Windows, LLVM/clang (via Xcode) on Mac and gcc on Linux.
> Portability to more exotic tools+OS combinations is not required.

Portable code is often, and in this case would be, /less/ code.

As such it is more likely correct code.

The problem is when a C++ implementation doesn't manage to provide the 
implied usability guarantee. It's sort of like a C++ implementation with 
a 1 MB `bool`, so that you can't have two of them on a default machine 
stack. That's formally OK; it just fails to provide a /usable/ `bool`.

- Alf

PS: I'm sorry that I by mistake sent essentially this reply via mail, 
presumably to an unused spam-dump e-mail address, but. Not sure how 
Thunderbird managed to trick me into doing that.

[toc] | [prev] | [next] | [standalone]

#87293

On Tuesday, November 8, 2022 at 7:30:32 PM UTC+2, alf.p.s...@gmail.com wrote:
> On 7 Nov 2022 13:11, Michael S wrote: 
> > On Monday, November 7, 2022 at 8:48:43 AM UTC+2, alf.p.s...@gmail.com wrote: 
> >> On 6 Nov 2022 23:30, Michael S wrote: 
> >>> On Sunday, November 6, 2022 at 9:54:11 PM UTC+2, Opus wrote: 
> >>>> Le 04/11/2022 à 06:06, Lynn McGuire a écrit : 
> >>>>> I forgot to add I would prefer a portable way if possible. I suspect 
> >>>>> that is not possible though below the second resolution. 
> >>>> You're asking specifically on Windows, and then you now want a portable 
> >>>> solution. There isn't. But you could write your own compatibility layer, 
> >>>> calling either Windows API functions or POSIX functions. This isn't 
> >>>> rocket science. I've done that long ago and keep reusing it. There may 
> >>>> of course be many third-party code/libraries doing just that if you 
> >>>> don't want to do it yourself. 
> >>>> 
> >>>> IME, using performance counters on Windows is the only sure way of 
> >>>> getting proper resolution. Any third-party code will use them in one way 
> >>>> or another. Why not do that yourself, it'll be only a few lines of code 
> >>>> to write a compatibility layer. 
> >>> 
> >>> Why do it it yourself? 
> >>> I don't find it very likely that compatibility layer consisting of few lines 
> >>> of code written by non-specialist will do a better job than compatibility 
> >>> layer provided by standard C++ library, in particular one in 
> >>> std::chrono::stable_clock. 
> >> But here your belief is in direct conflict with reality. 
> >> 
> >> The MinGW g++ chrono implementation has had (and probably still has) a 
> >> dynamically varying resolution down to 1/30 second, extremely unusable. 
> >> 
> >> - Alf 
> > 
> >> The MinGW g++ chrono implementation has had (and probably still has) a 
> >> dynamically varying resolution down to 1/30 second, extremely unusable. 
> > 
> > MinGW is obsolete since long ago, close to 10 years. 
> > It is replaced by MSYS2/Mingw64.
> Oh my. I just don't care to write MinGW64, it's a bit of a mouthful and 
> in general very unnecessary. Most people understand. 
> 
> But to be precise you're comparing the compiler/tool project MinGW with 
> the compiler distribution and Unix-like eco-system MSYS2. MSYS2 provides 
> one distro of MinGW64. Nuwen (that's STL at Microsoft, or if you like, 
> prince Nuwen from the Vernor Vinge novels) another. There are others. 
> 
> The project that provides the basic sources that they all use is the 
> MingW64 project, <url: https://www.mingw-w64.org/>.
> > Mingw64 had (has?) various problems with implementations of 
> > std::chrono::high_resolution_clock and, may be (not sure) 
> > of std::chrono::system_clock. But I don't suggest any of those. 
> > I suggest std::chrono::steady_clock. It has reasonable 
> > implementations on all x86-64 systems that I ever tested.
> The MinGW (that is, MinGW64) g++ implementation was not reasonable, and 
> probably isn't today either.

IMO, you are confused.
From the very beginning mingw64 std::chrono::steady_clock() is based on
QueryPerformanceCounter(). 
It's not the best possible clock available on Windows, but certainly not broken.
It has sub-microsecond resolution. Typically ~331ns.

Most likely you had seen std::chrono::high_resolution_clock broken (and
this one is broken indeed) and remembered that *something* is broken,
but forgot what is broken and what not.

> > 
> > Anyway, it seems to me that OPs attitude is toward using 
> > the most popular C++ tools on any given platform, i.e. MSVC on 
> > Windows, LLVM/clang (via Xcode) on Mac and gcc on Linux. 
> > Portability to more exotic tools+OS combinations is not required.
> Portable code is often, and in this case would be, /less/ code. 
> 
> As such it is more likely correct code. 
> 
> The problem is when a C++ implementation doesn't manage to provide the 
> implied usability guarantee. It's sort of like a C++ implementation with 
> a 1 MB `bool`, so that you can't have two of them on a default machine 
> stack. That's formally OK; it just fails to provide a /usable/ `bool`. 
> 
> - Alf 
> 
> PS: I'm sorry that I by mistake sent essentially this reply via mail, 
> presumably to an unused spam-dump e-mail address, but. Not sure how 
> Thunderbird managed to trick me into doing that.

That's o.k.
This mail address is not totally unused, but it is used may be once or 
twice per year. 

[toc] | [prev] | [next] | [standalone]

#87298

On Wednesday, 9 November 2022 at 01:37:23 UTC+2, Michael S wrote:
> On Tuesday, November 8, 2022 at 7:30:32 PM UTC+2, alf.p.s...@gmail.com wrote: 
> > On 7 Nov 2022 13:11, Michael S wrote: 
> > > On Monday, November 7, 2022 at 8:48:43 AM UTC+2, alf.p.s...@gmail.com wrote: 
> > >> On 6 Nov 2022 23:30, Michael S wrote: 
> > >>> On Sunday, November 6, 2022 at 9:54:11 PM UTC+2, Opus wrote: 
> > >>>> Le 04/11/2022 à 06:06, Lynn McGuire a écrit : 
> > >>>>> I forgot to add I would prefer a portable way if possible. I suspect 
> > >>>>> that is not possible though below the second resolution. 
> > >>>> You're asking specifically on Windows, and then you now want a portable 
> > >>>> solution. There isn't. But you could write your own compatibility layer, 
> > >>>> calling either Windows API functions or POSIX functions. This isn't 
> > >>>> rocket science. I've done that long ago and keep reusing it. There may 
> > >>>> of course be many third-party code/libraries doing just that if you 
> > >>>> don't want to do it yourself. 
> > >>>> 
> > >>>> IME, using performance counters on Windows is the only sure way of 
> > >>>> getting proper resolution. Any third-party code will use them in one way 
> > >>>> or another. Why not do that yourself, it'll be only a few lines of code 
> > >>>> to write a compatibility layer. 
> > >>> 
> > >>> Why do it it yourself? 
> > >>> I don't find it very likely that compatibility layer consisting of few lines 
> > >>> of code written by non-specialist will do a better job than compatibility 
> > >>> layer provided by standard C++ library, in particular one in 
> > >>> std::chrono::stable_clock. 
> > >> But here your belief is in direct conflict with reality. 
> > >> 
> > >> The MinGW g++ chrono implementation has had (and probably still has) a 
> > >> dynamically varying resolution down to 1/30 second, extremely unusable. 
> > >> 
> > >> - Alf 
> > > 
> > >> The MinGW g++ chrono implementation has had (and probably still has) a 
> > >> dynamically varying resolution down to 1/30 second, extremely unusable. 
> > > 
> > > MinGW is obsolete since long ago, close to 10 years. 
> > > It is replaced by MSYS2/Mingw64. 
> > Oh my. I just don't care to write MinGW64, it's a bit of a mouthful and 
> > in general very unnecessary. Most people understand. 
> > 
> > But to be precise you're comparing the compiler/tool project MinGW with 
> > the compiler distribution and Unix-like eco-system MSYS2. MSYS2 provides 
> > one distro of MinGW64. Nuwen (that's STL at Microsoft, or if you like, 
> > prince Nuwen from the Vernor Vinge novels) another. There are others. 
> > 
> > The project that provides the basic sources that they all use is the 
> > MingW64 project, <url: https://www.mingw-w64.org/>. 
> > > Mingw64 had (has?) various problems with implementations of 
> > > std::chrono::high_resolution_clock and, may be (not sure) 
> > > of std::chrono::system_clock. But I don't suggest any of those. 
> > > I suggest std::chrono::steady_clock. It has reasonable 
> > > implementations on all x86-64 systems that I ever tested. 
> > The MinGW (that is, MinGW64) g++ implementation was not reasonable, and 
> > probably isn't today either.
> IMO, you are confused. 
> From the very beginning mingw64 std::chrono::steady_clock() is based on 
> QueryPerformanceCounter(). 
> It's not the best possible clock available on Windows, but certainly not broken. 
> It has sub-microsecond resolution. Typically ~331ns. 
> 
> Most likely you had seen std::chrono::high_resolution_clock broken (and 
> this one is broken indeed) and remembered that *something* is broken, 
> but forgot what is broken and what not.

From that steady_clock we are supposed to get time since arbitrary time
point of past. No years and months that OP had. That is useful only in
context of checking durations of works or time-ordering of events of
(threads of) current process. If used as  (parts of) file names (like OP
seemed to want) the ordering and time distances become wrong with
restart of system.

[toc] | [prev] | [next] | [standalone]

#87342

On Wednesday, November 9, 2022 at 1:37:23 AM UTC+2, Michael S wrote:
> On Tuesday, November 8, 2022 at 7:30:32 PM UTC+2, alf.p.s...@gmail.com wrote: 
> > On 7 Nov 2022 13:11, Michael S wrote: 
> > > On Monday, November 7, 2022 at 8:48:43 AM UTC+2, alf.p.s...@gmail.com wrote: 
> > >> On 6 Nov 2022 23:30, Michael S wrote: 
> > >>> On Sunday, November 6, 2022 at 9:54:11 PM UTC+2, Opus wrote: 
> > >>>> Le 04/11/2022 à 06:06, Lynn McGuire a écrit : 
> > >>>>> I forgot to add I would prefer a portable way if possible. I suspect 
> > >>>>> that is not possible though below the second resolution. 
> > >>>> You're asking specifically on Windows, and then you now want a portable 
> > >>>> solution. There isn't. But you could write your own compatibility layer, 
> > >>>> calling either Windows API functions or POSIX functions. This isn't 
> > >>>> rocket science. I've done that long ago and keep reusing it. There may 
> > >>>> of course be many third-party code/libraries doing just that if you 
> > >>>> don't want to do it yourself. 
> > >>>> 
> > >>>> IME, using performance counters on Windows is the only sure way of 
> > >>>> getting proper resolution. Any third-party code will use them in one way 
> > >>>> or another. Why not do that yourself, it'll be only a few lines of code 
> > >>>> to write a compatibility layer. 
> > >>> 
> > >>> Why do it it yourself? 
> > >>> I don't find it very likely that compatibility layer consisting of few lines 
> > >>> of code written by non-specialist will do a better job than compatibility 
> > >>> layer provided by standard C++ library, in particular one in 
> > >>> std::chrono::stable_clock. 
> > >> But here your belief is in direct conflict with reality. 
> > >> 
> > >> The MinGW g++ chrono implementation has had (and probably still has) a 
> > >> dynamically varying resolution down to 1/30 second, extremely unusable. 
> > >> 
> > >> - Alf 
> > > 
> > >> The MinGW g++ chrono implementation has had (and probably still has) a 
> > >> dynamically varying resolution down to 1/30 second, extremely unusable. 
> > > 
> > > MinGW is obsolete since long ago, close to 10 years. 
> > > It is replaced by MSYS2/Mingw64. 
> > Oh my. I just don't care to write MinGW64, it's a bit of a mouthful and 
> > in general very unnecessary. Most people understand. 
> > 
> > But to be precise you're comparing the compiler/tool project MinGW with 
> > the compiler distribution and Unix-like eco-system MSYS2. MSYS2 provides 
> > one distro of MinGW64. Nuwen (that's STL at Microsoft, or if you like, 
> > prince Nuwen from the Vernor Vinge novels) another. There are others. 
> > 
> > The project that provides the basic sources that they all use is the 
> > MingW64 project, <url: https://www.mingw-w64.org/>. 
> > > Mingw64 had (has?) various problems with implementations of 
> > > std::chrono::high_resolution_clock and, may be (not sure) 
> > > of std::chrono::system_clock. But I don't suggest any of those. 
> > > I suggest std::chrono::steady_clock. It has reasonable 
> > > implementations on all x86-64 systems that I ever tested. 
> > The MinGW (that is, MinGW64) g++ implementation was not reasonable, and 
> > probably isn't today either.
> IMO, you are confused. 
> From the very beginning mingw64 std::chrono::steady_clock() is based on 
> QueryPerformanceCounter(). 
> It's not the best possible clock available on Windows, but certainly not broken. 
> It has sub-microsecond resolution. Typically ~331ns. 
> 
> Most likely you had seen std::chrono::high_resolution_clock broken (and 
> this one is broken indeed) and remembered that *something* is broken, 
> but forgot what is broken and what not.

Elaboration and rectification:
Mingw64 std::chrono::high_resolution_clock is broken on Win7 and derivatives
like WS2008r2. 
On Window 10 and derivatives (WS2016 and Ws2019) it works fine. 
In particular, on the Ws2019 it works not just fine, but very well providing
100ns increments.

> > > 
> > > Anyway, it seems to me that OPs attitude is toward using 
> > > the most popular C++ tools on any given platform, i.e. MSVC on 
> > > Windows, LLVM/clang (via Xcode) on Mac and gcc on Linux. 
> > > Portability to more exotic tools+OS combinations is not required. 
> > Portable code is often, and in this case would be, /less/ code. 
> > 
> > As such it is more likely correct code. 
> > 
> > The problem is when a C++ implementation doesn't manage to provide the 
> > implied usability guarantee. It's sort of like a C++ implementation with 
> > a 1 MB `bool`, so that you can't have two of them on a default machine 
> > stack. That's formally OK; it just fails to provide a /usable/ `bool`. 
> > 
> > - Alf 
> > 
> > PS: I'm sorry that I by mistake sent essentially this reply via mail, 
> > presumably to an unused spam-dump e-mail address, but. Not sure how 
> > Thunderbird managed to trick me into doing that.
> That's o.k. 
> This mail address is not totally unused, but it is used may be once or 
> twice per year.

[toc] | [prev] | [next] | [standalone]

#87224

In comp.lang.c++ Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> What is the best way to get microseconds of time on Windows in C or C++ 

It's a bit unclear whether you mean "time in microseconds units" or "time
at the microseconds resolution".

Because the latter may not be even possible (portable or not). Just because
some time function returns time "in microseconds" that doesn't mean that it
uses microsecond resolution (in other words, the value it returns may well
change at longer intervals than every microsecond; probably *significantly*
longer intervals).

It is possible to get some kind of timing at the CPU clock cycle interval
(in most modern CPUs, at least), which is about as accurate as you can
possibly get, but I don't know if there are eg. some system functions that
will return elapsed clock cycles converted into the equivalent amount of
microseconds.

[toc] | [prev] | [next] | [standalone]

#87236

On 11/4/2022 2:35 AM, Juha Nieminen wrote:
> In comp.lang.c++ Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>> What is the best way to get microseconds of time on Windows in C or C++
> 
> It's a bit unclear whether you mean "time in microseconds units" or "time
> at the microseconds resolution".
> 
> Because the latter may not be even possible (portable or not). Just because
> some time function returns time "in microseconds" that doesn't mean that it
> uses microsecond resolution (in other words, the value it returns may well
> change at longer intervals than every microsecond; probably *significantly*
> longer intervals).
> 
> It is possible to get some kind of timing at the CPU clock cycle interval
> (in most modern CPUs, at least), which is about as accurate as you can
> possibly get, but I don't know if there are eg. some system functions that
> will return elapsed clock cycles converted into the equivalent amount of
> microseconds.

Get time at the microseconds resolution.   My calculation engine creates 
a bunch of temporary files and I use the time to create unique names for 
those temporary files.  Seconds should be good enough for uniqueness but 
I like adding microseconds as a guarantee.  Something like
    uniquac1.out.009.20181972.20220912

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#87242

Lynn McGuire <lynnmcguire5@gmail.com> writes:

> On 11/4/2022 2:35 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>> What is the best way to get microseconds of time on Windows in C or C++
>> It's a bit unclear whether you mean "time in microseconds units" or "time
>> at the microseconds resolution".
>> Because the latter may not be even possible (portable or not). Just because
>> some time function returns time "in microseconds" that doesn't mean that it
>> uses microsecond resolution (in other words, the value it returns may well
>> change at longer intervals than every microsecond; probably *significantly*
>> longer intervals).
>> It is possible to get some kind of timing at the CPU clock cycle interval
>> (in most modern CPUs, at least), which is about as accurate as you can
>> possibly get, but I don't know if there are eg. some system functions that
>> will return elapsed clock cycles converted into the equivalent amount of
>> microseconds.
>
> Get time at the microseconds resolution.  My calculation engine
> creates a bunch of temporary files and I use the time to create unique
> names for those temporary files.  Seconds should be good enough for
> uniqueness but I like adding microseconds as a guarantee.  Something
> like
>    uniquac1.out.009.20181972.20220912

Have you ruled out tmpnam and tmpfile?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#87243

On 11/4/2022 2:50 PM, Ben Bacarisse wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
> 
>> On 11/4/2022 2:35 AM, Juha Nieminen wrote:
>>> In comp.lang.c++ Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>> What is the best way to get microseconds of time on Windows in C or C++
>>> It's a bit unclear whether you mean "time in microseconds units" or "time
>>> at the microseconds resolution".
>>> Because the latter may not be even possible (portable or not). Just because
>>> some time function returns time "in microseconds" that doesn't mean that it
>>> uses microsecond resolution (in other words, the value it returns may well
>>> change at longer intervals than every microsecond; probably *significantly*
>>> longer intervals).
>>> It is possible to get some kind of timing at the CPU clock cycle interval
>>> (in most modern CPUs, at least), which is about as accurate as you can
>>> possibly get, but I don't know if there are eg. some system functions that
>>> will return elapsed clock cycles converted into the equivalent amount of
>>> microseconds.
>>
>> Get time at the microseconds resolution.  My calculation engine
>> creates a bunch of temporary files and I use the time to create unique
>> names for those temporary files.  Seconds should be good enough for
>> uniqueness but I like adding microseconds as a guarantee.  Something
>> like
>>     uniquac1.out.009.20181972.20220912
> 
> Have you ruled out tmpnam and tmpfile?

I just ported this code from F77 to C++.  I totally forgot about tmpnam 
and tmpfile.

Thanks,
Lynn

[toc] | [prev] | [next] | [standalone]

#87246

Lynn McGuire <lynnmcguire5@gmail.com> writes:
> On 11/4/2022 2:35 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>> What is the best way to get microseconds of time on Windows in C or C++
>> It's a bit unclear whether you mean "time in microseconds units" or
>> "time
>> at the microseconds resolution".
>> Because the latter may not be even possible (portable or not). Just
>> because
>> some time function returns time "in microseconds" that doesn't mean that it
>> uses microsecond resolution (in other words, the value it returns may well
>> change at longer intervals than every microsecond; probably *significantly*
>> longer intervals).
>> It is possible to get some kind of timing at the CPU clock cycle
>> interval
>> (in most modern CPUs, at least), which is about as accurate as you can
>> possibly get, but I don't know if there are eg. some system functions that
>> will return elapsed clock cycles converted into the equivalent amount of
>> microseconds.
>
> Get time at the microseconds resolution.   My calculation engine
> creates a bunch of temporary files and I use the time to create unique
> names for those temporary files.  Seconds should be good enough for
> uniqueness but I like adding microseconds as a guarantee.  Something
> like
>    uniquac1.out.009.20181972.20220912

An alternative is to keep a counter, incremented for each generated file
name, and append it to the file name, perhaps resetting to 0 when the
seconds count advances.  If your only requirement is uniqueness, that
should be good enough.

Digression: I remember an implementation of gettimeofday() that did
something like that (on SunOS, maybe?).  The system clock had a
resolution of 0.01 second, so the value of tv_usec on successive calls
might be:
    420000
    420001
    420002
    430000
    430001
    430002
    ...
I don't remember whether the implicit counter was per-process or
system-wide.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#87247

On 11/4/2022 5:05 PM, Keith Thompson wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> On 11/4/2022 2:35 AM, Juha Nieminen wrote:
>>> In comp.lang.c++ Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>> What is the best way to get microseconds of time on Windows in C or C++
>>> It's a bit unclear whether you mean "time in microseconds units" or
>>> "time
>>> at the microseconds resolution".
>>> Because the latter may not be even possible (portable or not). Just
>>> because
>>> some time function returns time "in microseconds" that doesn't mean that it
>>> uses microsecond resolution (in other words, the value it returns may well
>>> change at longer intervals than every microsecond; probably *significantly*
>>> longer intervals).
>>> It is possible to get some kind of timing at the CPU clock cycle
>>> interval
>>> (in most modern CPUs, at least), which is about as accurate as you can
>>> possibly get, but I don't know if there are eg. some system functions that
>>> will return elapsed clock cycles converted into the equivalent amount of
>>> microseconds.
>>
>> Get time at the microseconds resolution.   My calculation engine
>> creates a bunch of temporary files and I use the time to create unique
>> names for those temporary files.  Seconds should be good enough for
>> uniqueness but I like adding microseconds as a guarantee.  Something
>> like
>>     uniquac1.out.009.20181972.20220912
> 
> An alternative is to keep a counter, incremented for each generated file
> name, and append it to the file name, perhaps resetting to 0 when the
> seconds count advances.  If your only requirement is uniqueness, that
> should be good enough.
> 
> Digression: I remember an implementation of gettimeofday() that did
> something like that (on SunOS, maybe?).  The system clock had a
> resolution of 0.01 second, so the value of tv_usec on successive calls
> might be:
>      420000
>      420001
>      420002
>      430000
>      430001
>      430002
>      ...
> I don't remember whether the implicit counter was per-process or
> system-wide.

The problem is multiple instances of the same program creating the same 
name files.

Lynn

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web