blog

abg.md (26561B)

---

 # abg
 
 this is associated with the preliminary post titled: "to make a cool background"
 
 # To Make a Cool Background
 
 I wrote a visualization program for prim's algorithm that induces a minimum spanning tree (MST) on a procedurally generated graph. How does one go about making this their background and screensaver with X11 / dwm?
 
 ## MST
 
 IMPLEMENTATION DETAILS
 
 ## Background making
 
 [https://github.com/python-xlib/python-xlib](https://github.com/python-xlib/python-xlib.md)
 
 ```python3
 os.environ["SDL_VIDEODRIVER"] = "dummy"
 ```
 
 why not just use screenshots in a shared location? 
 
 indeed, why not?
 
 ## fuck you and your bullshit.
 
 Benchmarking
 
 ## c -> c++
 
 realized I needed a heap.
 
 ## bmp vs png vs jpg
 
 bmp is crazy fucking fast (benchmark)
 
 (looked in the code for supported file formats, looked in feh -> lib(whatever) for support)
 
 note larger file size.
 
 this is interesting, look further.
 
 ### patched upstream xl
 
 ### x11
 
 x11 is weird with this because they are kind hacky in that they just put up a window and take away your inputs, forcing them to go to that window.
 
 (should learn more about this)
 
 ### Benchmarking
 
 uhhh... is it actually that fast?
 
 wait; did this just optimize all of my code?
 
 Well yes, but actually no. 
 
 adding:
 
 std::cout << g.toString() << std::endl;
 
 gives ~ the same perf (minus the amount of time it takes to send so much data to stdout)
 
 (this would require the full traversal because toString is dependent upon prior prim algo steps being performed otherwise the traversal status for edges and vertices would be incorrect).
 
 (fixed a bug in the python code slowing it down)
 
 see no_render_2_fixed_itr.
 
 ## C++ benchmarking
 
 330 ms for init stuff w/ graph
 1405 ms for iteration
 
 broken further down:
 
 average iteration time is ~0ms, reaching ~20ms for later stages. Over time the percentage of valid edges declines.
 
 added getUnvisitedEdges function to return only non-traversed edges
 
 Init time: 332
 Loop time: 1344
 Init time: 327
 Loop time: 1350
 Init time: 322
 Loop time: 1374
 
 still has a similar issue as before; degredation in perf towards the end bc things are pushed earlier on and then get invalidated later on.
 
 that's basically all I could squeeze out without changes to the algo to be eager instead of lazy wrt tracking vertices. Basically, what's the shortest distance to a given vertex instead of what's the edge that we have that's shortest. 
 
 such a refactor though is likely irrelevant right now due to the added cost of 
 
 ope; realized my function for get edges with unvisited vertices above was wrong. I was just not pushing visited edges, but we really care about vertices that haven't been visited so refactored the edge generation and stuff to get a stable ref to v2index and then push only if that hasn't been visited.
 
 Init time: 389
 Loop time: 706
 Init time: 315
 Loop time: 671
 Init time: 337
 Loop time: 692
 
 now we're cooking with gas.
 
 tests now fail. bc snapshots. updated and everything seems right again.
 
 actually the stable things isn't really necessary as this approach that's unstable is functionally the same, but safer in case there are changes to the IR of edges.
 
 Init time: 334
 Loop time: 694
 Init time: 321
 Loop time: 668
 Init time: 323
 Loop time: 701
 
 now we find this:
 
 (see benchmarking/no_render_v_100000_e_1000000_s_0/out1.csv)
 
 same optimization performed for python code so that's then down to 8.6 seconds ~~~ see andrew@deepthought:no_render_3_fixed_itr_fixed_check$
 
 at this point it's worth worrying about the return for the get untraversed edges for vertices not traversed. after that:
 
 Init time: 314
 Loop time: 678
 Init time: 312
 Loop time: 671
 Init time: 311
 Loop time: 680
 
 and with the optimization for edge ordering:
 
 Init time: 311
 Loop time: 659
 Init time: 333
 Loop time: 673
 Init time: 320
 Loop time: 709
 Init time: 311
 Loop time: 674
 
 this is still too fucking slow.
 
 what's making the graph induction so incredibly slow?
 
 just graph creation:
 
 graph create: 317
 Loop time: 691
 graph create: 314
 Loop time: 657
 graph create: 311
 Loop time: 665
 
 reserving instead of pushing:
 
 graph create: 314
 Loop time: 636
 graph create: 324
 Loop time: 688
 graph create: 315
 Loop time: 693
 
 replaced map with vector where we were using indices to index into the map (dumb):
 
 graph create: 174
 Loop time: 654
 graph create: 179
 Loop time: 610
 graph create: 184
 Loop time: 618
 graph create: 185
 Loop time: 622
 
 ok, let's now run the full benchmarks again:
 
 benchmarking/no_render_only_grab_unvisited_edges_vector_instead_of_map_v_100000_e_1000000_s_0/out1.csv
 
 0.04,0.79,0.84
 0.03,0.79,0.84
 0.04,0.77,0.82
 
 this was kind of just stalling though becaus I'm out of my depth as it relates to rendering, the larger perf issue.
 
 back to that. 
 
 here are where this stands w/ 1000 v and 10_000 edges
 
 prior was ~34s per iteration (final col)
 
 this is basically the same:
 
 benchmarking/better_render_v_1000_e_10000_s_0/out1.csv
 
 (snippet from above file)
 
 0.26,10.71,34.22
 0.29,10.64,33.24
 0.31,10.62,33.57
 0.28,10.53,33.56
 
 fine. we'll fix the raylib shit. (queue montage)
 
 make debug-build && time ./abg.out -s 0 --edges 2000 --vertices 200
 
 real    0m1.948s
 user    0m0.529s
 sys     0m0.060s
 
 ~20 milliseconds per render call w/ make debug-build && time ./abg.out -s 0 --edges 20000 --vertices 2000
 
 Total single iteration cost: 65
 Amount of time calling render: 18
 Total single iteration cost: 65
 Amount of time calling render: 18
 Total single iteration cost: 65
 Amount of time calling render: 18
 Total single iteration cost: 65
 Amount of time calling render: 18
 Total single iteration cost: 65
 Amount of time calling render: 19
 Total single iteration cost: 65
 Amount of time calling render: 18
 Total single iteration cost: 65
 Amount of time calling render: 18
 Total single iteration cost: 65
 
 huh; what's the other iteration cost?
 
 
     while (!WindowShouldClose() && toVisit.size() != 0) {
         auto startLoop = std::chrono::steady_clock::now();
         BeginDrawing();
         ClearBackground(BLACK);
         auto startRender = std::chrono::steady_clock::now();
         g.render();
         auto endRender = std::chrono::steady_clock::now();
         auto diff = std::chrono::duration_cast<std::chrono::milliseconds>(endRender - startRender);
         std::cout << "Amount of time calling render: " << diff.count() << std::endl;
         EndDrawing();
 
         // since we wait sleepTime here, the bg render has a render delta of
         // at minimum sleepTime when switching tags in dwm, this is rather
         // annoying because the screen doesn't repaint until the sleep time
         // passes, which results in artifacts on screen.
 
         // despite this, calling render a lot of times is rather intensive
         // (at least on my hardware) and so this tradeoff is accepted for
         // now, unless there's a simple approach that allows for preemption
 
         //usleep((int)(sleepTime * 1000000));
 
         oneStepPrim(toVisit, visitedIndices, g);
         auto endLoop = std::chrono::steady_clock::now();
         auto loopDiff = std::chrono::duration_cast<std::chrono::milliseconds>(endLoop - startLoop);
         std::cout << "Total single iteration cost: " << loopDiff.count() << std::endl;
 
     }
 
 so it's somewhere in that first block; in the render area. the actual computation cost at the end is inconsequential. 
 
 begindrawing is ~free.
 
 clear background is ~free.
 
 ~46 of 65ms are spent on enddrawing. 
 
 so two things:
 
 19ms on render
 46ms on enddrawing
 
 what about when the numbers are much bigger (100_000 edges, 10_000 vertices)?
 
 Render time: 56
 End Drawing time: 237
 Total single iteration cost: 316
 
 the other 23 ms is the prim step + begin drawing / clear background.
 
 can we just not clear the screen? does that help? nope. doesn't do anything.
 
 target 60 fps?
 
 nope.
 
 ahh; the slowness is being realized later on. while render is cool with me double calling on edges; this is felt when enddrawing is called as the gpu does the rendering and stuff at that point. 
 
 what happens if I use the better single time render method?
 
 before:
 
 Render time: 62
 End Drawing time: 244
 Total single iteration cost: 306
 Render time: 60
 End Drawing time: 245
 Total single iteration cost: 305
 Render time: 60
 End Drawing time: 245
 Total single iteration cost: 305
 Render time: 55
 End Drawing time: 252
 Total single iteration cost: 307
 Render time: 60
 End Drawing time: 245
 Total single iteration cost: 305
 Render time: 58
 End Drawing time: 247
 Total single iteration cost: 306
 
 after:
 
 Total single iteration cost: 158
 Render time: 46
 End Drawing time: 112
 Total single iteration cost: 159
 Render time: 46
 End Drawing time: 112
 Total single iteration cost: 159
 Render time: 45
 End Drawing time: 113
 Total single iteration cost: 159
 Render time: 46
 End Drawing time: 111
 Total single iteration cost: 158
 Render time: 46
 End Drawing time: 112
 Total single iteration cost: 158
 Render time: 46
 End Drawing time: 113
 
 hell yeah.
 
 why so slow still?
 
 Like this is only ~100_000 and ~10_000 vertices so like why so slow?
 
 benchmarked now:
 
 benchmarking/simpler_render_v_1000_e_10000_s_0/out1.csv
 0.29,7.77,18.96
 0.27,7.80,19.17
 0.29,7.90,19.17
 0.31,7.76,19.05
 0.29,7.72,18.68
 0.30,7.90,18.56
 0.27,7.78,18.80
 0.27,7.77,18.74
 0.29,7.69,18.77
 0.32,7.67,18.85
 
 alright then. unfortunately, we're only calling the draw function once per vertex and edge now. we could change the rendering to only render connections, this would increase speed a lot, but it also makes the animation look less cool so fuck that. 
 
 could we draw in the background? like create a new thread that doesn't block us and then wait until that's done once we get back?
 
 well maybe, but the issue is I don't know how well this handles drawing while there's a queue of messages still being sent. 
 
 std::thread t(endDrawing);
 t.join();
 
 vs endDrawing()
 
 result in entirely different outcomes.
 
 the second sort of renders some stuff, but gets totally fucked up and then just black screens.
 
 due to an import? no this shit's just fucked.
 
 opengl affinity.
 
 can prebake the graph though and then only render additions.
 
 after:
 
 0.19,1.77,3.86
 0.17,1.76,3.81
 0.19,1.76,3.82
 0.18,1.75,3.85
 0.18,1.71,3.86
 0.19,1.68,3.83
 0.18,1.72,3.83
 
 holy shit. can we make this faster?
 
 of fucking course we can. track if a traversed state has been rendered and skip it if it has, using this to update our incremental texture. we then render that. 
 
 benchmarking/cache_first_use_blank_graph_v_1000_e_10000_s_0/out1.csv
 
 0.17,0.65,3.06
 0.18,0.63,3.05
 0.18,0.66,3.05
 0.18,0.64,3.05
 0.18,0.64,3.04
 0.17,0.63,3.02
 0.18,0.62,3.04
 0.19,0.64,3.05
 0.17,0.65,3.04
 0.17,0.66,3.03
 0.18,0.62,3.04
 0.17,0.63,3.03
 
 this is too boring; let's turn this shit up.
 
 how fast are we relative to the python bloatware webshit?
 
 benchmarking/cache_first_use_blank_graph_v_10000_e_100000_s_0/out1.csv
 
 1.40,28.92,35.76
 1.53,29.30,35.95
 
 (notice the edges and vertices)
 
 vs python:
 
 1.33,10730.71,10772.74
 
 that's only >300x slower for the python code so the average python developer would totally be cool with shipping it. Job done, webshit: built. 
 
 alright then. enough messing around. We really should have a queue for items that are to be rendered so we don't have to iterate over all vertices and edges, checking if they have the 'rendered' flag set. 
 
 after doing this we find:
 
 benchmarking/track_to_render_v_10000_e_100000_s_0/out1.csv
 
 1.50,3.12,29.43
 1.51,3.20,29.67
 1.57,3.08,30.00
 1.57,3.04,30.07
 
 35.855000000000004 / 29.7925 = 1.2034908114458338
 
 okay, so 20 percent faster. still too fucking slow.
 
 i'm also getting sick of this bs chrono / time shit. time to bring in perf.
 
  3.20%           395  abg.out  libraylib.so.6.0.0            [.] rlVertex3f
  2.08%           338  abg.out  abg.out                       [.] Edge::operator>(Edge const&) const
  1.55%           245  abg.out  abg.out                       [.] oneStepPrim(std::priority_queue<Edge, std::vector<Edge, st>
  1.41%           255  abg.out  libraylib.so.6.0.0            [.] rlDrawRenderBatch
  1.22%           225  abg.out  libc.so.6                     [.] 0x0000000000185dde
  0.85%           129  abg.out  libraylib.so.6.0.0            [.] DrawCircleSector
  0.79%           136  abg.out  libc.so.6                     [.] pthread_mutex_lock
  0.74%           133  abg.out  libc.so.6                     [.] ioctl
  0.64%           115  abg.out  libgallium-26.2.2-arch1.1.so  [.] 0x00000000007f8138
  0.62%           113  abg.out  libraylib.so.6.0.0            [.] PollInputEvents
  0.57%            91  abg.out  libc.so.6                     [.] cfree
  0.56%            95  abg.out  libc.so.6                     [.] malloc
  0.54%            27  abg.out  libc.so.6                     [.] 0x00000000001866c9
  0.53%            99  abg.out  libgallium-26.2.2-arch1.1.so  [.] 0x000000000180c45c
 
 alright so raylib is spending a decent amount of time on Vertex3f though not a crazy amount. Comparisons between edges are common; not surprising as we are using a heap with lots of elements towards the end, as we've seen. prim's algorithm generally taking some time, makes sense.
 
 render drawing is rather low, but within reason. This is rather disappointing. It's nice when it's like, no, dude, you spent 99.95% of your time in one function. 
 
 looking at the call stack:
 
 |--14.80%--EndTextureMode
 |--58.02%--EndDrawing
 --1.62%--Graph::render()
 
 well. huh. end texture mode is where I add things though the function itself is just clearing the queue. 
 
 It's a bit surprising enddrawing is more expensive since it just loads in the texture I've baked. 
 
 ---
 
 I shall call this ~done. final findings with 
 
 rendered below is using     vertices = 10_000, edges = 100_000
 
 unrendered below is using   vertices = 200_000, edges = 2_000_000 
 
 - python (with overdraw mostly fixing + texture map)
     - rendered 
         - 58.758 seconds
     - unrendered
         - 20.253333333333334 seconds
 
 - c++ (with overdraw fixing + texture map)
     - rendered
         - - 29.7925 seconds
 
     - unrendered
         - 2.118 seconds
 
 
 benchmarking/final_no_render_v_200000_e_2000000_s_0/
 
 takeaway:
 
 the rendered python implementation w/ 10_000 v and 100_000 edges using perf:
 
 Performance counter stats for 'python3 prim.py':
 
                  0      context-switches:u               #      0.0 cs/sec  cs_per_second
                  0      cpu-migrations:u                 #      0.0 migrations/sec  migrations_per_second
             14,233      page-faults:u                    #    252.0 faults/sec  page_faults_per_second
          56,487.57 msec task-clock:u                     #      nan CPUs  CPUs_utilized
         30,763,483      branch-misses:u                  #      0.7 %  branch_miss_rate         (88.90%)
      4,305,442,939      branches:u                       #     76.2 M/sec  branch_frequency     (88.90%)
    128,137,043,750      cpu-cycles:u                     #      2.3 GHz  cycles_frequency       (88.90%)
     18,736,054,409      instructions:u                   #      0.1 instructions  insn_per_cycle  (88.85%)
             TopdownL1 #      0.1 %  tma_backend_bound
                                                          #     98.9 %  tma_bad_speculation      (88.87%)
                                                          #      0.5 %  tma_frontend_bound       (77.81%)
                                                          #      0.5 %  tma_retiring             (88.92%)
 
       59.936596362 seconds time elapsed
 
       52.628026000 seconds user
        1.492521000 seconds sys
 
 gpu constrained though. 
 
 the rendered c++ implementation w/ 10_000 v and 100_000 edges using perf:
 
  Performance counter stats for './abg.out -s 0 --vertices 10000 --edges 100000':
 
                  0      context-switches:u               #      0.0 cs/sec  cs_per_second
                  0      cpu-migrations:u                 #      0.0 migrations/sec  migrations_per_second
              9,363      page-faults:u                    #   1819.4 faults/sec  page_faults_per_second
           5,146.21 msec task-clock:u                     #      nan CPUs  CPUs_utilized
         28,144,835      branch-misses:u                  #      5.9 %  branch_miss_rate         (89.55%)
        473,319,266      branches:u                       #     92.0 M/sec  branch_frequency     (88.64%)
      3,973,233,282      cpu-cycles:u                     #      0.8 GHz  cycles_frequency       (88.55%)
      2,925,854,560      instructions:u                   #      0.7 instructions  insn_per_cycle  (89.12%)
             TopdownL1 #      2.7 %  tma_backend_bound
                                                          #     93.6 %  tma_bad_speculation      (88.66%)
                                                          #      0.9 %  tma_frontend_bound       (77.75%)
                                                          #      2.8 %  tma_retiring             (88.67%)
 
       29.577542431 seconds time elapsed
 
        2.925597000 seconds user
        2.094917000 seconds sys
 
 32x less instructions than the python version. Neither is cpu constrained, but this is a non-trivial amount of overhead from the python version; c++ version also had 7x higher instructions per cycle. 
 
 gpu constrained too.
 
 memory overhead?
 
 c++ rendered sits at ~171mb-175mb. it's not great, hasn't been optimized, def room for improvement. 
 
 python rendered sits at ~240mb-248mb
 
 the default invocation method for the c++ implementation I use as my lock screen is running at 160mb. This is rather annoying, but also, it's doing a bunch of rendering stuff so IG that's fine, and this does improve the computational cost in terms of cycles so...
 
 huh... after 2 hours it's chilling at 163mb (TODO).
 
 bc it's always holding onto at least one frame which is 5120x1440 pixels which is ~21mb minimum (assuming r g and b bytes per pixel.)
 
 an eager approach for this would be better, but c++ stl doesn't have an indexed priority queue, so I'll just retcon what I have. 
 
 basically, I just want to minimize the useless things I push to the queue. One way to do this is to track the minimum weighted edge with an untraversed vertex and then updating this and only pushing edges with it when they are < that weight. 
 
 before:
 
 benchmarking/final_no_render_v_200000_e_2000000_s_0/
 
 0.08,2.03,2.12
 0.09,2.02,2.12
 0.09,2.00,2.11
 0.09,2.00,2.11
 0.08,1.99,2.09
 0.07,1.99,2.08
 0.10,2.00,2.11
 0.09,2.00,2.11
 0.09,2.07,2.18
 0.06,2.08,2.15
 
 
 after:
 
 benchmarking/final_min_no_render_v_200000_e_2000000_s_0/out.csv
 
 0.06,0.97,1.04
 0.06,0.93,1.00
 0.07,0.95,1.03
 0.09,0.92,1.02
 0.08,0.94,1.02
 0.08,0.94,1.03
 0.08,0.94,1.03
 0.06,0.95,1.02
 0.08,0.93,1.02
 0.07,0.95,1.02
 0.07,0.95,1.03
 0.07,0.95,1.03
 0.08,0.95,1.04
 0.09,0.93,1.03
 0.07,0.98,1.06
 0.07,0.95,1.04
 0.08,0.94,1.03
 0.07,0.96,1.04
 0.07,0.95,1.04
 0.07,1.00,1.08
 
 this doesn't really impact time wrt rendered because that is basically all spent on rendering not computation. 
 
 do I have a memory leak?
 
 
 
 > time valgrind --tool=memcheck abg
 
 ==944657== Process terminating with default action of signal 2 (SIGINT)
 ==944657==    at 0x50D3952: __syscall_cancel_arch (syscall_cancel.S:56)
 ==944657==    by 0x5117AEC: internal_syscall_cancel (sysdep-cancel.h:53)
 ==944657==    by 0x5117AEC: clock_nanosleep@@GLIBC_2.17 (clock_nanosleep.c:48)
 ==944657==    by 0x5123F26: nanosleep (nanosleep.c:25)
 ==944657==    by 0x51532E9: usleep (usleep.c:31)
 ==944657==    by 0x40065B8: main (in /usr/local/bin/abg)
 ==944657==
 ==944657== HEAP SUMMARY:
 ==944657==     in use at exit: 11,776,171 bytes in 27,368 blocks
 ==944657==   total heap usage: 86,922 allocs, 59,554 frees, 29,848,973 bytes allocated
 ==944657==
 ==944657== LEAK SUMMARY:
 ==944657==    definitely lost: 0 bytes in 0 blocks
 ==944657==    indirectly lost: 0 bytes in 0 blocks
 ==944657==      possibly lost: 6,876,540 bytes in 3,237 blocks
 ==944657==    still reachable: 4,899,631 bytes in 24,131 blocks
 ==944657==         suppressed: 0 bytes in 0 blocks
 ==944657== Rerun with --leak-check=full to see details of leaked memory
 ==944657==
 ==944657== For lists of detected and suppressed errors, rerun with: -s
 ==944657== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
 
 
 real    12m18.560s
 user    0m23.848s
 sys     0m0.969s
 
 andrew@deepthought:~$ time valgrind --tool=memcheck abg
 ==947393== Memcheck, a memory error detector
 ==947393== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
 ==947393== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info
 ==947393== Command: abg
 ==947393==
 ^C==947393==
 ==947393== Process terminating with default action of signal 2 (SIGINT)
 ==947393==    at 0x50D3952: __syscall_cancel_arch (syscall_cancel.S:56)
 ==947393==    by 0x5117AEC: internal_syscall_cancel (sysdep-cancel.h:53)
 ==947393==    by 0x5117AEC: clock_nanosleep@@GLIBC_2.17 (clock_nanosleep.c:48)
 ==947393==    by 0x5123F26: nanosleep (nanosleep.c:25)
 ==947393==    by 0x51532E9: usleep (usleep.c:31)
 ==947393==    by 0x40065B8: main (in /usr/local/bin/abg)
 ==947393==
 ==947393== HEAP SUMMARY:
 ==947393==     in use at exit: 11,656,499 bytes in 27,404 blocks
 ==947393==   total heap usage: 64,820 allocs, 37,416 frees, 24,650,054 bytes allocated
 ==947393==
 ==947393== LEAK SUMMARY:
 ==947393==    definitely lost: 0 bytes in 0 blocks
 ==947393==    indirectly lost: 0 bytes in 0 blocks
 ==947393==      possibly lost: 6,744,916 bytes in 3,235 blocks
 ==947393==    still reachable: 4,911,583 bytes in 24,169 blocks
 ==947393==         suppressed: 0 bytes in 0 blocks
 ==947393== Rerun with --leak-check=full to see details of leaked memory
 ==947393==
 ==947393== For lists of detected and suppressed errors, rerun with: -s
 ==947393== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
 
 
 real    0m53.077s
 user    0m20.121s
 sys     0m0.750s
 
 andrew@deepthought:~$ time valgrind --leak-check=full --tool=memcheck abg -s 0
 
 ==948338==
 ==948338== LEAK SUMMARY:
 ==948338==    definitely lost: 0 bytes in 0 blocks
 ==948338==    indirectly lost: 0 bytes in 0 blocks
 ==948338==      possibly lost: 6,948,380 bytes in 3,271 blocks
 ==948338==    still reachable: 4,899,399 bytes in 24,179 blocks
 ==948338==         suppressed: 0 bytes in 0 blocks
 ==948338== Reachable blocks (those to which a pointer was found) are not shown.
 ==948338== To see them, rerun with: --leak-check=full --show-leak-kinds=all
 ==948338==
 ==948338== For lists of detected and suppressed errors, rerun with: -s
 ==948338== ERROR SUMMARY: 2838 errors from 2838 contexts (suppressed: 0 from 0)
 
 
 real    21m9.471s
 user    19m30.601s
 sys     1m12.207s
 
 seems like this was just me not closing the window. fixed that.
 
 ---
 
 profiling:
 
 start: 121mb (time 5:15pm after running for ~a minute)
 check-in: 121mb (time 8:55pm) -- this is just the default `abg` cmd so not a ton of churn
 stopped: 121mb (9:11pm)
 
 running again w/ s=0:
 
 ---
 
 (recompile)
 
 start: 123mb (time 9:13pm)
 end: 123mb (time: 11:00pm)
 
 ---
 
 seems good; calling it here. further refactors can be done that'd improve perf, mostly be improving cache utilization by removing unnecessary bits. This is what I'd say:
 
 - It's unlikely there's an optimization for my hardware that'd improve performance by 2x
 - It's unlikely there's an optimization for my hardware that'd improve performance by 5x across the workloads I've evaluated. There are ways to make prim's algorithm much faster on much larger graphs, but given what I care about, this is likely inconsequential.
 - These further optimizations are probably not worth it
     - They could make this faster but two things:
         1. They would decrease code readability and extensibility a non-trivial amount
             - sometimes worth it
         2. The improvements wouldn't be meaningful for average usage
             - most ppl will be draw constrained. I believe I'm close to what is optimal as it relates to using raylib, without diving straight into opengl
 
 
 ---
 
 Pygame vs raylib:
 
 - Not a super great comparison
 - SDL (pygame) will basically always be slower than opengl (raylib)
 
 ---
 
 okay, so, this is a comparison between pygame, rlib w/ python, rlib from c++:
 
 these are all only rendering deltas, using a texture with rlib, and just doing incremental writes with pygame (functionally the same amount of computation)
 
 
 each is running one iteration of prim, rendering each step, with 100000 edges and 10000 vertices
 
 (kept each render in the foreground as that makes it slower, disabled picom)
 
 sleep 1 for each
 
 max memory is me running /usr/bin/time -v {command}, taking the max resident set size
 
 py rlib:
 
 - (render_rlib)
     - 24.347371951736843 seconds avg
     - 7,884,780,154.947369 avg cycles
 - (render_rlib/mem)
     - 160.2857894736842 MiB avg
 
 py pygame:
 
 - (render_pygame/v...)
     - 52.71620356077778 seconds avg
     - 12,353,392,498.666666 avg cycles
 - (render_pygame/mem)
     - 201.89875 MiB avg
 
 c++ rlib:
 
 - (benchmarking/final_render/out.txt)
     - 23.859886112999998 seconds avg
     - 3,796,753,782.428571 avg cycles
 - (benchmarking/final_render_mem/out.txt)
     - 137.27142857142857 MiB avg
 
 summary:
 
 this is strictly rendering information.
 
 raylib and pygame, with the same algorithm / write count, albeit randomized so not technically the same graphs, but each with multiple runs, we find:
 
 - pygame used ~1.25x the memory of raylib
 - pygame ran ~2.15x slower than raylib
 
 python vs c++ (normalized with raylib)
 
 - python used 1.15x more memory than c++ (c++ not really optimized for memory as it used OO paradigm that increasde overhead relative to python, but still better)
 - python version ran ~1.02x slower than c++ version
     - the overhead of computation for the graph is trivial relative to the rendering, which was gpu bound in both
 - python spent ~3.25x more cpu cycles than the c++ version
     - again, gpu bound, so this doesn't change max fps, but does increase energy usage, espeically when considering this is to run in the background for a long time
 
 without rendering:
 
 since I didn't do the heap-push optimization in the python code, I'll compare the comparable c++ implementation without that optimization which improved perf by ~2x.
 
 - benchmarking/final_no_render_v_200000_e_2000000_s_0/
     - 2.118 seconds
 - no_render_final/v200000e2000000
     - 20.253333333333334 seconds
 
 - c++ ran ~9.56x faster
 
 takeaway:
 
 - the overhead for the python raylib bindings aren't that encumbering. The default pygame ones are (pygame -> sdl -> opengl), instead of raylib -> opengl.
 - rendering performance is excellerated greatly by re-using texture maps
 - raylib -> screenshot is far faster when going -> bmp instead of other image file formats
 
 ---
 
 headline: