celeritascelery

Why would that impact speculative loads/branch prediction? The pointers are untagged before they are accessed so it should not impact the loads.

I wrote the snippets in x86 asm because I assumed that more people are familiar with it than ARM. Also I ran them on an x86 processor as well.

Wouldn’t a stack map have that value as well?

I don’t know which is worse, that they sold my data or that it was worth so little.

Interesting write up. I am curious about the usage of this framework. One thing in reference counting’s favor is that it is hard to screw up. You just use the rc type and when it is no longer accessible it will magically get freed. That is how GC works in a high level language too, you almost never need to think about it.

Let’s look at the example from the docs:

    SWL_GCArena gc = swl_gc_arena_new(<starting-capacity>);
    int* foo = swl_gc_alloc(&gc, 5000, alignof(int), NULL);
    int* bar = swl_gc_alloc(&gc, 16000, alignof(int), NULL);
    int* baz = swl_gc_alloc(&gc, 3000, alignof(int), NULL);
    // foo and baz are roots
    SWL_GC_COLLECT(&gc, SWL_ROOT(foo), SWL_ROOT(baz));
    // bar is gone, poof

If you try to access bar at the end you get a use after free. I am pretty sure if you tried to access foo again it would trigger the same problem, because it is a pointer directly to int and not an indirection. What happens if you pass a non-arena pointer to SWL_ROOT? What happens if you have multiple arenas and you mix and match them?

There are many ways you could trivially shoot yourself in the foot in large program. It is a lot less “idiot-proof” than simple reference counting. The fact that you create each piece of memory and then have to manually pass it back to the root macro on each collection is very similar to the “malloc/free” dance we want to try and avoid.

The rooting issue is something I tried to tackle in my GC for rust[1]. Essentially making low level GC "idiot proof".

[1] https://coredumped.dev/2022/04/11/implementing-a-safe-garbag...

You can switch to it, but there are still crashes.

Imagine if instead he had been using a car without autopilot and had killed himself and or others. That’s how these “falling asleep at the wheel” stories usually go.

I know there are still some bugs and corner cases that need to be worked out, but I am really impressed with how well this is working. I would think that moving from a traditional single-threaded mark and sweep to a moving, concurrent GC would be a very involved change. Requiring a rewrite of many components. But it looks like it was “just” plugging into the MPS API. I realize that library does several things to make this easier, like supporting pinning and weak references, but I am still impressed.

> Even Copilot loses money, to the tune of around $20 to $80 a month per user, according to The Wall Street Journal

Wow. Does that mean that once the VC money dries up that will be the real cost of the products ($30-$90 a month)? That is much less accessible than $10.

Runtime functions (eg dyn Trait) can’t be inlined for one, so this would help there. But also if you can make calls cheaper then you don’t have to be so aggressive with inlining, which can help with code size and compile times.

It looks like you intended to say that on the sibling comment.

That is just using a RefCell under the hood[1] so it is effectively the same trade-offs as the RefCell example from the article.

[1]https://docs.rs/gc/0.5.0/src/gc/lib.rs.html#495-498

What other representations of "start/current/end" do you know of? Both versions just use 3 pointers. I am not aware of specific instructions on any architecture that would impact the direction the heap grows. They essentially boil down to adds, subtracts, and and's.

Given how much research there is into this topic, I am sure that I just don't understand the complexity of it. But to me it seems like you could have a function that associates one value with another in the GC. Something like `gc_borrows_from`. You would than write the problematic code like this:

    function blob_contents(blob)
       local len_out = ffi.new('unsigned int')
       local contents = gc_borrows_from(blob, hb.hb_blob_get_data(blob, len_out))
       local len = len_out[0];
       return ffi.string(contents, len)
    end

This would tell the GC that the data returned by `hb_blob_get_data` is borrowed from blob, and it can't collect `blob` until `contents` is also unreachable. How to implement that would be up to the runtime, but it seems reasonable to have a wrapper type that holds a traceable reference back to blob.

Wait… you switch away from Emacs?

Have you ever had problem where two of your dependencies are each using a different version of the same library? Or have you ever wanted to incrementally upgrade an API so that you don’t have to change your entire code base in one fell swoop? That is where things like Unison or scrapscript can make it very easy.

This looks like a cool project. It looks like it is up to the host language to compile to bytecode and do all the type analysis before passing that info to the verifier. Looks like there is no VM yet, it just verifies the bytecode and then prints it. But it looks like the host language must also be written in Rust because the main `go` method is expecting rust types. Is that correct?

This is really clever. I was surprised at how much speedup they got by just adding type information. But also the trick to make it ABI compatible with the current API. Takes a certain amount of madness.

I think the GraalVM approach of transforming the C into your own IR and then JITing that is another interesting approach. Essentially treat Java and C as one unified source and compile them together. That certainly takes more work and a very expressive IR, but it is another way to deal with the inefficiency at the API boundary.

If you are going to comment, then you should read the article. But most things posted here (especially by science and tech journalists) are not worth reading and you can get right to the actual information by looking at the comments. No need to read all that extra fluff from some content mill. If it still sounds interesting, then go read it.

> Will we have a way to hint a core/hart to dodge prediction for some branches, fine-grained and "cleanly"?

Why would you want to avoid the branch predictor? All it can do is speedup your code.

I looked into the jump table optimization. The normal Lua version is here[1] and it uses the opcode as a index into a static array to jump to the label. The “faster” Pluto version is here[2] and it just uses a switch statement on the labels. I would naively assume that these would compile to the same code because the lua version is just manually creating the jump table and the pluto version is leaving it to the compiler. How could the compiler optimize the switch so that would outperform the manual jump table (by a decent margin)?

[1] https://github.com/PlutoLang/Pluto/blob/main/src/ljumptabgcc...

[2] https://github.com/PlutoLang/Pluto/blob/main/src/ljumptab.h

How do you store power cheaply? We don’t have the have capability yet. Doesn’t mean we can’t figure it out, but until then we need consistent power. nuclear power is great because the materials are cheap and abundant and the power is very stable. Even the disposal is much safer “than most people think”.

Not OP, but one thing that surprised me was if you are doing rust Simd in a library, and part of the code is marked #[inline] but others are not you might see catastrophic performance regressions. We saw an issue where the SIMD version was over 10x slower because we missed marking one function as inline. Essentially rustc converted it from an intrinsic to a regular function call.

https://github.com/rust-lang/rust/issues/107617#issuecomment...

Not for customers per se, but the company I work for will regularly send “scam” emails to us. If you click on the link you get assigned mandatory corporate phishing trainings. Makes you extra cautious.

> So rather than reduce the animal protein in our diets, we’re determined to farm insects to supplement it.

Protein is really important for our diets. Many adults even in the first world are not getting enough of it. It's not some "luxury" macromolecule the we should just consume less of (like sugar). Most peoples diets (at least in the US) have too many carbs and sugars (plants) and not enough protein (meat). You can get the protein you need from plant based sources, but you have to be really intentional about it and work hard at it. Meat contains every nutrient your body needs besides vitamin C.

This is a really cool approach! But if it so obvious, why doesn't every hashmap use it? It seems like there are some trade-offs here that I must be missing.

I am still trying to wrap my head around how this works. It sounds like it is similar to avy[1] but you use your voice instead of the keyboard? Coupled with some AST aware commands.

[1] https://karthinks.com/software/avy-can-do-anything/

book.gtoolkit.com is the URL

I wasn’t expecting it to describe everything in GT. But I was hoping it would describe something about how these rust wrappers are implemented (or at least link to some code or docs). Being able to inspect your compiled machine code at a high level is really unique property I haven’t seen before and want to learn more about. I didn’t see anything about it in the book either.

I feel like that article skipped over the most interesting part, namely how they they actually implemented the object wrappers.