Hacker News Reader

Comment by skybrian | Hacker News Reader

Based on my experience porting Wren's interpreter to Go, I would expect this to be about 3x slower than a C interpreter (without JIT). But someday I hope to be pleasantly surprised.

I don't believe Go has been optimized for compiling an interpreter, so perhaps there is low-hanging fruit, should the Go team decide that it's a priority.

View on HN

They could fuse go func() that often call each other back to back, if someone was to model interpreter execution with go funcs.

oh, I've been looking for a Go based Wren.

I haven't open sourced it (yet). It's incomplete, has a slightly different syntax than Wren, and I basically ran out of steam and switched to another hobby.

But if someone else wants to work on it, it might be fun.

That is how my side projects often go.

Go was originally intended as a systems level language, suitable for writing extremely efficient servers, dealing directly with raw bytes where needed, therefore enabling writing code at both high and low levels. VMs typically take advantage of the lowest level of code that their language supports to be as efficient as possible. There's no reason Go code can't be as fast as C++ code with enough time for optimizations, and there's no reason a VM written in Go has to be slower than any other low-level program written in Go.

Go's native GC is specifically targeted for Go. To be performant, one would want GC targeted towards the language to be implemented.

Only if you're using Go's native GC as the Lua VM's GC, which isn't the only option.

I have to confess, I've been thinking of implementing Smalltalk in Go, using its native GC as a very unoptimized GC.

For go code to be as fast as C it would necessarily not look like go code as you’d have to avoid anything that would involve non-deterministic allocation or garbage collection. Sure, it’s possible. But it doesn’t make sense.

I believe there are compiler improvements that can be made without changing the Go language, like computed goto's for large switch statements. That will help.

However, to really do as well as C, Go would need a more space-efficient union type. A Go interface is always two pointers due to how the garbage collector works, and that's not going to be as efficient as using something like NaN-encoding for a union between a pointer and a float64.

Reply on news.ycombinator.com