crystalruby VS llvm-project

Recently, I came across an article titled “Ruby might be faster than you think” In this article, John Hawthorn revisits the code snippet from the CrystalRuby README and optimizes it to show that Ruby is just as performant, if not more, than the alternative presented by CrystalRuby.

It is common to call C functions from Ruby or Crystal. It's interesting to know that there are alternatives to bridge these two languages that share the same goal of writing beautiful programs, using a similar syntax. The mentioned crystalruby gem allows interfacing Ruby programs with Crystal, and the shard anyolite allows calling Ruby programs from Crystal.

Another ruby/crystal project coming hot on the heels of crystalruby[1].

I can see that both have different use cases but it's interesting to see the two approaches.

1. https://github.com/wouterken/crystalruby

https://llvm.org/

I tried PGO and BOLT but didn't get any improvement.

But I'm still sure that there are several UB's in my code :)

[1] https://tunglevo.com/note/an-optimization-thats-impossible-i...

[2] https://github.com/gcc-mirror/gcc/blob/d09131eea083e80ccad60...

[3] https://github.com/llvm/llvm-project/blob/4468d58080d0502a05...

Which is these is "faster" depends greatly on whether you have the very rare memcpy-only workload, or if your program actually does something useful. Many people believe, often with good evidence, that the most important thing is for memcpy to occupy as few instruction cache lines as is practical, instead of being something that branches all over kilobytes of machine code. For comparison, see the x86 implementations in LLVM libc.

https://github.com/llvm/llvm-project/blob/main/libc/src/stri...

Since preserve_none is Clang-only and only available on recent compilers, it would introduce an ABI hazard between the core library and generated code. We don't want to cause crashes if you compile protobuf with one compiler and generated code with another.

Also until quite recently preserve_none was incompatible with the sanitizers, but I believe this may have been fixed by: https://github.com/llvm/llvm-project/pull/81048

I am being silenced for speaking the truth! https://github.com/llvm/llvm-project/commit/12728e144994efe8...

LLVM can bisect down to individual transformation steps within a pass (for passes that implement the interface): https://llvm.org/docs/OptBisect.html

And there is a script bisecting functions when given assembly produced by working baseline and “bad” compiler to compare: https://github.com/llvm/llvm-project/blob/main/llvm/utils/ab...

Similarly, LLVM revolutionized the world of programming languages and compilers. Since its creation, we've seen many new languages being created of increased complexity.