Making an immutable API from a mutable one generally damages performance (on von neumann architectures) somewhat, the goal is to minimize that impact. Cheers. ~Liam On 7 July 2010 19:40, Yves Parès wrote:

That's indeed an advice I've read [1]. But wouldn't it damage the performances, since code will have to go through an extra layer?

[1] http://blog.ezyang.com/2010/06/principles-of-ffi-api-design

2010/7/7 Chris Eidhof

...

On 5 jul 2010, at 23:48, Yves Parès wrote:

...

Hello,

I don't know if some of you are familiar with the SFML library (stands for Simple and Fast Multimedia Library) --> http://sfml-dev.org As SDL, SFML is a 2D graphics library, but conversely to SDL it provides a hardware-accelerated drawing, through OpenGL. Well, I'm currently writing its Haskell binding, and I'm stuck with design issues. What I'm heading to is a full IO binding, and that's what I'd like to avoid.

Have you considered writing a low-level binding and building a high-level library on top of that?

-chris

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Jul 7, 2010 at 2:24 PM, Yves Parès wrote:

...

2010/7/7 Liam O'Connor

...

Making an immutable API from a mutable one generally damages performance (on von neumann architectures) somewhat, the goal is to minimize that impact.

In fact, I would like to determine if an EFFICIENT way to make images and such immutable exists, or if it is impossible.

Both OpenGL and DirectX, while supporting updates to images, make it slow enough that any image data is effectively immutable. Each animation step a completely fresh frame buffer is created, without overwriting any of the inputs, by combining these immutable images in interesting ways. You're expected to combine multiple immutable data sources in the shader to produce the final output (which will be a different image from the inputs). Examples of data sources would be images, transformation matrices, colours etc. It's extremely rare to see people poke values individually into a mutable buffer (in fact, the capability of doing this on the GPU is very recent, and even then it's highly limited). You do a big purely functional transform from inputs to outputs instead. HLSL and GLSL may not look like functional languages, but they essentially are, in that each kernel runs independently with no shared mutable state, producing outputs from immutable inputs. So, if you want to do it on the CPU, I would mimic the way GPUs have been doing it for ages. Define what operations you want to perform in terms of the inputs, and then do them all "in bulk" to produce the output image. You don't want people to go in and arbitrarily set pixels to anything they want at any time they want. -- Sebastian Sylvan

I think it might influence performance, but it doesn't have to be that much. There are some optimization tricks you can apply to deal with this. Premature optimization is the root of all evil ;) -chris On 7 jul 2010, at 11:40, Yves Parès wrote:

That's indeed an advice I've read [1]. But wouldn't it damage the performances, since code will have to go through an extra layer?

[1] http://blog.ezyang.com/2010/06/principles-of-ffi-api-design

2010/7/7 Chris Eidhof On 5 jul 2010, at 23:48, Yves Parès wrote:

...

Hello,

I don't know if some of you are familiar with the SFML library (stands for Simple and Fast Multimedia Library) --> http://sfml-dev.org As SDL, SFML is a 2D graphics library, but conversely to SDL it provides a hardware-accelerated drawing, through OpenGL. Well, I'm currently writing its Haskell binding, and I'm stuck with design issues. What I'm heading to is a full IO binding, and that's what I'd like to avoid.

Have you considered writing a low-level binding and building a high-level library on top of that?

-chris