3 ms·

>Usually people want software to do two things. The first is do what it is expected to do. The second is to do it as fast as possible. If performance is second

>Usually people want software to do two things. The first is do what it is expected to do. The second is to do it as fast as possible. If performance is second, it seems to be a very, very distant second for most uses. So much software is just absurdly slow.

johnisgood 2y ago
Yeah I do not buy the reason being performance, we are literally using bloated software, and bolt crap on top of these bloated junk, when we could do much better.
- ryao 2y ago
  It depends on whether something runs fast enough. Certain software, such as filesystem drivers in the OS kernel, never is fast enough as there is always someone who wants it to run faster, use less memory, etcetera. Efforts to get it as close to 0 overhead as possible (without killing maintainability) tend to be applauded by the community. Here are some patches I have written against kernel filesystem code in the past few years that were merged because people care about performance: This patch shaved a minuscule number of cycles off a hot code path, and was accepted on the basis that microbenchmarks showed that it made extremely hot loops run a few times faster: https://github.com/openzfs/zfs/commit/59493b63c18ea223857066218d6a58b67eb88159 https://github.com/openzfs/zfs/commit/59493b63c18ea223857066... This patch eliminated a redundant calculation that used 0.8% of CPU time: https://github.com/openzfs/zfs/commit/3236c0b891d0a09475bef8b6186ac8beed792fe9 https://github.com/openzfs/zfs/commit/3236c0b891d0a09475bef8... The impact of the following patch was not measured, but it is believed to have made checksum calculations run several times faster by eliminating unnecessary overhead: https://github.com/openzfs/zfs/commit/59493b63c18ea223857066218d6a58b67eb88159 https://github.com/openzfs/zfs/commit/59493b63c18ea223857066... The reason why the impact was not measured is that the code runs with interrupts disabled, which makes it invisible to kernel profilers. Another way of measuring was needed to quantify the improvement, but everyone agreed that it was a good improvement, so there was no need to evaluate the before/after improvement. Few people are willing to accept the performance impact of moving their filesystem driver into userland and practically no one wants the performance impact of moving almost everything into userland.
  - johnisgood 2y ago
    Yes, of course, but in general we tend to make the best out of already-existing bloated stuff, I think.
  - deleted 2y ago
    [deleted]
  - ryao 2y ago
    The first link was supposed to be this: https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7aa8807010a104563e4a https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...
ryao 2y ago
It depends on whether the software is performance critical. Many of the functions in the OS kernel are performance critical. In many cases in userspace, things are fast enough, rather than performance critical. This is why for example, Java in userspace took off, while Java in the kernel has not.

johnisgood 2y ago

Yeah I do not buy the reason being performance, we are literally using bloated software, and bolt crap on top of these bloated junk, when we could do much better.

ryao 2y ago
It depends on whether something runs fast enough. Certain software, such as filesystem drivers in the OS kernel, never is fast enough as there is always someone who wants it to run faster, use less memory, etcetera. Efforts to get it as close to 0 overhead as possible (without killing maintainability) tend to be applauded by the community. Here are some patches I have written against kernel filesystem code in the past few years that were merged because people care about performance: This patch shaved a minuscule number of cycles off a hot code path, and was accepted on the basis that microbenchmarks showed that it made extremely hot loops run a few times faster: https://github.com/openzfs/zfs/commit/59493b63c18ea223857066218d6a58b67eb88159 https://github.com/openzfs/zfs/commit/59493b63c18ea223857066... This patch eliminated a redundant calculation that used 0.8% of CPU time: https://github.com/openzfs/zfs/commit/3236c0b891d0a09475bef8b6186ac8beed792fe9 https://github.com/openzfs/zfs/commit/3236c0b891d0a09475bef8... The impact of the following patch was not measured, but it is believed to have made checksum calculations run several times faster by eliminating unnecessary overhead: https://github.com/openzfs/zfs/commit/59493b63c18ea223857066218d6a58b67eb88159 https://github.com/openzfs/zfs/commit/59493b63c18ea223857066... The reason why the impact was not measured is that the code runs with interrupts disabled, which makes it invisible to kernel profilers. Another way of measuring was needed to quantify the improvement, but everyone agreed that it was a good improvement, so there was no need to evaluate the before/after improvement. Few people are willing to accept the performance impact of moving their filesystem driver into userland and practically no one wants the performance impact of moving almost everything into userland.
- johnisgood 2y ago
  Yes, of course, but in general we tend to make the best out of already-existing bloated stuff, I think.
- deleted 2y ago
  [deleted]
- ryao 2y ago
  The first link was supposed to be this: https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7aa8807010a104563e4a https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...

ryao 2y ago

It depends on whether the software is performance critical. Many of the functions in the OS kernel are performance critical. In many cases in userspace, things are fast enough, rather than performance critical. This is why for example, Java in userspace took off, while Java in the kernel has not.