ell
Date: Tue May 24 00:08:11 2011 +0200
Add byte array copy primops
Signed-off-by: David Terei
>---
compiler/codeGen/CgPrimOp.hs| 59 +++
compiler/prelude/primops.txt.pp
ell
Date: Thu Jun 16 07:50:10 2011 +0200
Port "Add byte array copy primops" to the new code gen
Signed-off-by: David Terei
>---
compiler/codeGen/StgCmmPrim.hs | 57
han Tibell
Date: Tue May 24 00:06:16 2011 +0200
Add test for byte array copy primops
Signed-off-by: David Terei
>---
tests/ghc-regress/codeGen/should_run/all.T |1 +
tests/ghc-regress/codeGen/should_run/cg
--
>
> commit 5b1053897fa16ced293e749447e9c027d15d29f5
> Author: Edward Z. Yang
> Date: Fri Jun 10 17:16:32 2011 +0100
>
> Port "Make array copy primops inline" and related patches to new codegen.
>
> The following patches were ported:
&g
ang
Date: Fri Jun 10 17:16:32 2011 +0100
Port "Make array copy primops inline" and related patches to new codegen.
The following patches were ported:
d0faaa6 Fix segfault in array copy primops on 32-bit
18691d4 Make assignTemp_ less pessimistic
ell
Date: Tue Jun 7 14:44:23 2011 +0200
Fix segfault in array copy primops on 32-bit
The second argument to C's memset was passed as a W8 while memset
expects an int.
Signed-off-by: David Terei
>---
ell
Date: Fri Apr 15 13:40:05 2011 +0200
Make array copy primops inline
compiler/cmm/CmmExpr.hs |5 +-
compiler/codeGen/CgPrimOp.hs| 212 +++
compiler/codeGen/CgUtils.hs | 19 +++-
compiler/prelude/primops.txt.pp |6 -
includes/
On Tue, Feb 1, 2011 at 6:26 PM, Roman Leshchinskiy wrote:
> No, the operation is still impure. Suppose we had
>
> thawArray# :: Array# a -> Int# -> Int# -> MutableArray# s a
>
> Then, we write
>
> f xs = let ys = thawArray# xs 0 n#
> zs = thawArray# xs 0 n#
> in e
>
> Do ys and zs
Johan Tibell wrote:
> On Tue, Feb 1, 2011 at 4:24 PM, Roman Leshchinskiy
> wrote:
>
>> Johan Tibell wrote:
>>
>>>
>>> Does cloneArray# really have to take and return a `State# s`?
>>>
>>
>> Oops, no, it doesn't. This was purely a case of mindless copy-pasting.
>>
>
> Does this apply to any of the
On Tue, Feb 1, 2011 at 4:40 PM, Johan Tibell wrote:
> On Tue, Feb 1, 2011 at 4:24 PM, Roman Leshchinskiy
> wrote:
>>> Does cloneArray# really have to take and return a `State# s`?
>>
>> Oops, no, it doesn't. This was purely a case of mindless copy-pasting.
>
> Does this apply to any of the other
On Tue, Feb 1, 2011 at 4:24 PM, Roman Leshchinskiy wrote:
> Johan Tibell wrote:
>>
>> Something struck me today. Look at the type signature for cloneArray#
>>
>>
>> cloneArray# :: Array# a -> Int# -> Int# -> State# s -> (# State# s,
>> Array# a #)
>>
>>
>> Does cloneArray# really have to take an
On 31 January 2011 09:14, Simon Marlow wrote:
> On 30/01/2011 00:42, Daniel Peebles wrote:
>>
>> In a slightly related proposal on the same topic, what do people think of:
>>
>> newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s,
>> MutableArray# s a #)
>>
>> that would do the obvious
Johan Tibell wrote:
>
> Something struck me today. Look at the type signature for cloneArray#
>
>
> cloneArray# :: Array# a -> Int# -> Int# -> State# s -> (# State# s,
> Array# a #)
>
>
> Does cloneArray# really have to take and return a `State# s`?
Oops, no, it doesn't. This was purely a case o
Hi,
Something struck me today. Look at the type signature for cloneArray#
cloneArray# :: Array# a -> Int# -> Int# -> State# s -> (# State#
s, Array# a #)
Does cloneArray# really have to take and return a `State# s`? It seems
perfectly fine to float this expression around. It needs to be ma
On 30/01/2011 00:42, Daniel Peebles wrote:
In a slightly related proposal on the same topic, what do people think of:
newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s,
MutableArray# s a #)
that would do the obvious thing, by allocating an array of the size
specified by the Int#,
On Sun, Jan 30, 2011 at 1:42 AM, Daniel Peebles wrote:
> In a slightly related proposal on the same topic, what do people think of:
> newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s,
> MutableArray# s a #)
>
> that would do the obvious thing, by allocating an array of the size
> sp
Oh, and obviously it could replace newArray#, which would just be using (\_
-> k) as the function. Is the optimization machinery clever enough to see
the constant function on a primop boundary and fold it in?
On Sat, Jan 29, 2011 at 7:42 PM, Daniel Peebles wrote:
> In a slightly related proposal
In a slightly related proposal on the same topic, what do people think of:
newArrayWith# :: (Int# -> a) -> Int# -> State# s -> (# State# s,
MutableArray# s a #)
that would do the obvious thing, by allocating an array of the size
specified by the Int#, and then pass indices into the function to ge
On 01/26/11 06:22, Simon Marlow wrote:
No - as soon as the thread enters foreign code via a safe foreign call,
GC can happen at any time.
(Which is a very good thing: if you *want* to call a long-running, or
running forever, piece of foreign code, there is a way to do it without
breaking the
Simon Marlow wrote:
>
> No - as soon as the thread enters foreign code via a safe foreign call,
> GC can happen at any time.
Ah, ok. Thanks for setting me straight!
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/li
On 26/01/2011 11:15, Roman Leshchinskiy wrote:
Simon Peyton-Jones wrote:
| AFAIK, the GC never runs during foreign calls. This, combine with the
fact that GHC can | pass ByteArray# directly to FFI calls, should make
memcpy safe even for unpinned | byte arrays. At least that's how I
unders
Simon Peyton-Jones wrote:
>
> | AFAIK, the GC never runs during foreign calls. This, combine with the
> fact that GHC can | pass ByteArray# directly to FFI calls, should make
> memcpy safe even for unpinned | byte arrays. At least that's how I
> understand it.
>
> Unless I am much mistaken, GC
On Wed, Jan 26, 2011 at 11:57 AM, Simon Peyton-Jones
wrote:
>
> | AFAIK, the GC never runs during foreign calls. This, combine with the fact
> that GHC can
> | pass ByteArray# directly to FFI calls, should make memcpy safe even for
> unpinned
> | byte arrays. At least that's how I understand
| AFAIK, the GC never runs during foreign calls. This, combine with the fact
that GHC can
| pass ByteArray# directly to FFI calls, should make memcpy safe even for
unpinned
| byte arrays. At least that's how I understand it.
Unless I am much mistaken, GC absolutely does run during *safe* for
Johan Tibell wrote:
>
> OK. So we can implement copyByteArray# by FFI importing memcpy and
> using the automatic conversion of ByteArray#s into pointers in the FFI. For
> MutableByteArray#s we need to use an unsafeCoerce# as well.
No. Both ByteArray# and MutableByteArray# can be passed to FFI call
On Tue, Jan 25, 2011 at 11:22 PM, Roman Leshchinskiy
wrote:
> On 25/01/2011, at 22:05, Daniel Peebles wrote:
>
>> Roman: I'm thinking that even in the absence of GC during foreign calls, it
>> still seems worthwhile to provide the plain copying primitives, if only to
>> save "user" code from ha
Simon Marlow wrote:
>
> I don't think Cabal supports .cmm files, so if you went that route it
> would be limited to being a GHC boot package, like integer-gmp.
I was thinking about ghc-prim.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://
On 26/01/2011 09:52, Roman Leshchinskiy wrote:
Daniel Peebles wrote:
On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy
Hmm, come to think of it, could they perhaps be written in Cmm (calling
memcpy etc. internally) and imported using the (rather obscure) "prim"
calling convention?
http
Daniel Peebles wrote:
> On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy
>>
>> Hmm, come to think of it, could they perhaps be written in Cmm (calling
>> memcpy etc. internally) and imported using the (rather obscure) "prim"
>> calling convention?
>>
>>
>> http://www.haskell.org/ghc/docs/7.0-l
On 25/01/2011 21:30, Roman Leshchinskiy wrote:
On 25/01/2011, at 20:57, Johan Tibell wrote:
On Tue, Jan 25, 2011 at 9:47 PM, Roman
Leshchinskiy wrote:
On 25/01/2011, at 20:26, Johan Tibell wrote: AFAIK, the GC never
runs during foreign calls. This, combine with the fact that GHC
can pass Byte
On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy wrote:
> On 25/01/2011, at 22:05, Daniel Peebles wrote:
>
> > Roman: I'm thinking that even in the absence of GC during foreign calls,
> it still seems worthwhile to provide the plain copying primitives, if only
> to save "user" code from having
On 25/01/2011, at 22:05, Daniel Peebles wrote:
> Roman: I'm thinking that even in the absence of GC during foreign calls, it
> still seems worthwhile to provide the plain copying primitives, if only to
> save "user" code from having to know a) the structure of a (Byte)Array# and
> where the "da
On Tue, Jan 25, 2011 at 11:06 PM, Roman Leshchinskiy
wrote:
> Yes. See, for instance,
> http://hackage.haskell.org/packages/archive/vector/0.7.0.1/doc/html/Data-Vector.html#v:force
That's exactly the operation I had in mind. I have read your vector
code with enthusiasm. :)
Johan
_
On 25/01/2011, at 21:50, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 10:30 PM, Roman Leshchinskiy
> wrote:
>> thawArray# (which creates a mutable copy), update the element, then
>> unsafeFreeze#. I thought that's what you wanted (modulo names). In theory,
>> since both unsafeFreeze# and unsa
So, to summarize what you guys have been talking about, it's looking like
the primops would become:
copyArray#::Array# a -> Int# -> MutableArray# s a -> Int# ->
Int# -> State# s -> State# s
copyMutableArray# :: MutableArray# a -> Int# -> MutableArray# s a -> Int# ->
Int# -> State#
On Tue, Jan 25, 2011 at 10:30 PM, Roman Leshchinskiy
wrote:
> thawArray# (which creates a mutable copy), update the element, then
> unsafeFreeze#. I thought that's what you wanted (modulo names). In theory,
> since both unsafeFreeze# and unsafeThaw# do some work we might want 4
> different var
On 25/01/2011, at 20:57, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 9:47 PM, Roman Leshchinskiy
> wrote:
>> On 25/01/2011, at 20:26, Johan Tibell wrote:
>> AFAIK, the GC never runs during foreign calls. This, combine with the fact
>> that GHC can pass ByteArray# directly to FFI calls, should
On Tue, Jan 25, 2011 at 9:47 PM, Roman Leshchinskiy
wrote:
> On 25/01/2011, at 20:26, Johan Tibell wrote:
> AFAIK, the GC never runs during foreign calls. This, combine with the fact
> that GHC can pass ByteArray# directly to FFI calls, should make memcpy safe
> even for unpinned byte arrays. A
On 25/01/2011, at 20:26, Johan Tibell wrote:
> On Tue, Jan 25, 2011 at 6:35 PM, Roman Leshchinskiy
> wrote:
>> Daniel Peebles wrote:
>>>
>>> Johan Tibell and I have been working on some new primops for GHC that
>>> would allow people to use fast optimized memcpys on unpinned memory.
>>
>> Why
Hi Roman,
On Tue, Jan 25, 2011 at 6:35 PM, Roman Leshchinskiy
wrote:
> Daniel Peebles wrote:
>>
>> Johan Tibell and I have been working on some new primops for GHC that
>> would allow people to use fast optimized memcpys on unpinned memory.
>
> Why not just use memcpy?
I'm working with unpinned
Daniel Peebles wrote:
>
> Johan Tibell and I have been working on some new primops for GHC that
> would allow people to use fast optimized memcpys on unpinned memory.
Why not just use memcpy?
> The use
> cases I can think of would be in the vector package (possibly the New
> stuff in there, but a
Hi,
Johan Tibell and I have been working on some new primops for GHC that would
allow people to use fast optimized memcpys on unpinned memory. Some
preliminary benchmarks have shown that on my Mac, a memcpy-based array copy
is about 4x faster than a Haskell-based loop doing the same thing. The use
42 matches
Mail list logo
