Finding class template instantiations via runtime reflection (for openmethods)
It did not take long! Someone tried to create templatized open
methods and it didn't work right of the box. I expected that, but
in fact there may be a bit of hope. You cannot have virtual
function templates in C++ or in D because the layout of the
vtables have to be known at compile time - but openmethods
creates its method tables at runtime so maybe it can be made to
work.
I stumbled upon a problem very quickly: it seems that classes
that come from class template instantiations are not registered
in ModuleInfo - see below,
import std.stdio;
class Foo {}
class Bar(T) : Foo
{
int i;
}
alias BarInt = Bar!int;
const barInt = new BarInt;
void main()
{
foreach (mod; ModuleInfo) {
foreach (c; mod.localClasses) {
writeln(c);
}
}
}
...output:
modtemp.Foo
core.exception.RangeError
core.exception.AssertError
etc...
Neither 'Bar!int' nor 'BarInt' appear in 'localClasses'.
Ideas?
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 18:55:04 UTC, Vadim Lopatin
wrote:
On Thursday, 21 September 2017 at 18:49:00 UTC, bitwise wrote:
On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin
wrote:
[...]
Doesn't vibe-d use Fibers?
I tried to build a simple web server with a fiber-based
approach once - it was horribly slow.
I hope C# (and soon C++) style stackless resumable functions
will eventually come to D.
It does. But Golang uses them, too. Goroutines.
Indeed. I'm reading about them right now, and they seem to be
"multiplexed". I wonder if Vibe.d does something similar.
The fact that you've observed lower CPU usage by the D version
makes me think some kind of scheduling or thread-priority issue
is the cause.
For example, on windows, the default timer frequency is very low.
It would seem reasonable to get 1000 iterations per second in the
example below, but you get ~64.
`
auto now = steady_clock::now();
auto done = now + milliseconds(1);
int iterations = 0;
while(steady_clock::now() < done) {
++iterations;
Sleep(1);
}
cout << (iterations / 10) << endl;
`
When I wrap the above code with timeBeginPeriod(1) and
timeEndPeriod(1), I get ~550 on my machine.
IIRC, you get similar behavior on MacOS(maybe linux too?) unless
you explicitly raise the thread priority.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd757624(v=vs.85).aspx
So if you're benchmarking anything that sleeps regularly, like an
event based framework, something like
timeBeginPeriod/timeEndPeriod may help.
Re: static array with inferred size
On Wednesday, 20 September 2017 at 16:34:36 UTC, Andrei Alexandrescu wrote: On 09/20/2017 08:36 AM, jmh530 wrote: On Wednesday, 20 September 2017 at 12:10:47 UTC, Andrei Alexandrescu wrote: How would this be useful? -- Andrei Really just an additional convenience, instead of writing slice[0..$, 0..$, 0..$, i], you would write slice[.., .., .., i]. The result looks pretty awful. We save two characters per dimension to get Morse code. -- Andrei This is based on the Matlab colon operator. The .. was intended to keep it consistent with D's syntax. https://www.mathworks.com/help/matlab/ref/colon.html There was also a suggestion at mir-algorithm for allowing something like slice[0..2..$] https://github.com/libmir/mir-algorithm/issues/53 Again, the same idea could be expressed with the colon operator.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin wrote: There is a simple set of simple web server apps written in several languages (Go, Rust, Scala, Node-js): https://github.com/nuald/simple-web-benchmark I've sent PR to include D benchmark (vibe.d). I was hoping it could show performance at least not worse than other languages. But it appears to be slower than Go and even Node.js Are there any tips to achieve better performance in this test? Under windows, I can get vibe.d configured to use libevent to show results comparable with Go. With other configurations, it works two times slower. Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only advantage of D here is CPU load - 90% vs 120% in Go. I'm using DMD. Probably, ldc could speed up it a bit. Probably, it's caused by single threaded async implementation while other languages are using parallel handling of requests? Doesn't vibe-d use Fibers? I tried to build a simple web server with a fiber-based approach once - it was horribly slow. I hope C# (and soon C++) style stackless resumable functions will eventually come to D.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 18:49:00 UTC, bitwise wrote: On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin wrote: There is a simple set of simple web server apps written in several languages (Go, Rust, Scala, Node-js): https://github.com/nuald/simple-web-benchmark I've sent PR to include D benchmark (vibe.d). I was hoping it could show performance at least not worse than other languages. But it appears to be slower than Go and even Node.js Are there any tips to achieve better performance in this test? Under windows, I can get vibe.d configured to use libevent to show results comparable with Go. With other configurations, it works two times slower. Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only advantage of D here is CPU load - 90% vs 120% in Go. I'm using DMD. Probably, ldc could speed up it a bit. Probably, it's caused by single threaded async implementation while other languages are using parallel handling of requests? Doesn't vibe-d use Fibers? I tried to build a simple web server with a fiber-based approach once - it was horribly slow. I hope C# (and soon C++) style stackless resumable functions will eventually come to D. It does. But Golang uses them, too. Goroutines.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 17:13:16 UTC, Daniel Kozak wrote: Ok, maybe there is a some small improvments, but it is nothing what would make this faster than rust and still undere 30K on my pc More test results: On my Win10 PC, DMD/x86/libevent:27-29K, Go:31-33K
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
Ok, maybe there is a some small improvments, but it is nothing what would make this faster than rust and still undere 30K on my pc On Thu, Sep 21, 2017 at 7:02 PM, Daniel Kozak wrote: > in this situation I dont thing there will be difference > > On Thu, Sep 21, 2017 at 6:20 PM, Kagamin via Digitalmars-d < > digitalmars-d@puremagic.com> wrote: > >> Other implementations use switch. https://dpaste.dzfl.pl/406dafbedbd9 is >> it slower? >> > >
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
in this situation I dont thing there will be difference On Thu, Sep 21, 2017 at 6:20 PM, Kagamin via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > Other implementations use switch. https://dpaste.dzfl.pl/406dafbedbd9 is > it slower? >
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
Other implementations use switch. https://dpaste.dzfl.pl/406dafbedbd9 is it slower?
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
with dmd 26K - 28K witlh ldc 27K - 29K On Thu, Sep 21, 2017 at 3:53 PM, Vadim Lopatin via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Thursday, 21 September 2017 at 13:46:49 UTC, Daniel Kozak wrote: > >> Ok, after some more testing it seems it is almost sema with or without >> VibeManualMemoryManagement >> > > Do you see any benefits from using LDC instead of DMD? >
Re: static array with inferred size
On 21.09.2017 12:33, Per Nordlöw wrote: On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr wrote: Can that be done without breakages? -- Andrei No. Are thinking about typeof([1,2]) changing from int[] to int[2] ? Yes, and everything that entails, for example: auto x = [1,2]; x ~= 3; // goes from ok to `error: cannot append int to int[2]`.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 13:46:49 UTC, Daniel Kozak wrote: Ok, after some more testing it seems it is almost sema with or without VibeManualMemoryManagement Do you see any benefits from using LDC instead of DMD?
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
Ok, after some more testing it seems it is almost sema with or
without VibeManualMemoryManagement
On Thu, Sep 21, 2017 at 3:44 PM, Daniel Kozak wrote:
> And it seems it is faster with GC. So removing VibeManualMemoryManagement
> helped in some cases too.
>
> On Thu, Sep 21, 2017 at 3:43 PM, Daniel Kozak wrote:
>
>> BTW: I have changed dub.json a little too:
>>
>> {
>> "name": "vibedtest",
>> "targetName": "vibedtest",
>> "targetType": "executable",
>> "targetPath": "bin",
>> "dependencies": {
>> "vibe-d": "~>0.8.2-alpha.1"
>> },
>> "subConfigurations": {"vibe-d": "libevent"},
>> "versions": [
>> "VibeManualMemoryManagement"
>> ],
>> "buildTypes": {
>> "release": { "buildOptions": ["releaseMode", "optimize",
>> "inline"],
>> "dflags-posix-ldc": ["-flto=thin",
>> "-Xcc=-fuse-ld=gold"] }
>> }
>> }
>>
>> On Thu, Sep 21, 2017 at 3:32 PM, Vadim Lopatin via Digitalmars-d <
>> digitalmars-d@puremagic.com> wrote:
>>
>>> On Thursday, 21 September 2017 at 13:09:33 UTC, Daniel Kozak wrote:
>>>
wrong version, this is my letest version:
https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR
>>>
>>> Thank you!
>>> Updated.
>>>
>>
>>
>
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
s'/sema/same/
On Thu, Sep 21, 2017 at 3:46 PM, Daniel Kozak wrote:
> Ok, after some more testing it seems it is almost sema with or without
> VibeManualMemoryManagement
>
> On Thu, Sep 21, 2017 at 3:44 PM, Daniel Kozak wrote:
>
>> And it seems it is faster with GC. So removing VibeManualMemoryManagement
>> helped in some cases too.
>>
>> On Thu, Sep 21, 2017 at 3:43 PM, Daniel Kozak wrote:
>>
>>> BTW: I have changed dub.json a little too:
>>>
>>> {
>>> "name": "vibedtest",
>>> "targetName": "vibedtest",
>>> "targetType": "executable",
>>> "targetPath": "bin",
>>> "dependencies": {
>>> "vibe-d": "~>0.8.2-alpha.1"
>>> },
>>> "subConfigurations": {"vibe-d": "libevent"},
>>> "versions": [
>>> "VibeManualMemoryManagement"
>>> ],
>>> "buildTypes": {
>>> "release": { "buildOptions": ["releaseMode", "optimize",
>>> "inline"],
>>> "dflags-posix-ldc": ["-flto=thin",
>>> "-Xcc=-fuse-ld=gold"] }
>>> }
>>> }
>>>
>>> On Thu, Sep 21, 2017 at 3:32 PM, Vadim Lopatin via Digitalmars-d <
>>> digitalmars-d@puremagic.com> wrote:
>>>
On Thursday, 21 September 2017 at 13:09:33 UTC, Daniel Kozak wrote:
> wrong version, this is my letest version:
> https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR
>
Thank you!
Updated.
>>>
>>>
>>
>
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
And it seems it is faster with GC. So removing VibeManualMemoryManagement
helped in some cases too.
On Thu, Sep 21, 2017 at 3:43 PM, Daniel Kozak wrote:
> BTW: I have changed dub.json a little too:
>
> {
> "name": "vibedtest",
> "targetName": "vibedtest",
> "targetType": "executable",
> "targetPath": "bin",
> "dependencies": {
> "vibe-d": "~>0.8.2-alpha.1"
> },
> "subConfigurations": {"vibe-d": "libevent"},
> "versions": [
> "VibeManualMemoryManagement"
> ],
> "buildTypes": {
> "release": { "buildOptions": ["releaseMode", "optimize", "inline"],
> "dflags-posix-ldc": ["-flto=thin",
> "-Xcc=-fuse-ld=gold"] }
> }
> }
>
> On Thu, Sep 21, 2017 at 3:32 PM, Vadim Lopatin via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On Thursday, 21 September 2017 at 13:09:33 UTC, Daniel Kozak wrote:
>>
>>> wrong version, this is my letest version: https://paste.ofcode.org/qWsQi
>>> kdhKiAywgBpKwANFR
>>>
>>
>> Thank you!
>> Updated.
>>
>
>
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
BTW: I have changed dub.json a little too:
{
"name": "vibedtest",
"targetName": "vibedtest",
"targetType": "executable",
"targetPath": "bin",
"dependencies": {
"vibe-d": "~>0.8.2-alpha.1"
},
"subConfigurations": {"vibe-d": "libevent"},
"versions": [
"VibeManualMemoryManagement"
],
"buildTypes": {
"release": { "buildOptions": ["releaseMode", "optimize", "inline"],
"dflags-posix-ldc": ["-flto=thin",
"-Xcc=-fuse-ld=gold"] }
}
}
On Thu, Sep 21, 2017 at 3:32 PM, Vadim Lopatin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 21 September 2017 at 13:09:33 UTC, Daniel Kozak wrote:
>
>> wrong version, this is my letest version: https://paste.ofcode.org/qWsQi
>> kdhKiAywgBpKwANFR
>>
>
> Thank you!
> Updated.
>
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 13:09:33 UTC, Daniel Kozak wrote: wrong version, this is my letest version: https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR Thank you! Updated.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
wrong version, this is my letest version:
https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR
On Thu, Sep 21, 2017 at 3:01 PM, Daniel Kozak wrote:
> my version: https://paste.ofcode.org/RLX7GM6SHh3DjBBHd7wshj
>
> On Thu, Sep 21, 2017 at 2:50 PM, Sönke Ludwig via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:
>>
>>> On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>>>
shared static this()
> {
> (...)
> }
>
BTW, I'd recommend using
void main()
{
(...)
runApplication();
}
instead and dropping the VibeDefaultMain version in the package recipe.
The old approach is planned to be faded out slowly, because it requires
some special DUB support that would be nice to see gone at some point.
>>>
>>> Thank you!
>>> Trying to use multithreaded mode.
>>>
>>> Under windows, best Vibe.d results are equal to results of Go server.
>>> Under linux, Vibe.d is still slower even if there are 4 threads
>>> listening.
>>>
>>> Results:
>>>
>>> OS lang:config req/scomments
>>> === ===== ==
>>> Linuxgo53K
>>> LinuxD:default 48K 1 thread
>>> LinuxD:libevent48K 1 thread
>>> LinuxD:libasync46.5K4 threads
>>>
>>> Windows go12K
>>> Windows D:default 12K 4 threads
>>> Windows D:libevent12K 4 threads
>>> Windows D:libasync7K 4 threads
>>>
>>> Under Linux in default and libevent configurations, I see error messages
>>> from 3 of 4 threads - looks like only one thread can process connections.
>>>
>>> Failed to listen on 0.0.0.0:3000
>>> Task terminated with uncaught exception: Failed to listen for incoming
>>> HTTP connections on any of the supplied interfaces.
>>>
>>>
>>>
>> Oh, sorry, I forgot the reusePort option, so that multiple sockets can
>> listen on the same port:
>>
>> auto settings = new HTTPServerSettings("0.0.0.0:3000");
>> settings.options |= HTTPServerOption.reusePort;
>> listenHTTP(settings, &handleRequest);
>>
>
>
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
my version: https://paste.ofcode.org/RLX7GM6SHh3DjBBHd7wshj
On Thu, Sep 21, 2017 at 2:50 PM, Sönke Ludwig via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:
>
>> On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>>
>>> shared static this()
{
(...)
}
>>>
>>> BTW, I'd recommend using
>>>
>>> void main()
>>> {
>>> (...)
>>> runApplication();
>>> }
>>>
>>> instead and dropping the VibeDefaultMain version in the package recipe.
>>> The old approach is planned to be faded out slowly, because it requires
>>> some special DUB support that would be nice to see gone at some point.
>>>
>>
>> Thank you!
>> Trying to use multithreaded mode.
>>
>> Under windows, best Vibe.d results are equal to results of Go server.
>> Under linux, Vibe.d is still slower even if there are 4 threads listening.
>>
>> Results:
>>
>> OS lang:config req/scomments
>> === ===== ==
>> Linuxgo53K
>> LinuxD:default 48K 1 thread
>> LinuxD:libevent48K 1 thread
>> LinuxD:libasync46.5K4 threads
>>
>> Windows go12K
>> Windows D:default 12K 4 threads
>> Windows D:libevent12K 4 threads
>> Windows D:libasync7K 4 threads
>>
>> Under Linux in default and libevent configurations, I see error messages
>> from 3 of 4 threads - looks like only one thread can process connections.
>>
>> Failed to listen on 0.0.0.0:3000
>> Task terminated with uncaught exception: Failed to listen for incoming
>> HTTP connections on any of the supplied interfaces.
>>
>>
>>
> Oh, sorry, I forgot the reusePort option, so that multiple sockets can
> listen on the same port:
>
> auto settings = new HTTPServerSettings("0.0.0.0:3000");
> settings.options |= HTTPServerOption.reusePort;
> listenHTTP(settings, &handleRequest);
>
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
my results:
OS lang:config req/scomments
=== ===== ==
Linuxgo24K
LinuxD:libevent27K4 threads
LinuxD:libasync 26.5K 4 threads
On Thu, Sep 21, 2017 at 2:41 PM, Vadim Lopatin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>
>> shared static this()
>>> {
>>> (...)
>>> }
>>>
>>
>> BTW, I'd recommend using
>>
>> void main()
>> {
>> (...)
>> runApplication();
>> }
>>
>> instead and dropping the VibeDefaultMain version in the package recipe.
>> The old approach is planned to be faded out slowly, because it requires
>> some special DUB support that would be nice to see gone at some point.
>>
>
> Thank you!
> Trying to use multithreaded mode.
>
> Under windows, best Vibe.d results are equal to results of Go server.
> Under linux, Vibe.d is still slower even if there are 4 threads listening.
>
> Results:
>
> OS lang:config req/scomments
> === ===== ==
> Linuxgo53K
> LinuxD:default 48K 1 thread
> LinuxD:libevent48K 1 thread
> LinuxD:libasync46.5K4 threads
>
> Windows go12K
> Windows D:default 12K 4 threads
> Windows D:libevent12K 4 threads
> Windows D:libasync7K 4 threads
>
> Under Linux in default and libevent configurations, I see error messages
> from 3 of 4 threads - looks like only one thread can process connections.
>
> Failed to listen on 0.0.0.0:3000
> Task terminated with uncaught exception: Failed to listen for incoming
> HTTP connections on any of the supplied interfaces.
>
>
>
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:
On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
shared static this()
{
(...)
}
BTW, I'd recommend using
void main()
{
(...)
runApplication();
}
instead and dropping the VibeDefaultMain version in the package
recipe. The old approach is planned to be faded out slowly, because it
requires some special DUB support that would be nice to see gone at
some point.
Thank you!
Trying to use multithreaded mode.
Under windows, best Vibe.d results are equal to results of Go server.
Under linux, Vibe.d is still slower even if there are 4 threads listening.
Results:
OS lang:config req/s comments
=== == === ==
Linux go 53K
Linux D:default 48K 1 thread
Linux D:libevent 48K 1 thread
Linux D:libasync 46.5K 4 threads
Windows go 12K
Windows D:default 12K 4 threads
Windows D:libevent 12K 4 threads
Windows D:libasync 7K 4 threads
Under Linux in default and libevent configurations, I see error messages
from 3 of 4 threads - looks like only one thread can process connections.
Failed to listen on 0.0.0.0:3000
Task terminated with uncaught exception: Failed to listen for incoming
HTTP connections on any of the supplied interfaces.
Oh, sorry, I forgot the reusePort option, so that multiple sockets can
listen on the same port:
auto settings = new HTTPServerSettings("0.0.0.0:3000");
settings.options |= HTTPServerOption.reusePort;
listenHTTP(settings, &handleRequest);
Re: static array with inferred size
On 9/20/17 1:33 PM, ag0aep6g wrote:
On 09/20/2017 06:55 PM, Steven Schveighoffer wrote:
On 9/20/17 11:48 AM, Dgame wrote:
[...]
Unqual!T[n] s(T, size_t n)(T[n] arr)
{
return arr;
}
auto a = "hallo".s;
writeln(typeof(a).stringof); // char[5]
[...]
Still it can't handle the case of:
ubyte[3] x = [1, 2, 3];
Making the parameter variadic seems to do the trick:
import std.traits: Unqual;
Unqual!T[n] s(T, size_t n)(T[n] arr ...)
{
return arr[];
/* With indirections, dmd would complain about an
escaping reference. Slicing shuts it up. */
}
void main()
{
auto a = s("hello");
static assert(is(typeof(a) == char[5]));
auto x = s!ubyte(1, 2, 3);
static assert(is(typeof(x) == ubyte[3]));
auto y = s(new int, new int);
static assert(is(typeof(y) == int*[2]));
auto z = s(new immutable int, new immutable int);
static assert(is(typeof(z) == immutable(int)*[2]));
}
I had no idea you could use static arrays for typesafe variadics! You
learn something new every day :)
It's still a bit clunky. If you are explicitly specifying the type, you
can't use an array literal, you must use the variadic form:
auto x1 = s("hello"); // x1 is char[5]
auto x2 = s!char("hello"); // T == char, but it fails?
auto x3 = s!char('h','e','l','l','o'); // works, but not pleasant.
I think when IFTI is given the type, it should still infer the size from
the parameter.
This is close to a solution. I think if Jonathan's bug was fixed, we
wouldn't even need the variadic form, though it could be useful as
there's no way for the compiler to accidentally allocate on the heap.
However, I still feel the compiler doing the work is a better choice.
This is really basic initializer stuff, and generating templates for
every call isn't always a good idea.
The slicing thing is ugly too... Doesn't that make an unnecessary copy?
-Steve
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig
wrote:
shared static this()
{
(...)
}
BTW, I'd recommend using
void main()
{
(...)
runApplication();
}
instead and dropping the VibeDefaultMain version in the package
recipe. The old approach is planned to be faded out slowly,
because it requires some special DUB support that would be nice
to see gone at some point.
Thank you!
Trying to use multithreaded mode.
Under windows, best Vibe.d results are equal to results of Go
server.
Under linux, Vibe.d is still slower even if there are 4 threads
listening.
Results:
OS lang:config req/scomments
=== ===== ==
Linuxgo53K
LinuxD:default 48K 1 thread
LinuxD:libevent48K 1 thread
LinuxD:libasync46.5K4 threads
Windows go12K
Windows D:default 12K 4 threads
Windows D:libevent12K 4 threads
Windows D:libasync7K 4 threads
Under Linux in default and libevent configurations, I see error
messages from 3 of 4 threads - looks like only one thread can
process connections.
Failed to listen on 0.0.0.0:3000
Task terminated with uncaught exception: Failed to listen for
incoming HTTP connections on any of the supplied interfaces.
Re: static array with inferred size
On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr wrote: Can that be done without breakages? -- Andrei No. Are thinking about typeof([1,2]) changing from int[] to int[2] ?
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
shared static this()
{
(...)
}
BTW, I'd recommend using
void main()
{
(...)
runApplication();
}
instead and dropping the VibeDefaultMain version in the package recipe.
The old approach is planned to be faded out slowly, because it requires
some special DUB support that would be nice to see gone at some point.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
Am 21.09.2017 um 10:01 schrieb Vadim Lopatin:
There is a simple set of simple web server apps written in several
languages (Go, Rust, Scala, Node-js):
https://github.com/nuald/simple-web-benchmark
I've sent PR to include D benchmark (vibe.d).
I was hoping it could show performance at least not worse than other
languages.
But it appears to be slower than Go and even Node.js
Are there any tips to achieve better performance in this test?
Under windows, I can get vibe.d configured to use libevent to show
results comparable with Go. With other configurations, it works two
times slower.
Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only
advantage of D here is CPU load - 90% vs 120% in Go.
I'm using DMD. Probably, ldc could speed up it a bit.
Probably, it's caused by single threaded async implementation while
other languages are using parallel handling of requests?
Multi-threading (or multi-process processing) is probably the main
reason. The following initialization code should get this on par:
shared static this()
{
runWorkerTaskDist({
listenHTTP("0.0.0.0:3000", &handleRequest);
});
}
The other part is that currently the HTTP server code works rather
inefficiently with the new vibe-core implementation, ironically due to
the main feature that is meant to speed up vibe-core over the previous
implementation: using statically typed structs instead of dynamic
interfaces for streams. This currently requires using proxy objects in
the HTTP server, which perform their own type of dynamic dispatch, with
a higher overhead than using classes/interfaces directly.
But there is a pending redesign of the whole HTTP implementation, which
will, among other things, get rid of this and will use statically typed
streams throughout the code. It should then be considerably faster than
the current code path that uses classes/interfaces.
Finally, there is also a considerable performance bug in vibe-core
currently, which I can't fix due to an unresolved Optlink bug:
https://github.com/vibe-d/vibe-core/pull/27 (I tried to reduce this with
dustmite, took about a week, but of course it reduced to a piece of code
that was actually broken - I'll have to redo this with using the MS
linker in parallel as a counter test)
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 08:18:51 UTC, Suliman wrote: Can it be issue with regex speed? auto reg = ctRegex!"^/greeting/([a-z]+)$"; Did you try without it? Regex is used for request paths like "/greeting/username" and not used for path "/" There is no big slowdown caused by regex. 45.6K requests/second with regex vs 46.8K requests/second w/o regex.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
Can it be issue with regex speed? auto reg = ctRegex!"^/greeting/([a-z]+)$"; Did you try without it?
Simple web server benchmark - vibe.d is slower than node.js and Go?
There is a simple set of simple web server apps written in several languages (Go, Rust, Scala, Node-js): https://github.com/nuald/simple-web-benchmark I've sent PR to include D benchmark (vibe.d). I was hoping it could show performance at least not worse than other languages. But it appears to be slower than Go and even Node.js Are there any tips to achieve better performance in this test? Under windows, I can get vibe.d configured to use libevent to show results comparable with Go. With other configurations, it works two times slower. Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only advantage of D here is CPU load - 90% vs 120% in Go. I'm using DMD. Probably, ldc could speed up it a bit. Probably, it's caused by single threaded async implementation while other languages are using parallel handling of requests?
