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
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
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 effort to
On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow marlo...@gmail.com 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
On 18/02/2011 19:42, Nathan Howell wrote:
On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
mailto:r...@cse.unsw.edu.au wrote:
Max Bolingbroke wrote:
On 18 February 2011 01:18, Johan Tibell johan.tib...@gmail.com
mailto:johan.tib...@gmail.com wrote: It
On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow marlo...@gmail.com wrote:
On 18/02/2011 19:42, Nathan Howell wrote:
On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
mailto:r...@cse.unsw.edu.au wrote:
Max Bolingbroke wrote:
On 18 February 2011 01:18, Johan
On Mon, Feb 28, 2011 at 6:29 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow marlo...@gmail.com wrote:
On 18/02/2011 19:42, Nathan Howell wrote:
On Fri, Feb 18, 2011 at 12:54 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
mailto:r...@cse.unsw.edu.au
On 18 February 2011 01:18, Johan Tibell johan.tib...@gmail.com 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
Max Bolingbroke wrote:
On 18 February 2011 01:18, Johan Tibell johan.tib...@gmail.com 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
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'm
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 to
11 matches
Mail list logo
