Shawn P. Garbett wrote:
[...] Haskell Version on my laptop, FPS = 103 C Version on my laptop, FPS = 192 [...]
I just gave your example a quick try on my PC, the results do not differ that much for my setup (SuSE x86 Linux 8.2, 3GHz P4, NVIDIA FX 5900):
Haskell version: 6000 FPS C version: 7165 FPS
Curiously, using -O for the Haskell compilation doesn't make any difference. I'll take a closer look with GHC's profiler and the ltrace tool when I get some time.
Thanks for the conversion BTW, I'd like to place this example into GLUT'S "Misc" example directory, with a BSD-like license. Would that be OK?
There's a performance problem we discovered recently in GHC where code like this: case _ccall_ f ... of (# s, r #) -> ... would result in an out-of-line call to f instead of the expected inline call. This might affect you. Also, make sure that HOpenGL doesn't use the FFI facility to specify include files in a foreign import declaration: this prevents cross-module inlining of the call in GHC. Otherwise, the usual tricks apply: looks like the code has lots of Floats sloshing around, so try to get them unboxed as much as possible. If you store Floats/Doubles in a data structure, try using ! {-# UNPACK #-}. Cheers, Simon
On Tuesday 16 March 2004 3:16 am, Simon Marlow wrote:
Shawn P. Garbett wrote:
[...] Haskell Version on my laptop, FPS = 103 C Version on my laptop, FPS = 192 [...]
I just gave your example a quick try on my PC, the results do not differ that much for my setup (SuSE x86 Linux 8.2, 3GHz P4, NVIDIA FX 5900):
Haskell version: 6000 FPS C version: 7165 FPS
Curiously, using -O for the Haskell compilation doesn't make any difference. I'll take a closer look with GHC's profiler and the ltrace tool when I get some time.
Thanks for the conversion BTW, I'd like to place this example into GLUT'S "Misc" example directory, with a BSD-like license. Would that be OK?
There's a performance problem we discovered recently in GHC where code like this:
case _ccall_ f ... of (# s, r #) -> ...
would result in an out-of-line call to f instead of the expected inline call. This might affect you. Also, make sure that HOpenGL doesn't use the FFI facility to specify include files in a foreign import declaration: this prevents cross-module inlining of the call in GHC.
Otherwise, the usual tricks apply: looks like the code has lots of Floats sloshing around, so try to get them unboxed as much as possible. If you store Floats/Doubles in a data structure, try using ! {-# UNPACK #-}.
Cool I'll work on these items. These are all things I understand in concept, but haven't got hands on experience yet. One of my goals is to have a "naive" implementation. Then have an "optimized" implementation. Then both of these could be compared on a web page somewhere for understanding of what's required to get something up to speed. An earlier version I had, was regenerating the DisplayLists every time (a ton of trig). This was the first and most obvious optimization. I may for comparison sake put that back in. I've got an earlier array access example with optimization comparison, that could serve as a more trival example. I think these would be of help to a new developer. Shawn
participants (2)
-
Shawn P. Garbett -
Simon Marlow