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

Sean Kelly sean at invisibleduck.org
Fri Mar 7 08:53:38 PST 2014


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.


More information about the Digitalmars-d mailing list