fredlinhares (Frederico Linhares)
- Login: fredlinhares
- Registered on: 11/17/2025
- Last sign in: 04/30/2026
Issues
| open | closed | Total | |
|---|---|---|---|
| Assigned issues | 0 | 0 | 0 |
| Reported issues | 1 | 0 | 1 |
Activity
04/10/2026
-
06:15 PM Ruby Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust
- ufuk (Ufuk Kayserilioglu) wrote in #note-8:
How do get from compile time code generation to runtime compilation?
I am using these hacks I mentioned and many other related hacks to make a JIT compiler. My point is that using Ruby to ...
04/09/2026
-
06:21 PM Ruby Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust
- Let me try to elaborate as much as I can.
Rust is not as fast as C; it is as fast as the equivalent C. However, C allows us to use some valid memory management techniques that are impossible in Rust unless you use considerable amount...
04/08/2026
-
05:42 PM Ruby Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust
- Sorry for the delay. I was busy until very recently, but I will be more active from now on. Here is the repository: https://gitlab.com/fredlinhares/pre_c
11/20/2025
-
01:07 AM Ruby Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust
- Currently, my goal is to rewrite the C++ code I have into C. To achieve this, I am creating a set of macros in Ruby on top of C that run at compile time, and the output of these macros is C code. Here is an example of what I am doing, ...
11/17/2025
-
08:01 PM Ruby Feature #21695 (Open): Optimizing Ruby performance with Ruby itself instead of Rust
- I am using ERB on top of C for a game I am making now. We can use the tool to improve the productivity, memory safety, and runtime speed for Ruby. It can also replace a Rust JIT compiler for better results. The only problem is that it...