Re: std.variant benchmark

I profiled it and found out much of the time is spent inside TypeInfo.opEquals being called from tryPutting. So I tried replacing "!= typeid" in tryPutting with "!is typeid". That brought the time from 2.8 s down to 0.12 on my machine. I don't know if that is the proper solution, since I don't

Re: std.variant benchmark

On Fri, Aug 3, 2012 at 8:28 AM, jerro wrote: > On Sunday, 29 July 2012 at 20:24:42 UTC, Dmitry Olshansky wrote: > >> On 30-Jul-12 00:11, Dmitry Olshansky wrote: >> >>> I've found something far more evil: >>> >>> @property bool convertsTo(T)() const >>> { >>> TypeInfo info = typeid(T);

Re: std.variant benchmark

On Sunday, 29 July 2012 at 20:24:42 UTC, Dmitry Olshansky wrote: On 30-Jul-12 00:11, Dmitry Olshansky wrote: I've found something far more evil: @property bool convertsTo(T)() const { TypeInfo info = typeid(T); return fptr(OpID.testConversion, null, &info) == 0; } Okay.

Re: std.variant benchmark

On 30/07/12 13:24, Andrei Alexandrescu wrote: On 7/30/12 4:34 AM, Dmitry Olshansky wrote: On 30-Jul-12 06:01, Andrei Alexandrescu wrote: In fact memcpy could and should be replaced with word by word copy for almost all of struct sizes up to ~32 bytes (as size is known in advance for this partic

Re: std.variant benchmark

On 7/30/12 4:34 AM, Dmitry Olshansky wrote: On 30-Jul-12 06:01, Andrei Alexandrescu wrote: In fact memcpy could and should be replaced with word by word copy for almost all of struct sizes up to ~32 bytes (as size is known in advance for this particular function pointer i.e. handler!int). In f

Re: std.variant benchmark

On 30-Jul-12 06:01, Andrei Alexandrescu wrote: In fact memcpy could and should be replaced with word by word copy for almost all of struct sizes up to ~32 bytes (as size is known in advance for this particular function pointer i.e. handler!int). In fact memcpy should be smart enough to do all t

Re: std.variant benchmark

On Mon, Jul 30, 2012 at 6:07 AM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 7/29/12 11:20 AM, Gor Gyolchanyan wrote: > >> On Sun, Jul 29, 2012 at 6:43 PM, Dmitry Olshansky > **> wrote: >> This should be more relevant then: >> >> //fib.d >

Re: std.variant benchmark

On 7/29/12 11:20 AM, Gor Gyolchanyan wrote: On Sun, Jul 29, 2012 at 6:43 PM, Dmitry Olshansky mailto:dmitry.o...@gmail.com>> wrote: This should be more relevant then: //fib.d import std.datetime, std.stdio, std.variant; auto fib(Int)() { Int a = 1, b = 1;

Re: std.variant benchmark

On 7/29/12 4:11 PM, Dmitry Olshansky wrote: On 29-Jul-12 22:59, Andrei Alexandrescu wrote: On 7/29/12 10:43 AM, Dmitry Olshansky wrote: I'm horrified. Who was working on std.variant enhancements? Please chime in. I guess you just volunteered! When I looked at it this morning I noticed a few s

Re: std.variant benchmark

https://jshare.johnshopkins.edu/rjacque2/public_html/variant.mht https://jshare.johnshopkins.edu/rjacque2/public_html/variant.d

Re: std.variant benchmark

Am Mon, 30 Jul 2012 00:24:40 +0400 schrieb Dmitry Olshansky : > Just commenting one extra branch of this horror movie > gives interesting change: > > 2779us > 2667us > 3153762us > > After: > > 2319us > 2523us > 288581us > > Aye, 10x :o) Very nice finding. Now it is only 100x slower. :D It see

Re: std.variant benchmark

On Sunday, July 29, 2012 18:43:07 Dmitry Olshansky wrote: > I'm horrified. Who was working on std.variant enhancements? Please chime in. I believe that Robert Jaques fixed up std.variant as part of his work on fixing up std.json and that he intended to get the std.variant changes reviewed and me

Re: std.variant benchmark

On 30-Jul-12 00:11, Dmitry Olshansky wrote: I've found something far more evil: @property bool convertsTo(T)() const { TypeInfo info = typeid(T); return fptr(OpID.testConversion, null, &info) == 0; } Okay... now let me pull off another piece of rag: private VariantN

Re: std.variant benchmark

On 29-Jul-12 22:59, Andrei Alexandrescu wrote: On 7/29/12 10:43 AM, Dmitry Olshansky wrote: I'm horrified. Who was working on std.variant enhancements? Please chime in. I guess you just volunteered! When I looked at it this morning I noticed a few signs of bit rot, e.g. opAssign returns by val

Re: std.variant benchmark

On 29-Jul-12 23:20, Peter Alexander wrote: On Sunday, 29 July 2012 at 14:43:09 UTC, Dmitry Olshansky wrote: On 29-Jul-12 18:17, Andrei Alexandrescu wrote: On 7/29/12 8:17 AM, Gor Gyolchanyan wrote: std.variant is so incredibly slow! It's practically unusable for anything, which requires even a

Re: std.variant benchmark

On Sunday, 29 July 2012 at 14:43:09 UTC, Dmitry Olshansky wrote: On 29-Jul-12 18:17, Andrei Alexandrescu wrote: On 7/29/12 8:17 AM, Gor Gyolchanyan wrote: std.variant is so incredibly slow! It's practically unusable for anything, which requires even a tiny bit of performance. You do realize

Re: std.variant benchmark

On 7/29/12 2:57 PM, jerro wrote: I thought this results are a bit strange, so I converted the result to seconds. This gave me: [3.73e-06, 3.721e-06, 2.97281] Very nice analysis! Andrei

Re: std.variant benchmark

On 7/29/12 10:43 AM, Dmitry Olshansky wrote: I'm horrified. Who was working on std.variant enhancements? Please chime in. I guess you just volunteered! When I looked at it this morning I noticed a few signs of bit rot, e.g. opAssign returns by value and such. (Only planting a "ref" there impr

Re: std.variant benchmark

On Sunday, 29 July 2012 at 14:43:09 UTC, Dmitry Olshansky wrote: On 29-Jul-12 18:17, Andrei Alexandrescu wrote: On 7/29/12 8:17 AM, Gor Gyolchanyan wrote: std.variant is so incredibly slow! It's practically unusable for anything, which requires even a tiny bit of performance. You do realize

Re: std.variant benchmark

On Sun, Jul 29, 2012 at 6:41 PM, Tobias Pankrath wrote: > I do compare it with nothing, just to see how many times does it exceed the >> performance of static typed storage. The point is that Variant is >> extremely >> slow. >> All I want is to find out how to implement a very fast typeless storag

Re: std.variant benchmark

On Sun, Jul 29, 2012 at 6:43 PM, Dmitry Olshansky wrote: > On 29-Jul-12 18:17, Andrei Alexandrescu wrote: > >> On 7/29/12 8:17 AM, Gor Gyolchanyan wrote: >> >>> std.variant is so incredibly slow! It's practically unusable for >>> anything, which requires even a tiny bit of performance. >>> >> >> Y

Re: std.variant benchmark

On 29-Jul-12 18:17, Andrei Alexandrescu wrote: On 7/29/12 8:17 AM, Gor Gyolchanyan wrote: std.variant is so incredibly slow! It's practically unusable for anything, which requires even a tiny bit of performance. You do realize you actually benchmark against a function that does nothing, right?

Re: std.variant benchmark

I do compare it with nothing, just to see how many times does it exceed the performance of static typed storage. The point is that Variant is extremely slow. All I want is to find out how to implement a very fast typeless storage with maximum performance and type safety. Isn't that a paradox

Re: std.variant benchmark

On Sun, Jul 29, 2012 at 6:17 PM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 7/29/12 8:17 AM, Gor Gyolchanyan wrote: > >> std.variant is so incredibly slow! It's practically unusable for >> anything, which requires even a tiny bit of performance. >> > > You do realize you actu

Re: std.variant benchmark

On 7/29/12 8:17 AM, Gor Gyolchanyan wrote: std.variant is so incredibly slow! It's practically unusable for anything, which requires even a tiny bit of performance. You do realize you actually benchmark against a function that does nothing, right? Clearly there are ways in which we can improve

std.variant benchmark

std.variant is so incredibly slow! It's practically unusable for anything, which requires even a tiny bit of performance. Benchmark done under -noboundscheck -inline -release -O: import std.stdio; import std.variant; import std.datetime; void on() { auto var = Variant(5); int i = var.get!int; }