Optimizing Raku Programs with Zig | Hacker News Reader

Optimizing Raku Programs with Zig

raku-advent.blog

65 pointssystems13 comments

> Tikka throws her arms around her daughter and says, “Well, I sure am glad I was listening to all your chirping about Zig! It looks like we have a workable solution for speeding up our Raku code to handle the peak load!”

> Tamala squirms, trying helplessly to dodge her mother’s love attack.

cargo uninstall mommy-rs

nice summary - Raku’s strong NativeCall (FFI) support makes light of integrations like these - C, C++, Python, Perl5 are all good targets and handy for grabbing packages from PyPI and cpan when the raku ecosystem (2777 packages and growing) doesn’t yet have a native module

all dynamic languages compromise on execution speed and often a Python package combines a fast C execution engine - Raku modules can build in binaries in an analogous way

when it comes to dropping into a low level code for a speed boost, for a while I have thought that Raku + Rust is a good combination (akin to Python + C), for example to integrate to the blazing fast Rust Polars data science module

looks like Zig is an even better bet for a lightweight glue layer to harness a C library (or roll your own low level accelerator), especially since the safety aspects of Rust are reduced whenever FFI comes into play

> makes light of

I assume you mean "makes light work of". Making light of something means to disparage it, usually as frivolous/unserious/etc.

guess your a Rust coder by nature

> all dynamic languages compromise on execution speed

Not all, some of them bring a JIT compiler, or several, in the box, reducing the need to reach out to compiled languages as step zero on optimizations.

Some of them even support AOT compilation, alongside low level systems programming, like BASIC, Lisp, Scheme or Dylan.

fair point, perl5 is pretty fast too

the raku vm (moarvm) does have jit already but until the current AST work is done, it is limited in the depth of code inspection it can do to meaningfully accelerate

even with very mature jit (eg. java) it is not generally possible to outperform static compiler optimisations

On Java case, depends on which toolchain it is being tested, how many JIT levels it supports, if PGO is part of the picture, if it does JIT caching, if there is an AOT compilation available as well.

On Android/ART, multiple factors collaborate for the best AOT compilation with optimising compiler, when the device is idle, while a tiered JIT does its best, depending if PGO data was downloaded alongside the APK, or needed to be generated from scratch.

Then there are all the other JVMs.

Wow, the performance improvements are insane!

You mean Zig is insane ?

not quite as insane as Raku :-)

Perfectly sane for anyone used to AOT compiled languages.

AOT can be besten by optimizing JIT.

In this case you basically have a server a long running process that does the same code many many times.

If you're careful of memory allocations, the JVM may be able to beat this.

I just skim the article. Is the essential of this article just being able to call fast language x from slow language y, except for trendy languages Z and R?

there is some talk in the Raku community about porting some of the moarvm code to Zig … so this is one of the core devs getting their feet wet as part of the raku advent blog … based on this ‘spike’ they make a good case

Reply on news.ycombinator.com