> Il giorno 09 nov 2015, alle ore 00:17, Edward Z. Yang <[email protected]> ha > scritto: > > Excerpts from Nicola Gigante's message of 2015-11-04 23:13:51 -0800: >> We don't have measurements, but we ruled out this possibility for >> performance reasons. Our idea is to make a thin Haskell wrapper >> around a tiny bit of highly optimized C code. What's the performance >> of locking on MVars? > > I still don't know what it is you're trying to do. If you have a tiny > bit of optimized C code that runs quickly, then you should just make > an unsafe FFI call to it (as for as Haskell's runtime is concerned, > it's just a "fat instruction”). >
I’m sorry, I know my description was too vague. The reason is that we have a blind review pending on a paper and I had instructions of not to talk about what we are doing. Anyway, your reply is nevertheless very clear. >> While we are at it: are primops callable directly from C? I suppose >> calling conventions are different. > > Anything is "callable" from C, but yes, you have to do the right > calling convention. Primops are not easily callable from C. > Ok, that’s what I meant. >> A question comes to mind: you mentioned "safe" calls. >> Are unsafe calls different regarding the detaching of the capability? > > An unsafe call does not detach the capability. > Ok, thanks for the confirmation of this fact. >> Also: would a patch to make this possible be accepted? >> In particular: >> - add a way to make a "ultraunsafe" foreign call that do not loose the >> ownership of the calling thread. > > I don't see what the difference between this and an unsafe foreign call > is. > Nothing actually, I was confused about what “unsafe” call means. >> - add a BlockedOnExplicitSleep flag for tso->why_blocked >> (And in turn this means managing a different blocking queue, right?) >> - export something to reliably put in sleep and resume threads >> in this way. >> >> Is this feasible? Would it be a good idea? > > I still don't see why you can't just block the thread on an MVar > (removing it from the main run queues), and then when you want to > resume it write to the MVar. It'll have an added bonus that you'll > automatically handle masking/async exceptions correctly. > > If you find the MVar implementation is too slow, then maybe you > can think about making an optimized implementation which doesn't > use any synchronization / is inline in the TSO so no allocation > is necessary. But in my opinion this is putting the cart before > the horse. > Yes, that seems simple and fast enough. You’re right that we should measure before making assumptions about hypothetical poor performance. Thank you for your help > Edward Greetings, Nicola _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
