On Wednesday, 1 July 2015 at 18:09:19 UTC, Mathias Lang wrote:
> On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:
>> [...]
>
> In your dub.json, can you use the following:
>
>     "subConfigurations": {
>         "vibe-d": "libasync"
>     },
>     "dependencies": {
>         "vibe-d": "~>0.7.24-beta.3"
>     },
>
>
> Turns out it makes it much faster on my machine (371ms vs 1474ms). I guess it could be a good thing to investigate if we can make it the default in 0.7.25.

submit an issue on vibe.d's github, they'd probably like to know about this.

On Wednesday, 1 July 2015 at 18:09:19 UTC, Mathias Lang wrote:
> On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:
>> Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks.
>>
>> Compilers
>> go:     go version go1.4.2 linux/amd64
>> vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23
>>
>> Code
>> go:     http://pastebin.com/2zBnGBpt
>> vibe.d: http://pastebin.com/JkpwSe47
>>
>> go version build with     "go build test.go"
>> vibe.d version built with "dub build --build=release test.d"
>>
>> Results on my machine:
>>
>> go:     168.736462ms (overhead ~ 68ms)
>> vibe.d: 1944ms       (overhead ~ 1844ms)
>>
>> Why creating of vibe.d tasks is so slow (more then 10 times)???
>
> In your dub.json, can you use the following:
>
>     "subConfigurations": {
>         "vibe-d": "libasync"
>     },
>     "dependencies": {
>         "vibe-d": "~>0.7.24-beta.3"
>     },
>
>
> Turns out it makes it much faster on my machine (371ms vs 1474ms). I guess it could be a good thing to investigate if we can make it the default in 0.7.25.

I don't benchmark my code frequently, but that's definitely flattering :)

I hope we can see a release LDC 2.067.0 soon so that I can optimize the code further. I've given up on 2.066 a while back

On Tue, 2015-06-30 at 15:20 +0000, Alex Parrill via Digitalmars-d-learn wrote:
> 
[…]
> Use GDC or LDC for profiling code; the DMD optimizer isn't as good.

Also note that gc code generation is poor compared to gccgo: always use gccgo for benchmarking.

[…]
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Am 01.07.2015 um 20:09 schrieb Mathias Lang:
> On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:
>> Just creating a bunch (10k) of sleeping (for 100 msecs) goroutines/tasks.
>>
>> Compilers
>> go:     go version go1.4.2 linux/amd64
>> vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23
>>
>> Code
>> go:     http://pastebin.com/2zBnGBpt
>> vibe.d: http://pastebin.com/JkpwSe47
>>
>> go version build with     "go build test.go"
>> vibe.d version built with "dub build --build=release test.d"
>>
>> Results on my machine:
>>
>> go:     168.736462ms (overhead ~ 68ms)
>> vibe.d: 1944ms       (overhead ~ 1844ms)
>>
>> Why creating of vibe.d tasks is so slow (more then 10 times)???
>
> In your dub.json, can you use the following:
>
>      "subConfigurations": {
>          "vibe-d": "libasync"
>      },
>      "dependencies": {
>          "vibe-d": "~>0.7.24-beta.3"
>      },
>
>
> Turns out it makes it much faster on my machine (371ms vs 1474ms). I
> guess it could be a good thing to investigate if we can make it the
> default in 0.7.25.

This sounds like the event_del() + event_add() sequence that is done in the libevent driver causes this slowdown. If anyone knows of a faster way to rearm a timer for libevent that would be great. Otherwise I don't really know what to do about this (other than using a different driver).

As for libasync, making it the default is maybe still a little too early, but we should definitely think about how to make it more prominent for testing (maybe even still for 0.7.24).

Am 01.07.2015 um 09:55 schrieb Daniel Kozák:
> On Wed, 01 Jul 2015 03:28:01 +0000
> "rsw0x" <anonymous@anonymous.com> wrote:
>>
>> how do they compare if you replace the sleep with yield?
>
> Same problem still extreamly slow

Hm, this is strange. I'll have to find some time to profile this. More or less all that yield() does is to call Fiber.yield() and then once processes pending events.