Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to make a fast dynamic language interpreter

zef-lang.dev

Post reply on HN
Print view View original

11–20 of 67 posts

Re: How to make a fast dynamic language interpreter

#11

Post by raincole »

pizlonator wrote: post #8
tiffanyh wrote: post #7

I see Lua was included, wish LuaJIT was as well.

I bet LuaJIT crushes Zef! Or rather, I would hope that it does, given how much more engineering went into it There are many runtimes that I could have included but didn’t. Also, it’s quite impressive how much faster PUC Lua is than QuickJS and Python

Because QuickJS is really slow. Don't be fooled by the name. It's almost an order of magnitude slower than node/v8.

(I suppose the quick in QuickJS means "quick for a pure interpreter without JIT compilation or something...)

Re: How to make a fast dynamic language interpreter

#12

Post by vlovich123 »

pizlonator wrote: post #6
boulos wrote: post #5

How's your experience with Fil-C been? Is it materially useful to you in practice?

I’m biased since I’m the Fil. It was materially useful in this project. - Caught multiple memory safety issues in a nice deterministic way, so designing the object model was easier than it would have been otherwise. - C++ with accurate GC is a really great programming model. I feel like it speeds me up by 1.5x relative to normal C++, and maybe like 1.2x relative to other GC’d languages (because C++’s APIs are so rich…

I’m curious. Given the overheads of Fil-C++, does it actually make sense to use it for greenfield projects? I like that Fil-C fills a gap in securing old legacy codebases, I’m just not sure I understand it for greenfield projects like this other than you happen to know C++ really well.

Re: How to make a fast dynamic language interpreter

#13

Post by pizlonator »

raincole wrote: post #11
pizlonator wrote: post #8

Earlier quoted context omitted.

I bet LuaJIT crushes Zef! Or rather, I would hope that it does, given how much more engineering went into it There are many runtimes that I could have included but didn’t. Also, it’s quite impressive how much faster PUC Lua is than QuickJS and Python

Because QuickJS is really slow. Don't be fooled by the name. It's almost an order of magnitude slower than node/v8. (I suppose the quick in QuickJS means "quick for a pure interpreter without JIT compilation or something...)

based on this data, it’s probably slower than JSC’s or V8’s interpreter

So like that’s wild

Re: How to make a fast dynamic language interpreter

#14

Post by pizlonator »

vlovich123 wrote: post #12
pizlonator wrote: post #6

Earlier quoted context omitted.

I’m biased since I’m the Fil. It was materially useful in this project. - Caught multiple memory safety issues in a nice deterministic way, so designing the object model was easier than it would have been otherwise. - C++ with accurate GC is a really great programming model. I feel like it speeds me up by 1.5x relative to normal C++, and maybe like 1.2x relative to other GC’d languages (because C++’s APIs are so rich…

I’m curious. Given the overheads of Fil-C++, does it actually make sense to use it for greenfield projects? I like that Fil-C fills a gap in securing old legacy codebases, I’m just not sure I understand it for greenfield projects like this other than you happen to know C++ really well.

It made sense because I was able to move very quickly, and once perf became a problem I could move to Yolo-C++ without a full rewrite.

> happen to know C++ really well

That’s my bias yeah. But C++ is good for more than just perf. If you need access to low level APIs, or libraries that happen to be exposed as C/C++ API, or you need good support for dynamic linking and separate compilation - then C++ (or C) are a great choice

Re: How to make a fast dynamic language interpreter

#15

Post by zephen »

pizlonator wrote: post #10
zephen wrote: post #9

Earlier quoted context omitted.

> it’s quite impressive how much faster PUC Lua is than QuickJS and Python Python's execution time is mostly spent looking up stuff. I don't think lua is quite as dynamic.

Lua is way more dynamic

I suppose it depends on where you are looking for dynamicity. In some ways, lua is much more laissez faire of course.

But in Python, everything is an object, which is why, as I said, it spends much of its time looking things up. And things like bindings for closures are late, so that's more lookups as well.

In lua, many things aren't objects, and, for example, you can add two numbers without looking anything up. Another issue, of course, when you do that, is that you could conceivably overflow an integer, but that can't happen in Python either.

The Python interpreter has some fast paths for specific object types, but it is really limited in the optimizations it can do, because there simply aren't any unboxed types.

Re: How to make a fast dynamic language interpreter

#16

Post by vlovich123 »

pizlonator wrote: post #14
vlovich123 wrote: post #12

Earlier quoted context omitted.

I’m curious. Given the overheads of Fil-C++, does it actually make sense to use it for greenfield projects? I like that Fil-C fills a gap in securing old legacy codebases, I’m just not sure I understand it for greenfield projects like this other than you happen to know C++ really well.

It made sense because I was able to move very quickly, and once perf became a problem I could move to Yolo-C++ without a full rewrite. > happen to know C++ really well That’s my bias yeah. But C++ is good for more than just perf. If you need access to low level APIs, or libraries that happen to be exposed as C/C++ API, or you need good support for dynamic linking and separate compilation - then C++ (or C) are a great…

Hmmm… I did about 20+ years of C++ coding and since I’ve been doing Rust I haven’t seen any of these issues. It has trivial integrations with c/c++ libraries (often with wrappers already written), often better native libraries to substitute those c++ deps wholesale, and separate compilation out of the box. It has dynamic linking if you really need it via the C ABI or even rlib although I’ll grants the latter is not as mature.

The syntax and ownership rules can take some getting used to but after doing it I start to wonder how I ever enjoyed the masochism of the rule of 5 magic incantation that no one else ever followed and writing the class definition twice. + the language gaining complexity constantly without ever paying back tech debt or solving real problems.

Re: How to make a fast dynamic language interpreter

#18

Post by electroly »

injidup wrote: post #17

What is this YOLO-c++ compiler that is referenced in the article? Google searches turn up nothing and chatgpt seems not to know it either.

The author of Fil-C, who is also the author of this language, uses "Yolo-C/C++" to mean regular C/C++ without Fil-C.

Re: How to make a fast dynamic language interpreter

#19

Post by pansa2 »

In a similar vein, see this page about the performance of the interpreter for the dynamic language Wren: https://wren.io/performance.html

Unlike the Zef article, which describes implementation techniques, the Wren page also shows ways in which language design can contribute to performance.

In particular, Wren gives up dynamic object shapes, which enables copy-down inheritance and substantially simplifies (and hence accelerates) method lookup. Personally I think that’s a good trade-off - how often have you really needed to add a method to a class after construction?

Post reply on HN