Re: [Haskell-cafe] Memory efficiency questions for real-time graphics
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 first implement the formulas in Haskell and leave the optimization for later, if at all. I'd be very surprised to see a vertex transform that would be faster to implement on the CPU than the GPU. It appears you misunderstood complex time-dependent function. This is quite a bit of Haskell code involving a significant amount of octonion algebra. It could, in principle, be put on the GPU, however that should be the very last step after everything else works. There are various ways of writing out your vertex data too, so if it doesn't change too often you can still do the transformation on the GPU, As I previously stated, it changes every frame. 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 stutter. This is not just theoretical: I *see* it as I increase N while it's running. This is the point of my initial email, the subject of which is memory efficiency. ___ 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
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 stutter. This is not just theoretical: I *see* it as I increase N while it's running. This is the point of my initial email, the subject of which is memory efficiency. I'm glad things are going well. Do you have the code somewhere for review? If you read my initial post, you'll see that I am looking to convert an existing C++ application to Haskell. Above I am describing the current C++ implementation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Automatic parallelism in Haskell, similar to make -j4?
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 could do a significant amount of parallelism itself without any hints or code changes at all. I am thinking of our troglodytic friend 'make', which will run (for example) 4 parallel jobs when given the option make -j4. Even 'rake', the ruby version of make, now has a branch (called drake) which does the parallel -j option. Since much of Haskell code is free of side effects, it would seem that it can be analyzed in similar manner to Makefile dependencies in order to find sections which can be run in parallel. What would it take to implement a -j equivalent for, say, GHC? Or if this is not possible, what is wrong with my reasoning? Thanks, TW ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic parallelism in Haskell, similar to make -j4?
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 to parallel every machine operation, it will pend more time maintaining these jobs. 'par' is just the way to tell GHC this part of job is large enough Right, but couldn't the Haskell complier+runtime discover rather large pieces of work? ___ 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
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 reason why you can not do this in the vertex shader? You really should avoid trying to touch the vertices with the CPU if at all possible. 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 first implement the formulas in Haskell and leave the optimization for later, if at all. The current C++ implementation which uses userland-memory vertex arrays already performs very well. On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander [EMAIL PROTECTED] wrote: Even when generating one or more copies of world per frame the performance stays fine and allocations are minimal. Who says? That may be your particular experience from your particular tests. In my case, any copy of the world on each frame would have a catastrophic effect on the framerate, for any such definition of world. From what ive seen, the OpenGL calls are whats going to bottle neck. Yes, that may as well be a tautology. The problem is sporadic lag and jittering from occasional large allocations and/or garbage collection from frequent small allocations. It's a unique situation where even the best profiling cannot pinpoint what is blatantly obvious to the human eye. Though the profiler may register it as 0.01%, the actual effect is glitchy behavior which comes off as unprofessional. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Memory efficiency questions for real-time graphics
As my first Haskell exposure, I've been working through Real World Haskell. I am considering converting some of my C++ graphics libraries to Haskell. I've done a fair amount of googling on the subject, however I haven't quite been able to find clear answers to some of following issues. (1) Using an OpenGL vertex array (a contiguous chunk of memory which is handed to the graphics card) is important. I see the source code of Frag does this, so it looks like we're good. Check. (2) In-place modification of the vertex array is important. Every vertex changes on each frame update. And we always want more vertices. (3) Growing and shrinking the vertex array efficiently is important. Here the behavior of C++ std::vector happens to be ideal. When growing, extend the array in-place if possible (using reserved space if any), otherwise allocate a new chunk (amortized constant time). When shrinking, do nothing but record the smaller size; the unused memory chunk is reserved for possible future growth. (4) Doing little to no allocations each frame update is important. In the current C++ version, zero allocations occur during a normal frame update. When the vertex array changes, that is the only allocation which happens. 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.) The object is described by a certain function, and is generated from a 3D domain grid. 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 ___ 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
On Mon, Oct 27, 2008 at 10:07 PM, Don Stewart [EMAIL PROTECTED] wrote: Seems fine. You'll be working at a low level, with strict, mutable, unboxed data structures, but that's fine: the machine loves them. Thanks for the quick reply. One last question -- is it at all possible to segfault 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
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 without hesitation, knowing that what I want in the end is actually possible. Thanks again, TW ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
