7 ms·

Sure, Java or C will be much faster at any computational work. And I am no node.js fan-boi. But doing actual asynchronous local-file IO in C is non-trivial, and

Sure, Java or C will be much faster at any computational work. And I am no node.js fan-boi. But doing actual asynchronous local-file IO in C is non-trivial, and if their server is not CPU bound, there doesn't seem to be anything wrong with using node.js. Could you also use libuv from C? Sure.

niggler 13y ago
"Java or C will be much faster at any computational work" That is far from clear. I've been using nodejs for some computational work using https://github.com/substack/gamma.js https://github.com/substack/gamma.js and https://github.com/niggler/bessel https://github.com/niggler/bessel and found that the JS version is faster than the straightforward Java implementation.
- halter73 13y ago
  The OP made too general of a statement because there are certain cases where V8 can preform better than the JVM; however, generally Java does seem to perform better (ignoring startup time). http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=java http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... In the linked benchmarks, V8 only has a decided advantage executing regexes.
  - gritzko 13y ago
    Heh. Last time I checked v8 regexes were really fast, except their string builder was a disaster... it wrapped every piece of string as a js object (gc and everything).
    - Cthulhu_ 13y ago
      Sounds familiar to Java's own string concatenation. In Java you use StringBuilder / Buffer to create larger strings from smaller ones; in Node you'd use Buffers, although I never dived too deep into those.
- loeg 13y ago
  Well, C will be faster anyways... and the JVM is probably faster than v8 more times than not.
kayoone 13y ago
im not an expert but arent UDP Socket connections more like an fire and forget scenario which doesnt create alot of waiting ? Id think that game servers have to compute heavier stuff per tick and have to process all the incoming packets anyway so that waiting for IO isnt really an issue ? It might make sense to have the game world updating and sending/recieving packets in different threads though, so is that were nodejs makes sense?
- loeg 13y ago
  The network stuff is, yeah. But presumably you want your minecraft world to be durable, which means hitting disk. And you don't want your network stuff blocked behind that.
  - kayoone 13y ago
    ok makes sense but i wouldnt write every change to the disk anyway. The server state can well be kept inside memory and only be saved once in a while, but nevertheless doing that in a different thread would make sense.
rorrr 13y ago
"asynchronous local-file IO" is not exactly the bottleneck when implementing a Minecraft server. It's all about computation. C/C++ is the way to go.

niggler 13y ago

"Java or C will be much faster at any computational work" That is far from clear. I've been using nodejs for some computational work using https://github.com/substack/gamma.js https://github.com/substack/gamma.js and https://github.com/niggler/bessel https://github.com/niggler/bessel and found that the JS version is faster than the straightforward Java implementation.

halter73 13y ago
The OP made too general of a statement because there are certain cases where V8 can preform better than the JVM; however, generally Java does seem to perform better (ignoring startup time). http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=java http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... In the linked benchmarks, V8 only has a decided advantage executing regexes.
- gritzko 13y ago
  Heh. Last time I checked v8 regexes were really fast, except their string builder was a disaster... it wrapped every piece of string as a js object (gc and everything).
  - Cthulhu_ 13y ago
    Sounds familiar to Java's own string concatenation. In Java you use StringBuilder / Buffer to create larger strings from smaller ones; in Node you'd use Buffers, although I never dived too deep into those.
loeg 13y ago
Well, C will be faster anyways... and the JVM is probably faster than v8 more times than not.

kayoone 13y ago

im not an expert but arent UDP Socket connections more like an fire and forget scenario which doesnt create alot of waiting ? Id think that game servers have to compute heavier stuff per tick and have to process all the incoming packets anyway so that waiting for IO isnt really an issue ? It might make sense to have the game world updating and sending/recieving packets in different threads though, so is that were nodejs makes sense?

loeg 13y ago
The network stuff is, yeah. But presumably you want your minecraft world to be durable, which means hitting disk. And you don't want your network stuff blocked behind that.
- kayoone 13y ago
  ok makes sense but i wouldnt write every change to the disk anyway. The server state can well be kept inside memory and only be saved once in a while, but nevertheless doing that in a different thread would make sense.

rorrr 13y ago

"asynchronous local-file IO" is not exactly the bottleneck when implementing a Minecraft server. It's all about computation. C/C++ is the way to go.