On 2014-03-07 08:45:21 +0000, Bienlein said:
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."
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
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++.
Have you used vibe.d? It already supports in-process fibers, and much
of the work that Sönke is doing is being ported to phobos. I have no
trouble believing that MQTT implemented on top of vibed could compete
with Go or Erlang. If it can't do it right now, it's not because of a
fundamental design problem, but because of bugs.
-S.
