Boost Lambda Performance: Rewrite Ruchy-Lambda Runtime

by SLV Team 55 views
Boost Lambda Performance: Rewrite Ruchy-Lambda Runtime

Hey everyone, let's dive into a cool feature request that could seriously supercharge the ruchy-lambda project! We're talking about rewriting the Lambda runtime in Ruchy itself, once async/await support lands. Sounds exciting, right?

The Current Setup and Why We're Looking at a Change

Right now, the ruchy-lambda project is built with Rust. Specifically, the runtime infrastructure, which handles the nitty-gritty details like HTTP requests, event loops, and deserialization, is all hand-written in Rust. You can check it out in the crates/runtime/ directory of the ruchy-lambda repository. The current implementation is already pretty solid, but we're always looking for ways to make things better, faster, and more efficient.

Now, you might be wondering, why the switch? Well, it all boils down to performance and developer experience. As you all know, we're all about optimization and squeezing every last drop of performance out of our systems. And as it turns out, Ruchy has the potential to do just that. Our benchmarks show that Ruchy can generate Rust code that rivals, or even surpasses, hand-written Rust in terms of performance. In one specific benchmark (BENCH-011), Ruchy actually outperformed hand-written Rust by a significant margin. This is a huge deal, because it means we could potentially make our Lambda runtime even faster by leveraging Ruchy.

So, what does this mean? It means we're considering a move that could not only boost performance, but also make the codebase more pleasant to work with. Keep reading to find out why.

The Proposal: Ruchy to the Rescue!

Here's the plan, guys. Once Ruchy gets async/await support, which is on the roadmap, we're going to rewrite the Lambda runtime infrastructure in Ruchy. Let's break down the current state and the envisioned future, comparing the code to give you a clear picture.

Current (Rust):

// crates/runtime/src/lib.rs
impl Runtime {
    pub async fn next_event(&self) -> Result<String> {
        let client = self.get_client()?;
        client.get("/runtime/invocation/next").await
    }
}

Future (Ruchy with async):

# runtime.ruchy
class Runtime
  async fun next_event() -> String
    client = get_client()
    await client.get("/runtime/invocation/next")
  end
end

As you can see, the Ruchy version is more compact and, in my opinion, easier to read. It's written in a Ruby-like syntax that is meant to be more ergonomic to write and maintain. This is an added benefit on top of potential performance improvements. The transition would involve re-implementing crucial components like the Runtime class, the HttpClient, and the event loop, all within the Ruchy language. This would give us an opportunity to make the codebase more maintainable and enjoyable to work with. The goal is to get a faster, more readable codebase, and improve our developer experience.

The Perks: Why This Rewrite Rocks!

This rewrite is a total win-win situation. The benefits are numerous, but let's highlight the major ones:

  1. Performance Boost: Ruchy's transpiler could generate EVEN more optimal Rust code than we can write by hand. That's a huge potential win for speed.
  2. Developer Nirvana: Ruby-like syntax is easier to write and maintain, making development a breeze. It's all about making the code more human-friendly!
  3. Dogfooding Delight: This would prove Ruchy can build production systems, which is something we are all eager to see!
  4. Binary Size Reduction: The transpiler's optimizations might shrink the binary size, making our Lambda functions even leaner.

These are all pretty compelling reasons to go ahead with this rewrite. This isn't just about faster performance, it's about a better development experience and the ability to build even more robust systems using Ruchy. It could give our Lambda functions a significant speed and size boost, while making the codebase itself more pleasant to work with. If it is possible, this is a must do.

The Roadblocks: What We Need to Overcome

Of course, there are a few things standing in our way. Let's talk about the roadblocks we need to address before we can make this happen:

  • Ruchy async/await Implementation: This is the big one. We need the async/await keywords implemented in Ruchy before we can do anything. The implementation is in the planned section and there are no roadblocks here.
  • Tokio Integration: We need support for Rust futures and tokio in the transpiled code. This includes implementing an HTTP client library that will handle the network requests. It involves figuring out how to integrate with an async runtime like Tokio or creating our own implementation.
  • HTTP Client APIs: We need to figure out how we will implement the HTTP client. The decision is either a built-in HTTP client or an FFI to existing Rust crates like hyper or reqwest. We need to address the basic async I/O primitives like TcpStream, etc.

Overcoming these roadblocks is critical, but the potential payoff is well worth the effort. Let's get these things moving!

Dependencies: The To-Do List

Here's what needs to be done to make this happen. It's a to-do list for anyone who wants to jump in and help!

  • Implement async/await keywords in Ruchy language.
  • Support for Rust futures/tokio in transpiled code.
  • HTTP client library (built-in or FFI to hyper/reqwest).
  • Async I/O primitives (TcpStream, etc.).

By checking off these boxes, we'll be well on our way to a re-written Lambda runtime in Ruchy.

Success Criteria: How We'll Know We Won

Okay, so what does success look like? Here's what we'll be aiming for:

  • The entire Lambda runtime (Runtime, HttpClient, event loop) must be written in Ruchy.
  • Performance must be at least as good as the current Rust implementation. We're aiming for faster, but at a minimum, we don't want to lose ground.
  • Binary size should be less than or equal to the current implementation. We want our Lambda functions to be lean and efficient.
  • All tests must pass. We need to maintain a high level of code quality and ensure everything still works as expected. We want to be sure that the 65+ test suite is running without any issues.

These criteria are a must, it ensures that we are moving forward with a good direction.

Related Work: Where to Learn More

If you want to dive deeper, here are some resources:

  • Appendix B: Ruchy vs Julia architecture comparison. Check this out to get a better understanding of how Ruchy compares to other languages and its architecture.
  • BENCH-011: Ruchy transpiled beats Rust by 7%. This benchmark demonstrates the potential performance benefits of Ruchy.
  • ruchy serve command: This shows Ruchy can handle HTTP and async via Rust FFI. This can give you an idea of how Ruchy handles HTTP and asynchronous operations.

Check these out to learn more and see the potential of Ruchy.

Priority: Medium, but High Value

This is a medium-priority task right now, as it's blocked on the async/await implementation. But once that lands, the value is super high. This is one of those projects that has the potential to make a big impact on the ruchy-lambda project.

---This is a fantastic opportunity to improve performance, improve developer experience, and explore the potential of the Ruchy language. Let's get to it!

Note: This issue tracks a future enhancement. Current ruchy-lambda development continues with Rust runtime until Ruchy async lands.