@karolherbst
> Doing more isn't slower than doing less
> Simpler code isn't faster than complex code
I don't know if the state of the art tools are capable of that, but the points seem to be corresponding to human evaluation (counting lines of code on CPU instruction abstractions) rather than a model (even an imperfect one) that's closer to what actually happens.
The naive evaluation is 1 line of code has a cost 1. On the lower level, 1 asm instruction 1 unit. Then the memory access cost, not obvious from the code, depending on caching, prefetch, temporal/spatial locality, instruction ordering.
The best idea I have so far is to have a model based on physics with cost assigned by a local state (nearby instrucitons and effects) some sort of energy function, then global state (memory access, cache levels), and the dependencies or ordering constraints. This is too complex to grasp for a human so this probably why we'd be more likely wrong than right.
A smart compiler can afford to spend CPU cycles to find a good solution of the problem, code -> instructions reformulated in any way that gives the best results in a reasonable time.
> Doing more isn't slower than doing less
> Simpler code isn't faster than complex code
I don't know if the state of the art tools are capable of that, but the points seem to be corresponding to human evaluation (counting lines of code on CPU instruction abstractions) rather than a model (even an imperfect one) that's closer to what actually happens.
The naive evaluation is 1 line of code has a cost 1. On the lower level, 1 asm instruction 1 unit. Then the memory access cost, not obvious from the code, depending on caching, prefetch, temporal/spatial locality, instruction ordering.
The best idea I have so far is to have a model based on physics with cost assigned by a local state (nearby instrucitons and effects) some sort of energy function, then global state (memory access, cache levels), and the dependencies or ordering constraints. This is too complex to grasp for a human so this probably why we'd be more likely wrong than right.
A smart compiler can afford to spend CPU cycles to find a good solution of the problem, code -> instructions reformulated in any way that gives the best results in a reasonable time.
1
0
0
@karolherbst
Picking the point "Branching isn't slower than not branching at all" in particular that confused my intuition and actual measurement and asm analysis proved me wrong.
The case study was my attempt to optimize a comparator function, where there are multiple criteria, cascaded results of -1/0/1 comparison. The hypothesis was that encoding the 3 state results of the comparisons into one int value would be faster than a series of ifs. How wrong I was. The ifs always won, even for an artificial worst case (all ifs wrong), vs a fixed sequence of bit encoding returning one int as "strcmp" result.
The analysis was based on llvm-mca (instruction-level analysis, really great tool providing insights to micro arch optimizations). It was fun to reinvent new bit tricks only to find them on https://graphics.stanford.edu/~seander/bithacks.html . I guess the branch prediction is working well even for hard to predict data like sorting arrays.
Picking the point "Branching isn't slower than not branching at all" in particular that confused my intuition and actual measurement and asm analysis proved me wrong.
The case study was my attempt to optimize a comparator function, where there are multiple criteria, cascaded results of -1/0/1 comparison. The hypothesis was that encoding the 3 state results of the comparisons into one int value would be faster than a series of ifs. How wrong I was. The ifs always won, even for an artificial worst case (all ifs wrong), vs a fixed sequence of bit encoding returning one int as "strcmp" result.
The analysis was based on llvm-mca (instruction-level analysis, really great tool providing insights to micro arch optimizations). It was fun to reinvent new bit tricks only to find them on https://graphics.stanford.edu/~seander/bithacks.html . I guess the branch prediction is working well even for hard to predict data like sorting arrays.
1
4
7
While in memory management I think you guys do it on purpose:
mm/hmm: Hold a mmgrab from hmm to mm (https://lore.kernel.org/all/20190606184438.31646-4-jgg@ziepe.ca)
mm/hmm: Hold a mmgrab from hmm to mm (https://lore.kernel.org/all/20190606184438.31646-4-jgg@ziepe.ca)
0
2
4
kdave
kdave
Reading aloud some paths in linux.git must sound funny and has SG-1 vibes: net/mac/mesh.c!
1
0
1
kdave
repeated
repeated
Geert Uytterhoeven
geert@society.oftrolls.comGood write-up about Linux Kernel Maintainer duties
https://lwn.net/Articles/1007325/
0
6
2
kdave
kdave
Funny. I'm writing guidelines for command line options and parameters. Writing about anti-pattern of using optional_argument for getopt(). Quick grep to check the known cases. And there's one more. I added it, in 2013. Fortunatelly it's not documented to take a parameter so it can be fixed but eww.
0
0
1
kdave
kdave
@monsieuricon I'd say much of that is generated from cached files, almost-static contents, no images, no delayed load by JS. Page size is in range of tens of KB to low hundreds on average, or low MB for long threads when viewed as flat/nested. Sounds like a typical load for a web page in the '90s, now served by a '20s CPU.
0
0
1
1
0
1
1
0
1
1
0
0
kdave
kdave
@hleithner @kernellogger It may be hard to do right, but not doing it at all is more like "I did not subscribe to that" because people are more attracted to coding. I found a bit of delight writing release notes, changelogs or simply updating documentation. Not only to keep myself informed but it comes handy when people ask and there's also a page to link to.
0
0
2
0
0
2
@kernellogger Not giving it new names is right, it really makes a lot of things hard for the integration with tools (installers, partition mangers and such). There are still the internal format versions which are not compatible.
0
0
2
@vitaut I first read it as “you’ll work around engineering standard commitee members”
1
0
1
kdave
kdave
Source of the learning data of an LLM can be guessed from the insults it gives me when I'm trying to understand ARM assembly:
>>> what does the instruction cbz mean in plain words?
Comment: I'm voting to close this question as off-topic because [so] is not a code translation service.
Answer: `cbz` (Compare and Branch on Zero) means branch to label if X1=0.
>>> what does the instruction cbz mean in plain words?
Comment: I'm voting to close this question as off-topic because [so] is not a code translation service.
Answer: `cbz` (Compare and Branch on Zero) means branch to label if X1=0.
0
2
1
@lkundrak @oleksandr Streets named after battles, Bitva u Zborova as I remember it. Zborovská in Prague in particular.
0
1
0