commit 02dd25c7db6f7dec480d8855a670258701c9cb8d
parent 04d951431fe34a999d4074abf84f310e7cc3721d
Author: Andrew Laack <andrew@laack.co>
Date: Fri, 18 Sep 2026 15:00:10 -0500
Updated styling, more notes on new post
Diffstat:
2 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/posts/site/style.css b/posts/site/style.css
@@ -1,6 +1,14 @@
.spacer{
height: 50px;
}
+
+ pre {
+ width: 52rem;
+ font-size: 0.85rem;
+ padding: 0.75rem;
+ overflow: auto;
+ background-color: #dddddd;
+ }
.pgp-container {
text-align: center;
padding: 20px;
diff --git a/posts/wip/to-make-a-cool-background.md b/posts/wip/to-make-a-cool-background.md
@@ -475,8 +475,9 @@ unrendered below is using vertices = 200_000, edges = 2_000_000
- 20.253333333333334 seconds
- c++ (with overdraw fixing + texture map)
- - rendered (I don't know if this is right)
- - track_to_render_v_10000_e_100000_s_0/out1.csv
+ - rendered
+ - - 29.7925 seconds
+
- unrendered
- 2.118 seconds
@@ -722,3 +723,80 @@ 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:
