Re: [Haskell-cafe] Memory efficiency questions for real-time graphics

2008-11-02 Thread T Willingham
On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan [EMAIL PROTECTED] wrote: On Sat, Nov 1, 2008 at 6:57 PM, T Willingham [EMAIL PROTECTED] The per-vertex computation is a quite complex time-dependent function applied to the given domain on each update. Yet even if it were simple, I would still

Re: [Haskell-cafe] Memory efficiency questions for real-time graphics

2008-11-02 Thread T Willingham
On Sun, Nov 2, 2008 at 2:13 PM, Don Stewart [EMAIL PROTECTED] wrote: t.r.willingham: Take a highly complicated function and apply it to N vertices. Now increase N until the framerate is affected. That is where I am. It is obvious that any N-sized allocations will cause the framerate to

[Haskell-cafe] Automatic parallelism in Haskell, similar to make -j4?

2008-11-02 Thread T Willingham
I was surprised when I read the multi-core section of Real World Haskell which explains the use of par, seq, and force to achieve parallelism. While it's obvious a programmer could provide useful parallelism hints to the compiler, given the nature of the language I would have thought Haskell

Re: [Haskell-cafe] Automatic parallelism in Haskell, similar to make -j4?

2008-11-02 Thread T Willingham
On Sun, Nov 2, 2008 at 6:44 PM, Bulat Ziganshin [EMAIL PROTECTED] wrote: What would it take to implement a -j equivalent for, say, GHC? Or if this is not possible, what is wrong with my reasoning? problem is that make have rather large pices of work which it can run parallel. if ghc will try

Re: [Haskell-cafe] Memory efficiency questions for real-time graphics

2008-11-01 Thread T Willingham
On Tue, Oct 28, 2008 at 3:24 PM, Sebastian Sylvan [EMAIL PROTECTED] wrote: 2008/10/28 T Willingham [EMAIL PROTECTED] To give a context for all of this, I am applying a non-linear transformation to an object on every frame. (Note: non-linear, so a matrix transform will not suffice.) Any

[Haskell-cafe] Memory efficiency questions for real-time graphics

2008-10-27 Thread T Willingham
. The user can change the resolution of the grid on the fly, while the object is moving. (Hence the need for grow/shrink efficiency.) Given that (1) is out of the way, what's the best I expect from Haskell concerning (2)-(4)? Thanks, T. Willingham

Re: [Haskell-cafe] Memory efficiency questions for real-time graphics

2008-10-27 Thread T Willingham
with strict, mutable, unboxed structures? I don't quite understand how it knows not to overwrite or underwrite. Cheers, T. Willingham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Memory efficiency questions for real-time graphics

2008-10-27 Thread T Willingham
On Mon, Oct 27, 2008 at 11:04 PM, Don Stewart [EMAIL PROTECTED] wrote: It depends on the operations (safe indexing or unsafe indexing). Being strict or unboxed doesn't determine the safety. OK, that makes sense. This is a huge load off my conscience. I can now dig into Real World Haskell