> Interesting. Care to convert this post (only a little adjustment needed) to a blog and publish with source code? Would make a great article. Ask your friends to contribute with descriptions of their implementations, too.

If I convert this post into a blog it's going to take more than a little adjustment for me to be happy with it. I guess having had to write a PhD thesis has now scarred me for life.

I'll see if I get around to it in the next few days and I'll ask the guys about their implementations as well. I guess I should go set up wordpress.

Atila

> Ah this is rather sad. It makes tests results somewhat unstable

They're not ideal, but they're not unstable with respect to time - I did and redid all those measurements a few times, the error bars are the standard deviation taken to be the systematic error.

I got challenged so I decided to beat his implementation, even this level of detail got called going overboard ;)

Atila

On Wednesday, 4 December 2013 at 12:49:13 UTC, Atila Neves wrote:
> P.S. vibe.d is awesome, although I wish it'd compile with ldc or gdc

What are the issues that are blocking you from using it with LDC? The 2.064 frontend not being officially yet? I couldn't find any mention of vibe.d in the open bugs on our GitHub tracker (besides #468, which concerns the unstable Win64 port). So even though I agree that vibe.d would be a very interesting target for LDC, there is little chance of the situation improving.

David

On 2013-12-04 12:59 PM, Atila Neves wrote:
>> Interesting. Care to convert this post (only a little adjustment
>> needed) to a blog and publish with source code? Would make a great
>> article. Ask your friends to contribute with descriptions of their
>> implementations, too.
>
> If I convert this post into a blog it's going to take more than a little
> adjustment for me to be happy with it. I guess having had to write a PhD
> thesis has now scarred me for life.
>
> I'll see if I get around to it in the next few days and I'll ask the
> guys about their implementations as well. I guess I should go set up
> wordpress.
>
> Atila

It would be interesting to have a GitHub repo with the scripts for each language, vibe.d also has a multithreaded version that is off by default (fibers created from new tcp connections are distributed in a thread pool where communication is done through Isolated!()). So I'd love to be able to fork it and rerun this with some adjustments.

>>> What about the relative elegance/maintainability/ease of comprehension
>>> of the different solutions?  Playing devil's advocate for a moment, I
>>> can well understand if a preference for one language over another was
>>> decided on the basis of its performance being good _enough_ and the
>>> code being really easy to work with, rather than simply the best
>>> performer.
>>
>> I can't read Erlang (yet) so I don't know about that one. The C code
>> is... well C code so not great. I have a profound dislike for Go but I'd
>> say the Go and D implementations are just as readable. Then again, I
>> wrote the D code so if I didn't think that was readable... :P
>
> How do they compare in lines of code?
>

That's hard to measure. Not only because of the standard fare about not counting empty lines and comments, but because of some other issues as well. The Erlang implementation has the unit tests in the same files so it's all intertwined. The Go implementation makes use of a repository on github, should that be counted? In my own case I used my D serialisation library and also vibe.d. I would say neither should count towards the final tally, but others may beg to differ.

All in all the MQTT specific parts in all 3 projects weigh in at around 500 - 700 total lines as measured by wc -l, if memory serves me correctly. I'm on another computer now and pressed for time.

I wouldn't be surprised if the Erlang version was the shortest at the end of the day. I know that the Go and D implementations are comparable.

Atila

On Wednesday, 4 December 2013 at 18:05:11 UTC, David Nadlinger wrote:
> What are the issues that are blocking you from using it with LDC? The 2.064 frontend not being officially yet? I couldn't find any mention of vibe.d in the open bugs on our GitHub tracker (besides #468, which concerns the unstable Win64 port). So even though I agree that vibe.d would be a very interesting target for LDC, there is little chance of the situation improving.

Quick search has found these issues:

dub:
https://github.com/rejectedsoftware/dub/issues/172

vibe.d:
https://github.com/rejectedsoftware/vibe.d/issues/351

I remember also someone mentioning crash during fiber switch when using LDC but can't find that place right now.

> It would be interesting to have a GitHub repo with the scripts for each language,

I might set this up after / because of the blog post. We'll see how it goes.

>vibe.d also has a multithreaded version that
> is off by default (fibers created from new tcp connections are distributed in a thread pool where communication is done through Isolated!()).

Oh, I know. I tried it. The threads spent more time sending messages to each other than doing actual work. And that was before I changed the data structure for the subscriptions so it did even less work.

The problem (at least with those 2 benchmarks) just isn't amenable to be made faster by throwing threads at it. It wasn't just the D/vibe.d version. The Go and Erlang versions were tried with multiple threads as well. They either stayed at the same speed or ran slower.

Atila

On 2013-12-04 1:05 PM, David Nadlinger wrote:
> On Wednesday, 4 December 2013 at 12:49:13 UTC, Atila Neves wrote:
>> P.S. vibe.d is awesome, although I wish it'd compile with ldc or gdc
>
> What are the issues that are blocking you from using it with LDC? The
> 2.064 frontend not being officially yet? I couldn't find any mention of
> vibe.d in the open bugs on our GitHub tracker (besides #468, which
> concerns the unstable Win64 port). So even though I agree that vibe.d
> would be a very interesting target for LDC, there is little chance of
> the situation improving.
>
> David

I tried on linux x64 about 2 weeks ago and it's not vibe.d itself but the subpackages like vibelog, userman, or vibed.org, the issues were with std.range I think. I can start sending bug reports in, it would be great to see this working.

On Wednesday, 4 December 2013 at 18:02:18 UTC, Atila Neves wrote:
>> Ah this is rather sad. It makes tests results somewhat unstable
>
> They're not ideal, but they're not unstable with respect to time - I did and redid all those measurements a few times, the error bars are the standard deviation taken to be the systematic error.
>
> I got challenged so I decided to beat his implementation, even this level of detail got called going overboard ;)
>
> Atila

By "stable" here I mean "reproducible on similar h/w and within similar (but not same) environment and meaningfully scaling to high load factors". It is simply impossible in general case when single PC is used for testing.

That does not make results less interesting though :)

On 4 December 2013 18:09, Dicebot <public@dicebot.lv> wrote:
> On Wednesday, 4 December 2013 at 18:05:11 UTC, David Nadlinger wrote:
>>
>> What are the issues that are blocking you from using it with LDC? The
>> 2.064 frontend not being officially yet? I couldn't find any mention of
>> vibe.d in the open bugs on our GitHub tracker (besides #468, which concerns
>> the unstable Win64 port). So even though I agree that vibe.d would be a very
>> interesting target for LDC, there is little chance of the situation
>> improving.
>
>
> Quick search has found these issues:
>
> dub:
> https://github.com/rejectedsoftware/dub/issues/172
>
> vibe.d: https://github.com/rejectedsoftware/vibe.d/issues/351
>
> I remember also someone mentioning crash during fiber switch when using LDC but can't find that place right now.

Ditto with GDC too... I did a quick search on those two project and found that people had reported supposed bugs in GDC, but again none of which have been raised in GDC itself.

Regards
Iain.