That seems great, I have seen a few similar dbs written in java that say the same thing, that when written correctly you can get the perf very close to C, but at that point you are just writing C with a different syntax. You don't win on any in the security guarantees, so at that point can we just not build everything in wasm and then we can interface it from both dotnet and the jvm?

I hope we get more people testing and wonting on harnesses for local agents so they get more democratized

To be honest I am a bit sad as, glm5.1 is producing mich better typescript than opus or codex imo, but no matter what it does sometimes go into shizo mode at some point over longer contexts. Not always tho I have had multiple session go over 200k and be fine.

I just set the context window to 100k and manage it actively (e.g. I compact it regularly or make it write out documentation of its current state and start a new session).

For me, Opus 4.6 isn't working quite right currently, and I often use GLM 5.1 instead. I'd prefer to use peak Opus over GLM 5.1, but GLM 5.1 is an adequate fallback. It's incredible how good open-weight models have gotten.

When it works and its not slow it can impress. Like yesterday it solved something that kimi k2.5 could not. and kimi was best open source model for me. But it still slow sometimes. I have z.ai and kimi subscription when i run out of tokens for claude (max) and codex(plus).

i have a feeling its nearing opus 4.5 level if they could fix it getting crazy after like 100k tokens.

Why don't you start a new session or use the /compact command when context gets to 100k tokens?

From my testing it was ok until 145k tokens, the largest context I had before switching to a new session. I think Z.ai officially said it should be good until 200k tokens.

Using it in Open Code is compacting the context automatically when it gets too large.

Why is that sad? A free and open source model outperforming their closed source counterparts is always a win for the users

The non-awesome context window is the sad part, but I think a better harness can deal with this.

I honestly still hold onto habits from earlier days of Claude & Codex usage and tend to wipe / compact my context frequently. I don't trust the era of big giant contexts, frankly, even on the frontier models.

I also feel like its helping me on the big models these days with claude giving so many issues.

After the context gets to 100k tokens you should open a new session or run /compact.

I've set max context to 180k and usually compact around 120k. It's much better to re-read stuff than to have it under-perform when it's over 120k.

Isn't the same with opus nowadays?

Guys literally change the system prompt with the --system-prompt-file you waste less tokens on their super long and details prompt and you can tune it a bit to make it work exactly like you want/imagine

Where can I see mine?

Install the plugin and then load up your profile page, or any page with ac omment from you (like this one)

You have an overall 7 out of 8.

I have used baml before and that worked super well for me multiple times so I don't see a problem with that.

This is actually super cool, you can use those as both math accelerators and as io, and them being in lockstep you can kind of use them as int only shader units. I don't know how this is useful yet.

Btw I am curious what about edge cases. Maybe I have missed that from the article but what is the size of the FIFO?

Or the more dangerous part that is you have complex to determine timing now for complex cases like each reqd from FIFO is and ISR and you have until the next read from the FIFO amount of instructions otherwise you would stall the system and that looks to me too hard to debug.

FIFO is 8-deep. I did fail to mention that explicitly in the article, I think. The depth is so automatic to me that I forget other people don't know it.

The deadlock possibilities with the FIFO are real. It is possible to check the "fullness" of a FIFO using the built-in event subsystem, which allows some amount of non-blocking backpressure to be had, but it does incur more instruction overhead.

True, but take into account that plants need to be able to fly/fight with instruments only and without vision.

Also dogfights are much rarer now, most people just fling rockets at each other (so you know how much these cost, a b200 seems cheap in comparison)

That reminds me a lot of the xmos xcore mcus with 8 cores. I am curious what kind of synchronization primitives have you added and why?

I'm actually working on a comprehensive write up on exactly this topic that should be out sometime next week!

Just ordered 2 to play with!

thank you~~

Sounds like the Parallax Propeller 1/2 as well.

It's a good model for MCU stuff. There were people pushing Chip Gracey (Parallax) to use RISC-V instead of his custom ISA when he designed the P2 a few years ago, but he chose to do his own thing. Which has made compiler development difficult.

This seems more on the RPI side rather than propeller, propeller was never a really good choice for production integration. This looks like it could hold its own in many contexts.

If I understand the architecture it's both -- a main MPU style core and then a bunch of PicoRiscV cores doing MCU tasks. The smart thing about using RISC-V here being having a unified ISA so you can compile programs that run on both or move between both, etc.

I'm assuming he probably has some sort of roundrobin shared memory access similar to what Chip did with "HUB Ram" on the P2.

This is the same chip as the iphone, the only thing that need to be done is make something like m1n1 work with iOS and circumvent all the security measures