IIRC MacRuby used to compile to native code on OSX using LLVM, and was supposed to support native OSX APIs and Objective-C frameworks. It always seemed like a neat idea, and a slick integration, but I guess Apple moved to Swift instead.
I'll have to pick up a copy of this "Ruby Under a Microscope" book when the new version comes out. I've always liked Ruby, I just haven't had much chance to use it.
The creator of MacRuby left Apple, and created RubyMotion. It's continued by different people, but still around, though it seems the main focus of the people involved now is DragonRuby (a game-focused Ruby implementation)
My understanding is that MacRuby relied on Apple's ill-fated attempts to migrate from reference counting to regular garbage collection. I would be surprised if GC still worked on modern arm64 macOS. RubyMotion later adopted ARC but then it's not really Ruby anymore.
Typical. I may get absolutely destroyed for this, but being professionally proficient in a ton of languages, including Ruby and the ones I mention below, and the ones I'm about to mention:
This sounds like Microsoft when they moved from VB6 to VB.Net. At least they have a good thing going with C# though.
VB6 was quite an interesting beast. You could do basically everything that you could do in languages like C/C++, but in most cases, you could churn out code quicker. This even extended to DirectX/Direct3D! For Web pages? ASP Classic.
The tl;dr is that I really wish that ease of development were prioritized along with everything else. One of the reasons I like Ruby is the elegance of the language and ease of using it.
Note that I've been using it since the mid 2000s or so, but not exclusively (both it and VB6 defined my career, however). C# is my second most favorite.
If Ruby had the GUI design tools VB6 had, it would be interesting to look at the popularity stats
VB6 deserves the huge popularity it had, but the reason wasn't because of the language design, rather, its (extremely) rapid GUI application development. It was actually a two-edged sword - it facilitated writing spaghetti code.
> You could do basically everything that you could do in languages like C/C++
As long as there is some form of memory access, any language can do basically everything that one can do in C/C++, but this doesn't make much sense.
> As long as there is some form of memory access, any language can do basically everything that one can do in C/C++, but this doesn't make much sense.
No VB6 had really easy COM integration which let you tap into a lot of Windows system components. The same code in C++ often required hundreds of lines of scaffolding, and I'm not exaggerating
FWIW, the pywin32 Python package and win32ole Ruby package have streamlined COM integration for Python and Ruby. Not quite as easy as VB6, but it's pretty close. I was even able to tab complete COM names in the Emacs Python REPL, but I remember it being a little buggy.
It probably still sucks in C, but the C++ DX got a lot better. Importing the idl would generate wrapper functions that made calling code look much more like a normal function. It would check the hresult and return an out param from the function. They also introduced types like _variant_t that help boxing and unboxing native types. It still wasn't fun but it greatly reduced line count.
Nah, unless talking about C++ Builder extensions for COM, in Visual C++ land it still sucks big time.
For some reason, there are vocal teams at Microsoft that resist anything in C++ that is comparable to VB, Delphi, .NET, C++ Builder ease of use regarding COM.
Hence why we got MFC COM, ATL COM, WRL, WinRT (as COM evolution), C++/CX, C++/WinRT, WIL, and eventually all of them lose traction with that vocal group that aparently rather use COM with bare bones IDL files, using the command line and VI on Windows most likely.
Windows has a COM system. VB6 isn’t special. You can do that with VB.Net or C# too, C and C++. Windows COM is a thing. VB6 COM isn’t as VB6 only hooked into windows COM.
I'm just giving context as to why VB6 was much better than C++ back in the day for building windows apps. VB.Net and C# didn't exist in the halcyon days of 1998
I don't think it was too similar, TBH. Apple never took MacRuby as seriously as Microsoft took VB6, and it hadn't even had a 1.0 release when the single developer left Apple to work on RubyMotion.
I do agree it'd be interesting to have a GUI designer for Ruby. Does QML paired with QtRuby work?
In the distant past I had a book about FXRuby, but never used it much, and don't think it had a UI designer - it was just bindings to Fox Toolkit, which is lightweight, but not as well maintained as Qt or Gtk.
By .NET 2.0, VB.NET got most of the stuff back VB 6 folks complained about.
Now what .NET never did as good as VB 6, was ease of COM development experience.
Which given the role of COM in Windows APIs since Vista, is a major pain point as I don't get if COM is so relevant, why Microsoft teams keep rebooting, badly, the COM development experience.
What about something like Shoes[1]? I have played with it a little, just to make a simple UI to run some scripts I can run fine in a shell myself, but less-technical people may be too scared to fire up Terminal.app in order to do the same...
I don’t know what either of those mean in this context, and I used VB6 for a couple years at least and have been programming ObjC and / or Swift since 2006, with some time in Rails over a couple years.
I’m extremely confused by your comment, it’s apparently near verboten in polite company, yet, manages to say nothing other than that while invoking several things of which I’m quite familiar.
If you are destroyed, I anticipate it will be for a quarter baked, horrible, analogy between ObjC/Swift (or is it Ruby/Swift)? and VB6/VB.NET that somehow has something to do with Ruby.
Really happy to see Pat keeping it up! His first Ruby under a Microscope book but also his blog posts are amazing and a major source of inspiration for me. I did meet him personally in a Euruko conference. Such a great person.
I used Ruby a lot from about 2002 to 2010. Haven't used it much since then, but this article really makes me want to get a copy of the upcoming version Ruby Under a Microscope.
It seems to be gone from the repo, and doesn't seem to be worked on any more? A shame.
AOT compiling Ruby is hard. I'm trying [1] [2].
Sorbet would be in a good position because part of the challenge of making it fast is that Ruby has a lot of semantics that are rarely used but that makes making compiled Ruby fast really hard. E.g. the bignum promotion adds overhead to every single operation unless you can prove invariants about the range of the values; the meta-programming likewise adds overhead and makes even very basic operations really expensive unless you can prove classes (or individual objects) aren't being mucked with...
So starting with type checking is an interesting approach to potentially allow for compiling guarded type-specific fast paths. If my compiler ever gets close enough to feature complete (it's a hobby project, so depends entirely on how much time I get, though now I also justify more time for it by using it as a test-bed for LLM tooling), it's certainly a direction I'd love to eventually explore.
[2] https://github.com/vidarh/writing-a-compiler-in-ruby/ (updated now primarily by Claude Code; it's currently focusing on actually passing RubySpec and making speedy progress, at the cost of allowing some fairly ugly code - I do cleanup passes occasionally, but most of the cleanup will be deferred until more passes)
While not related to compiling Ruby, I found the book "Enterprise Integration with Ruby"[0] to be enlightening regarding using it outside of web applications.
Glad to see that Ruby Under a Microscope is still being updated. It’s an essential read for anyone who wants to understand how Ruby works internally — and I truly enjoy reading it.
Once a YJIT block executes enough times to warrant compilation, how does this system keep track of which types to compile for? Each block is tracking how many times it's entered, but not how many times it's entered for int or float or whatever types; so in the given example how would Ruby handle the compilation of the "opt_plus" stub when the input types may vary?
And by what process is the correct compiled block used depending on the input variable types?
That's the magic of YJIT, and what I'll describe in the rest of Chapter 4. YJIT uses a "wait-and-see" approach, and often defers compilation of the block/function until the actual types are provided by your program. And YJIT then keeps track of separate block versions based on the operand types, and can call the appropriate block version as needed.
This basic algorithm is called "Basic Block Versioning." Maxime Chevalier-Boisvert from Shopify has some great presentations online about this; for example [1].
I believe ZJIT, the newer JIT engine, uses a different approach. I'm exploring that now.
> To find hot spots, YJIT counts how many times your program calls each function or block
At first glance this seems too simple. Compare it to JavaScript JITs, which IIRC can compile hot spots even in functions that are only called a few times (e.g. those that contain heavy loops) via on-stack replacement. (Although I’ve also heard on-stack replacement called a “party trick” - more useful for optimising benchmark scores than for real code.)
But on the other hand, Ruby’s language design might help here. Idiomatic Ruby uses blocks for loop bodies - so can Ruby JITs optimise long-running loops by treating the loop body as just another function?
Yes that's something I want to dig into and explore in this chapter... when exactly does Ruby's JIT compiler activate and optimize our code? And you're right: since Ruby will JIT blocks as if they were separate function many loops will be optimized using this simple heuristic.
Making dynamically typed, single threaded languages faster via JIT usually comes at the cost of a significant increase in memory consumption which for businesses smaller than Shopify is a much more significant factor.
Is it? Smaller business usually comes with smaller applications. Most cloud and hardware vendors give you about 4GiB of RAM per core, maybe only 2 when using "CPU optimized instances", that's huge and leave plenty of space for a couple hundred MB of JITed code.
Agreed. In Java land, if I understand correctly the OpenJ9 JVM can (or at least could) beat HotSpot in memory consumption, while being slightly behind in execution times. It still sees only limited adoption. This may be just because it's seen as an 'alternative' option, less trustworthy than HotSpot, but it also seems to indicate the HotSpot developers aren't prioritising memory consumption.
I find that using C as an intermediate step really helps conceptualize this process. It can be tough to imagine how to represent a language like ruby as C. Essentially you have to start from the point that everything is an object and method calls on objects, then build up from that. Then C to assembler is more manageable. Ymmv.
I always found the steps to assembler harder. I'd wish we could have both a hardware interface that is resembled at the same level as the software - but super simple. With that I mean super-simple to understand and write; assembler is simple but not easy to understand. The complexity scales quickly. That's why C was successful - it was much easier to reason about the system in C than it was in assembler/assembly.
Great clear explanation of how YJIT and ZJIT work. The details on block compilation and counting make JIT internals more accessible to Ruby developers.
If you want to compare it against other languages you could look at The Computer Language Benchmarks Game [1], which is an ongoing comparison of various programs written in various popular languages. You should always take all these benchmarks with a pinch of salt though since they are never truly apples-to-apples. That said, Ruby seems to measure slightly faster than Python and Lua, slightly slower than PHP, and maybe 1 order of magnitude slower than Node.js, just to compare it with other similar languages.
Compared to itself from 10 years ago I think it's made great progress. Can't put a number to it but I wouldn't be surprised if it's 2x or 3x faster, especially with the "new" JIT (YJIT) enabled. The JIT comes with a memory usage penalty though. You can see some benchmarks over time (although not going back as far as 10 years) at https://speed.ruby-lang.org
I have a prototype ahead-of-time Ruby compiler. It's woefully incomplete - I've just recently picked it up again after years of inactivity, with heavy AI use to pursue rubyspec compliance (it's nowhere close). The point of mentioning that: MRI - the main Ruby interpreter - is fast enough that competing against it with an unoptimized compiler goes really badly unless you do a lot to optimise the garbage collector (I haven't yet).
So it's "fast". There's plenty more that can be done to make it much faster still, but even before yjit, MRI had gotten pretty decent.
It's gotten faster, but so have other languages. The broad strokes rankings haven't changed so much that raw performance would change your mind today compared to 2015.
I did recent testing that showed it to be faster than Python but slower than Lua: Lua, Ruby and Python ran my benchmark in 12, 18 and 25 seconds respectively.
This was measured using the latest versions of each language (5.4, 3.4 and 3.13), using only the interpreters, no JITs.
> I haven't used it in about 10 years
It looks like the relative performance of the three languages hasn't changed much since I did a similar benchmark with Ruby 2.0, about that long ago.
IIRC MacRuby used to compile to native code on OSX using LLVM, and was supposed to support native OSX APIs and Objective-C frameworks. It always seemed like a neat idea, and a slick integration, but I guess Apple moved to Swift instead.
I'll have to pick up a copy of this "Ruby Under a Microscope" book when the new version comes out. I've always liked Ruby, I just haven't had much chance to use it.
The creator of MacRuby left Apple, and created RubyMotion. It's continued by different people, but still around, though it seems the main focus of the people involved now is DragonRuby (a game-focused Ruby implementation)
It lives on as RubyMotion after the author left Apple, http://www.rubymotion.com/
https://en.wikipedia.org/wiki/RubyMotion
AFAIK, you can still use Objective-C and create apps for macOS, iOS, and iPadOS? The APIs previously used may not be available anymore.
I'm sure you can still use Objective-C, but MacRuby stopped being updated around 2011, and I don't know how well it'd support newer versions of OSX.
I dropped OSX long ago, so can't even try it out any more.
I wonder how much of the LLVM bits could be reused? I'm sure LLVM's changed a bunch in the last 15 years, too.
My understanding is that MacRuby relied on Apple's ill-fated attempts to migrate from reference counting to regular garbage collection. I would be surprised if GC still worked on modern arm64 macOS. RubyMotion later adopted ARC but then it's not really Ruby anymore.
Gees, I forgot about their move to Arm. Almost certainly wouldn't work out of the box any more.
I think you misunderstood the comment. They were referring to Ruby and accessing the APIs.
Typical. I may get absolutely destroyed for this, but being professionally proficient in a ton of languages, including Ruby and the ones I mention below, and the ones I'm about to mention:
This sounds like Microsoft when they moved from VB6 to VB.Net. At least they have a good thing going with C# though.
VB6 was quite an interesting beast. You could do basically everything that you could do in languages like C/C++, but in most cases, you could churn out code quicker. This even extended to DirectX/Direct3D! For Web pages? ASP Classic.
The tl;dr is that I really wish that ease of development were prioritized along with everything else. One of the reasons I like Ruby is the elegance of the language and ease of using it.
Note that I've been using it since the mid 2000s or so, but not exclusively (both it and VB6 defined my career, however). C# is my second most favorite.
If Ruby had the GUI design tools VB6 had, it would be interesting to look at the popularity stats
Anyway, I'm rambling, so there is that. ;)
VB6 deserves the huge popularity it had, but the reason wasn't because of the language design, rather, its (extremely) rapid GUI application development. It was actually a two-edged sword - it facilitated writing spaghetti code.
> You could do basically everything that you could do in languages like C/C++
As long as there is some form of memory access, any language can do basically everything that one can do in C/C++, but this doesn't make much sense.
> As long as there is some form of memory access, any language can do basically everything that one can do in C/C++, but this doesn't make much sense.
No VB6 had really easy COM integration which let you tap into a lot of Windows system components. The same code in C++ often required hundreds of lines of scaffolding, and I'm not exaggerating
FWIW, the pywin32 Python package and win32ole Ruby package have streamlined COM integration for Python and Ruby. Not quite as easy as VB6, but it's pretty close. I was even able to tab complete COM names in the Emacs Python REPL, but I remember it being a little buggy.
It probably still sucks in C, but the C++ DX got a lot better. Importing the idl would generate wrapper functions that made calling code look much more like a normal function. It would check the hresult and return an out param from the function. They also introduced types like _variant_t that help boxing and unboxing native types. It still wasn't fun but it greatly reduced line count.
Nah, unless talking about C++ Builder extensions for COM, in Visual C++ land it still sucks big time.
For some reason, there are vocal teams at Microsoft that resist anything in C++ that is comparable to VB, Delphi, .NET, C++ Builder ease of use regarding COM.
Hence why we got MFC COM, ATL COM, WRL, WinRT (as COM evolution), C++/CX, C++/WinRT, WIL, and eventually all of them lose traction with that vocal group that aparently rather use COM with bare bones IDL files, using the command line and VI on Windows most likely.
Windows has a COM system. VB6 isn’t special. You can do that with VB.Net or C# too, C and C++. Windows COM is a thing. VB6 COM isn’t as VB6 only hooked into windows COM.
I'm just giving context as to why VB6 was much better than C++ back in the day for building windows apps. VB.Net and C# didn't exist in the halcyon days of 1998
I don't think it was too similar, TBH. Apple never took MacRuby as seriously as Microsoft took VB6, and it hadn't even had a 1.0 release when the single developer left Apple to work on RubyMotion.
I do agree it'd be interesting to have a GUI designer for Ruby. Does QML paired with QtRuby work?
In the distant past I had a book about FXRuby, but never used it much, and don't think it had a UI designer - it was just bindings to Fox Toolkit, which is lightweight, but not as well maintained as Qt or Gtk.
By .NET 2.0, VB.NET got most of the stuff back VB 6 folks complained about.
Now what .NET never did as good as VB 6, was ease of COM development experience.
Which given the role of COM in Windows APIs since Vista, is a major pain point as I don't get if COM is so relevant, why Microsoft teams keep rebooting, badly, the COM development experience.
What about something like Shoes[1]? I have played with it a little, just to make a simple UI to run some scripts I can run fine in a shell myself, but less-technical people may be too scared to fire up Terminal.app in order to do the same...
1: http://shoesrb.com/
Shoes was very limited, and could only be used for extremely simple applications.
> At least they have a good thing going with C# though.
F# is pretty well-liked, too, isn't it?
Typical? Of whom?
You might get destroyed for this? Why?
I don’t know what either of those mean in this context, and I used VB6 for a couple years at least and have been programming ObjC and / or Swift since 2006, with some time in Rails over a couple years.
I’m extremely confused by your comment, it’s apparently near verboten in polite company, yet, manages to say nothing other than that while invoking several things of which I’m quite familiar.
If you are destroyed, I anticipate it will be for a quarter baked, horrible, analogy between ObjC/Swift (or is it Ruby/Swift)? and VB6/VB.NET that somehow has something to do with Ruby.
Really happy to see Pat keeping it up! His first Ruby under a Microscope book but also his blog posts are amazing and a major source of inspiration for me. I did meet him personally in a Euruko conference. Such a great person.
What a lovely comment - thank you!
whoa, the man himself! I second the praise, an all around excellent writer!
I loved Ruby Under a Microscope when I first read it, and using that knowledge was able to have fun with some CTFs years ago.
I haven't kept up with the evolving Ruby implementation internals, so I will sure as heck buy this new version of the book.
I used Ruby a lot from about 2002 to 2010. Haven't used it much since then, but this article really makes me want to get a copy of the upcoming version Ruby Under a Microscope.
Speaking of compiling Ruby. And Stripe coders who have used the Sorbet compiler?
https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp...
It seems to be gone from the repo, and doesn't seem to be worked on any more? A shame.
AOT compiling Ruby is hard. I'm trying [1] [2].
Sorbet would be in a good position because part of the challenge of making it fast is that Ruby has a lot of semantics that are rarely used but that makes making compiled Ruby fast really hard. E.g. the bignum promotion adds overhead to every single operation unless you can prove invariants about the range of the values; the meta-programming likewise adds overhead and makes even very basic operations really expensive unless you can prove classes (or individual objects) aren't being mucked with...
So starting with type checking is an interesting approach to potentially allow for compiling guarded type-specific fast paths. If my compiler ever gets close enough to feature complete (it's a hobby project, so depends entirely on how much time I get, though now I also justify more time for it by using it as a test-bed for LLM tooling), it's certainly a direction I'd love to eventually explore.
[1] https://hokstad.com/compiler (not updated for a decade)
[2] https://github.com/vidarh/writing-a-compiler-in-ruby/ (updated now primarily by Claude Code; it's currently focusing on actually passing RubySpec and making speedy progress, at the cost of allowing some fairly ugly code - I do cleanup passes occasionally, but most of the cleanup will be deferred until more passes)
While not related to compiling Ruby, I found the book "Enterprise Integration with Ruby"[0] to be enlightening regarding using it outside of web applications.
0 - https://www.goodreads.com/book/show/624316.Enterprise_Integr...
Glad to see that Ruby Under a Microscope is still being updated. It’s an essential read for anyone who wants to understand how Ruby works internally — and I truly enjoy reading it.
Once a YJIT block executes enough times to warrant compilation, how does this system keep track of which types to compile for? Each block is tracking how many times it's entered, but not how many times it's entered for int or float or whatever types; so in the given example how would Ruby handle the compilation of the "opt_plus" stub when the input types may vary?
And by what process is the correct compiled block used depending on the input variable types?
That's the magic of YJIT, and what I'll describe in the rest of Chapter 4. YJIT uses a "wait-and-see" approach, and often defers compilation of the block/function until the actual types are provided by your program. And YJIT then keeps track of separate block versions based on the operand types, and can call the appropriate block version as needed.
This basic algorithm is called "Basic Block Versioning." Maxime Chevalier-Boisvert from Shopify has some great presentations online about this; for example [1].
I believe ZJIT, the newer JIT engine, uses a different approach. I'm exploring that now.
[1] https://www.youtube.com/watch?v=zO9_uTaELCw — RubyConf 2021 - YJIT - Building a new JIT Compiler inside CRuby by Maxime Chevalier Boisvert.
Ever since I discovered MRuby, I’ve had fun converting my projects and scripts into standalone executable files.
> To find hot spots, YJIT counts how many times your program calls each function or block
At first glance this seems too simple. Compare it to JavaScript JITs, which IIRC can compile hot spots even in functions that are only called a few times (e.g. those that contain heavy loops) via on-stack replacement. (Although I’ve also heard on-stack replacement called a “party trick” - more useful for optimising benchmark scores than for real code.)
But on the other hand, Ruby’s language design might help here. Idiomatic Ruby uses blocks for loop bodies - so can Ruby JITs optimise long-running loops by treating the loop body as just another function?
> Idiomatic Ruby uses blocks for loop bodies
Yes that's something I want to dig into and explore in this chapter... when exactly does Ruby's JIT compiler activate and optimize our code? And you're right: since Ruby will JIT blocks as if they were separate function many loops will be optimized using this simple heuristic.
Making dynamically typed, single threaded languages faster via JIT usually comes at the cost of a significant increase in memory consumption which for businesses smaller than Shopify is a much more significant factor.
Is it? Smaller business usually comes with smaller applications. Most cloud and hardware vendors give you about 4GiB of RAM per core, maybe only 2 when using "CPU optimized instances", that's huge and leave plenty of space for a couple hundred MB of JITed code.
Agreed. In Java land, if I understand correctly the OpenJ9 JVM can (or at least could) beat HotSpot in memory consumption, while being slightly behind in execution times. It still sees only limited adoption. This may be just because it's seen as an 'alternative' option, less trustworthy than HotSpot, but it also seems to indicate the HotSpot developers aren't prioritising memory consumption.
https://bell-sw.com/announcements/2022/06/28/hotspot-vs-open...
https://eclipse.dev/openj9/performance/ (non-impartial source, of course)
I find that using C as an intermediate step really helps conceptualize this process. It can be tough to imagine how to represent a language like ruby as C. Essentially you have to start from the point that everything is an object and method calls on objects, then build up from that. Then C to assembler is more manageable. Ymmv.
I always found the steps to assembler harder. I'd wish we could have both a hardware interface that is resembled at the same level as the software - but super simple. With that I mean super-simple to understand and write; assembler is simple but not easy to understand. The complexity scales quickly. That's why C was successful - it was much easier to reason about the system in C than it was in assembler/assembly.
Great clear explanation of how YJIT and ZJIT work. The details on block compilation and counting make JIT internals more accessible to Ruby developers.
How fast is Ruby, lately?
I haven't used it in about 10 years
If you want to compare it against other languages you could look at The Computer Language Benchmarks Game [1], which is an ongoing comparison of various programs written in various popular languages. You should always take all these benchmarks with a pinch of salt though since they are never truly apples-to-apples. That said, Ruby seems to measure slightly faster than Python and Lua, slightly slower than PHP, and maybe 1 order of magnitude slower than Node.js, just to compare it with other similar languages.
Compared to itself from 10 years ago I think it's made great progress. Can't put a number to it but I wouldn't be surprised if it's 2x or 3x faster, especially with the "new" JIT (YJIT) enabled. The JIT comes with a memory usage penalty though. You can see some benchmarks over time (although not going back as far as 10 years) at https://speed.ruby-lang.org
1: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I have a prototype ahead-of-time Ruby compiler. It's woefully incomplete - I've just recently picked it up again after years of inactivity, with heavy AI use to pursue rubyspec compliance (it's nowhere close). The point of mentioning that: MRI - the main Ruby interpreter - is fast enough that competing against it with an unoptimized compiler goes really badly unless you do a lot to optimise the garbage collector (I haven't yet).
So it's "fast". There's plenty more that can be done to make it much faster still, but even before yjit, MRI had gotten pretty decent.
It's gotten faster, but so have other languages. The broad strokes rankings haven't changed so much that raw performance would change your mind today compared to 2015.
> How fast is Ruby, lately?
I did recent testing that showed it to be faster than Python but slower than Lua: Lua, Ruby and Python ran my benchmark in 12, 18 and 25 seconds respectively.
This was measured using the latest versions of each language (5.4, 3.4 and 3.13), using only the interpreters, no JITs.
> I haven't used it in about 10 years
It looks like the relative performance of the three languages hasn't changed much since I did a similar benchmark with Ruby 2.0, about that long ago.
> I did recent testing
A little more detail would be helpful.
luajit likely still smokes it then
Yeah, LuaJIT and PyPy run it in about 2 seconds. I haven't tried a Ruby JIT though.
"naive un-optimised single-thread programs transliterated line-by-line literal style into different programming languages from the same original."
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Fast enough for most normal sites.