Question to the one that tested it : Does it still timeout a lot with unreliable response time (1-5 sec) ?
Readit NewsFiahil commented on Improved Gemini 2.5 Flash and Flash-Lite developers.googleblog.com... · Posted by u/meetpateltech
Compiler performance must be considered up front in language design. It is nearly impossible to fix once the language reaches a certain size without it being a priority. I recently saw here the observation that one can often get a 2x performance improvement through optimization, but 10x requires redesigning the architecture.
Rust can likely never be rearchitected without causing a disastrous schism in the community, so it seems probable that compilation will always be slow.
At some point, the community is also responsible for the demanding expectation of a "not slow" compiler.
What's "slow"? What's "fast"? It depends. It depends on the program, the programmer, his or her hardware, the day of the week, the hour of the day, the season, what he or she had for lunch, ...
It's a never ending quest.
I, for exemple, am perfectly happy with the current benchmark of the rust compiler. I find a x2 improvement absolutly excellent.
Fiahil commented on Lock-Free Rust: How to Build a Rollercoaster While It's on Fire yeet.cx/blog/lock-free-ru... · Posted by u/r3tr0
You can go one step further if :
- you don't reallocate the array
- you don't allow updating/ removing past inserted values
In essence it become a log, a Vec<OnceCell<T>> or a Vec<UnsafeCell<Option<T>>>. Works well, but only for a bounded array. So applications like messaging, or inter-thread communication are not a perfect fit.
It's a fixed-size vector that can be read at the same time it's being written to. It's no a common need.
Let me remind you guys that "just 20 light years" = roughly 200 trillion kms. At the speed of voyager 1, it takes roughly 1600 yrs to travel 1 trillion kms. 200 trillion kms would take 320,000 years to reach there. Even if you increased the speed of voyager 1 by 10 times, it would still take 32000 years to reach. We really need to up the speed by a factor of 10000 before we can get anywhere close to human lifetime achievable travel times.
Yes, but that’s only a few hours away through hyperspace !
Fiahil commented on Show HN: Kameo – Fault-tolerant async actors built on Tokio github.com/tqwewe/kameo... · Posted by u/tqwewe
> Right. It's not a very widespread use case, to be honest. You'd find that most would be N actors for M threads (where N <= M
What makes you think that? Having a large number of actors per thread is by far the most important use case. The Actor model is commonly used in communication systems where there are hundreds of thousands of actors per machine (often one for every single user). In this context, Actors are typically extremely lightweight and not CPU-bound. Instead, they mostly focus on network I/O and are often idle, waiting for messages to arrive or be sent.
I think you misread :
- 2 actors on 1 thread = OK
- 1 actor on 2 thread = you are probably doing it wrong.
As for the rest, whether or not they are used in communication systems and whether or not they are cpu-bound, consider there are and run the handle on a separate loop from the main message dispatching. Otherwise you _will_ delay messaging if handles don't await.
Fiahil commented on Show HN: Kameo – Fault-tolerant async actors built on Tokio github.com/tqwewe/kameo... · Posted by u/tqwewe
In the case of tokio, multiple actors can run on a single thread. Tokio uses a worker pool of threads equal to the number of cores on your system. So spawning a new actor will run amongs other actors. This lets us perform io operations in an actor, such as http connection, and progress other actors whilst waiting for a response.
Kameo does have a `spawn_in_thread` function for CPU bound actors if needed.
> multiple actors can run on a single thread.
Right. It's not a very widespread use case, to be honest. You'd find that most would be N actors for M threads (where N <= M ; an Actor in itself is never shared among multiple threads [So `Send` and not `Sync`, in theory] - an inner message handler _could_ have parallel processing but that's up to the user)
I think you should assume in Kameo that every Actor's message handler is going to be CPU-bound. For example, it means that your internal message dispatch and Actor management should be on a separate loop from the User's `async fn handle`. I don't know if it's already the case, but it's an important consideration for your design.
Nice library, BTW, I think it checks all the marks and I like your design. I've tried most of them but could not find one that I liked and/or that would not have a fatal design flaw (like async_traits, ...) :)
PS : Multi-threaded tokio runtime should be the default. Nobody wants a single-threaded actor runtime. It should be in capital letters in the readme.
Fiahil commented on Show HN: Kameo – Fault-tolerant async actors built on Tokio github.com/tqwewe/kameo... · Posted by u/tqwewe
What's the reason for using Async for an Actor framework ?
They run in separate tasks / threads anyway and they are cpu-bound. So, why would it be necessary to make them async ?
Deleted Comment
Fiahil commented on The OpenAI board was right garymarcus.substack.com/p... · Posted by u/isaacfrond
It is reasonably common in the voicing part of the acting industry, when a famous name turns you down, that you instead turn to a voice imitator to give a performance that's reminiscent of a number of factors (kind of sounding like this other person, for example).
This way, legally you're in the clear, because you didn't use the voice of X. Not on any occasion did you use the voice of X. You even paid a voicer to make your recordings, and it's their voice.
Morally, it can be - and probably is - a different matter.
Yet, legal opinions seems to differ : https://news.ycombinator.com/item?id=40423224
Kanclaw
Clawban
Clawboard
Clawlo
Clask (Claw-task)