3 ms·

They claim higher performance for nnn than mc. Not sure it’s really needed in most cases though... but nnn could come in handy in edge cases of really large dir

by janekm 9y ago

They claim higher performance for nnn than mc. Not sure it’s really needed in most cases though... but nnn could come in handy in edge cases of really large directories, say. BTW their docs say that they avoid div instructions in favour of floating point multiply. Is this still faster on recent CPUs?

apjana 9y ago
I can't be very specific without citing examples. The following APIs may explain what I mean: https://github.com/jarun/nnn/blob/master/nnn.c#L358 https://github.com/jarun/nnn/blob/master/nnn.c#L358 https://github.com/jarun/nnn/blob/master/nnn.c#L1267 https://github.com/jarun/nnn/blob/master/nnn.c#L1267 https://github.com/jarun/nnn/blob/master/nnn.c#L1617 https://github.com/jarun/nnn/blob/master/nnn.c#L1617 Most of the functions in nnn are targeted to be high-performance like these.
- fredericoqq 9y ago
  Hmm. I'm not convinced any of your routines are more "high-performance" than the standard-library, have you benchmarked them? For example, I don't think your getorder() could possibly be faster than __builtin_ctz(), or even a wrapper around ffs(). You also hardcoded the size of size_t to 32 bits, so it's not more portable than those options. Edit: I checked, ffs is a tiny branch-free routine in glibc: (gdb) disassemble ffs Dump of assembler code for function ffsl: 0x0007e9d0 <+0>: mov $0xffffffff,%edx 0x0007e9d5 <+5>: bsf 0x4(%esp),%eax 0x0007e9da <+10>: cmove %edx,%eax 0x0007e9dd <+13>: add $0x1,%eax 0x0007e9e0 <+16>: ret End of assembler dump.
  - apjana 9y ago
    > __builtin_ctz avoided it to stay out of compiler-specific stuff. we do have plans to replace getorder() with ffsl(). Perhaps I would be more accurate if I say nnn is faster by design. Movement of data around memory is minimal. No redundant bytes are allocated. We use quicksort and optimize further by pushing non-matches down right away so they never appear in a filter comparison again. And of course, using non-lib custom functions enable using static linkage, having a controlled binary size and removing redundant checks/processing because the limits and borderline cases are known.
    - deleted 9y ago
      [deleted]
kees99 9y ago
> avoid div instructions in favour of floating point multiply. > Is this still faster on recent CPUs? NB - >>[Taking this question out of context]<< - looks like the answer is "no". From a quick test: - intel Broadwell: 64-bit integer div is fastest, float div is 69% slower, float mul is 50% slower; - AMD Ryzen: 64-bit integer div is fastest, float div is 47% slower, float mul is 60% slower; - ARM11 (Raspberry Zero): 64-bit integer div is fastest, float div is 138% slower, float mul is 159% slower. quick-and-dirty test used: https://pastebin.com/raw/4XqnuXL5 https://pastebin.com/raw/4XqnuXL5
- apjana 9y ago
  We don't have the case of integer div. And if you take a look into the coolsize() func we don't re-compute the factor. So it's not very significant. To get the size of a file we multiply only once with this factor. What is significant is the while() loop where the iterations increase with the file size. There's no mul or div in it giving the API a reasonable performance benefit.

by janekm 9y ago

apjana 9y ago

I can't be very specific without citing examples. The following APIs may explain what I mean: https://github.com/jarun/nnn/blob/master/nnn.c#L358 https://github.com/jarun/nnn/blob/master/nnn.c#L358 https://github.com/jarun/nnn/blob/master/nnn.c#L1267 https://github.com/jarun/nnn/blob/master/nnn.c#L1267 https://github.com/jarun/nnn/blob/master/nnn.c#L1617 https://github.com/jarun/nnn/blob/master/nnn.c#L1617 Most of the functions in nnn are targeted to be high-performance like these.

fredericoqq 9y ago
Hmm. I'm not convinced any of your routines are more "high-performance" than the standard-library, have you benchmarked them? For example, I don't think your getorder() could possibly be faster than __builtin_ctz(), or even a wrapper around ffs(). You also hardcoded the size of size_t to 32 bits, so it's not more portable than those options. Edit: I checked, ffs is a tiny branch-free routine in glibc: (gdb) disassemble ffs Dump of assembler code for function ffsl: 0x0007e9d0 <+0>: mov $0xffffffff,%edx 0x0007e9d5 <+5>: bsf 0x4(%esp),%eax 0x0007e9da <+10>: cmove %edx,%eax 0x0007e9dd <+13>: add $0x1,%eax 0x0007e9e0 <+16>: ret End of assembler dump.
- apjana 9y ago
  > __builtin_ctz avoided it to stay out of compiler-specific stuff. we do have plans to replace getorder() with ffsl(). Perhaps I would be more accurate if I say nnn is faster by design. Movement of data around memory is minimal. No redundant bytes are allocated. We use quicksort and optimize further by pushing non-matches down right away so they never appear in a filter comparison again. And of course, using non-lib custom functions enable using static linkage, having a controlled binary size and removing redundant checks/processing because the limits and borderline cases are known.
  - deleted 9y ago
    [deleted]

kees99 9y ago

> avoid div instructions in favour of floating point multiply. > Is this still faster on recent CPUs? NB - >>[Taking this question out of context]<< - looks like the answer is "no". From a quick test: - intel Broadwell: 64-bit integer div is fastest, float div is 69% slower, float mul is 50% slower; - AMD Ryzen: 64-bit integer div is fastest, float div is 47% slower, float mul is 60% slower; - ARM11 (Raspberry Zero): 64-bit integer div is fastest, float div is 138% slower, float mul is 159% slower. quick-and-dirty test used: https://pastebin.com/raw/4XqnuXL5 https://pastebin.com/raw/4XqnuXL5

apjana 9y ago
We don't have the case of integer div. And if you take a look into the coolsize() func we don't re-compute the factor. So it's not very significant. To get the size of a file we multiply only once with this factor. What is significant is the while() loop where the iterations increase with the file size. There's no mul or div in it giving the API a reasonable performance benefit.