On Friday, 7 March 2014 at 08:45:22 UTC, Bienlein wrote:
On Friday, 7 March 2014 at 08:23:09 UTC, Atila Neves wrote:
I'm suspecting that Vibe's performance is heavily based upon
the systems state i.e. hdd. Not so much on the code
generation.
I don't know where we can get more performance out of it. But
something doesn't quite feel right.
Robert Pike, the Go lead developer, some days ago published
this tweet:
"Just looked at a Google-internal Go server with 139K
goroutines serving over 68K active network connections.
Concurrency wins."
68K connections is nothing. I'll start getting interested when
his benchmarks are 200K+. Event-based systems in C can handle
millions of concurrent connections if implemented properly. I'd
like to believe vibe.d can approach this as well.
In that way your MQTT benchmarks falls short with a maximum of
1k connections. You need to repeat it with 50k and 100k
connections. Then Go and Erlang will rock and leave D behind.
If you want to be fair with Erlang you need to make a benchmark
run with 1.000k connections and more, see
https://www.erlang-solutions.com/about/news/erlang-powered-whatsapp-exceeds-200-million-monthly-users
Does Erlang really scale that well for network IO? I love their
actor model, but their network programming model kind of stinks.
I don't like Go's simplistic nature, either, but Go is not
about the language. It is about making concurrency much simpler
and allowing for many many threads. IMHO this is what gives Go
the attention. Except for Erlang no other system/language than
Go can get something similar accomplished (except Rust maybe
when it is finished, but it is not clear whether it will have
good built times like Go or D).
If you want to give D a boost, put Go-style CSP and green
threads into it as well. Then D will start to fly. Otherwise it
will have to continue competing against C++ as its sole
application area where it will always remain a niche player,
because of the market dominance of C++.
vibe.d already works this way. And there's a pull request in
place to make std.concurrency support green threads. I think
we're really pretty close. I do need to set aside some time to
start on IPC though.
