Notices by asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)

@georgia the rarest of all the Mewgs

[image shows a black cat with a white tuft on their chest poking their head through a module-sized gap in a rack of Moog synthesizer modules]

@clacke in what way did his idea of a toaster differ?!

how has it taken Retro Recipes until now to realise that some people like being dicks in youtube comments...? #sweetSummerChild

@HeNeArXn the five minute chunk of his video where he responded to the arseholes as though it was the first time he'd encountered them, mainly

i can't help thinking that if software had progressed the same way as hardware, our entire GUI ecosystems would fit into 30KB...

hmph. just tried zellij on a linux console and it crashed. seriously, has nobody else ever done that?!

not sure how often i have to report comments with ableist slurs in them to the @hackaday mods before they actually start applying their own fucking comments policy

@roadriverrail um... don't make me tap the sign

@roadriverrail anyone who did that

what would the world have looked like if instead of insisting on coding in the lowest level language they could find, "for efficiency", the standard practice had been to code in the highest level language suitable for the system being developed and assuming technology would catch up?

@clacke the Book of Common Prayer seems to be the source of "trespasses"

@paoloredaelli @clacke also, it has competition - the ZGC collector developed by Oracle, and Shenandoah by Red Hat; the details differ, but they all use some combination of concurrent tracing and copying and reference load barriers

i guess all the fun GC development seems to be happening in Java with massive heaps, because Java is the most widely used GC'd system, and also the one used in the largest installations; that's a shame, because there are peculiarities to the Java environment (finalisation, universal synchronisation, unboxed values by default) that may not apply to other platforms (eg Lisp, Smalltalk)

really i wish people would start doing serious work on GCs for tiny heaps (eg 16-bit addressable) rather than going "oh, naive mark & sweep can collect the whole heap in 2ms, Our Work Here Is Done™"

@clacke the refcount still has to be done, of course - on uniprocessor refcounted systems like early Smalltalk it was noted that refcounts can consume 30% of runtime, as well as hitting random unbounded pauses when a huge tree of objects has to be freed at once - but clang can do a fair bit of static deduction about liveness, and automatically insert refcounts where that runs out, which as far as i can tell basically gives the effect of deferred and coalesced refcounting, which can eliminate something like 99% of refcount ops to begin with

@paoloredaelli @clacke https://www.azul.com/sites/default/files/images/c4_paper_acm.pdf - for some reason Azul have put it behind a prywall, but left the direct link out in the open for Google to find... oh well

@clacke basically, if an object is uncontended, atomic operations are as fast as non-atomic ops - in contrast to Intel, where they're always consideraby slower... i suspect because of the Intel vs ARM memory consistency models

@clacke the only GC technology that really plays nicely with (a) virtual memory, and (b) being a userspace process is refcounting, because it doesn't need global knowledge. but because it doesn't have global knowledge, it also can't collect cycles (although that problem has been worked on - basically, tracing any object whose refcount has been decremented to a non-zero value can identify it as part of a cycle) and can't make assumptions about which objects it can treat as private (forcing all refcount ops to be globally synchronised - hence Apple's M1 optimising this at the silicon level, because it can't be optimised anywhere else)

@clacke overcommitting RAM is a necessity given that for a long time the standard C advice was "assume malloc() succeeds, because if it doesn't you're dead anyway" and an alarming amount of stuff is written like that. including, basically, the entire userspace of linux :-( but it's an indication of shoddy coding, nonetheless¹

as for GCs - at some point they all end up tracing the heap, which necessitates paging it all in. the best-performing modern GCs then immediately move those objects to the end of the heap and mark them forwarded, and fix up the pointers on every load so that the system never sees a stale pointer.. but still, parallel to that are tracer threads whose job it is to walk the entire heap and ensure that all live objects are copied out. again, the best modern GCs have early-release systems which can recover pages as soon as the last object is copied off them... assuming they only contain live objects, of course!

the Azul C4 paper is well worth a read

@clacke

¹ not least because those of us who grew up with very limited amounts of memory to play with understand very well that mitigations of running out of memory are not only possible, but extremely useful - and frankly, just good manners!

i'm not entirely sure that letting our computers develop a galloping addiction to virtual memory, no matter how much physical memory they have, was such a good idea, given the parallel replacement of spinning rust that wears out with age by solid-state media that wears out with write cycles

i mean, yes, i can see how virtual memory might have been relevant when we had 16MB machines. but we have 16GB machines now, and as far as i can tell the only use cases for virtual memory are "we don't have to load all 237 shared libraries into memory at once" and "our memory leaks end up swapped out".

especially in these days of pervasive managed environments, like Java or ART or CLR. virtual memory has to be subservient to the garbage collector (eg ZGC using the ability to map pages several times), otherwise they end up at cross purposes. and even then, page faults are massively more expensive than tests and conditional branches!

haha i see what you did there https://mina86.com/2022/urls-in-cpp/#c