On 23/04/2010 19:03, Denys Rtveliashvili wrote:
Tue Dec 1 16:03:21 GMT 2009 Simon Marlowmarlo...@gmail.com
mailto:marlo...@gmail.com
* Make allocatePinned use local storage, and other refactorings
The version I have checked out is 6.12 and that's why I haven't seen
this patch.
Are
On Fri, Apr 23, 2010 at 07:07:29PM +0100, Denys Rtveliashvili wrote:
It appears that I am on 6.12.
Strange, as I thought I have check-out the HEAD by following the
instructions on the wiki:
darcs get --partial http://darcs.haskell.org/ghc
The wiki does not tell explicitly what
On 23/04/2010 04:39, Denys Rtveliashvili wrote:
OK, the code I have checked out from the repository contains this in
rts/sm/Storage.h:
extern bdescr * pinned_object_block;
And in rts/sm/Storage.c:
bdescr *pinned_object_block;
Ah, I was looking in the HEAD, where I've already fixed
Hi Simon,
OK, the code I have checked out from the repository contains this in
rts/sm/Storage.h:
extern bdescr * pinned_object_block;
And in rts/sm/Storage.c:
bdescr *pinned_object_block;
Ah, I was looking in the HEAD, where I've already fixed this by moving
Bertram,
It appears that I am on 6.12.
Strange, as I thought I have check-out the HEAD by following the
instructions on the wiki:
darcs get --partial http://darcs.haskell.org/ghc
The wiki does not tell explicitly what will be checked out, so I
expected it to be HEAD.
With kind
Thank you, Simon
I have identified a number of problems and have created patches for a
couple of them. A ticket #4004 was raised in trac and I hope that
someone would take a look and put it into repository if the patches look
good.
Things I did:
* Inlining for a few functions
* changed
On 22/04/10 21:25, Denys Rtveliashvili wrote:
Thank you, Simon
I have identified a number of problems and have created patches for a
couple of them. A ticket #4004 was raised in trac and I hope that
someone would take a look and put it into repository if the patches look
good.
Things I did:
*
Hi Simon,
Thanks - I already did this for alloca/malloc, I'll add the others from
your patch.
Thank you.
We go to quite a lot of trouble to avoid locking in the common cases and
fast paths - most of our data structures are CPU-local. Where in
particular have you encountered locking
On 18/04/2010 10:28, Denys Rtveliashvili wrote:
While alloca is not as cheap as, say, C's alloca, you should find that
it is much quicker than C's malloc. I'm sure there's room for
optimisation if it's critical for you. There may well be low-hanging
fruit: take a look at the Core for alloca.
While alloca is not as cheap as, say, C's alloca, you should find that
it is much quicker than C's malloc. I'm sure there's room for
optimisation if it's critical for you. There may well be low-hanging
fruit: take a look at the Core for alloca.
Thank you, Simon.
Indeed, there is a
On Apr 15, 2010, at 15:34 , Denys Rtveliashvili wrote:
As for the performance of alloca, I though it would be faster than
malloc. However, in a simple test I have just written it is
actually slower. The test allocates 16-bytes arrays and immediately
de-allocates them. This operation is
While alloca is not as cheap as, say, C's alloca, you should find that
it is much quicker than C's malloc. I'm sure there's room for
optimisation if it's critical for you. There may well be low-hanging
fruit: take a look at the Core for alloca.
The problem with using the stack is that
On 14/04/10 06:02, Denys Rtveliashvili wrote:
Good morning,
Yesterday I did a few tests to measure the performance of FFI calls and
found that the calls themselves are very quick (1-2 nanosecond).
However, there is a kind of FFI calls when one have to allocate a
temporary memory block (for a
Good morning,
Yesterday I did a few tests to measure the performance of FFI calls and
found that the calls themselves are very quick (1-2 nanosecond).
However, there is a kind of FFI calls when one have to allocate a
temporary memory block (for a struct, or a temporary buffer). One of
examples is
14 matches
Mail list logo
