Pagwin/new_blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

not sure if it was purely the SSG or also the markdown but either way fixed something with fractions-sidequest
Some checks failed
/ Generate Site (push) Has been cancelled
Details
/ Publish Site (push) Has been cancelled
Details

Browse source
This commit is contained in:
Pagwin 2026-02-27 22:52:10 -05:00
parent e158caf4b9
commit 791195bf6f
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
posts/fractions_sidequest.md
View file

@ -72,7 +72,7 @@ impl Add for Frac{
This code feels bad even from a code quality point of view but idk why, regardless it's hilariously bad performance wise.
<video controls src="/static/video/frac_gen_v1.mp4"></video>
<video controls="" src="/static/video/frac_gen_v1.mp4"></video>
Considering that we're "only" doing addition this is incredibly slow. Slower than addition in (insert butt of the joke language of this week here). All that in mind something is definitely up and if you read the code above and think about it enough you'll probably see it.
@ -154,7 +154,7 @@ async fn recurse(f1:Frac,f2:Frac, remaining:u64)->Vec<Frac>{
looks good at first glance(actual version code quality is bad but blog version seems alright). What happens when we run it?
<video controls src="/static/video/frac_gen_v2.mp4"></video>
<video controls="" src="/static/video/frac_gen_v2.mp4"></video>
Oh... we run out of memory... or well we run out of 30 gigabytes of memory because I set a limit to avoid affecting the other stuff running on the server(because it isn't mine). But why? Doing the math if all we had to deal with was the fractions we'd be using about `17501876*4/1000**3 ~ 0.07 GB`, if we include the overhead of all the Vecs we make and are pretty agressive with how much memory they use maybe 0.21 GB which is a difference of over 142x. So what's the rest of the memory?
@ -196,7 +196,7 @@ fn recurse(f1:Frac,f2:Frac, remaining:u64)->Vec<Frac>{
This solves the whole running out of memory thing. A funny side effect is that now it's even faster(even though it's 1 thread).
<video controls src="/static/video/frac_gen_v3.mp4"></video>
<video controls="" src="/static/video/frac_gen_v3.mp4"></video>
So that was fun going through and making all this work out well, now I can generate gigabytes upon gigabytes of fractions with ease.