Love me overwatch. Love cheese pizza. Love Indian food. Love nature. Love the rain. Love me aul ma. Love me grand parents. Love the crisp cold of an early morning. Love the sound of thunder as a storm rolls in. Love music, sleeping in, and winter days. Love being the only person around. Simple as!
Then if you want the fastest performance possible for a server this is the epoll-based fastest benchmark program (it calls directly into an optimized server dispatcher built into the runtime. It's designed to minimize Python call overhead while still supporting handlers):
There's an equivalent of that for TCP connections too. UDP hasn't been added yet (optimized version.) And yes -- I have to admit that the API is a mess at the moment and so are the docs. This hasn't been designed well to be user-friendly (like 10 ways to do the same thing...) I just haven't had time to do it. All my time went into testing the project. And tuning performance. So you see a mix of different approaches. But this could be fixed fairly easily in the future.
It depends on Python >= 3.13t, no-gil (so it can use real OS threads without locking.) It's been tested on 3.13t and 3.14t. As far as I know future versions of Python beyond that aren't planned for release for a number of years. But the extension code is fairly isolated. E.g. getting the extension to work on 3.14t from 3.13t took about 5 minutes. We're not reaching deep into the interpreter because the interface for extensions is well-defined already.
For the Python code you've really got 3 ways to use this extension:
1. You can use the main API. No monkey patching stuff. You use things like channels and the optimized serve API (this is what had the highest number in bench marks.) Here, you're using the projects APIs for networking.
2. Monkey patching. You use regular Python code inside the fibers. So you can write stuff like socket.socket ... and its patched to call runloom networking functions. You can see this points back to (1) but it has an overhead on top. You get to use libraries you're familiar with.
3. AIO bridge. This is to get asyncio code running on the scheduler. When you use the asyncio bridge it only uses a single thread. The main purpose of this is kind of like: "try out the project with your existing code." It also served the duel purpose of helping to find bugs in the runtime. Since I could reuse literally millions of test cases for the bridge.
tl; dr, (1) for a new project trying runloom -- learn the APIs. Or (2) if you mostly don't want to bother learning anything new / optimising anything. It might be a little slower but it will work. (3) you can mostly ignore. Unless you want to try asyncio code on it for the hell of it.
I just copy pasted the work from my old repo into the main one. The main reason was hundreds of MD files and agent results were added into the repo that would have been impossible to clear from history.
This wasn't all written in one shot. I built the project over several months and spent the whole time testing it. Most of the code in the repo is QA / tests.
I had written an article that speaks about the project that I'd hoped would get upvoted (instead of this github link.) It speaks a lot about where the project aims, how it works, and the testing process, (read about my testing process at the end):
You can make software secure though since it can be patched. How do you patch hardware if it has design flaws? The whole claim behind these hardware cages is they can't be accessed from outside the cage, period. So IMO, seeing multiple failings of this sort kind of makes me not want to trust it.
there are private exploits built into devices like Cellebrite that the police have access to. The system isn't as infallible as you think. Would not be surprised if the NSA and various hacking groups have stockpiles, too.
It's a nice idea, but I wouldn't design any system on the assumption that a TPM needs to stay secure for the system to be safe. There's been so many exploits. We can consider the iphone as an R & D platform for doing blackbox computations. In that nothing is allowed to run that Apple doesn't want. Protecting that is apples bread and butter and they care about it enough to value critical exploits in the millions. Yet people still find them all the time. I feel like if a company that invests millions in the concept can't make it secure then the concept probably isn't that great.
Bros "discuss on hacker news" link takes you to submit the article here. that really rustles my jimmies. its unfortunate that bro couldnt csrf the submit link thanks to submit tokens. I have no doubt he would have tried that too.
I've never had a single email from posting in any of these threads. I think posting here just makes you look desperate. Biggest success I've had is just emailing people.
"I think this could have been explicit.
Developer tools can enforce terms. API providers can detect abuse. Companies can protect their models."
Literally, how. How does one determine what abusive use looks like for the API without context into the client? All requests look like the same stuff. If there was a better way then they would have done it. Or is the author hoping that if Anthropic writes "hey china, please don't steal our models, kthanks" they won't? Like get real. This stuff means nothing in China. China can't even manage to regulate their building industry enough to use real concrete where it's warranted.
Yes, io_uring is significantly faster than epoll (I think I had like 20% faster req/s with io_uring.) The catch is that its kernel opt-in and disabled just about everywhere for security reasons. I think that it has direct memory sharing between the kernel and user-land which is kind of yikes. There's been multiple exploits that hit io_uring in recent times. It's because of this that even engineering projects that try to reach the highest performance possible (like Go) don't really bake io_uring in as a sane default. Though if you want to take the risk you can always run it yourself for your favourite language. It is faster but the cost is possible exploits.
It can already produce code for just about anything you can name. From implementations of browsers to micro-kernels. Yes, it doesn't yet one-shot any problem but my interactions lead me think it won't be long before that is automated. My intuition of how this will be done won't be with some elegant solution where any given step never fails. It will more be like swarms of interacting agents, loops, and formalised processes (themselves little more than frameworks of prompts), all inching towards the solution progressively and self-correcting when they go off course. This will be cheaper to do when models improve and cost less.
There is another bottleneck though and it's important: the personal computing needed to really do this well is ... expensive. What I mean is to even utilise this in a development process you need access to your own high-end hardware where the agents can run experiments fast. That requires (1) a lot of cores (2) and a lot of RAM. So there's a bottleneck in personal computing, too. Unfortunately, I really do think we're all screwed here. Increasingly: the most optimistic projections for what AI will be able to do are starting to become reality every few months. So the odds aren't looking good here.
https://youtube.com/watch?v=1YW_6OXYB7E