Total time (ms): 11374.4
Repetitions: 200
Sample mode: 56 (89 ocurrences)
Median time: 56.312
Avg time : 56.872
Std dev. : 2.60698
Minimum: 53.978
Maximum: 81.602
95% conf.int. : [51.7624, 61.9816] e = 5.10959
99% conf.int. :
A confusing example:
import std.stdio, std.variant, std.conv;
alias Value = Variant;
alias List = Value[];
alias Map = List[Value];
void main(string[] args){
Value value = abc;
Map map = [value:[]];
Value key = value; // save value
On Monday, 11 March 2013 at 14:23:41 UTC, Peter Sommerfeld wrote:
A confusing example:
import std.stdio, std.variant, std.conv;
alias Value = Variant;
alias List = Value[];
alias Map = List[Value];
Oh, the new alias syntax is in?
The problem you
Total time (ms): 10941.9
Repetitions: 200
Sample mode: 54 (118 ocurrences)
Median time: 54.5855
Avg time : 54.7094
Std dev. : 1.33935
Minimum: 52.535
Maximum: 67.206
95% conf.int. : [52.0843, 57.3345] e = 2.62509
99% conf.int. :
On 2013-03-11 16:11, Namespace wrote:
I've also done some benchmarks. And I wonder why my appender is much faster if I
enable memory reservation.
Probably just because D's Appender has a better growth scheme than yours and you
reallocate too often. Try to compare how often that happens.
Jesse Phillips wrote:
On Monday, 11 March 2013 at 14:23:41 UTC, Peter Sommerfeld wrote:
A confusing example:
import std.stdio, std.variant, std.conv;
alias Value = Variant;
alias List = Value[];
alias Map = List[Value];
Oh, the new alias syntax is
On Monday, 11 March 2013 at 15:21:31 UTC, FG wrote:
On 2013-03-11 16:11, Namespace wrote:
I've also done some benchmarks. And I wonder why my appender
is much faster if I
enable memory reservation.
Probably just because D's Appender has a better growth scheme
than yours and you reallocate
But I do not think you can extend a memory block with C functions.
What about realloc?
On Monday, 11 March 2013 at 15:51:58 UTC, David wrote:
But I do not think you can extend a memory block with C
functions.
What about realloc?
That's what I use. But it moves your old memory into the new
allocated. Or proves it first if your current memory block could
be extended?
On Monday, 11 March 2013 at 15:25:55 UTC, Peter Sommerfeld wrote:
Seems I have to dig into the implementation for a workaround
or use
my own union to integrate the types.
Thanks, Peter
To get the held type of a Variant, use .type():
if(value.type() == typeid(Map))
writeln(value == map);
On Monday, 11 March 2013 at 15:56:37 UTC, Namespace wrote:
On Monday, 11 March 2013 at 15:51:58 UTC, David wrote:
But I do not think you can extend a memory block with C
functions.
What about realloc?
That's what I use. But it moves your old memory into the new
allocated. Or proves it
extends if possible.
http://dpaste.dzfl.pl/f86e5db6
import core.stdc.stdlib;
void main()
{
auto p1 = malloc(14);
auto p2 = realloc(p1, 15);
assert(p1 is p2);
}
Cool, nice to know.
Currently I have this benchmark:
Without memory reserve:
Total time (ms):
On Monday, 11 March 2013 at 16:37:00 UTC, Namespace wrote:
Seems to be the wrong point of optimizations.
Profile?
Also, note that appender is a tool for appending stuff *into an
array*. If you don't actually need an array at the end, then you
could give Array a roll?
I don't think it will
On 11/03/2013 15:25, Peter Sommerfeld wrote:
alias Value = Variant;
alias List = Value[];
alias Map = List[Value];
Oh, the new alias syntax is in?
Hmmm, I'm new to D, why should I use the old one? And I like
the new one more too, it is more descriptive IMHO.
The new syntax is fine, and to
On Monday, March 11, 2013 17:22:26 Nick Treleaven wrote:
On 11/03/2013 15:25, Peter Sommerfeld wrote:
alias Value = Variant;
alias List = Value[];
alias Map = List[Value];
Oh, the new alias syntax is in?
Hmmm, I'm new to D, why should I use the old one? And I like
the new one
11-Mar-2013 04:43, Druzhinin Alexandr пишет:
On 11.03.2013 02:32, Dmitry Olshansky wrote:
I didn't bother to check the text dump in depth but here is one slice:
n6: 41816 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
n1: 8208 0x540209: _D2gc3gcx4Pool10initializeMFmbZv (in
On Sunday, 10 March 2013 at 11:06:41 UTC, simendsjo wrote:
I haven't used valgrind/cachegrind on C/C++ programs before,
but I'm pretty sure it doesn't behave as expected on D code. I
found this page to fix the mangling issue:
http://wiki.dlang.org/Other_Dev_Tools, but all callgraphs is
empty.
I've been trying UDAs today, but I'm hitting roadblocks all the
time..
For instance:
@(10) struct A;
pragma(msg, __traits(getAttributes, A)); // Empty
@(10) struct B {}
pragma(msg, __traits(getAttributes, B)); // tuple(10)
I've encountered several other things that has been
cal callumena...@gmail.com wrote:
To get the held type of a Variant, use .type():
if(value.type() == typeid(Map))
writeln(value == map);
else if(value.type() == typeid(Value))
writeln(value == Value); // Is still Value!
prints map.
Thanks cal, that will help! Seems I'm currently (?)
On Monday, 11 March 2013 at 19:03:49 UTC, simendsjo wrote:
I've been trying UDAs today, but I'm hitting roadblocks all the
time..
For instance:
@(10) struct A;
pragma(msg, __traits(getAttributes, A)); // Empty
@(10) struct B {}
pragma(msg, __traits(getAttributes, B)); //
DMD 2.062:
//-- module other.d, same dir as main --
module other;
int j;
//--
//-- module dir/other.d, subdir of main --
module dir.other;
int j;
//--
//-- module main.d --
module main;
import other;
pragma(msg, [__traits(allMembers, (other))]);
import dir.other;
pragma(msg,
Profile?
Also, note that appender is a tool for appending stuff *into an
array*. If you don't actually need an array at the end, then
you could give Array a roll?
I don't think it will necessarily do better, but it doesn't
hurt to give it a roll.
My profile output looks like this:
On 3/11/13, cal callumena...@gmail.com wrote:
When the module name I use inside __traits is in the same dir as
the main module, I need the extra parenthesis to satisfy the
compiler. Is this a bug, or unavoidable?
I can't reproduce this. How are you compiling the modules?
On Monday, 11 March 2013 at 23:10:58 UTC, Andrej Mitrovic wrote:
On 3/11/13, cal callumena...@gmail.com wrote:
When the module name I use inside __traits is in the same dir
as
the main module, I need the extra parenthesis to satisfy the
compiler. Is this a bug, or unavoidable?
I can't
On Monday, 11 March 2013 at 23:19:18 UTC, cal wrote:
On Monday, 11 March 2013 at 23:10:58 UTC, Andrej Mitrovic wrote:
On 3/11/13, cal callumena...@gmail.com wrote:
When the module name I use inside __traits is in the same dir
as
the main module, I need the extra parenthesis to satisfy the
On Monday, 11 March 2013 at 23:22:42 UTC, cal wrote:
On Monday, 11 March 2013 at 23:19:18 UTC, cal wrote:
On Monday, 11 March 2013 at 23:10:58 UTC, Andrej Mitrovic
I can't reproduce this. How are you compiling the modules?
Specifically:
dmd main.d other.d dir/other.d
produces:
Error:
On 3/12/13, cal callumena...@gmail.com wrote:
if i remove the parenthesis around 'other'.
Ah yes, I can recreate it now. Can you file this as a bug?
On Monday, 11 March 2013 at 23:38:20 UTC, Andrej Mitrovic wrote:
On 3/12/13, cal callumena...@gmail.com wrote:
if i remove the parenthesis around 'other'.
Ah yes, I can recreate it now. Can you file this as a bug?
Sure thanks for checking it
On 3/12/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 3/12/13, cal callumena...@gmail.com wrote:
if i remove the parenthesis around 'other'.
Ah yes, I can recreate it now. Can you file this as a bug?
Ok I filed it: http://d.puremagic.com/issues/show_bug.cgi?id=9692
Maybe a stupid question: an immutable class instance can't
change, so is it possible and is it a good idea to remove (to not
add) the monitor pointer field from immutable class instances,
saving memory and allowing them to store one more word in the
same amount of memory?
Bye,
bearophile
On Monday, 11 March 2013 at 15:25:55 UTC, Peter Sommerfeld wrote:
Jesse Phillips wrote:
Oh, the new alias syntax is in?
Hmmm, I'm new to D, why should I use the old one? And I like
the new one more too, it is more descriptive IMHO.
I just didn't know it made it in yet, so many changes going
On Mon, 11 Mar 2013 21:54:46 -0400, bearophile bearophileh...@lycos.com
wrote:
Maybe a stupid question: an immutable class instance can't change, so is
it possible and is it a good idea to remove (to not add) the monitor
pointer field from immutable class instances, saving memory and
On 12.03.2013 01:28, Dmitry Olshansky wrote:
Thanks for answer, Dmitry! My Mr.X was opengl driver - I just checked my
code that using 3rd libs without debug symbols and found who it was.
Massif shows me gc the same way as you, I just didn't show it.
What visualizer do you use?
I think it's
On 12.03.2013 01:39, Brian Schott wrote:
On Sunday, 10 March 2013 at 11:06:41 UTC, simendsjo wrote:
I haven't used valgrind/cachegrind on C/C++ programs before, but I'm
pretty sure it doesn't behave as expected on D code. I found this page
to fix the mangling issue:
34 matches
Mail list logo
