@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.

· · Web · 3 · 0 · 0

@akkartik I'm not sure what dynamic memory means, for example, drawing a line segment is a 40 some bytes routine, and I use 5 shorts of memory to keep stuff in memory while the routine happens:


@neauoire It's the equivalent of malloc in C or ALLOCATE in Forth. It's different from the stack in that you don't have rigid constraints on the order in which things are reclaimed.

I'm going over the Uxn opcodes now. I'm pretty sure you must have it for at least some esoteric purposes..

@akkartik Oh, yes we use calloc to create the memory for the screen pixels!

@akkartik I have LOVE installed on the pinebook, but anything remotely "animated" slows down to a crawl.

@akkartik I can try it out tomorrow, I was just about to make dinner.

@akkartik lines.love? Is that a love2d benchmark I hadn't heard of? Can't seem to find it... @neauoire

@neauoire @akkartik ARM GPU drivers on Linux are a bit hit and miss as far as what GL stacks they implement; I think the PBP only implements a few of the GLES stacks which may be an issue for LOVE

@klardotsh @akkartik Love2d has this really bad issue on PB, everytime I start it, it makes the screen flicker white, and after that some program have a hard time recovering, like firefox will not redraw its body unless I resize the window, which is incredibly annoying.

@neauoire @klardotsh @akkartik mine was running really well with alpine/postmarketos but then it stopped working suddenly. I’ve got the probe to debug it but time is a premium.

@neauoire So starting Love2d destabilizes _other programs_ running on the same computer?!

@akkartik yes, I remember uxn had that same issue a while back, it might be a sdl issue.

@neauoire I've been thinking about this thread today. As I've been spending more time in my note-taking app, my computer has been heating up. I'll probably soon need to dig into the memory footprint of pensive.love. Which makes me wonder what life is like in a parallel universe where I accepted the 16-bit restriction and went with Uxn.

@akkartik I'd prefer to see you build a 16-bit version of Mu based on your own vision of a dream cpu.

@neauoire :pilin: I still miss Mu but nah, I'm done building things to build things for a while. Now I just want to build things.

@akkartik I totally understand.

Scoping uxn to be a year long project turned out to be a good idea, I haven't actually worked on uxn itself since last winter, and it paid itself over many times since in how it allowed me to actually get things done thereafter.

Well, in any case, if you're ever tired of your fancyful 32 bits, I'd be happy to help you figure out how to twist uxntal into fun hings.


Your chart is ready, and can be found here:


Things may have changed since I started compiling that, and some things may have been inaccessible.

In particular, the very nature of the fediverse means some toots may never have made it to my instance, in which case I can't see them, and can't include them.

The chart will eventually be deleted, so if you'd like to keep it, make sure you download a copy.

@ColinTheMathmo To my infinite regret, I accidentally delete-and-redrafted the wrong post so you can't tell what @neauoire is responding to up top. For future reference, here's the question that started this thread:

"On uxn do you find yourself more frequently running out of time or memory?"


@akkartik That's part of the value of Chartodon ... so often it unearths corners of a conversation you never knew existed.


@akkartik If you have a link to the original comment then I can manually cross-link to make the chart more complete.


@ColinTheMathmo That was the problem: I deleted the original by mistake. And it already had responses so I couldn't fix the issue.

Maybe just wire up merveilles.town/@akkartik/1087 and deal with a cycle? 😀

@ColinTheMathmo To clarify, I hit delete-and-redraft on the parent of the comment I intended. When I realized my mistake I didn't actually redraft the comment I deleted.

@akkartik I've updated the chart, but not done anything about tying in other toots.

I hope it's useful as it stands, but if I can do anything, don't hesitate to ask.

@akkartik Just checking that you are aware that clicking on a node will open the toot.

@ColinTheMathmo I wasn't, thanks! I didn't mean to sound like I was requesting a feature.

@akkartik No, I didn't think you were, I just thought I'd mention it in passing because many people see the "SVG" affix and assume it's static.

@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.

@akkartik I feel like I've just understood something crucial. 👀

@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 @akkartik well, half the time, I just don't know the terms, like, if someone said "yeah, uxn is garbage collected", I would not have been too surprised.

@technomancy Yeah, 20% in fairly pessimistic microbenchmarks, though I'm sure you could create worse ones.

@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.

@neauoire @technomancy @alderwick Oh interesting.

How do y'all decide what to initialize `heap` to?

@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.

@technomancy @alderwick

@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.

@technomancy @alderwick

@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.

@technomancy @neauoire @akkartik TIL now I’m replying old threads in my head worrying I may have assumed too much. <3

@peregrine @technomancy @akkartik everyone assumes I know more than I do because I have great taste in wallpapers.

@neauoire @technomancy @akkartik for me its the eso-lang you use. It all seems extremely advanced and foreign, so it must be from some ancient tome of knowledge.

@neauoire @peregrine @technomancy @akkartik a diligent beginner in a field often arrives at wonderful solutions to impossible problems precisely because they don't know what's impossible.

@eqe @peregrine @technomancy @akkartik ah yeah I remember that quote, "they did it because they didn't know it was impossible"

@neauoire @akkartik AFAIK uxn is fully non-GC, but that's also because it is fully programmer-managed memory anyway out of that static 64KB block.

the rough tl;dr is: in a language like C you call malloc() to get a block of heap ram at some given size, and have to remember to free() that ram later or it'll leak. in a language like, say, Lua, strings just "come into existence" as far as the developer is concerned, and the VM tracks its lifecycle (and calls free() for you when the string "dies")

Sign in to participate in the conversation

Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.