5 ms·

I don't know why I'm even replying, this will get so much hate here, oh well... 1. Just because things aren't done "the way you would do them" doesn't mean the

I don't know why I'm even replying, this will get so much hate here, oh well... 1. Just because things aren't done "the way you would do them" doesn't mean they're "bad" or "wrong". 2. If you're not on a solo project, I've found writing correct but less "clever" code to help shorten ramp-up time for new devs and be more beneficial to future maintainability of the code-base and system. TL;DR; Swapping values by XOR'ing may look elite and clever but hurts you in the long run.

kazagistar 10y ago
I am pretty sure it hurts you in the short run too. After all, the microcode probably does a register rename or the like with a normal swap, but has to actually burn cycles on using aritmetic for the xor swap.
- sverrirs 10y ago
  On modern CPU architectures, the XOR technique can be slower than using a temporary variable to do swapping. One reason is that modern CPUs strive to execute instructions in parallel via instruction pipelines. In the XOR technique, the inputs to each operation depend on the results of the previous operation, so they must be executed in strictly sequential order, negating any benefits of instruction-level parallelism.[3] https://en.wikipedia.org/wiki/XOR_swap_algorithm#Reasons_for_avoidance_in_practice https://en.wikipedia.org/wiki/XOR_swap_algorithm#Reasons_for...
TickleSteve 10y ago
Absolutely. Further, I would consider Linus's one-liner 'indirect=...' to be 'clever' code. If I were reviewing it, I would want it expanded into more obvious code as it requires too much cognitive overhead to parse.
- sverrirs 10y ago
  Agree on the cognitive overhead. People will and are arguing that "it is kernel code, it should be complicated" but I really think this is backwards. Because it is low level and debugging is really cognitively intense and difficult at this level the code should be even clearer and easier to understand.
  - addicted 10y ago
    People aren't arguing kernel code must be complicated. People are arguing that dealing with pointers should be second nature to kernel developers, so the lines of code causing you and me congnitive overhead should be second nature to a kernel Dev.
    - TickleSteve 10y ago
      I'm an embedded/real-time/bare-metal softie with over 20 years experience.... I do this stuff all day, every day. This code is inherently too complex. it should be simplified
- MawKKe 10y ago
  Comparing the two versions, I found the 'clever' version to have less cognitive overhead, since the reader has less state to keep track of (1 vs 2 variables). I don't find the pointer syntax that difficult to reason with. How would you expand the code?
eps 10y ago
Re: #2 - in Linux case, double-pointer list removal succinctly illustrates the minimum C proficiency needed for tinkering with kernel code. That is, not every project has "shortening ramp-up time" as a priority. In quite a few cases non-trivial code doubles as filter for less skilled devs.
- sverrirs 10y ago
  Projects should be accessible to new developers regardless of their complexity level. Even operating systems. Otherwise they will simply stagnate and die. Also, "less skilled devs" are just people that are still learning. We've all been there.
  - huhtenberg 10y ago
    This makes no sense. Projects should be accessible to new developers with appropriate skill set, which is inherently defined by the projects' complexity.
- krylon 10y ago
  I still think one should not make code more complicated than it has to be just to weed out the newbies. An OS kernel is going to be a very complex piece of code (ignoring microkernels) because what it does is complex. But that is all the more reason to keep the code as straightforward as possible. (There are still going to be times where code is not straightforward due to inherent complexity of the problem, or performance considerations, or portability, ...)
- phee 10y ago
  >In quite a few cases non-trivial code doubles as filter for less skilled devs Right, until the less skilled dev it's you, months later after you moved on to other stuff, and have to get back and fix some clever shit you wrote but don't understand anymore. Unless you're doing numeric or performance critical work, code should be optimized for readability and maintainability.
  - smitherfield 10y ago

kazagistar 10y ago

I am pretty sure it hurts you in the short run too. After all, the microcode probably does a register rename or the like with a normal swap, but has to actually burn cycles on using aritmetic for the xor swap.

sverrirs 10y ago
On modern CPU architectures, the XOR technique can be slower than using a temporary variable to do swapping. One reason is that modern CPUs strive to execute instructions in parallel via instruction pipelines. In the XOR technique, the inputs to each operation depend on the results of the previous operation, so they must be executed in strictly sequential order, negating any benefits of instruction-level parallelism.[3] https://en.wikipedia.org/wiki/XOR_swap_algorithm#Reasons_for_avoidance_in_practice https://en.wikipedia.org/wiki/XOR_swap_algorithm#Reasons_for...

TickleSteve 10y ago

Absolutely. Further, I would consider Linus's one-liner 'indirect=...' to be 'clever' code. If I were reviewing it, I would want it expanded into more obvious code as it requires too much cognitive overhead to parse.

sverrirs 10y ago
Agree on the cognitive overhead. People will and are arguing that "it is kernel code, it should be complicated" but I really think this is backwards. Because it is low level and debugging is really cognitively intense and difficult at this level the code should be even clearer and easier to understand.
- addicted 10y ago
  People aren't arguing kernel code must be complicated. People are arguing that dealing with pointers should be second nature to kernel developers, so the lines of code causing you and me congnitive overhead should be second nature to a kernel Dev.
  - TickleSteve 10y ago
    I'm an embedded/real-time/bare-metal softie with over 20 years experience.... I do this stuff all day, every day. This code is inherently too complex. it should be simplified
MawKKe 10y ago
Comparing the two versions, I found the 'clever' version to have less cognitive overhead, since the reader has less state to keep track of (1 vs 2 variables). I don't find the pointer syntax that difficult to reason with. How would you expand the code?

eps 10y ago

Re: #2 - in Linux case, double-pointer list removal succinctly illustrates the minimum C proficiency needed for tinkering with kernel code. That is, not every project has "shortening ramp-up time" as a priority. In quite a few cases non-trivial code doubles as filter for less skilled devs.

sverrirs 10y ago
Projects should be accessible to new developers regardless of their complexity level. Even operating systems. Otherwise they will simply stagnate and die. Also, "less skilled devs" are just people that are still learning. We've all been there.
- huhtenberg 10y ago
  This makes no sense. Projects should be accessible to new developers with appropriate skill set, which is inherently defined by the projects' complexity.
krylon 10y ago
I still think one should not make code more complicated than it has to be just to weed out the newbies. An OS kernel is going to be a very complex piece of code (ignoring microkernels) because what it does is complex. But that is all the more reason to keep the code as straightforward as possible. (There are still going to be times where code is not straightforward due to inherent complexity of the problem, or performance considerations, or portability, ...)
phee 10y ago
>In quite a few cases non-trivial code doubles as filter for less skilled devs Right, until the less skilled dev it's you, months later after you moved on to other stuff, and have to get back and fix some clever shit you wrote but don't understand anymore. Unless you're doing numeric or performance critical work, code should be optimized for readability and maintainability.
- smitherfield 10y ago