vibe.d benchmarks

[rsw0x via Digitalmars-d]

On Tuesday, 5 January 2016 at 13:09:55 UTC, Etienne Cimon wrote:
> On Tuesday, 5 January 2016 at 10:11:36 UTC, Atila Neves wrote:
>> On Thursday, 31 December 2015 at 08:23:26 UTC, Laeeth Isharc 
>> wrote:
>>>  [...]
>>
>> vibe.d _was_ faster than Go. I redid the measurements recently 
>> once I wrote an MQTT broker in Rust, and it was losing to 
>> boost::asio, Rust's mio, Go, and Java. I told Soenke about it.
>>
>> I know it's vibe.d and not my code because after I got the 
>> disappointing results I wrote bindings from both boost::asio 
>> and mio to my D code and the winner of the benchmarks shifted 
>> to the D/mio combo (previously it was Rust - I figured the 
>> library was the cause and not the language and I was right).
>>
>> I'd've put up new benchmarks already, I'm only waiting so I 
>> can show vibe.d in a good light.
>>
>> Atila
>
> The Rust mio library doesn't seem to be doing any black magic. 
> I wonder how libasync could be optimized to match it.

Have you used perf(or similar) to attempt to find bottlenecks yet?

If you use linux and LDC or GDC, I found it worked fine for my 
needs. Just compile it with optimizations & frame 
pointers(-fno-omit-frame-pointers for GDC and -disable-fp-elim 
for LDC) or dwarf debug symbols. I can't remember which generates 
a better callstack right now, actually, so it's probably worth 
playing around with under the --call-graph flag(fp or dwarf).

Perf is a bit hard to understand if you've never used it before, 
but it's also very powerful.

Bye.