Re: Faster Array#/MutableArray# copies

2011-03-01 Thread Nathan Howell
On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow wrote: > Ideally you'd want the heap check in the primop to be aggregated into the > calling function's heap check, and the primop should allocate directly from > the heap instead of calling out to the RTS allocate(). All this is a bit > much to expec

Re: Faster Array#/MutableArray# copies

2011-03-01 Thread Roman Leshchinskiy
Simon Marlow wrote: > On 01/03/2011 11:55, Roman Leshchinskiy wrote: > >> >> Would it, in theory, be possible to have an "unpacked" array type? That >> is, could we have constructors for which the length of the closure is >> determined dynamically at runtime? > > Certainly, but the amount of effor

Re: Faster Array#/MutableArray# copies

2011-03-01 Thread Simon Marlow
On 01/03/2011 11:55, Roman Leshchinskiy wrote: Simon Marlow wrote: For small arrays like this maybe we should have a new array type that leaves out all the card-marking stuff too (or just use tuples, as Roman suggested). Would it, in theory, be possible to have an "unpacked" array type? That

Re: Faster Array#/MutableArray# copies

2011-03-01 Thread Roman Leshchinskiy
Simon Marlow wrote: > > For small arrays like this maybe we should have a new array type that > leaves out all the card-marking stuff too (or just use tuples, as Roman > suggested). Would it, in theory, be possible to have an "unpacked" array type? That is, could we have constructors for which the

Re: Faster Array#/MutableArray# copies

2011-02-28 Thread Gábor Lehel
On Mon, Feb 28, 2011 at 6:29 PM, Johan Tibell wrote: > On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow wrote: >> On 18/02/2011 19:42, Nathan Howell wrote: >>> >>> On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy >> > wrote: >>> >>>    Max Bolingbroke wrote: >>>    

Re: Faster Array#/MutableArray# copies

2011-02-28 Thread Johan Tibell
On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow wrote: > On 18/02/2011 19:42, Nathan Howell wrote: >> >> On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy > > wrote: >> >>    Max Bolingbroke wrote: >>     > On 18 February 2011 01:18, Johan Tibell >    

Re: Faster Array#/MutableArray# copies

2011-02-28 Thread Simon Marlow
On 18/02/2011 19:42, Nathan Howell wrote: On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy mailto:r...@cse.unsw.edu.au>> wrote: Max Bolingbroke wrote: > On 18 February 2011 01:18, Johan Tibell mailto:johan.tib...@gmail.com>> wrote:> It seems like a sufficient solution for your n

Re: Faster Array#/MutableArray# copies

2011-02-18 Thread Tyson Whitehead
On February 17, 2011 20:18:11 Johan Tibell wrote: > * Can we use SSE instructions? > > * Can we get the C memcpy code inlined into the C-- source (crazy, I > know). If so we could perhaps benefit directly from optimizations in > libc. From the standpoint of numerical code, it would be very nice

Re: Faster Array#/MutableArray# copies

2011-02-18 Thread Nathan Howell
On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy wrote: > Max Bolingbroke wrote: > > On 18 February 2011 01:18, Johan Tibell wrote:> > It seems like a sufficient solution for your needs would be for us to > > use the LTO support in LLVM to inline across module boundaries - in > > particular

Re: Faster Array#/MutableArray# copies

2011-02-18 Thread Roman Leshchinskiy
Johan Tibell wrote: > > * Could we use built-in compiler rules to catch array copies of known > length and replace them with e.g. unrolled loops? My particular use case > involves copying small arrays (size: 1-32). Ideally this should be as fast > as copying a tuple of the corresponding size but I'

Re: Faster Array#/MutableArray# copies

2011-02-18 Thread Roman Leshchinskiy
Max Bolingbroke wrote: > On 18 February 2011 01:18, Johan Tibell wrote: > > It seems like a sufficient solution for your needs would be for us to > use the LTO support in LLVM to inline across module boundaries - in > particular to inline primop implementations into their call sites. LLVM > would

Re: Faster Array#/MutableArray# copies

2011-02-18 Thread Max Bolingbroke
On 18 February 2011 01:18, Johan Tibell wrote: > C compilers, like gcc, go to great lengths making memcpy fast and I > was thinking that we might be able to steal a trick or two from them. > I'd like some feedback on these ideas: It seems like a sufficient solution for your needs would be for us