This is slightly offtopic, but MQTT says it can provide "exactly once" delivery. I thought that wasn't possible?
It is possible if you are prepared to wait for an unbounded amount of time.
Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
41–50 of 50 posts
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#42"Since the Erlang unit tests are in the same files as the implementation, it’s hard to know exactly how many lines long it is. It gets worse since it implements most of MQTT, the D implementation essentially only implements what’s necessary to run the benchmarks." Benchmarking the entire spec versus only the minimal set is almost certainly part of the problem here. If you want to benchmark implementations against eac…
No, not really. I understand why you'd think that but knowing the MQTT spec and the benchmark, it shouldn't make any difference at all.
Are you sure about that one? I am thinking about the situation where presence of alternative code paths that never actually get executed can lead to fairly large differences in timings, particularly for tight loops. (At least in computational code; I'd expect it to be much less common for protocol handling benchmarks like these...)
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#43Earlier quoted context omitted.
No, not really. I understand why you'd think that but knowing the MQTT spec and the benchmark, it shouldn't make any difference at all.
Are you sure about that one? I am thinking about the situation where presence of alternative code paths that never actually get executed can lead to fairly large differences in timings, particularly for tight loops. (At least in computational code; I'd expect it to be much less common for protocol handling benchmarks like these...)
Pretty sure yeah, I looked at a lot of profiling logs.
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#44I'm the author but not the OP.
Out of morbid curiousity, how many lines of code did the C implementation clock in at?
~20kSLOC IIRC. It's not a fair comparison since it does more, but let's face it, if these implementations did the exact same thing I doubt they'd pass the 5kSLOC mark.
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#45did you use GOMAXPROCS=$YOUR_CORES ? or just the standard in 1.2? Actually golang is really good in multithreading. Next you also have a Java example, did you warm it up or not? Actually thats why I hate benchmarks, since mostly they are screwed since most people who are writing benchmarks actually knowing just a little of each language. (actually they just want to show that "their" language is good)
Back then I tried GOMAXPROCS from 1 to 8 and it didn't make much of a difference. Later on with a different version of Go (I don't remember which), increasing GOMAXPROCS to 2 made a difference, but any more than that was pretty much the same. In any case (and again, the last time I tried), the Go implementation with GOMAXPROCS=2 was the slowest even though it was using twice as many threads as the other ones!
As for showing "their"/"my" language: there were implementations from 4 different sources, and I didn't write the benchmarks; the guy who wrote the Go implementation did (and that's why the benchmark app is in Go).
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#46> What about readability and ease of writing? I can’t read Erlang so I can’t comment on that. The Erlang code looks very nice. If you read this, great work Patrick! https://bitbucket.org/pvalsecc/ Nice use of gen_fsm + binary matching. Here is an example of the client code that takes only 200 lines: https://bitbucket.org/pvalsecc/erlangmqtt/src/f37505188c1f1c...
Writing code in Erlang is such a pleasure. I really hope more people get exposed to it. The pattern matching alone is just so nice (and concise!).
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#47Earlier quoted context omitted.
How about Java, then? It's a little less esoteric than most of those languages.
Funny you should ask: https://atilanevesoncode.wordpress.com/2014/01/08/adding-jav...
So Java is the pingtest winner, and I'm sure that with just a little more work it can be the loadtest winner as well.
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#48Earlier quoted context omitted.
Funny you should ask: https://atilanevesoncode.wordpress.com/2014/01/08/adding-jav...
So Java is the pingtest winner, and I'm sure that with just a little more work it can be the loadtest winner as well.
I doubt it, Patrick properly profiled and optimised it. Later on I got the D version to within 3% of Java's performance in pingtest.
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#49Earlier quoted context omitted.
So Java is the pingtest winner, and I'm sure that with just a little more work it can be the loadtest winner as well.
I doubt it, Patrick properly profiled and optimised it. Later on I got the D version to within 3% of Java's performance in pingtest.
It's clearly optimized for latency over throughput. For one, it is single threaded -- unlike the Erlang, Go and, I believe D (vibe.d) implementations. Also, I don't know exactly how the benchmark was performed, but Java takes time to warm up (otherwise you're testing a completely different implementation of Java, which is only used at startup time).
I've found that for long-running server-side apps, Java is very hard to beat in terms of performance, especially relative to the effort spent. I also think it's a nicer language than Go (I also prefer it over C++ and D).
Re: Go, D, Erlang and C in real life: MQTT broker implementation shootout (2013)
#50Earlier quoted context omitted.
Out of morbid curiousity, how many lines of code did the C implementation clock in at?
~20kSLOC IIRC. It's not a fair comparison since it does more, but let's face it, if these implementations did the exact same thing I doubt they'd pass the 5kSLOC mark.
I get about 1.5-2x for c vs c++. Genuinely surprised that erlang took so many lines of code.