Why is vibe.d still performing bad in benchmarks?

[Sönke Ludwig]

Am 12.07.2019 um 00:33 schrieb Daniel Kozak:
> On Thu, Jul 11, 2019 at 1:25 PM Sönke Ludwig via Digitalmars-d 
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
> 
>     The problem is that for some reason it doesn't scale properly with the
>     number of cores in that benchmark. I have a dual-Xeon server that I can
>     in theory use for profiling this, but I simply still lack the time
>     to do so.
> 
> 
> Unfortunately that is not true anymore. Some time ago it was true, on my 
> 4 core system vibed generaly has been one of the most fastest.
> But now it is not true. So I am not sure the main issue is with number 
> of cores.
> 
>     If you or anyone else who is interested has a bit of time to spare, I
>     would suggest to change the benchmark setup to start one process per
>     core instead of using multiple threads. This is the preferred approach
>     anyway, for multiple reasons, but one of them being that it ensures
>     proper scaling, no matter if the GC kicks in, or some other kind of
>     lock
>     contention happens.
> 
> 
> I have already try this and there is no (countable) difference.
> 
> As I already said I have spent a lot of time to figure it out, but it 
> seems the main issue right now is with vibe-d:http. But as 
> Boris-Barboris mentioned maybe the main issue is with RC.

The issue with InterfaceProxy is definitely true, this has a 
considerable performance hit and the new vibe-http module will get rid 
of that. However, even with InterfaceProxy, the performance is still 
well within the same order of magnitude.

But the Techempower benchmark runs on a 14-core machine (plus HT) - even 
if a single core would only yield 15 kreq/s, that should give at least 
 >200 kreq/s and not just 60 kreq/s. So the main issue here is 
definitely scaling AFAICS.

It could of course still be that the GC is somehow involved and the 
system is RAM bandwidth limited due to constant scanning. The GC 
pressure should be pretty low, but who knows. Once I get a little bit 
more time available and have worked a bit on the backlog, I'll run some 
tests on my 2x8 core box, which should be able to reproduce the issue.