Live data from Hacker News

How to make a fast dynamic language interpreter

zef-lang.dev

31–40 of 67 posts

Re: How to make a fast dynamic language interpreter

#32
post #19

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

Yes, language design is a hugely important determinant of interpreter or JIT speed. There are many highly optimised VMs for dynamic languages but LuaJIT is king because Lua is such a small and suitable language, and although it does have a couple difficult to optimise features, they are few enough that you can expend the effort. It's nothing like Python. It's not much of an exaggeration to say Python is designed to m…

Python is worse, but not by all that much. After all, PyPy has been several times faster for many years.

Re: How to make a fast dynamic language interpreter

#33

Earlier quoted context omitted.

Nop, Python is not full object. Not even Ruby is fully object, try `if.class` for example. Self, Smalltalk, Lisp, and Io are fully object in that sense. But none as far as I know can handle something like `(.class`.

Aren't you mixing up syntax and the concepts it expresses? Why would (.class have to be a thing? Is space dot class a thing? I don't think this makes sense and it doesn't inform about languages "being fully object". Such syntax is merely for producing an AST and that alone doesn't mean "object" or "not object". It could just as well be all kinds of different things, or functions, or stack pushes and pops or something…

I think the idea is that SmallTalk replaced conditional syntax with methods on booleans. You could call `ifTrue:` on a boolean, passing it a code block; a true boolean would execute the block, and a false boolean would not. (There was also an `ifFalse:` method.)

This feels more like a party trick than anything. But it does represent a deep commitment to founding the whole language on object orientation, even when it seems silly to folks like me.

Re: How to make a fast dynamic language interpreter

#34

Earlier quoted context omitted.

Nop, Python is not full object. Not even Ruby is fully object, try `if.class` for example. Self, Smalltalk, Lisp, and Io are fully object in that sense. But none as far as I know can handle something like `(.class`.

Aren't you mixing up syntax and the concepts it expresses? Why would (.class have to be a thing? Is space dot class a thing? I don't think this makes sense and it doesn't inform about languages "being fully object". Such syntax is merely for producing an AST and that alone doesn't mean "object" or "not object". It could just as well be all kinds of different things, or functions, or stack pushes and pops or something…

>Why would (.class have to be a thing?

It doesn’t have to in the absolute. It just that if some speech seel that a programing language is completely object oriented, it’s fun to check to which point it actually is.

There are many valid reasons why one would not to do that, of course. But if it’s marketed as if implicitly one could expect it should, it seems fair to debunk the myth that it’s actually a fully object language.

>Is space dot class a thing?

Could be, though generally spaces are not considered like terms – but Whitespace shows it’s just about what is conventionally retained.

So, supposing that ` .class` and `.class` express the same value, the most obvious convention that would come to my mind then would be to consider that it’s applied to the implicit narrower "context object" in the current lexical scope.

Raku evaluate `.WHAT` and `(.WHAT)` both as `(Any)` for giving a concrete example of related choice of convention.

>Such syntax is merely for producing an AST and that alone doesn't mean "object" or "not object".

Precisely, if the language is not providing complete reflection facility on every meaningful terms, including syncategorematic ones, then it’s not fully object. Once again, being almost fully object is fine, but it’s not being fully object.

https://en.wikipedia.org/wiki/Syncategorematic_term

Re: How to make a fast dynamic language interpreter

#35
post #19

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

That’s basically what is done all the time in languages where monkey patching is accepted as idiomatic, notably Ruby. Ruby is not known for its speed-first mindset though. On the other side, having a type holding a closed set of applicable functions is somehow questioning. There are languages out there that allows to define arbitrary functions and then use them as a methods with dot notation on any variable matching…

It is getting better, now that they finally got the Smalltalk lessons from 1984.

"Efficient implementation of the smalltalk-80 system"

https://dl.acm.org/doi/10.1145/800017.800542

Re: How to make a fast dynamic language interpreter

#36
post #19

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

Yes, language design is a hugely important determinant of interpreter or JIT speed. There are many highly optimised VMs for dynamic languages but LuaJIT is king because Lua is such a small and suitable language, and although it does have a couple difficult to optimise features, they are few enough that you can expend the effort. It's nothing like Python. It's not much of an exaggeration to say Python is designed to m…

CPython current state is more a reflection of resources spent, than what is possible.

See experience with Smalltalk and Self, where everything is dynamic dispatch, everything is an object, in a live image that can be monkey patched at any given second.

PyPy and GraalPy, and the oldie IronPython, are much better experiences than where CPython currently stands on.

Re: How to make a fast dynamic language interpreter

#37
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…

Are you using malloc + GC in preference to smart pointers, and if so why? I thought Fil-C was just C not C++?

It doesn't seem like that is necessarily a performance win, especially since you could always use a smart pointer's raw pointer (preferably const) in a performance critical path.

Re: How to make a fast dynamic language interpreter

#38
post #15

Earlier quoted context omitted.

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. Anot…

I think you’re describing deficiencies in the Python impl not anything about the language

Re: How to make a fast dynamic language interpreter

#39

Do you think this exercise has taught you anything that could make fil c itself better?

Yeah I really need to have a better fix for how I handle unions.

And the fact that having outline calls to methods of value objects is so expensive

Post reply on HN