@PaperTrail I have to agree with Lensflare on this one lol

@retoor I'm always a quick shot, hah ladies? ;)

@retoor There is some overhead in Rust if you use a lot of the high level features, but if you know what you're doing it's not a big deal. And in the end it all gets optimized via LLVM, same as C via Clang ;P

@retoor What CPU do you have btw?

@retoor How often did you have to run it to get that result? ;D

@retoor It's still my newest code. I just pulled your latest commit and those are the numbers :P

And get some nutella while your at it :D

Did you try a waffle recipe with buttermilk? Those are actually insane

AoC gets INSANE really quickly. Last year i didn't make it past day 12 i believe lol

@retoor I dunno, i'm not a vibe coder, but I am pretty knowledgeable when it comes to very low level and interpreter programming

Rava seems pretty good! I wonder how you are doing memory management though... I haven't seen any garbage collection or similar in the code

@retoor I don't really remember, but if valgrind found anything than probably because some singleton was persistently allocated until the end of the program. There's not really anything wrong with that since the OS will clean up the memory at end of process. In fact I optimized my latest isspam version to leak values at the end so that drop impls don't increase run time :P

And if you like Swift, then do swift. I don't have anything against it. I just really like rust

@retoor I can emulate C in Rust with 3 lines of code, it's very simple. The whole point is that it's *also* memory safe :P

@Lensflare I want to try swift at some point but I also just really like Rust

@retoor Sorry, haven't read it yet

@lorentz Just look at the codegen difference: https://godbolt.org/z/vsTeGcz8M

Pretty crazy

@lorentz It's probably fine either way :P

But the issue with "heavy" branches that contain function calls, etc -- even if they are very rarely taken -- is that it pessimizes everything else around it, especially register allocation. And in case of the Rc decrement, I think that can panic aswell, which requires the codegen to do some stuff for unwinding too

@antigermanist Its that big huh

@lorentz Arenas would impose some awkward lifetime restrictions if you want to use raw ptrs internally and make it not unsound. Alternatively you could use general indices but then you need to query the arena with a key all the time which is very awkward -- I actually did that before switching to Rc because it was way too annoying

I guess ultimately, I'm doing this because why not :P

And it's gonna be pretty fast too. Using Rcs has some unfortunate codegen. If you have a bunch of short lived Rc clones, each time you drop one it has to check whether it's dead and emit a heavy dealloc branch

@afaIk Maybe your parents shouldn't have coded your dna

@Lensflare Well it *can* if you make it do it :P

It's really not *that* complex though. Rust can be as low level as C, so essentially I'm just implementing a spin on conservative tracing garbage collection (and it's single threaded, so quite a lot easier)

So if you call a gc cycle, I load the current stack pointer and walk over the raw stack. Anything that looks like a valid gc pointer (i.e. it points to within my gc heap) is treated like a real pointer and that object gets tagged. Then you go over your heap and delete all dead objects

From a Rust standpoint it's no problem: Gc<T> is just a raw ptr with a deref impl. That cannot result in UB since aslong as somebody still holds a gc handle it won't get deleted. And once nobody holds it, nobody can obverse the deletion

@retoor Was your GC just part of a higher level code or actual pointer and byte level? Because that's when it becomes tricky :P

Right now I'm kinda struggling how to make the memory allocator not waste a bunch of space

I'm thinking creating a ram-sized virtual memory region and then committing the pages I need but for each n pages I also have one metadata page so that "is this pointer a valid allocation" (which is needed for the conservative tracing routine) can be efficient -- without wasting one slot per page for page metadata. At higher size classes (> 16 byte) that's just wasted space...

@BordedDev If you keep to a sane subset yaml is actually pretty nice IMO. When people say they hate YAML most of the time they hate the weird kubernetes config language which is YAML with special tags for a bit of scripting (which is very horrible)

Maybe you just weren't white enough

@retoor -.-

Now I'm hungry :(

Screw society then. Bunch of sheep anyways

@YourMom TOML is justice 😭

Do note that toml doesn't really do nested objects easily, so not the best choice for a scene graph, but I guess you could just have a flat list of objects with parent = <id> field

Classic prisoners dilemma

At the end of the day you'll always find someone who will do it, so we are all doomed to also play along

@CoreFusionX I think as long as you don't compose multiple euler angle rotations you shouldn't have a problem with gimbal lock. I.e. you can always decompose any rotation into a sane set of euler angles in a given coordinate system

But you're right, just use quaternions :P They're faster anyways because of less trigonometric operations