So my buddy Jeff at work is a massive Go fan and goes on about it all the time. He even got me to try it once but I mostly hated it. To each his own. However, he laid down the gauntlet last Thursday saying his MQTT broker implementation in Go couldn't be beaten in performance. For those not in the know, MQTT is a publish/subscribe network protocol. And Go is all about parallel network programming, so what could beat it, right?

Always up for a challenge, I went ahead and implemented enough of an MQTT broker to handle the functionality required by the benchmark program he wrote to test his own code. In D of course, with the network code coming from vibe.d.

The result? 11% - 34% faster than the Go implementation depending on the workload (34%, 30%, 11%, 30%). The low end of that was with a higher number of connected clients, and that could always be me not using vibe.d well (I'd never used it before last Friday).

I also measured Mosquitto, an open-source C implementation. It mostly beat my D one, and went from 1% slower to 17% faster than the D/vibe.d combo depending on workload, with that 17% being an outlier (-1%, 5%, 17%, 3%, 3%).

I actually have error bars for all those values but thought it'd be too much to post them here. D FTW!

Atila

P.S. Not all was roses. Although getting to write D again was awesome (and I beat him), I ran into multiple problems:

- Trying to use dub to compile the project in release or profile mode flat out didn't work. I had to take the verbose output of dub, use it to compile vibe.d in debug mode into an object file and compile my own code separately and link it in. I believe this was a dmd regression. Speaking of which, why does dub recompile the world instead of tracking dependencies (I tried the rdmd option once but that didn't work, I can't remember why)?

- I ran into a dmd bug when I tried to use TaskPool.map with a delegate so I had to give up trying that possible optimisation.

- I ran into another dmd bug (it crashed) at one point if -inline was used.

- dub build with LDC and GDC failed miserably. I think it was because of vibe.d.

Yeah, unfortunately there were lot of 2.063.2 bugs that vibe.d triggered during transition to 2.064, it was quite a mess for some time. I expect out-of-the-box experience to be much better at point of 2.064 release.

On Tuesday, 5 November 2013 at 13:05:21 UTC, Atila Neves wrote:
> So my buddy Jeff at work is a massive Go fan and goes on about it all the time. He even got me to try it once but I mostly hated it. To each his own. However, he laid down the gauntlet last Thursday saying his MQTT broker implementation in Go couldn't be beaten in performance. For those not in the know, MQTT is a publish/subscribe network protocol. And Go is all about parallel network programming, so what could beat it, right?
>
> Always up for a challenge, I went ahead and implemented enough of an MQTT broker to handle the functionality required by the benchmark program he wrote to test his own code. In D of course, with the network code coming from vibe.d.
>
> The result? 11% - 34% faster than the Go implementation depending on the workload (34%, 30%, 11%, 30%). The low end of that was with a higher number of connected clients, and that could always be me not using vibe.d well (I'd never used it before last Friday).
>
> I also measured Mosquitto, an open-source C implementation. It mostly beat my D one, and went from 1% slower to 17% faster than the D/vibe.d combo depending on workload, with that 17% being an outlier (-1%, 5%, 17%, 3%, 3%).
>
> I actually have error bars for all those values but thought it'd be too much to post them here. D FTW!
>
> Atila
>
> P.S. Not all was roses. Although getting to write D again was awesome (and I beat him), I ran into multiple problems:
>
> - Trying to use dub to compile the project in release or profile mode flat out didn't work. I had to take the verbose output of dub, use it to compile vibe.d in debug mode into an object file and compile my own code separately and link it in. I believe this was a dmd regression. Speaking of which, why does dub recompile the world instead of tracking dependencies (I tried the rdmd option once but that didn't work, I can't remember why)?
>
> - I ran into a dmd bug when I tried to use TaskPool.map with a delegate so I had to give up trying that possible optimisation.
>
> - I ran into another dmd bug (it crashed) at one point if -inline was used.
>
> - dub build with LDC and GDC failed miserably. I think it was because of vibe.d.

this is with dmd? I wonder how those numbers would look if you could get ldc/gdc up and running.

On Tuesday, 5 November 2013 at 13:11:26 UTC, Dicebot wrote:
> Yeah, unfortunately there were lot of 2.063.2 bugs that vibe.d triggered during transition to 2.064, it was quite a mess for some time. I expect out-of-the-box experience to be much better at point of 2.064 release.

P.S. Also there are speculations about performance regressions,
once those are figured out it may yield even better results :)

> this is with dmd? I wonder how those numbers would look if you could get ldc/gdc up and running.

Yep, dmd. I mentioned the problems getting the whole thing (including vibe.d) to compile with ldc and gdc because I was trying those two exactly to try and eke more performance out. Neither worked with dub and I think running them manually got me into problems too.

On Tuesday, 5 November 2013 at 13:12:33 UTC, Dicebot wrote:
> P.S. Also there are speculations about performance regressions,
> once those are figured out it may yield even better results :)

So I read while looking around for info on how to use vibe.d properly. I might revisit and remeasure once a see a post about it and rub it in my buddy's face again. :)

05.11.2013 22:17, Atila Neves пишет:
>> this is with dmd? I wonder how those numbers would look if you could
>> get ldc/gdc up and running.
>
> Yep, dmd. I mentioned the problems getting the whole thing (including
> vibe.d) to compile with ldc and gdc because I was trying those two
> exactly to try and eke more performance out. Neither worked with dub and
> I think running them manually got me into problems too.
>
Did you try --compiler=ldmd2 to use ldc? May be it helps.

So, is he writing D code now :D. Or did he complain about the syntax, all the types being on the left?

> Did you try --compiler=ldmd2 to use ldc? May be it helps.

I tried every combination I could think of, including that one.

On Tuesday, 5 November 2013 at 13:05:21 UTC, Atila Neves wrote:
> - Trying to use dub to compile the project in release or profile mode flat out didn't work. I had to take the verbose output of dub, use it to compile vibe.d in debug mode into an object file and compile my own code separately and link it in. I believe this was a dmd regression. Speaking of which, why does dub recompile the world instead of tracking dependencies (I tried the rdmd option once but that didn't work, I can't remember why)?
>
> - I ran into a dmd bug when I tried to use TaskPool.map with a delegate so I had to give up trying that possible optimisation.
>
> - I ran into another dmd bug (it crashed) at one point if -inline was used.
>
> - dub build with LDC and GDC failed miserably. I think it was because of vibe.d.

Are all of these issues noted on bugzilla? If not are you able to add them please? They sound serious and don't want to be forgotten about.