Live data from Hacker News

Filesystem devs should aim to make “badly written” app code “just work” (2009)

lwn.net

81–90 of 117 posts

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#81
post #29

I think he's got a point. As a developer I find myself in a different scenario. I'm usually trying to find out what exactly the 100% guaranteed way to do something is. Instead, I find incomplete documentation and different people with different opinions on what the guarantees are, and most people writing bad code that they assume will usually work. Just modifying a file in an atomic way requires a complicated dance o…

I do, but it's not a popular opinion. POSIX, and by extension, the classic 1960s-1980s era UNIX way of doing things just needs die a long overdue death. This stuff was designed at a time when every CPU instruction mattered, everything was optimised to death for frugality, and commands were abbreviated from "copy" to "cp" because ermahgerd two bytes is a huge saving! That mentality got us Y2K. This is an era where lat…

Your comment reminds me of the situation of game engines and 3D graphics APIs a few years ago before Vulkan and Metal were released. Too high-level for developers who want control (and understand how the hardware actually works), but too low-level for developers who want to minimize complexity.

Now, Vulkan and Metal offer the detailed control for library developers, and everyone else uses some higher-level wrapper.

Does it make sense to split the file system in a similar way? I guess the main challenge is avoiding too many competing wrappers.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#82
post #80
post #59

I'd argue that UNIX-type file systems should offer several types of files: * Unit files. When you create a file and write it, it's not visible for other opens until you close it. If you open a file with O_CREAT|O_WRONLY|O_TRUNC, you create a new file, which replaces the old one on close. In the event of a program or system crash, or exiting via "abort" without closing first, the old file remains. So there's always on…

Nagle, I believe I last read your comment on this ( https://news.ycombinator.com/item?id=13964053 ), progress has been made . We have the temporary files you're asking for. https://lwn.net/Articles/619146/ With O_TMPFILE, you can also write new data, and then automatically replace a file on disk.

With O_TMPFILE, you can also write new data, and then automatically replace a file on disk.

How? Using "linkat"? That's not automatic.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#83
post #5

"Anybody who wants more complex and subtle filesystem interfaces is just crazy. Not only will they never get used, they'll definitely not be stable." I think there is a more universal truism here - that "complex and subtle" are sources of pain, problems and headaches. I want to write "cool" and "magical" code as much as the next person, but that's the stuff that I look at later WTF because I am no longer in the same…

The more time I spend as a dev, the more I realize that writing clear, simple, straight forward code is actually the greater challenge. When I started progressing beyond learning the basics, the sort of projects I was building were quite simple, so writing the simple code for them came to feel boring. I would read complex codebases and see all the fascinating tricks they employed and wished I was writing code like th…

> It felt like, "Those are the smart programmers. I should emulate them."

That’s probably the main reason why so many C++ codebases are unnecessarily complicated. People look at what standard library developers did, and emulating it.

The complexity of the standard library is actually justified: containers need to scale from 1 to 1E9 items and more, algorithms need to work with whatever broken classes users throw at them, the whole standard library needs to be extremely generic.

None of these requirements apply to code of most applications, yet I have seen many C++ projects where people designed their code the same way the standard library is designed, without thinking about the reasons. The result is template heavy code which takes long time to compile, and hard to modify or debug.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#84
post #59

I'd argue that UNIX-type file systems should offer several types of files: * Unit files. When you create a file and write it, it's not visible for other opens until you close it. If you open a file with O_CREAT|O_WRONLY|O_TRUNC, you create a new file, which replaces the old one on close. In the event of a program or system crash, or exiting via "abort" without closing first, the old file remains. So there's always on…

> * Temporary files. You can do all the file operations, and the file disappears on a reboot. It would be nice to be able to have a process tree own a temporary file, such that when the last process in the tree exits (not necessarily the process which created the file), the file is automatically deleted, rather than having to wait for the next reboot.

Can't you create file, unlink it and then fork as much as necessary? I think that OS will maintain reference counter for that inode and will delete it when all processes will close that handle (explicitly or implicitly with exit).

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#85
post #75

Earlier quoted context omitted.

I am currently trying to wring maximum performance from Cloud TPUs. This comment really resonated with me, because Cloud TPUs are complex, subtle, overly complicated, and have twenty opaque ways that you can ruin your performance. Compare that with a GPU. It took decades, but (at least for nvidia GPUs) they have finally reached the point where you can be at least reasonably certain that high-performance is the defaul…

Anecdotally, I have seen 50-100x (seriously) increases when moving from a V100 to TPUv3. To be fair, some of that is batch size increase. This was using the models in https://github.com/tensorflow/tpu/tree/master/models/officia... . On the other hand, a lot of those models are broken in some way and need fixing before running, caveat emptor.

Can you be more specific? I have seen many such claims, and every time I try to reproduce the results, there always seems to be some catch.

We're trying to use TPUs to fine tune GPT-2 1.5B. The model takes up 5.8GB memory, which is well over half of a TPUv2 core (8GB). It always OOMs when I try to do a training step, due to the gradient calculations requiring memory. It even OOMs on a TPUv3, which has 16GB per core. I've tried using bfloat16 (which ought to cut memory usage in half) and using Ada optimizer (which should be no more expensive than plain old SGD). Yet if I colocate the gradients to the same core as the model, I always OOM. (Colocation just means "don't use any memory except the memory physically on this one core.") With colocation off, I don't OOM, and I do see some speed gains using all 8 cores. But it's no more than a factor of 2x, and in fact closer to like 1.15x (i.e. it's roughly equivalent to just using larger batch sizes on a single core). And I don't understand why I'd OOM in the TPUv3 case; even with float32, the model is only using 5.8GB out of 16GB. Are gradient computations really taking up more than 10GB for the optimizer? (That leads to https://github.com/cybertronai/gradient-checkpointing and such, but I haven't tried it yet.)

If I try the same experiment with a much smaller model (117M, or about 13x smaller), I can successfully colocate the gradients onto the same core as the model. And when I use all eight cores, I'm able to get 1225 tokens/sec (roughly 1 example per second, since 1 example = 1024 tokens for GPT-2), vs the standard case of around 400 tokens/sec when using only one core. But that's still "only" a 3x speedup.

So when I see "50-100x increases," alarm bells start going off. I'm missing something fundamental here. Either you are getting 100x speedups, or I am somehow missing something fundamental.

People have even started asking me for answers regarding the TPU case, and I'm forced to be like "Yeah! I expected TPUs to be so much faster too. Everyone says they're getting 100x speed gains. Yet we're 11x slower than the GPU case, and here's a notebook showing a 11x slowdown."

https://github.com/shawwn/gpt-2/issues/5

I'm suspecting that memory bandwidth is the bottleneck here for large models. This paper even pretty much says "GPUs are more flexible and faster when memory bandwidth is an issue": https://twitter.com/mosicr/status/1196749286815481856

The closest I've come to finding an actual example of a speedup to aim for is this: https://github.com/imcaspar/gpt2-ml

They used a TPUv3-512 pod to train a GPT-2 1.5B model to 99k steps in 50 hours. If you work out the math, that's about 1 example per second. We're getting about 0.08 examples per second on a single TPUv2 core. So yes, it's a big speedup (12.5x) but certainly not 50-100x. Yet it has 64x the cores as my TPUv2; why isn't it 64x faster? And we're only using 1 core; why not 512x faster?

I have also tried this on TPUv3-8, and we're getting about the same examples/sec, further increasing the plausibility of the theory that memory bandwidth is the bottleneck.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#86
post #59

I'd argue that UNIX-type file systems should offer several types of files: * Unit files. When you create a file and write it, it's not visible for other opens until you close it. If you open a file with O_CREAT|O_WRONLY|O_TRUNC, you create a new file, which replaces the old one on close. In the event of a program or system crash, or exiting via "abort" without closing first, the old file remains. So there's always on…

> Unit files. ... you create a new file, which replaces the old one on close.

Classic MacOS-9 had the PBExchangeFiles call which did this perfectly. Before call:

    dirEntryA -> fileContentsA     
    dirEntryB -> fileContentsB     
after call

    dirEntryA -> fileContentsB     
    dirEntryB -> fileContentsA     
This meant that the user kept all meta info for files, e.g. tags, window position, custom icons, etc.

So when saving a new document you wrote it to a new hidden temp file, and when everything was written, you called PBExchangeFiles to swap the contents of the old and new files. After this you deleted your temp file which now contained the old document content.

http://mirror.informatimago.com/next/developer.apple.com/doc...

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#87
post #29

I think he's got a point. As a developer I find myself in a different scenario. I'm usually trying to find out what exactly the 100% guaranteed way to do something is. Instead, I find incomplete documentation and different people with different opinions on what the guarantees are, and most people writing bad code that they assume will usually work. Just modifying a file in an atomic way requires a complicated dance o…

I do, but it's not a popular opinion. POSIX, and by extension, the classic 1960s-1980s era UNIX way of doing things just needs die a long overdue death. This stuff was designed at a time when every CPU instruction mattered, everything was optimised to death for frugality, and commands were abbreviated from "copy" to "cp" because ermahgerd two bytes is a huge saving! That mentality got us Y2K. This is an era where lat…

I give it 2-3 more years of people saying "this is impossible" before Lennart does it and makes everyone mad

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#88
post #5

"Anybody who wants more complex and subtle filesystem interfaces is just crazy. Not only will they never get used, they'll definitely not be stable." I think there is a more universal truism here - that "complex and subtle" are sources of pain, problems and headaches. I want to write "cool" and "magical" code as much as the next person, but that's the stuff that I look at later WTF because I am no longer in the same…

The more time I spend as a dev, the more I realize that writing clear, simple, straight forward code is actually the greater challenge. When I started progressing beyond learning the basics, the sort of projects I was building were quite simple, so writing the simple code for them came to feel boring. I would read complex codebases and see all the fascinating tricks they employed and wished I was writing code like th…

Problem is when you have a shitty language like Python that does almost no optimisations so you're forced to write "clever" code if you want it to run reasonably fast.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#89

> The undeniable FACT that people don't tend to check errors from close() should, for example, mean that delayed allocation must still track disk full conditions, for example. If your filesystem returns ENOSPC at close() rather than at write(), you just lost error coverage for disk full cases from 90% of all apps. It's that simple. Most programmers abstraction of a computer system is synchronous and consistent. If yo…

This could be summarised as: don't assume the responsibility to do something correctly if you don't have to, and whoever has to do it otherwise is more competent than you.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#90
post #81

Earlier quoted context omitted.

I do, but it's not a popular opinion. POSIX, and by extension, the classic 1960s-1980s era UNIX way of doing things just needs die a long overdue death. This stuff was designed at a time when every CPU instruction mattered, everything was optimised to death for frugality, and commands were abbreviated from "copy" to "cp" because ermahgerd two bytes is a huge saving! That mentality got us Y2K. This is an era where lat…

Your comment reminds me of the situation of game engines and 3D graphics APIs a few years ago before Vulkan and Metal were released. Too high-level for developers who want control (and understand how the hardware actually works), but too low-level for developers who want to minimize complexity. Now, Vulkan and Metal offer the detailed control for library developers, and everyone else uses some higher-level wrapper. D…

The problem with Vulkan is even graphics driver developers struggle to use it correctly.
Post reply on HN