Possible runtime overhead of wrapping the IO monad?

[Brian Hulley]

Chris Kuklewicz wrote:
> Brian Hulley wrote:
>> Hi,
>> I'm designing an API for a simple graphics window, and am trying to
>> [snip]
>
> There should be no overhead for a newtype.  The above can be
> shortened to one line:
>
> newtype VertexM a = VertexM (IO a) deriving (Functor,Monad,MonadIO)

Thanks - that certainly saves a lot of typing! :-)

>
> (Needs ghc -fglasgow-exts, I expect)
>
>>
>> Also, in:
>>
>>   foreign import ccall duma_vertex3f :: Float -> Float -> Float ->
>> IO ()
>>
>>   vertex3f :: Float -> Float -> Float -> VertexM ()
>>   vertex3f x y z = liftIO $ duma_vertex3f x y z
>>
>> is there a penalty involved in calling vertex3f (from another
>> module) or will the worker/wrapper optimization ensure that machine
>> code in the other module just calls duma_vertex3f directly since the
>> liftIO operation is just an irrelevance at the machine code level?
>
> I doubt there is a penalty.
> [snip]
> In particular -ddump-simpl has been helpful for some people, and you
> want -ddump-stg, perhaps.

I've just now tried compiling with -ddump-stg but this is difficult (for me) 
to understand so I tried with -ddump-simpl as you suggested, and compared 
the outputs when compiling with and without the -O2 optimization flag. 
With -O2 enabled, __ccall_GC duma_vertex3f is indeed called directly instead 
of vertex3f, from a different module, so that proves that different monads 
can indeed be used to wrap IO operations without any performance penalty at 
all. What a great language and compiler!!! :-)

One little thing I wondered about when looking at the -ddump-simpl output: 
for each C API function, there is a warning of the form:

    warning: implicit declaration of function `duma_vertex3f'

Do you know what this means? It doesn't seem to matter as everything 
compiles and runs ok but it would be interesting to know.

Thanks, Brian.