Added Rust and OCaml as a benchmark tests

[OvermindDL1]

It is not efficient Rust, I'm still learning it, but I was curious how it would do in the test so I added it, see the results on the updated README.md and below (I have a very old desktop, so I'm curious as to the results on your much newer system). I compiled the rust file with rustc -C opt-level=3 rust_port.rs, I have no idea how the go file was compiled so I had to recompile it for my system so I just did it via go compile go_port.go or something like that.

I have to admin, I'm impressed at just how slow java is, probably because it did not get a chance to warm up the JIT first. Any chance at spamming all the ports with about 100k messages to let everything warm up before the actual benchmarking starts because Java should not really be 'that' slow I'd think?

Interestingly though, with my very newbie level Rust, Rust blew away everything else. The only real thing I had to do to the rust code was lock stdout because the port was being killed before everything was flushed out properly on the last run, which was causing the last comparison tests to fail, but just lock()ing it fixed that (prevents the process from dying until stdout is fully flushed).

I'm also surprised at how huge the go binary is. The Rust binary is not too small either (it has options that can reduce the size), but the go binary is just huge. o.O

Would you be curious in some other languages? I can toss in C/C++ and OCaml at least. I was just doing Rust currently as I was curious at how Rust itself acted by being a port (Rust can be a NIF as well, see the Rustler library).

My result on my extremely ancient test desktop:

Settings:
  duration:      1.0 s

## LargeMsgBench
large message is 8010 bytes.
[12:28:02] 1/10: go
[12:28:05] 2/10: java
[12:28:08] 3/10: node
[12:28:10] 4/10: ocaml
[12:28:13] 5/10: rust
## SmallMsgBench
small message is 102 bytes.
[12:28:16] 6/10: go
[12:28:18] 7/10: java
[12:28:21] 8/10: node
[12:28:24] 9/10: ocaml
[12:28:26] 10/10: rust

Finished in 26.72 seconds

## LargeMsgBench
benchm iterations   average time
rust        50000   53.28 µs/op
ocaml       20000   84.54 µs/op
go          20000   94.96 µs/op
node        10000   136.08 µs/op
java        10000   197.80 µs/op
## SmallMsgBench
benchm iterations   average time
rust       100000   20.90 µs/op
ocaml      100000   21.44 µs/op
go         100000   24.25 µs/op
java        50000   32.77 µs/op
node        50000   52.35 µs/op

Hmm, also those are supposed to be µs, guess that did not translate well via copy/pasting, will fix...

EDIT: Updated above stats with OCaml too

[OvermindDL1]

Actually, if I don't mind, I'm adding OCaml as well, I'm especially curious in how OCaml and Rust compare for input/output speeds, hold off while I get it added right quick...

[OvermindDL1]

And updated with OCaml, as well as compilation instructions for the now 3 native code binaries.

[OvermindDL1]

OCaml is 'almost' the fastest, and it has some of the best code it seems as well... Rust compiles more easily on Windows though, but OCaml can still be done on Windows easily enough... Interesting...

[beepboopitschloe]

Good stuff!

I have no idea how the go file was compiled so I had to recompile it for my system so I just did it via go compile go_port.go or something like that.

That's exactly what I did. I don't actually know if Go has an optimization flag.

I have to admin, I'm impressed at just how slow java is, probably because it did not get a chance to warm up the JIT first. Any chance at spamming all the ports with about 100k messages to let everything warm up before the actual benchmarking starts because Java should not really be 'that' slow I'd think?

That's a good point, I bet this is why Java performs so badly in the test. I made an issue for it: #2

Rust blew away everything else.

Makes sense. Rust doesn't have any overhead in the form of a VM or garbage collector– in a toy program like this, it should be the undisputed king. Except maybe C.

I'm also surprised at how huge the go binary is. The Rust binary is not too small either (it has options that can reduce the size), but the go binary is just huge. o.O

The one currently on master is 2.4MB on my system. Maybe the win32 binaries are just bigger? On an unrelated note, I made another issue (#3) to build & run the benchmarks in Travis, since it's free anyway. That way we won't have to check in binaries at all.

[OvermindDL1]

The one currently on master is 2.4MB on my system. Maybe the win32 binaries are just bigger? On an unrelated note, I made another issue (#3) to build & run the benchmarks in Travis, since it's free anyway. That way we won't have to check in binaries at all.

It compiled to the same size on both windows and linux for me, it seems it is just because Go is not able to optimize out its included standard library like most languages do. Rust's is large because it trims based on modules, not individual functions. I have no doubt I could get a C program down to a few kb at most (less if I did a little magic). :-)

OCaml was nicely small however and still very fast, I was impressed at it. :-)

And yeah, Travis would be good but do note that it is not consistent in speed, it depends on what else it is doing so you will not get reliable results. :-)