@akkartik mhmm, it depends, I'd say time? But uxn just waits if a frame takes longer than expect so it's not really noticeable.
This week, people revealed in the mailing list that they were using fancy stashing techniques to spread logic over multiple frames, I realized that I was using the update vector for almost everything, and maybe I shouldn't do.. that-
I haven't written an application that was larger than 20kb yet, so not space.
@neauoire Do you use any dynamic memory? Like, lines.love is 40KB, but it usually allocates a few tens of MB.
With LÖVE I've been finding that CPU is plentiful -- as long as I don't use too much memory, overloading the GC.
@akkartik I've been seeing the words garbage collection flying around all day on here, and I went to look it up and I don't understand what they mean.
Is uxn garbage collected?
@neauoire Likely not. It wouldn't work well with 64KB, and 64KB likely won't need it. Forth isn't GC'd.
@akkartik Is C garbage collected? Is garbage collection like, automatic freeing of memory when it hasn't been using for a while or something?
@neauoire Yeah exactly. C isn't, because you have to free() anything you malloc() when you don't need it. (And if you pick the wrong time to do it you can have strange bugs. A lot of Rust's goal is to avoid those strange bugs without runtime overhead. Mu avoided them with some runtime overhead.)
@akkartik I saw your message where you said that Mu had 20% overhead to handle that sort of thiing.
@neauoire @akkartik I think it's nearly impossible to nail it down to a number like 20%; more likely it'd be like 20% in the worst-case scenario or something like that.
also i love the idea of someone building out a whole little virtual machine platform and never having learned what garbage collection is because they never needed it. <3
@technomancy @neauoire I spent a lot of time designing Mu to allow heap allocation and reclamation -- but never actually implemented reclamation. So arguably I didn't need it either just because I was running on computers with lots of RAM.
@akkartik @technomancy I noticed @alderwick implemented a heap system for asma
https://git.sr.ht/~rabbits/uxn/tree/main/item/projects/library/heap.tal
@neauoire @technomancy @alderwick Oh interesting.
How do y'all decide what to initialize `heap` to?
@akkartik @technomancy @alderwick you put it's label anywhere in your program https://git.sr.ht/~rabbits/uxn/tree/main/item/projects/software/asma.tal#L46
@akkartik @technomancy @alderwick in this example, its length is the distance between the last byte of the asma.tal file, up to &end, which is padded to $e000
@neauoire @technomancy @alderwick Ah, that makes sense! That's where the heap allocator needs to connect up with the source language.
@akkartik @technomancy @alderwick So Mu is like that, it has a heap, but it doesn't really go and clean up the things that have expired?
@neauoire @technomancy @alderwick Yeah. It could, in principle, but in practice it was never a priority.
I think it would have been a priority if I'd been on a PineBook..
@neauoire Touche. It's possible the heap allocation has some fundamental flaw that means all of Mu is busted. I doubt it, though.
@neauoire On some level everything we do with computers suffers from this potential for unknown unknowns that can bust the whole philosophy. I think Meltdown/Sceptre did that for a lot of hardware optimizations.
@neauoire @akkartik @technomancy @alderwick
PBP (and almost all ARM Linux devices except the top-of-line Qualcomm (mobile/desktop) and Ampere (server) chips) is a super-computer relative to the hardware humanity went to the moon with, but relative to the demands of the modern Linux desktop?.... well.... I'm preaching to the choir if I go on much more :)
Wild to think that my first Linux box, a Pentium 4 with 1GB of DDR-400 and an AGP GPU, ran Gentoo happily, incl. OpenOffice + KDE + Firefox.
@neauoire @akkartik @technomancy @alderwick oh how far we've moved in ~15 years or whatever it's been
@akkartik @technomancy @alderwick well, on paper it's a super-computer people have told me.