[Haskell-cafe] Re: Threads with high CPU usage

[Simon Marlow]

John Goerzen wrote:
> Duncan Coutts wrote:
>> On Mon, 2008-12-22 at 10:30 +0000, Malcolm Wallace wrote:
>>
>>> The terminology seems counter-intuitive, but in other other words, a
>>> "safe" call is slower but more flexible, an "unsafe" call is fast and
>>> dangerous.  Therefore it is always OK to convert an "unsafe" declaration
>>> into a "safe" one, but never OK to convert from "safe" to "unsafe"
>>> without looking at what the foreign side actually does.
>> And in general we would not even bother with considering using "unsafe"
>> for calls that are already expensive. It's only worth considering when
>> the length of the call is always very short.
>>
>> For example in a database library it might make sense to use 'unsafe' on
>> the data-access functions that extract data from a local query result
>> but we should always use 'safe' on any DB function that might want to
>> talk to the network (eg to get more query results).
> 
> It's difficult to anticipate the needs here.  For instance, some people
> may be using a few very-long-running queries measured in minutes, such
> as the original poster.  Other people, such as web app developers, may
> be issuing literally millions of queries, right after another, where the
> difference matters.

I'd be really interested to know whether you can actually measure a 
difference between safe and unsafe foreign calls for something complicated 
like a database query.  Do you have any figures?  If it turns out that 
"safe" calls are a bottleneck, then there might be room for optimisation there.

> I had initially used "unsafe" because of the documented performance
> benefit, plus I certainly am not expecting Sqlite to call back into the
> Haskell runtime.
> 
> It seems to me strange that using "unsafe" instead of "safe" would have
> negative implications for threading.  After all, as Malcolm said above,
> "it is always OK to convert an unsafe declaration into a safe one".  So
> could the compiler be made to be smart enough to do so when it is
> advantageous for threading purposes?

It's not possible to make the choice at runtime without compromising the 
efficiency of "unsafe" calls.  An "unsafe" call is just an inline call to 
the C function, whereas a "safe" call is wrapped in a couple of calls into 
the RTS to save/restore the Haskell state.

Cheers,
	Simon