Skip to content
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

Closed
rocuh opened this issue Jan 11, 2018 · 4 comments
Closed

Support truncate function #8

rocuh opened this issue Jan 11, 2018 · 4 comments

Comments

@rocuh
Copy link

rocuh commented Jan 11, 2018

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

@geky
Copy link
Member

geky commented Jan 12, 2018

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);

@geky
Copy link
Member

geky commented Jan 21, 2018

Here we go: d88f0ac

Let me know if you run into any issues.

@s-macke
Copy link

s-macke commented Jan 21, 2018

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.

@geky
Copy link
Member

geky commented Jan 23, 2018

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.

@geky geky closed this as completed Jan 29, 2018
geky added a commit that referenced this issue May 1, 2024
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.
geky added a commit that referenced this issue May 6, 2024
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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants