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

The Neko Virtual Machine

nekovm.org

Post reply on HN
Print view View original

21–29 of 29 posts

Re: The Neko Virtual Machine

#21

Post by mratsim »

johnday wrote: post #16
Gama11 wrote: post #12

Earlier quoted context omitted.

Neko isn't that fast, since the bytecode is dynamically typed. That combined with the fact that it's not really actively developed anymore, you'd probably be better off checking out its successor called "HashLink" instead (see comment thread above). Btw, a JVM target (generating JVM bytecode directly) was recently merged into the Haxe compiler. Previously there was already a target that generates Java source code, bu…

Why would types speed up the code?

Without types everything is a pointer (boxing), and when you actually need the value you need to resolve (dereference).

This is almost always cache miss.

If the collection is polymorphic it's even worse because you dereference to access the dispatch table which then redirects you to the real value.

Furthermore, each variable will need heap allocation and tracking, stressing the garbage collector and the underlying allocator (unless you preallocate big chunks like Java).

Re: The Neko Virtual Machine

#22

Post by codetrotter »

Gama11 wrote: post #14
codetrotter wrote: post #4

Earlier quoted context omitted.

I’ve only ever heard of Neko in the context of Haxe, a scripting language created by the same people that make Neko. Never did look really closely into either of them though. I found the following three resources helpful in getting a bit of an idea about what Neko really is beyond being a target VM of Haxe. Neko C FFI - https://nekovm.org/doc/ffi/ A comparison of Neko and Lua - https://nekovm.org/doc/lua/ Language In…

Haxe is hardly a "scripting language", at least according to my definition of that term. It's a strictly typed high-level language with a proper optimizing compiler. Depending on the target it produces either bytecode (Neko, HashLink, Flash and recently JVM) or source code (C++, JavaScript, Python, Lua, C#, Java, PHP). See https://haxe.org/documentation/introduction/compiler-targets... for a full list of targets.

Yeah sorry, like I said, never did look closely into either of them before. Knew that Haxe had multiple targets but aside from Neko and Flash and JavaScript I didn’t remember the others. Should’ve checked the Haxe website also.

Re: The Neko Virtual Machine

#23

Post by Gama11 »

codetrotter wrote: post #22
Gama11 wrote: post #14

Earlier quoted context omitted.

Haxe is hardly a "scripting language", at least according to my definition of that term. It's a strictly typed high-level language with a proper optimizing compiler. Depending on the target it produces either bytecode (Neko, HashLink, Flash and recently JVM) or source code (C++, JavaScript, Python, Lua, C#, Java, PHP). See https://haxe.org/documentation/introduction/compiler-targets... for a full list of targets.

Yeah sorry, like I said, never did look closely into either of them before. Knew that Haxe had multiple targets but aside from Neko and Flash and JavaScript I didn’t remember the others. Should’ve checked the Haxe website also.

No worries, just wanted to clear up the misconception. :)

Re: The Neko Virtual Machine

#24

Post by azhenley »

Gama11 wrote: post #11
k_ wrote: post #7

Neko has been around for 10+ years and is being replaced progressively by HL (HashLink, [1]), from the same creator. I mainly know Neko as one of many transpiling targets for Haxe programming language [2] (10+ targets including JS, PHP, C++), and have used it many years ago for all my backend stuff. [1]: https://hashlink.haxe.org/ [2]: https://haxe.org/

I'm also surprised that Neko has been posted here rather than HashLink, which is much more impressive: - unlike Neko, the bytecode is strictly typed, allowing it to be much faster - there are two different ways to use it: - HL/JIT, compiling to bytecode and using the VM - HL/C, compiling to raw C code to gain an extra bit of performance and allow it to run on devices that don't allow JIT (mobile / consoles) - the suc…

Sorry, I found Neko for the first time and didn't see any mention of HL on the Neko website. HashLink does look very impressive so thanks for the details. I'm looking into it now.

Re: The Neko Virtual Machine

#26

Post by Gama11 »

azhenley wrote: post #24
Gama11 wrote: post #11

Earlier quoted context omitted.

I'm also surprised that Neko has been posted here rather than HashLink, which is much more impressive: - unlike Neko, the bytecode is strictly typed, allowing it to be much faster - there are two different ways to use it: - HL/JIT, compiling to bytecode and using the VM - HL/C, compiling to raw C code to gain an extra bit of performance and allow it to run on devices that don't allow JIT (mobile / consoles) - the suc…

Sorry, I found Neko for the first time and didn't see any mention of HL on the Neko website. HashLink does look very impressive so thanks for the details. I'm looking into it now.

That is a good point, a mention on the Neko website would make sense.

Re: The Neko Virtual Machine

#27

Post by logicprog »

Gama11 wrote: post #12
logicprog wrote: post #2

[edited after reading FAQ] Minor criticism: It would be helpful to see some code so you can tell what you're going to have to be generating to use the VM. Especially since it's not bytecode or abstract machine instructions so it's hard to know what to expect. Otherwise, this is an incredibly cool project, which I'm definitely going to check out more in the future. Out of curiosity, how does its performance and memory…

Neko isn't that fast, since the bytecode is dynamically typed. That combined with the fact that it's not really actively developed anymore, you'd probably be better off checking out its successor called "HashLink" instead (see comment thread above). Btw, a JVM target (generating JVM bytecode directly) was recently merged into the Haxe compiler. Previously there was already a target that generates Java source code, bu…

Yeah I was concerned reading that, about boxing everything due to dynamic types.

Re: The Neko Virtual Machine

#28

Post by naasking »

cygx wrote: post #18
johnday wrote: post #16

Earlier quoted context omitted.

Why would types speed up the code?

Static types avoid the cost of runtime type checks and dynamic dispatch.

Also they permit more inlining opportunities, allow eliminating more dead code, and more. Types almost always improve program performance.

Re: The Neko Virtual Machine

#29

Post by pier25 »

Gama11 wrote: post #11
k_ wrote: post #7

Neko has been around for 10+ years and is being replaced progressively by HL (HashLink, [1]), from the same creator. I mainly know Neko as one of many transpiling targets for Haxe programming language [2] (10+ targets including JS, PHP, C++), and have used it many years ago for all my backend stuff. [1]: https://hashlink.haxe.org/ [2]: https://haxe.org/

I'm also surprised that Neko has been posted here rather than HashLink, which is much more impressive: - unlike Neko, the bytecode is strictly typed, allowing it to be much faster - there are two different ways to use it: - HL/JIT, compiling to bytecode and using the VM - HL/C, compiling to raw C code to gain an extra bit of performance and allow it to run on devices that don't allow JIT (mobile / consoles) - the suc…

So how much faster is HashLink than Neko?

Are there any benchmarks somewhere?

Edit: It's significantly faster then Neko and about as fast as HXCPP target.

https://twitter.com/jdbaudi/status/789231337467174912

Post reply on HN