On Friday, 15 August 2014 at 21:24:25 UTC, Jonathan M Davis wrote:
On Friday, 15 August 2014 at 16:48:10 UTC, monarch_dodra wrote:
If you are using "raw GC arrays", then the "raw" append
operation will, outweigh the relocation cost on extension. So
pre-allocation wouldn't really help in this si
On Friday, 15 August 2014 at 16:48:10 UTC, monarch_dodra wrote:
If you are using "raw GC arrays", then the "raw" append
operation will, outweigh the relocation cost on extension. So
pre-allocation wouldn't really help in this situation (though
the use of Appender *should*)
Is that because it'
On Fri, Aug 15, 2014 at 10:04 PM, John Colvin via Digitalmars-d-learn
wrote:
> compiler, version, OS, architecture, flags?
Compiler: DMD 2.065 and LDC 0.14
OS: Linux 64bits (8 cores, but there is no parallelism here)
flags: -O -release -inline (and -noboundscheck for DMD)
> Have you looked at
On Thursday, 14 August 2014 at 17:16:42 UTC, Philippe Sigaud
wrote:
From time to time, I try to speed up some array-heavy code by
using std.array.Appender, reserving some capacity and so on.
It never works. Never. It gives me executables that are maybe
30-50% slower than bog-standard array cod
On Friday, 15 August 2014 at 16:51:20 UTC, Philippe Sigaud wrote:
On Friday, 15 August 2014 at 16:48:10 UTC, monarch_dodra wrote:
Make sure you don't use that if your type has elaborate
construction, or assumes a certain initial state (unless you
are actually emplacing your objects of course).
On Friday, 15 August 2014 at 16:48:10 UTC, monarch_dodra wrote:
On Friday, 15 August 2014 at 14:40:36 UTC, Philippe Sigaud
wrote:
Well, I created a wrapper around a
std.array.uninitializedArray call, to manage the interface I
need
Make sure you don't use that if your type has elaborate
const
On Friday, 15 August 2014 at 14:40:36 UTC, Philippe Sigaud wrote:
Well, I created a wrapper around a std.array.uninitializedArray
call, to manage the interface I need
Make sure you don't use that if your type has elaborate
construction, or assumes a certain initial state (unless you are
actua
Well, I created a wrapper around a std.array.uninitializedArray
call, to manage the interface I need (queue behavior: pushing at
the end, popping at the beginning). When hitting the end of the
current array, it either reuse the current buffer or create a new
one, depending of the remaining capa
On Friday, 15 August 2014 at 12:08:58 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
Hmm, what about a sort of linked list of static arrays, that
allocates
a new one when necessary?
Appender is not a container, and has no freedom on the data it
manipulates. It has to be able to accept an
On Friday, 15 August 2014 at 11:57:30 UTC, Messenger wrote:
T[size] beats all of those on dmd head, though it is inarguably
a
bit limiting.
Hey guys, just a bit of background and my own understanding of
Appender, having worked on it a fair bit.
First of all, Appender was not designed as a nec
On Fri, Aug 15, 2014 at 1:57 PM, Messenger via Digitalmars-d-learn
wrote:
> T[size] beats all of those on dmd head, though it is inarguably a
> bit limiting.
I confirm (even with 2.065). With ldc2 it's optimized out of the way,
so it gives 0 hnsecs :-)
Hmm, what about a sort of linked list of st
On Friday, 15 August 2014 at 10:31:59 UTC, Dicebot wrote:
On Friday, 15 August 2014 at 08:35:41 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
I wonder if using plain `Array` instead may be result in
better performance
where immutability is not needed.
Hmm, no:
...
It is very differen
> It is very different with better compiler though :
>
> $ ldmd2 -release -O a.d
> $ ./appendertest
> Appender.put :378 ms, 794 μs, and 9 hnsecs
> Appender ~=:378 ms, 416 μs, and 3 hnsecs
> Std array :2 secs, 222 ms, 256 μs, and 2 hnsecs
> Std array.reserve :2 secs, 199 ms,
On Thursday, 14 August 2014 at 18:31:15 UTC, Dicebot wrote:
I don't know much about Phobos appender implementation details
but the key thing with reusable buffer is avoid freeing them.
AFAIR Appender.clear frees the allocated memory but
`Appender.length = 0` does not, making it possible to just
On Friday, 15 August 2014 at 08:35:41 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
I wonder if using plain `Array` instead may be result in
better performance
where immutability is not needed.
Hmm, no:
...
It is very different with better compiler though :
$ ldmd2 -release -O a.d
$
On Thu, Aug 14, 2014 at 11:33 PM, Joseph Rushton Wakeling via
Digitalmars-d-learn wrote:
> On 14/08/14 19:16, Philippe Sigaud via Digitalmars-d-learn wrote:
>>
>> Do people here get good results from Appender? And if yes, how are you
>> using it?
>
>
> An example where it worked for me:
> http://b
> I wonder if using plain `Array` instead may be result in better performance
> where immutability is not needed.
Hmm, no:
module appendertest;
import std.array;
import std.datetime;
import std.stdio;
import std.container;
enum size = 1_000;
void test1()
{
auto arr = appender!(int[])();
> Quick test...
Ah, thanks a lot Jonathan. I kept telling me I should probably test it
on a simple case.
OK, the good news is, Appender works in these cases (I mean, that's
good news for Phobos).
Now, I just have to find out why it's slower in my case :)
>
> import std.array;
>
On Thursday, 14 August 2014 at 17:16:42 UTC, Philippe Sigaud
wrote:
From time to time, I try to speed up some array-heavy code by
using std.array.Appender, reserving some capacity and so on.
It never works. Never. It gives me executables that are maybe
30-50% slower than bog-standard array cod
On Thursday, 14 August 2014 at 21:34:04 UTC, Jonathan M Davis
wrote:
On Thursday, 14 August 2014 at 21:11:51 UTC, safety0ff wrote:
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
That would make some sense, though it must be co
On Thursday, 14 August 2014 at 21:34:04 UTC, Jonathan M Davis
wrote:
On Thursday, 14 August 2014 at 21:11:51 UTC, safety0ff wrote:
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
That would make some sense, though it must be co
On 14/08/14 23:33, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
An example where it worked for me:
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
I should add that I don't think I ever explored the case of just using a regular
array with assumeSafeAppend. Now that you'
On Thursday, 14 August 2014 at 21:11:51 UTC, safety0ff wrote:
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
That would make some sense, though it must be completely avoiding
~= then and probably is even GC-mallocing the array
On Thursday, 14 August 2014 at 21:00:55 UTC, Jonathan M Davis
wrote:
On Thursday, 14 August 2014 at 19:47:33 UTC, Brad Anderson
wrote:
On Thursday, 14 August 2014 at 19:10:18 UTC, Jonathan M Davis
wrote:
I've never really tried to benchmark it, but it was my
understanding that the idea behind A
On 14/08/14 19:16, Philippe Sigaud via Digitalmars-d-learn wrote:
Do people here get good results from Appender? And if yes, how are you using it?
An example where it worked for me:
http://braingam.es/2013/09/betweenness-centrality-in-dgraph/
(You will have to scroll down a bit to get to the p
IIRC it manages the capacity information manually instead of
calling the runtime which reduces appending overhead.
On Thursday, 14 August 2014 at 19:47:33 UTC, Brad Anderson wrote:
On Thursday, 14 August 2014 at 19:10:18 UTC, Jonathan M Davis
wrote:
I've never really tried to benchmark it, but it was my
understanding that the idea behind Appender was to use it to
create the array when you do that via a lot
On Thursday, 14 August 2014 at 20:50:37 UTC, Dicebot wrote:
Oh crap I had std.array.Array in mind which does have `length`
exposes. And Appender seems to indeed clear / shrink data in a
horrible way:
https://github.com/D-Programming-Language/phobos/blob/master/std/array.d#L2597
https://github.
On Thursday, 14 August 2014 at 20:42:08 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
You mean by using the shrinkTo method? (Appender does not have a
length, that's a bit of a bother btw).
I just did, it does not change anything. Too bad.
Heck, my code is simpler to read and use *and* fas
> Thanks! Repeating what I have mentioned during DConf talk - have you ever
> considered proposing Pegged for Phobos inclusion? It feels like important
> bit of infrastructure to me.
At the time, it was considered (rightfully) far too slow and
memory-hogging. I think having a generic lexer and a s
>> There is a misunderstanding there: I'm using clear only to flush the
>> state at the beginning of the computation. The Appender is a class
>> field, used by the class methods to calculate. If I do not clear it at
>> the beginning of the methods, I keep appending new results to old
>> computation
On Thursday, 14 August 2014 at 19:29:28 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
There is a misunderstanding there: I'm using clear only to
flush the
state at the beginning of the computation. The Appender is a
class
field, used by the class methods to calculate. If I do not
clear it
On Thursday, 14 August 2014 at 18:55:55 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
btw, I saw your Dconf talk yesterday, nice content! And thanks
for
talking about Pegged!
It might interest you to know that the code I'm trying to use
Appender
on is a new engine for Pegged, based on GLL
On Thursday, 14 August 2014 at 19:10:18 UTC, Jonathan M Davis
wrote:
I've never really tried to benchmark it, but it was my
understanding that the idea behind Appender was to use it to
create the array when you do that via a lot of appending, and
then you use it as a normal array and stop using
On Thursday, 14 August 2014 at 19:29:28 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
It sounds like you're trying to use it as a way to manage
reusing
the array, and I have no idea how it works for that.
There is a misunderstanding there: I'm using clear only to
flush the
state at the
> I've never really tried to benchmark it, but it was my understanding that
> the idea behind Appender was to use it to create the array when you do that
> via a lot of appending, and then you use it as a normal array and stop using
> Appender.
That's how I use it, yes.
> It sounds like you're tr
On Thursday, 14 August 2014 at 17:16:42 UTC, Philippe Sigaud
wrote:
From time to time, I try to speed up some array-heavy code by
using std.array.Appender, reserving some capacity and so on.
It never works. Never. It gives me executables that are maybe
30-50% slower than bog-standard array cod
> I don't know much about Phobos appender implementation details but the key
> thing with reusable buffer is avoid freeing them. AFAIR Appender.clear frees
> the allocated memory but `Appender.length = 0` does not, making it possible
> to just overwrite stuff again and again.
I call .clear() only
On Thursday, 14 August 2014 at 17:16:42 UTC, Philippe Sigaud
wrote:
From time to time, I try to speed up some array-heavy code by
using std.array.Appender, reserving some capacity and so on.
It never works. Never. It gives me executables that are maybe
30-50% slower than bog-standard array cod
From time to time, I try to speed up some array-heavy code by
using std.array.Appender, reserving some capacity and so on.
It never works. Never. It gives me executables that are maybe
30-50% slower than bog-standard array code.
I don't do anything fancy: I just replace the types, use clear()
40 matches
Mail list logo
