[Haskell-cafe] Re: Threads with high CPU usage
marlowsd at gmail.com
Tue Jan 6 11:07:35 EST 2009
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.
More information about the Haskell-Cafe