- FFI - Haskell.org

RE: module Data.Bits
by Simon Marlow 09 Sep '02

09 Sep '02

> I have just been implementing the library module `Data.Bits' > for nhc98, > as part of an effort to bring that compiler up-to-date with > the latest FFI spec. > > The FFI spec says that the operations called 'shift' and 'rotate', > shift and rotate their argument to the right. However, the GHC > implementation in CVS shifts and rotates to the left, and is > documented to do so. > > Who is right? FWIW, before I read any documentation I expected the > undecorated forms to be rightward. I think it's probably a mistake in the FFI addendum. As far as I can tell, the GHC/Hugs implementation of Bits has always worked the other way around. Cheers, Simon

1 0

Proposed change to ForeignPtr
by Alastair Reid 05 Sep '02

05 Sep '02

[Now that we've gotten the library specification issue out of the way, I'd like to revive discussion of this topic. Last time we discussed it, there seemed to be concensus that we would make a change but I didn't get much response when I made a concrete proposal. I'd like to resolve this promptly so that the impending Hugs release can match what the spec says (or vice-versa...).] Since requiring ForeignPtr.newForeignPtr would require preemptive concurrency (see previous discussion), I propose the following changes: 1) Add these functions: makeForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a) attachForeignPtrFinalizer :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO () It is implementation defined whether the free functions are allowed to call Haskell functions. 2) Remove newForeignPtr and addForeignPtrFinalizer [GHC can go ahead and list them as non-standard extensions] There's a minor issue about whether the old function names should be reused (leaving GHC to come up with its own names) or not. I have ceased to care either way. -- Alastair Reid alastair(a)reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

2 2

RE: Proposed change to ForeignPtr
by Simon Marlow 05 Sep '02

05 Sep '02

> 1) Add these functions: > > makeForeignPtr > :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a) > attachForeignPtrFinalizer > :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO () > > It is implementation defined whether the free functions are allowed > to call Haskell functions. > > 2) Remove newForeignPtr and addForeignPtrFinalizer > [GHC can go ahead and list them as non-standard extensions] > > > There's a minor issue about whether the old function names should be > reused (leaving GHC to come up with its own names) or not. I have > ceased to care either way. I have a slight preference for re-using the old names, at least for newForeignPtr. The reason is that it follows the naming conventions in http://www.haskell.org/~simonmar/libraries/conventions.html Cheers, Simon

1 0

RE: Cheap ForeignPtr allocation
by Simon Marlow 04 Sep '02

04 Sep '02

> > Hi Folks, I'd like to propose two new functions for the ForeignPtr > > interface: > > I'm a bit uneasy about this. > > It seems like decisions made on technological grounds (i.e., because > they enable an optimization) tend to date rather quickly because the > technology tends to change too. Hmm, I see your point. Nevertheless, I think even without the tricks I'm using in GHC, the case where a ForeignPtr is used in conjunction with malloc()/free() is one which is likely to be optimisable in any system with its own memory management. > The functions may cover a fairly common case of using ForeignPtrs > (though I've never used ForeignObjs or MallocPtrs that way) - but most > code doesn't use ForeignPtrs so it's a common case of an uncommon > thing. Ok, I'll give some more motivation. I've been converting over some old FFI code, namely GHC's POSIX library. This was written back in the old days before the FFI, and uses lots of GHC extensions. One such extension, which doesn't have an equivalent in the FFI, is to use ByteArrays as garbage-collected chunks of memory which can be passed to foreign functions. The example I'm looking at right now is the SignalSet type in the POSIX library: a SignalSet is a pure value, and there are operations to create new empty/full sets, and create new sets by adding/deleting elements from existing sets. All these operations are pure and work outside the IO monad: emptySignalSet :: SignalSet fullSignalSet :: SignalSet addSignal :: Signal -> SignalSet -> SignalSet deleteSignal :: Signal -> SignalSet -> SignalSet inSignalSet :: Signal -> SignalSet -> Bool However, inside a SignalSet is a real sigset_t which can be passed to the C functions which operate on it. An ideal opportunity for a ForeignPtr, one might think: but using a ForeignPtr here, with free() as its finalizer, adds so much overhead that it would be better to go back to manipulating SignalSets in the IO monad (perhaps this isn't such a good example, it's unlikely that someone is going to be doing a lot of SignalSet mangling, but anyway). Another possibility is to fully marshal the sigset_t into Haskell. The marshalling would be quite expensive, but if there was a lot of manipulation of the SignalSet going on in Haskell land then this might be a good choice. This is a well-known tradeoff; and sometimes it isn't possible to do the marshalling because the C type is abstract. The main point is that having a cheap way to use ForeignPtr with malloc()/free() makes it much more likely that we'll settle on a nice pure interface in this case, because the overhead for doing so is significantly lower. > I'm inclined to say: add it to GHC for now and prod us again once a > decent body of examples builds up. Well, I'll do this if I have to, but I don't really want to make my FFI code non-portable. Cheers, Simon

2 1

Cheap ForeignPtr allocation
by Simon Marlow 04 Sep '02

04 Sep '02

Hi Folks, I'd like to propose two new functions for the ForeignPtr interface: mallocForeignPtr :: Storable a => IO (ForeignPtr a) mallocForeignPtrBytes :: Int -> IO (ForeignPtr a) (the names can change, of course). The implementations are trivial in terms of existing things: mallocForeignPtr = do p <- malloc newForeignPtr p free mallocForeignPtrBytes size = do p <- mallocBytes size newForeignPtr p free However, in GHC we can provide a far more efficient implementation by using pinned ByteArray#s, avoiding the overhead of malloc()/free() and the finalizer. Since this is quite a common idiom when using ForeignPtrs, I think it's a good case to optimise. I did a little test, and using the above functions gave a 6x improvement in a small example which just repeatedly allocated a new ForeignPtr and passed it to a foreign function. The GHC implementation is to extend the ForeignPtr type like this: data ForeignPtr a = ForeignPtr ForeignObj# | MallocPtr (MutableByteArray# RealWorld) so it does in theory slow down normal ForeignPtrs slightly, but I didn't measure any difference in the limited tests I did. Comments? Cheers, Simon

3 3

project facilitation
by Francis Agedonuma 03 Sep '02

03 Sep '02

Pardon the abruptness and the liberty of this letter; It is due to its exigency. I am a government functionary in my country. I write to ask for your help. My colleagues and I are in need of a foreign partner to assist in the transfer of a considerable amount of money. My colleagues and I have deliberated much on the issue at hand. What we require is someone who is reliable and trustworthy, who has a vision and who will be able to manage whatever business in which we shall inject venture capital. We need someone who can share our dreams and ideals. I have the legal title to the sum and we shall go through the legal procedures entailed in both our laws and international laws in transferring the funds to you in trust. Please do not at this point misunderstand my intention, because understandably, we are not acqainted. I do not even know if you will be reliable and trustworthy, but I believe that everything starts with a first step. I know that I need to explain everything clearly to you before you can come to a decision as to whether you can assist me or not, and I will do this as soon as I get a response from you. I am sure that with the insider information I can provide, we will with your help, conclude the transaction within 21 working days. In consideration for your assistance, we have agreed to give you the normal transaction commission obtainable of 10% of the total sum, and another 5% if you can successfully put together an investment portfolio for us, as we will like to invest some of this money in your country, rather than leave it idle in a bank account. If you can be of assistance, please reach me at franuma(a)mail.com or send a fax to 234 1 7594298 for more information, otherwise, I thank you for your patience. Thank you for your courtesies. Best regards, Francis Agedonuma

1 0

RE: Cheap ForeignPtr allocation
by Simon Marlow 03 Sep '02

03 Sep '02

> I vaguely remeber that in the context of the withForeignPtr > discussion we where once trying to achieve some similar > effect (but couldn't come up with something that would > work). Do you remember? Uh, my memory's a bit vague too :-) For a long time we were trying to get cheap allocation/freeing for temporary storage, i.e. a cheap alloca. We managed to achieve that when I realised I could pull a trick with GHC's garbage collector and have "pinned" objects as long as they don't contain any pointers into the heap. So instead of using malloc()/free() for alloca, we allocate a pinned ByteArray# and let the GC free it. (it needs to be pinned so that it can be passed to foreign functions which might re-enter the RTS and trigger GC, etc.) This proposed extension to ForeignPtr is just taking the idea one step further: we can use the same trick for ForeignPtrs too, at least in the common case where you want the finalizer to free() the object again. > Does this, then, effectively solve > this old problem? Wouldn't you want newXXX and withXXX > variants of the above, too? The two functions I mentioned are all that's needed: mallocForeignPtr :: Storable a => IO (ForeignPtr a) mallocForeignPtrBytes :: Int -> IO (ForeignPtr a) they both do the job of a combined malloc/newForeignPtr. withForeignPtr still works fine with a ForeignPtr constructed this way. Cheers, Simon

1 0

RE: Library archives
by Simon Peyton-Jones 03 Sep '02

03 Sep '02

| .NET is a different beast from other calling conventions in | that you may want to compile Haskell ccalls to .NET | intermediate language. In other words, it is about being | able to implement ccall *on* .NET. Thus, the mix. I think that is exactly the issue. | At the moment, there doesn't seem to be much support for | [lib]. The last message from SimonPJ (a while ago) on this | issues also seems to indicate that he isn't to bothered about | it. But AFAIK he is away at the moment. So let's omit it for now; but we will need to think about what to do when someone really does do a Haskell-on-.NET binding. Simon

2 1

RE: Cheap ForeignPtr allocation
by Simon Marlow 03 Sep '02

03 Sep '02

> Can you achieve the same performance gain by adding some > rewrite rules? Perhaps you could try to spot (>>=) malloc (\p -> newForeignPtr p free) Hmmm. Actually I'd like to do both: add the functions, because they encapsulate a common case and guarantee a speed improvement if you use them, and add the rewrite rule because it might catch some cases in existing code. The problem with relying on rewrite rules exclusively is that they tend to be a bit fragile and can fail to trigger without you noticing. Cheers, Simon

1 0

Say�n ffi ,
by Green Card 30 Aug '02

30 Aug '02

1 0