Thu May 29 09:35:05 PM +08 2025 #33 ✎
Yeah. I guess swapping two elements of slice is just faster than assigning one to another through = and pointing this values by index. No matter how many compare operations we can avoid.
Thu May 29 09:19:10 PM +08 2025 #32 ✎
Ok, here is the trick in Python's heap structure implementation that allows us to cut amount of comparison when sifting up items in the heap. https://github.com/python/cpython/blob/3.13/Lib/heapq.py#L278 We don't compare parent value with the children when sifting it up, assuming that item which is taken from the leaf will end up somewhere near the leaf. The idea (D.Knuth, Art of Programming, Volume 3) is to sift item through smallest of the children (and shifting smallest child towards the root on each step) to the leaf without swapping it in a process, then assign it to the leaf, and then sift it down to the proper place. Doing it this way must reduce amount of "compare" operations, because sifting item down to it place from the leaf is shorter path than the sifting it up to its location towards the leaf. It is low price to don't stop ("break" the loop) on proper location, but go down to the leaf with low cost operations and then go a little bit up comparing values. I know I have formulated this idea twice already. :-) Here is the third time: we make long path cheaper, according the heuristics about nature of the value we are sifting through the heap. Now, here is my research. I had wrote a little bit of code in Rust, playing with the heap. I am 37 years old programmer, but never played with the heap data structure. Oh, boy, brothers. Just having some fun here. And I've tested and benchmarked some code. And... idk, but my benchmarks in Rust said that "non-optimized" version when we swapping items towards the leaf and breaking the loop when we arrived is faster. Is this compiler optimizations? Some low-level stuff? I am not really into that. Maybe I made a mistake. https://github.com/fuzz88/rust_stuff/blob/master/heap/src/main.rs#L73 test tests::bench_heapify_not_optimized ... bench: 2,796.01 ns/iter (+/- 54.45) test tests::bench_heapify_optimized ... bench: 6,668.45 ns/iter (+/- 182.72) Just a memo to myself: benchmark critical parts, make decisions based on the data. Or just use "good enough" stuff for the task. I will call it a day.
Wed May 28 05:32:22 PM +08 2025 #31 ✎
"Be patient. Your future will come to you and lie down at your feet like a dog who knows and likes you no matter what you are."
Wed May 28 01:58:00 PM +08 2025 #30 ✎
...And Justice for All (1979)
Wed May 28 11:04:36 AM +08 2025 #29 ✎
What is good style? Good style in any language consists of code that is: Understandable Reusable Extensible Efficient Easy to develop and debug It also helps ensure correctness, robustness, and compatibility. Maxims of good style are: Be explicit Be specific Be concise Be consistent Be helpful (anticipate the reader's needs) Be conventional (don't be obscure) Build abstractions at a usable level Allow tools to interact (referential transparency) Know the context when reading code: Who wrote it and when? What were the business needs? What other factors contributed to the design decisions?
Mon May 26 11:46:21 PM +08 2025 #28 ✎
Sat May 17 10:40:56 PM +08 2025 #27 ✎
Thu May 15 08:34:58 PM +08 2025 #26 ✎
Wed May 14 05:26:51 PM +08 2025 #25 ✎
123
123
Thu May 08 01:56:23 PM +08 2025 #24 ✎
vo2max
Sun May 04 08:58:09 AM +08 2025 #23 ✎
Sun May 04 08:25:24 AM +08 2025 #22 ✎
Wed Apr 30 12:40:53 PM +08 2025 #21 ✎
well tapered
Tue Apr 29 12:31:46 PM +08 2025 #20 ✎
When you ignore convention, you must be ready to stand your ground.
Sat Apr 26 12:55:49 AM +08 2025 #19 ✎
¯\_(ツ)_/¯
Mon Apr 21 10:56:38 PM +08 2025 #18 ✎
In computer programming our basic building block has an associated time grain of less than a microsecond, but our program may take hours of computation time. I do not know of any other technology covering a ratio of 10¹⁰ or more: the computer, by virtue of its fantastic speed, seems to be the first to provide us with an environment where highly hierarchical artefacts are both possible and necessary. This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts.
Tue Apr 15 08:45:24 AM +08 2025 #17 ✎
Как вы видите даже одна операция выделения памяти может стать узким местом, если она выполняется внутри часто вызываемой логики. В играх динамическое выделение памяти в большинстве случаев запрещено, вам 95% завернут такой код на ревью. Без веских на такое действие причин выделять память где хочется нельзя. Все, что может быть выделено, должно быть выделено до старта уровня.
Mon Apr 14 02:11:45 PM +08 2025 #16 ✎
Verba/Salix acutifolia
Fri Apr 11 01:56:10 PM +08 2025 #15 ✎
Run/walk
Thu Apr 10 01:13:27 PM +08 2025 #14 ✎
2016 on one's own
Tue Apr 08 04:58:03 PM +08 2025 #13 ✎
Tue Apr 01 08:52:06 PM +08 2025 #12 ✎
Первая весенняя свежесть, +12
Sun Mar 30 01:48:58 PM +08 2025 #11 ✎
1936
Sun Mar 30 10:25:56 AM +08 2025 #10 ✎
There you have it: some of the weirdest things in the Linux kernel's git history. There are 1,549 octopus merges, one of which has 66 parents. The most heavily diverged merge has 22,445,760 lines of diff, though it's a bit of a technicality because it shares no history with the rest of the repo. The kernel has four separate "initial" commits, one of which was a mistake. None of this will show up in the vast majority of git repos, but all of it is well within git's design parameters.
Sat Mar 29 08:29:22 PM +08 2025 #9 ✎
Above all, you do not let your tests drive your design, you let your design drive your tests! The design is going to point you in the right direction of what layer in the MVC cake should get the most test frosting. When you stop driving your design first, and primarily, through your tests, your eyes will open to much more interesting perspectives on the code. The answer to how can I make it better, is how can I make it clearer, not how can I test it faster or more isolated. The design integrity of your system is far more important than being able to test it any particular layer. Stop obsessing about unit tests, embrace backfilling of tests when you're happy with the design, and strive for overall system clarity as your principle pursuit.