Hi! I've upgraded my haskell programs to opengl 2.4.0.1 and I've noticed massive (3X) slowdown. I did only type fixes on code. Is it normal? Csaba
Am Sonntag, 13. September 2009 18:03:30 schrieb Csaba Hruska:
Hi! I've upgraded my haskell programs to opengl 2.4.0.1 and I've noticed massive (3X) slowdown. I did only type fixes on code. Is it normal?
No, it isn't. The only circumstances I can think of where you could perhaps notice some slowdown are using an Haskell interpreter *and* massively using OpenGL's deprecated immediate mode (glBegin/glEnd a.k.a. renderPrimitive). But even then a factor of 3 would be surprising, because stripping away the newtypes for the basic OpenGL types shouldn't be that costly. A compiler like GHC should "compile away" those newtypes, so there should be no difference in the performance then. Could you post your old code and your new code where you observed the slowdown, please? Cheers, S.
Am Sonntag, 13. September 2009 18:03:30 schrieb Csaba Hruska:
Hi! I've upgraded my haskell programs to opengl 2.4.0.1 and I've noticed massive (3X) slowdown. I did only type fixes on code. Is it normal?
I could reproduce this, but the slowdown was related to the OpenGL package only indirectly, the real cause were your type fixes. I had a look at your code, and you can quickly get back your previous performance by an evil 2-line hack: ----------------------------------------------------------------------------------------------- panne@spock:~/build/lambdacube> diff lambdacube.orig/Graphics/LambdaCube/Render.hs lambdacude/Graphics/LambdaCube/Render.hs 11a12
import Unsafe.Coerce 42c43 < m <- (newMatrix ColumnMajor $ map realToFrac $ toListsMat44 t) :: IO (GLmatrix GLfloat)
m <- (newMatrix ColumnMajor $ unsafeCoerce $ toListsMat44 t) :: IO
(GLmatrix GLfloat) ----------------------------------------------------------------------------------------------- As I said, this is evil and probably not the right way to fix you code. Your FloatType and OpenGL's GLfloat have the same runtime representation, so 'realToFrac' is a no-op at runtime, *but* 'map realToFrac' is not a no-op, at least not with GHC's current optimizer. To avoid creating the transformation matrices over and over again, you could e.g. use a GLmatrix for your Transformation type or use GLfloat directly in your Math module. In a nutshell: "map realToFrac" considered harmful. ;-) Cheers, S.
participants (2)
-
Csaba Hruska -
Sven Panne