-
Notifications
You must be signed in to change notification settings - Fork 816
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Support truncate function #8
Comments
That's a good suggestions. I'm hesitant, since I want to keep the scope of this project small and contained. But a truncate function would be more efficient than existing functions, since it can reuse old data on the disk. I'm thinking of adding a function with this API when I get the chance: int lfs_file_truncate(lfs_t *lfs, lfs_file_t *file, lfs_off_t size); |
Here we go: d88f0ac Let me know if you run into any issues. |
Is it possible to update littlefs-fuse as well? You might want to take a look at the git submodule feature. This way you don't have to update such projects by its own. |
Sure thing, here you go: littlefs-project/littlefs-fuse@ed8713c Instead of using git submodules, littlefs-fuse is using git subtrees. If you wanted to switch to the most up to date branch, you could merge in littlefs's master yourself: $ cd littlefs-fuse
$ git remote add -f littlefs git@github.com:geky/littlefs
$ git subtree merge --prefix=littlefs littlefs/master --squash The reason for not using submodules is that submodules adds an extra user step that isn't intuitive, whereas with subtrees all the user needs to do is clone and they're ready to go. |
We're using parity a lot more than popc now (actually, now that we don't use CTZ skip-lists, do we use popc at all?), so it makes sense to the compiler's __builtin_parity intrinsic when possible. On some processors parity can be much cheaper than popc. Notably, the 8080 family just includes a parity flag in the set of carry flags that are implicitly updated on most ALU operations. Though I think this approach didn't scale, you don't really see parity flags on most >8-bit architectures... Unfortunately, ARM thumb, our test arch, does not have a popc or parity instruction. I guess because thanks to implicit shifts in most instructions, the tree-reduction solution is surprisingly cheap: ea80 4010 eor.w r0, r0, r0, lsr #16 ea80 2010 eor.w r0, r0, r0, lsr #8 ea80 1010 eor.w r0, r0, r0, lsr #4 ea80 00c0 eor.w r0, r0, r0, lsr #2 ea80 0050 eor.w r0, r0, r0, lsr #1 f000 0001 and.w r0, r0, #1 Both popc and parity benefit from this (GCC 11): code __popcountsi2: 40 __paritysi2: 32 (-20.0%) So, thumb is not an arch where we see much benefit: code stack before: 33908 2840 after: 33924 (+0.0%) 2840 (+0.0%) Not really sure where the +16 bytes come from, we removed several masks, so I guess it's just bool vs in compiler noise? Still, this may be useful for other archs with parity instructions/ hardware.
We're using parity a lot more than popc now (actually, now that we don't use CTZ skip-lists, do we use popc at all?), so it makes sense to the compiler's __builtin_parity intrinsic when possible. On some processors parity can be much cheaper than popc. Notably, the 8080 family just includes a parity flag in the set of carry flags that are implicitly updated on most ALU operations. Though I think this approach didn't scale, you don't really see parity flags on most >8-bit architectures... Unfortunately, ARM thumb, our test arch, does not have a popc or parity instruction. I guess because thanks to implicit shifts in most instructions, the tree-reduction solution is surprisingly cheap: ea80 4010 eor.w r0, r0, r0, lsr #16 ea80 2010 eor.w r0, r0, r0, lsr #8 ea80 1010 eor.w r0, r0, r0, lsr #4 ea80 00c0 eor.w r0, r0, r0, lsr #2 ea80 0050 eor.w r0, r0, r0, lsr #1 f000 0001 and.w r0, r0, #1 Both popc and parity benefit from this (GCC 11): code __popcountsi2: 40 __paritysi2: 32 (-20.0%) So, thumb is not an arch where we see much benefit: code stack before: 33908 2824 after: 33924 (+0.0%) 2824 (+0.0%) Not really sure where the +16 bytes come from, we removed several masks, so I guess it's just bool vs in compiler noise? Still, this may be useful for other archs with parity instructions/ hardware.
If possible support for truncate would be useful, e.g.
int truncate(const char *path, off_t length);
or using the file handle like ftruncate
The text was updated successfully, but these errors were encountered: