Thanks for pointing this out. To be frank, I would not have expected to see someone highly competent attempting to build a core product with Raku, let alone what looks to be an not entirely trivial compiler. I didn't realize that in addition to being a luajit expert agentzh is also a long-time perl hacker.
Amusingly though he found it necessary to write his own proprietary implementation of (a "dialect" of?) Raku, compiling to luajit byte code.
At first I thought -- oh, cool, a suite of tools leveraging LLVM's XRay! But then after digging for a bit, I can't tell exactly what this does or how it does it, but it is not quite clear whether it leverages LLVM's XRay. Oh well, it's interesting enough. Buuuut -- they trademarked 'OpenResty XRay'? Seems like it's on the hairy edge of 'confusingly similar' -- it's definitely intended for tracing/introspection.
OpenResty filed for their trademark in 2020 and LLVM XRay goes back at least to ~2016/2017. OpenResty itself has been around since ~2011? But I couldn't find anything in google regarding OpenResty XRay before 2016.
Anyways, interesting spelunking. To be clear, I'm not suggesting that there's anything wrong. LLVM's license permits this kind of commercialization -- if it were the case here.
Searching on X-?Ray debugging, I see a lot of products from separate vendors so I think it's valid to consider XRay alone a general industry term that is based on an obvious analogy, so disputes hopefully have to relate to an entire trademarked name.
Lua's a little more opaque than Python or JS, a little more flexible, a little more bug-prone, and a lot simpler. But those aren't the reasons VLC and Wireshark and WoW use Lua instead of Python or JS; they use it because it's enormously less costly to embed. Imagine you decide to switch from Lua to Python for your game. Now you have:
- 3600 kilobytes of bloat instead of 110;
- a huge and bug-prone ABI to deal with to make sure Python doesn't inject memory leaks;
- Python assholes publicly shaming you for using an unfashionable version of Python.
The percentages of improvement that result from finding and tuning the worst paths in a system are often this good unless it has already been done once for the system.. Sun engineers put a lot of thought into algorithms and where bottlenecks should be but still had some improvements like this when first applying DTrace.
16 comments
[ 3.8 ms ] story [ 46.2 ms ] threadI'm about to start work on adding eBPF probes to the open source project I maintain for automated Kubernetes troubleshooting (robusta.dev).
Does anyone have good examples of specific data they collected with eBPF probes that would be good to see whenever problems of a certain type occur?
Amusingly though he found it necessary to write his own proprietary implementation of (a "dialect" of?) Raku, compiling to luajit byte code.
https://blog.openresty.com/en/ylang-intro-part4/#the-ylang-c...
> OpenResty XRay
At first I thought -- oh, cool, a suite of tools leveraging LLVM's XRay! But then after digging for a bit, I can't tell exactly what this does or how it does it, but it is not quite clear whether it leverages LLVM's XRay. Oh well, it's interesting enough. Buuuut -- they trademarked 'OpenResty XRay'? Seems like it's on the hairy edge of 'confusingly similar' -- it's definitely intended for tracing/introspection.
OpenResty filed for their trademark in 2020 and LLVM XRay goes back at least to ~2016/2017. OpenResty itself has been around since ~2011? But I couldn't find anything in google regarding OpenResty XRay before 2016.
Anyways, interesting spelunking. To be clear, I'm not suggesting that there's anything wrong. LLVM's license permits this kind of commercialization -- if it were the case here.
- 3600 kilobytes of bloat instead of 110;
- a huge and bug-prone ABI to deal with to make sure Python doesn't inject memory leaks;
- Python assholes publicly shaming you for using an unfashionable version of Python.
Large Memory Consumption Up to 90% memory footprint reduction, less than 5 minutes to locate memory leaks
Slow Disk I/O Capable of 80% reduction in disk I/O saturation and latency
High Network Latency As much as 90% reduction in response latency and timeout errors
Smells snake oil to me