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

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

Cool !

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

Contents

  Cool ! Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-08 19:25 +0200
    Unbelievable Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-09 08:01 +0200
      Re: Unbelievable Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-09 08:17 +0200
        Re: Unbelievable scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 13:57 +0000
          Re: Unbelievable Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-09 16:18 +0200
            Re: Unbelievable scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 16:01 +0000
              Re: Unbelievable Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-10 12:11 +0200
                Re: Unbelievable scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:44 +0000
                  Re: Unbelievable Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-10 17:40 +0200
                    Re: Unbelievable scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 15:49 +0000
                      Re: Unbelievable Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-10 19:03 +0200
                      Re: Unbelievable David Brown <david.brown@hesbynett.no> - 2023-08-11 08:28 +0200
                        Re: Unbelievable Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-11 09:17 +0200
                          Re: Unbelievable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-11 12:02 +0100
                          Re: Unbelievable Paavo Helde <eesnimi@osa.pri.ee> - 2023-08-11 15:31 +0300

#91214 — Cool !

I can have native FILETIME in C++:

#include <Windows.h>
#include <iostream>
#include <chrono>

using namespace std;
using namespace chrono;

int main()
{
	int64_t sinceEpoch = file_clock::now().time_since_epoch().count(), ft;
	do
		sinceEpoch = file_clock::now().time_since_epoch().count(),
		GetSystemTimeAsFileTime( &(FILETIME &)ft );
	while( sinceEpoch != ft );
	cout << "C++: " << sinceEpoch << endl;
	cout << "Win32: " << ft << endl;
}

[toc] | [next] | [standalone]

#91218 — Unbelievable

I disassembled GetSystemTimeAsFileTime() some years ago and it used
x86's RDTSC internally. But now it switched to a memory-mapped hard-
ware register with about millisecond resolution. Before it had 100ns
-resolution.

#include <Windows.h>
#include <iostream>
#include <chrono>

using namespace std;
using namespace chrono;

int main()
{
	constexpr int64_t ROUNDS = 100'000'000;
	auto tGet = []()
	{
		int64_t t;
		GetSystemTimeAsFileTime( &(FILETIME &)t );
		return t;
	};
	int64_t tSum = 0, n = 0, tBefore = tGet();
	for( int64_t r = ROUNDS, t, tDiff; r--; )
		t = tGet(),
		tDiff = t - tBefore,
		tSum += tDiff,
		n += (bool)tDiff,
		tBefore = t;
	cout << (double)tSum / n << endl;
}

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

#91219 — Re: Unbelievable

I got it: they don't use the TSC anymore because there might be
still machines with invariant TSC and because the TSC would not
be contignous across virtual machine migrations. That's while
there's GetSystemTimePreciseAsFileTime, which is still up to
the TSC.
But the're for sure no x64-machines with invariant TSC. And to
manage virtual machine migrations Intel could have added an off-
set added to the TSC before it is read which is set by the kernel.


#include <Windows.h>
#include <iostream>
#include <chrono>

using namespace std;
using namespace chrono;

int main()
{
	auto tDo = []( char const *what, void (*fn)( FILETIME * ) )
	{
		constexpr int64_t ROUNDS = 100'000'000;
		auto tGet = [&]()
		{
			int64_t t;
			fn( &(FILETIME &)t );
			return t;
		};
		int64_t tSum = 0, n = 0, tBefore = tGet();
		for( int64_t r = ROUNDS, t, tDiff; r--; )
			t = tGet(),
			tDiff = t - tBefore,
			tSum += tDiff,
			n += (bool)tDiff,
			tBefore = t;
		cout << (double)tSum / n << endl;
	};
	tDo( "precise: ", GetSystemTimePreciseAsFileTime );
	tDo( "relaxed: ", GetSystemTimeAsFileTime );
}

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

#91228 — Re: Unbelievable

Bonita Montero <Bonita.Montero@gmail.com> writes:

>But the're for sure no x64-machines with invariant TSC.

Perhaps that is a mistranslation from deutsch?

All modern x64 processors support invariant (and nonstop) TSC.  That
doesn't mean that there are no x86 processors
running production code that do not support invariant TSC.

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

#91229 — Re: Unbelievable

Am 09.08.2023 um 15:57 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
> 
>> But the're for sure no x64-machines with invariant TSC.
> 
> Perhaps that is a mistranslation from deutsch?

No, that's still the reason. I know that x86 CPUs have
had invariant TSCs for a long time, x64 CPUs anyway.

I wonder if the argument that the TSC isn't used because it's
not portable across VM boundaries makes sense. The TSC is con-
verted into a timestamp that indicates the 100ns steps since
1/1/1601, and the offset that is selected for this is certainly
not absolutely precise. Also, migrating a VM takes quite a long
time and never  guarantees exactly the same time. In this res-
pect, it would not be a problem to map GetSystemTimeAsFileTime()
directly to GetSystemTimePreciseAsFileTime(). The Microsoft
engineers probably didn't think about it.

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

#91233 — Re: Unbelievable

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 09.08.2023 um 15:57 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> 
>>> But the're for sure no x64-machines with invariant TSC.
>> 
>> Perhaps that is a mistranslation from deutsch?
>
>No, that's still the reason. I know that x86 CPUs have
>had invariant TSCs for a long time, x64 CPUs anyway.
>
>I wonder if the argument that the TSC isn't used because it's
>not portable across VM boundaries makes sense.

I suspect it is because nanosecond resolution on a filesystem
timestamp is neither possible nor useful.

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

#91238 — Re: Unbelievable

Am 09.08.2023 um 18:01 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 09.08.2023 um 15:57 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> But the're for sure no x64-machines with invariant TSC.
>>>
>>> Perhaps that is a mistranslation from deutsch?
>>
>> No, that's still the reason. I know that x86 CPUs have
>> had invariant TSCs for a long time, x64 CPUs anyway.
>>
>> I wonder if the argument that the TSC isn't used because it's
>> not portable across VM boundaries makes sense.
> 
> I suspect it is because nanosecond resolution on a filesystem
> timestamp is neither possible nor useful.

FILETIME isn't at nanosecond-resolution but in 100ns-steps. If you'd
have a 100ns interval timestamp sine 1/1/1601 00:00.0 the timestamp
would have ended 7/21/2185 23:34:33.71. Microsoft expects that Windows
wil last longer (about 30828). ;-)

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

#91239 — Re: Unbelievable

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 09.08.2023 um 18:01 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 09.08.2023 um 15:57 schrieb Scott Lurndal:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>
>>>>> But the're for sure no x64-machines with invariant TSC.
>>>>
>>>> Perhaps that is a mistranslation from deutsch?
>>>
>>> No, that's still the reason. I know that x86 CPUs have
>>> had invariant TSCs for a long time, x64 CPUs anyway.
>>>
>>> I wonder if the argument that the TSC isn't used because it's
>>> not portable across VM boundaries makes sense.
>> 
>> I suspect it is because nanosecond resolution on a filesystem
>> timestamp is neither possible nor useful.
>
>FILETIME isn't at nanosecond-resolution but in 100ns-steps. If you'd
>have a 100ns interval timestamp sine 1/1/1601 00:00.0 the timestamp
>would have ended 7/21/2185 23:34:33.71. Microsoft expects that Windows
>wil last longer (about 30828). ;-)

That kind of resolution is only available if the underlying filesystem
metadata (e.g. inode) supports it.  Most filesystems (particularly
legacy filesystems) support one second resolution.  There may be some
that support sub-second (perhaps 10ms) resolution, but that is far
from universal.

What would the use case be for higher resolution filesystem timestamps stored
in metadata (which increases the size of the metadata, reducing
the amount of storage available for data by some small factor)?

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

#91240 — Re: Unbelievable

Am 10.08.2023 um 16:44 schrieb Scott Lurndal:

> That kind of resolution is only available if the underlying filesystem
> metadata (e.g. inode) supports it.  Most filesystems (particularly
> legacy filesystems) support one second resolution.  There may be some
> that support sub-second (perhaps 10ms) resolution, but that is far
> from universal.

file_clock::timestamp with that resolution could be used independent
from any file-operations, just like results from GetSystemTimeAsFileTime
is usually not used for file operations.

> What would the use case be for higher resolution filesystem timestamps
> stored in metadata (which increases the size of the metadata, ...

No one cares for three 64 bit values for the file's metadata.

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

#91241 — Re: Unbelievable

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 10.08.2023 um 16:44 schrieb Scott Lurndal:
>
>> That kind of resolution is only available if the underlying filesystem
>> metadata (e.g. inode) supports it.  Most filesystems (particularly
>> legacy filesystems) support one second resolution.  There may be some
>> that support sub-second (perhaps 10ms) resolution, but that is far
>> from universal.
>
>file_clock::timestamp with that resolution could be used independent
>from any file-operations, just like results from GetSystemTimeAsFileTime
>is usually not used for file operations.
>
>> What would the use case be for higher resolution filesystem timestamps
>> stored in metadata (which increases the size of the metadata, ...
>
>No one cares for three 64 bit values for the file's metadata.

Sure they do.  If supporting 64-bit values causes the metadata size
to require additional storage space on the volume, that's a cost.

In any case, none of the existing filesystems, widely used, would
be willing to make such a change, so your point is moot.

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

#91242 — Re: Unbelievable

Am 10.08.2023 um 17:49 schrieb Scott Lurndal:

> Sure they do.  If supporting 64-bit values causes the metadata size
> to require additional storage space on the volume, that's a cost.

Wo really cares for that ? Imagine you have a small cluster size of
4kB and you have the smallest possible size of one cluster, then the
additional overhead is 12 byte against 4kB, that's 3 per thousand,
dimishing when the file becomes bigger. If the cluster size is larger
the part is even smaller.

> In any case, none of the existing filesystems, widely used,
> would be willing to make such a change, so your point is moot.

You couldn't change existing filesstems for that without
changing the API. This would never change for Unix systems.

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

#91244 — Re: Unbelievable

On 10/08/2023 17:49, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 10.08.2023 um 16:44 schrieb Scott Lurndal:
>>
>>> That kind of resolution is only available if the underlying filesystem
>>> metadata (e.g. inode) supports it.  Most filesystems (particularly
>>> legacy filesystems) support one second resolution.  There may be some
>>> that support sub-second (perhaps 10ms) resolution, but that is far
>>> from universal.
>>
>> file_clock::timestamp with that resolution could be used independent
>>from any file-operations, just like results from GetSystemTimeAsFileTime
>> is usually not used for file operations.
>>
>>> What would the use case be for higher resolution filesystem timestamps
>>> stored in metadata (which increases the size of the metadata, ...
>>
>> No one cares for three 64 bit values for the file's metadata.
> 
> Sure they do.  If supporting 64-bit values causes the metadata size
> to require additional storage space on the volume, that's a cost.
> 
> In any case, none of the existing filesystems, widely used, would
> be willing to make such a change, so your point is moot.
> 

ext4 has nanosecond resolution for its timestamps - and that is, I would 
argue, quite a widely used filesystem.

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

#91245 — Re: Unbelievable

Am 11.08.2023 um 08:28 schrieb David Brown:

> ext4 has nanosecond resolution for its timestamps - and
> that is, I would  argue, quite a widely used filesystem.

And what's the API to use that ?
For sure not stat(), because that uses time_t timestamps.

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

#91246 — Re: Unbelievable

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 11.08.2023 um 08:28 schrieb David Brown:
>
>> ext4 has nanosecond resolution for its timestamps - and
>> that is, I would  argue, quite a widely used filesystem.
>
> And what's the API to use that ?

Various, including stat(2).

> For sure not stat(), because that uses time_t timestamps.

Modern stat(2) uses struct timespec fields with #defines that make
st_[acm]time access the 'seconds' part of the timespec.

-- 
Ben.

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

#91247 — Re: Unbelievable

11.08.2023 10:17 Bonita Montero kirjutas:
> Am 11.08.2023 um 08:28 schrieb David Brown:
> 
>> ext4 has nanosecond resolution for its timestamps - and
>> that is, I would  argue, quite a widely used filesystem.
> 
> And what's the API to use that ?
> For sure not stat(), because that uses time_t timestamps.

Some quick googling says:

"Since kernel 2.5.48, the stat structure supports nanosecond resolution 
for the three file timestamp fields."

Glibc is exposing these fields in form stat.st_mtim.tv_nsec et al.

[toc] | [prev] | [standalone]

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

csiph-web