Live data from Hacker News

Compiling Ruby to machine language

patshaughnessy.net

51–56 of 56 posts

Re: Compiling Ruby to machine language

#51

Earlier quoted context omitted.

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++…

> 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

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.

Re: Compiling Ruby to machine language

#52

Earlier quoted context omitted.

> 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

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

Re: Compiling Ruby to machine language

#53

Earlier quoted context omitted.

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.

Re: Compiling Ruby to machine language

#54

How fast is Ruby, lately? I haven't used it in about 10 years

"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/...

Re: Compiling Ruby to machine language

#55
post #26

How fast is Ruby, lately? I haven't used it in about 10 years

> 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 change…

> I did recent testing

A little more detail would be helpful.

Re: Compiling Ruby to machine language

#56
post #47
post #25

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)

Post reply on HN