Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?

[Atila Neves]

I initially capped the benchmarks at 1k connections because I ran 
out of file handles and didn't feel like modifying my system.

I don't know why you think that "Then Go and Erlang will rock and 
leave D behind" when:

. I don't see any new data to back that up
. Extrapolating the existing MQTT data doesn't suggest that

If the Erlang and Go implementations were slower but seemed to 
scale better then sure, but that's not what the data show at all.

Since there's so substitute to cold hard data, I went back to the 
measurements after setting my hard limit for file handles to 150k 
and using ulimit. I only bothered with Go, D and Erlang. 
Unfortunately, the most I got away with was around 7500 
connections for loadtest. Any more than that and I got failures. 
I suspect this might be a limitation of the benchmark itself, 
which was written in Go. The failures happened for all 3 
implementations. I managed to get up to 10k connections for 
pingtest. It failed a lot though.

The results? There's probably a problem with the Erlang 
implementation but I don't know because I didn't write it. But 
its performance falls off a cliff in both benchmarks as the 
number of connections gets up to or close to 10k.

For loadtest D beats both Go and Erlang and there's no sign of Go 
scaling better (the Erlang one definitely didn't). For pingtest 
at 10k Go seems to start doing better than D, so maybe you have a 
point there.

I suspect you might have missed the point of my original blog 
post. Yes, it shows D beating Erlang and Go, and that's something 
I obviously like. But that wasn't the point I was trying to make. 
My point was that just by writing it in Go doesn't mean magical 
performance benefits because of its CSP, and that vibe.d's fibers 
would do just fine in a direct competition. The data seem to 
support that.

Atila


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."
>
> 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++.