41–50 of 67 posts
Do you run an optimization pass on the AST between parsing and evaluation?
Earlier quoted context omitted.
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 a…
The jump from change #5 to #6 (inline caches + hidden-class object model) doing the bulk of the work here really tracks with how V8/JSC got fast historically — dynamic dispatch on property access is where naive interpreters die, and everything else is kind of rounding error by comparison. Nice that it's laid out so you can see the contribution of each step in isolation; most perf writeups just show the final number.
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…
A general rule of thumb is that if you can assign an expression a static type, then you can compile it fairly efficiently. Complex dynamic languages obviously actively fight this in numerous ways, and so end up being difficult to optimize. Seems obvious in retrospect.
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…
Or its maintainability, and this is one of the big reasons why. Methods and variables are dynamically generated at runtime which makes it impossible to even grep for them. If you have a large Ruby codebase (say Gitlab or Asciidoctor), it can be almost impossible to trace through code unless you are familiar with the entire codebase.
Their "answer" is that you run the code and use the debugger, but that's clearly ridiculous.
So I would say dynamically defined classes is not only bad for performance; it's just bad in general.
Earlier quoted context omitted.
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…
It also made it really easy to ingest code, and do meta programming.
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
local t = setmetatable({}, {
__index = pcall, __newindex = rawset,
__call = function(t, i) t[i] = 42 end,
})
for i=1,100 do assert(t[i] == true and rawget(t, i) == 42) end
A more nuanced take is that Lua has many happy fast paths, whereas Python has some unfortunate semantic baggage that complicates those. Another key issue is the over-reliance on C modules with bindings that expose way too many internals.
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…
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Earlier quoted context omitted.
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.
The JIT would help everyone else more than removing the GIL, I wish PyPy became the reference implementation during 2.7