llvm dev - Aug 2018 - [cfe-dev] Filesystem has Landed in Libc++

On Aug 10, 2018, at 9:35 PM, Eric Fiselier <eric at efcs.ca>
wrote:
> 
> Part of me is still concerned with the future, and the filesystems which
are yet to exist.
> 
Me too.  But it is best to target modern systems when targeting future systems
adds an unnecessary cost.  When future systems come into being, it is likely
because future hardware is making those future systems practical.

E.g. nanosecond precision file systems were not produced prior to the widespread
adoption of 64 bit hardware.  Mainly because they were just too expensive on 32
bit hardware.

In the future, we will have a better shot at dealing with that future.  The
std::lib we write today will have to evolve, no matter what we do today.  Future
proof where it is practical to do so, and don’t where it isn’t.

Howard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/5e73a64f/attachment.sig>

On Fri, Aug 10, 2018 at 10:41 PM Howard Hinnant <howard.hinnant at
gmail.com>
wrote:
> On Aug 10, 2018, at 9:35 PM, Eric Fiselier <eric at efcs.ca> wrote:
> >
> > Part of me is still concerned with the future, and the filesystems
which
> are yet to exist.
> >
>
> Me too.  But it is best to target modern systems when targeting future
> systems adds an unnecessary cost.  When future systems come into being, it
> is likely because future hardware is making those future systems practical.
>
I'll have to write benchmarks which demonstrate the actual cost of the 128
operations which users might commonly cause to be performed.

>
> E.g. nanosecond precision file systems were not produced prior to the
> widespread adoption of 64 bit hardware.  Mainly because they were just too
> expensive on 32 bit hardware.
>
> In the future, we will have a better shot at dealing with that future.
> The std::lib we write today will have to evolve, no matter what we do
> today.  Future proof where it is practical to do so, and don’t where it
> isn’t.
>
As you're well aware, ABI evolution isn't quite that simple.

>
> Howard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/d0d37eb2/attachment.html>

Btrfs stores 64-bit sec, and 32-bit nsec on disk, and you can set and get
it fine on linux. I think it'd be a very bad idea to use a return type
which must truncate the timestamp info from the filesystem.

Demo (on a btrfs partition):
$ touch -d '9000-04-21 09:45:12.123456789' asdf
$ ls -l --time-style=full-iso
-rw-r--r-- 1 jyknight users   0 9000-04-21 09:45:12.123456789 -0400 asdf

If the efficiency of 128-bit math was a concern, a different API for
std::filesystem should've been used, with separate sec/nsec fields. But,
seems too late for that now.

In fact, I now have the precise _opposite_ concern of Howard: I'm concerned
that on 32-bit systems, libc++'s std::filesystem only uses a 64-bit type
("long long") for its timestamps, and _NOT_ the >=94-bit type which
is
required for correctness.

(Note that many 32-bit platforms are already using a 64-bit time_t, and
others like Linux/i386 are in the midst of planning and executing on that
transition -- being 32-bit is no excuse for being wrong.)

Since AFAIK no compilers support __int128 on 32-bit platforms, I suppose a
custom class will need to be used, like <
https://github.com/abseil/abseil-cpp/blob/master/absl/numeric/int128.h>...




On Fri, Aug 10, 2018 at 10:41 PM Howard Hinnant via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Aug 10, 2018, at 9:35 PM, Eric Fiselier <eric at efcs.ca> wrote:
> >
> > Part of me is still concerned with the future, and the filesystems
which
> are yet to exist.
> >
>
> Me too.  But it is best to target modern systems when targeting future
> systems adds an unnecessary cost.  When future systems come into being, it
> is likely because future hardware is making those future systems practical.
>
> E.g. nanosecond precision file systems were not produced prior to the
> widespread adoption of 64 bit hardware.  Mainly because they were just too
> expensive on 32 bit hardware.
>
> In the future, we will have a better shot at dealing with that future.
> The std::lib we write today will have to evolve, no matter what we do
> today.  Future proof where it is practical to do so, and don’t where it
> isn’t.
>
> Howard
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/6c625b2f/attachment-0001.html>

On Aug 10, 2018, at 11:47 PM, James Y Knight <jyknight at google.com>
wrote:
> 
> Btrfs stores 64-bit sec, and 32-bit nsec on disk, and you can set and get
it fine on linux.
A 128 bit time_point seems like a good way to model those platforms that can
mount Btrfs.  A 128 bit time_point does not seem like a good way to model those
platforms which can only support 64 bit time stamps.

The authors of a std::lib should write non-portable code so that I don’t have
to.

Howard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180811/6e9603ac/attachment.sig>