On Saturday, 23 September 2017 at 22:07:58 UTC, bitwise wrote:
>
> Of the few different architectures I tried, the fiber based approach was much slower. It's possible that my implementation did too many unnecessary context switches.

Can you give a bit more details? What kind of architectures do you mean (hardware, software, ..)?
What was your use case? IO-multiplexing, coarse-grained high-level cooperative multi-tasking, or range-like data processing state-machines?

>
> I suppose this is off topic, but for games, or any realtime application where things need to run intermittently, but at high frequency, and in high numbers, stackless resumable functions are a big win. A lot of AI I've been writing lately (including some flocking behaviors) have been built on top of C# IEnumerators.

Very interesting, I would like to hear more about your approach. I have kind of the opposite experience with C# v7.1. When writing synchronous pull-style code I constantly miss the power of D's ranges, templates and DbI, when I'm forced to work with C#'s IEnumerable<T> extension methods, expression trees and run-time reflection.
About push-style asynchronous code, I find async/await unusable for anything more than the absolute basic stuff. For 95% of my code in this area I use RX.NET (http://reactivex.io/). I'm sure they probably use async/await somewhere down in their implementation, but I just find that it scales very poorly when complexity increases.
My time "lost" by going from Task<T> to IObservable<T> (yes, even for single items) is immediately regained by using a few powerful operators like Buffer, CombineLatest and Switch.

On Sunday, 24 September 2017 at 08:08:35 UTC, Petar Kirov [ZombineDev] wrote:
> On Saturday, 23 September 2017 at 22:07:58 UTC, bitwise wrote:
>>
>> [...]
>
> Can you give a bit more details? What kind of architectures do you mean (hardware, software, ..)?
> What was your use case? IO-multiplexing, coarse-grained high-level cooperative multi-tasking, or range-like data processing state-machines?

Probably not without embarrassing myself ;)
Even now, server tech isn't really my domain, and it was a long time ago.

The effort was mainly a learning experience to better understand what's going on under the hood when working on multiplayer games, web-apps, etc..

All of my implementations were built around the same code though, except request scheduling, where I first tried some kind of state machine, and then switched to fibers afterward, which totally destroyed it's already mediocre performance.

> Very interesting, I would like to hear more about your approach. I have kind of the opposite experience with C# v7.1. When writing synchronous pull-style code I constantly miss the power of D's ranges

I'm not talking about using IEnumerators as generators. I mean using them for user-level threads. So basically, an IEnumerator method being "ticked" regularly by a scheduler/engine could return a scalar or predicate that specified when execution should resume, or it could return another IEnumerator method that the scheduler would run to completion before returning to the first one.

Simplified pseudo-example:

`
IEnumerator Attack(enemy) {
    // attack until enemy dead or escaped
    // maybe the enemy parameter should be 'scope' XD
}

IEnumerator Idle() {
    enemy = null;

    while(true) {
        position += wanderOffset();

        if(enemy = getEnemiesInRange()) {
            yield Attack(enemy);
            enemy = null;
            yield 2.seconds;
        }

        yield;
    }
}

engine.runCoroutine(Idle());

while(true) { // 60 FPS+
    engine.tickCoroutines();
    // ...
    engine.draw();
}
`

I think it's easy to imagine how using fibers would be much more expensive in the above example as it scales in number of AI characters and complexity of behavior.

> About push-style asynchronous code, I find async/await unusable for anything more than the absolute basic stuff. For 95% of my code in this area I use RX.NET (http://reactivex.io/). I'm sure they probably use async/await somewhere down in their implementation, but I just find that it scales very poorly when complexity increases.
> My time "lost" by going from Task<T> to IObservable<T> (yes, even for single items) is immediately regained by using a few powerful operators like Buffer, CombineLatest and Switch.

I'm not sure I understand exactly what you're talking about here, but I know that basic applications get A LOT easier with async/await. For GUI-based applications with network connectivity, the whole concept of threading basically disappears. No need for locks, no need to dispatch UI updates to the main thread. Just code naturally and expect functions that make network calls to just take as long as they need without ever blocking the UI thread.

As far as using async/await at scale, I would blame C# and it's standard library before than the underlying concept itself. I don't think there's anything inherently slow about an async/await type framework, but if you look at microsoft's reference source for C# online, you can see that it's designed with productivity in mind, and that performance takes a back seat. I'm sure the situation in C++ will be very different if stackless resumables are accepted.

On Friday, 22 September 2017 at 09:40:00 UTC, Sönke Ludwig wrote:
> What's was the last status? Could you observe any meaningful thread scaling?
It works for me - multithreading improves performance on my PC.


So far, test results on https://github.com/nuald/simple-web-benchmark
show that D is 2-3 times slower than any other language including node.js

nuald reverted change which enables multithreading since it's "unfair".

On Sunday, 24 September 2017 at 18:36:50 UTC, Vadim Lopatin wrote:
> On Friday, 22 September 2017 at 09:40:00 UTC, Sönke Ludwig wrote:
>> What's was the last status? Could you observe any meaningful thread scaling?
> It works for me - multithreading improves performance on my PC.
>
>
> So far, test results on https://github.com/nuald/simple-web-benchmark
> show that D is 2-3 times slower than any other language including node.js
>
> nuald reverted change which enables multithreading since it's "unfair".

Just cloned the repo and tried. With ldc 1.4.0 (release mode) I get Illegal instruction (core dumped). Debug mode works fine. Works fine with dmd v2.075.1 release mode.

```
24-09-2017 15:08:37 vaalaham ~/code/d/simple-web-benchmark/d
$ bin/vibedtest
Illegal instruction (core dumped)
24-09-2017 15:08:40 vaalaham ~/code/d/simple-web-benchmark/d
$
```

Am 24.09.2017 um 20:36 schrieb Vadim Lopatin:
> On Friday, 22 September 2017 at 09:40:00 UTC, Sönke Ludwig wrote:
>> What's was the last status? Could you observe any meaningful thread scaling?
> It works for me - multithreading improves performance on my PC.
> 
> 
> So far, test results on https://github.com/nuald/simple-web-benchmark
> show that D is 2-3 times slower than any other language including node.js

The response times look very strange for the kind of load that appears to be generated. Unfortunately the testing methodology is so simple that it's difficult so judge anything without running it again locally.

Having said that, the Windows implementation does have performance issues and needs to be looked at. It has rather low priority for me though, because I neither run any servers with Windows, nor did I hear that from anyone else who uses vibe.d.

> 
> nuald reverted change which enables multithreading since it's "unfair".

How on earth can that be unfair when the Go, node.js and Scala versions appear to use multi-threading, too?

On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig wrote:
> How on earth can that be unfair when the Go, node.js and Scala versions appear to use multi-threading, too?

Looks like repo owner thinks they are single threaded.

On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin wrote:
> On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig wrote:
>> How on earth can that be unfair when the Go, node.js and Scala versions appear to use multi-threading, too?
>
> Looks like repo owner thinks they are single threaded.

Just checked threads of Go version. I see 7 'go' and 7 'main' threads.

On 2017-09-24 20:36, Vadim Lopatin wrote:

> nuald reverted change which enables multithreading since it's "unfair".

That's kind of stupid. In a real world scenario one would do everything possible to get the best performance. If one of the frameworks doesn't support mutlithreading, too bad for that framework.

-- 
/Jacob Carlborg

On Monday, 25 September 2017 at 07:05:57 UTC, Vadim Lopatin wrote:
> On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin wrote:
>> On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig wrote:
>>> How on earth can that be unfair when the Go, node.js and Scala versions appear to use multi-threading, too?
>>
>> Looks like repo owner thinks they are single threaded.
>
> Just checked threads of Go version. I see 7 'go' and 7 'main' threads.

I've just tried this on my linux box (only dmd as ldc2 fails with release build - https://github.com/ldc-developers/ldc/issues/2280).

rust:			Requests/sec:	38757.2625
vibe-d:core libevent:	Requests/sec:	27906.8119
vibe-d:core libasync:	Requests/sec:	20534.3057
vibe-core:		Requests/sec:	18042.4251

Didn't include the Go version as it's indeed using more threads.
Results are just for the base url to not include the regex matching there.

On Monday, 25 September 2017 at 08:01:02 UTC, tchaloupka wrote:
> On Monday, 25 September 2017 at 07:05:57 UTC, Vadim Lopatin wrote:
>> On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin wrote:
>>> On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig wrote:
>>>> How on earth can that be unfair when the Go, node.js and Scala versions appear to use multi-threading, too?
>>>
>>> Looks like repo owner thinks they are single threaded.
>>
>> Just checked threads of Go version. I see 7 'go' and 7 'main' threads.
>
> I've just tried this on my linux box (only dmd as ldc2 fails with release build - https://github.com/ldc-developers/ldc/issues/2280).
>
> rust:			Requests/sec:	38757.2625
> vibe-d:core libevent:	Requests/sec:	27906.8119
> vibe-d:core libasync:	Requests/sec:	20534.3057
> vibe-core:		Requests/sec:	18042.4251
>
> Didn't include the Go version as it's indeed using more threads.
> Results are just for the base url to not include the regex matching there.

I've sent PR https://github.com/nuald/simple-web-benchmark/pull/11 to re-enable multithreading in D test app.

BTW, does Rust version use multithreading?