I want to write a grid library,the code like belows
data HMesh m v hf f c=HMesh{
hmesh_get_vertices:: HMap.HashMap Int (HVertex v),
hmesh_get_halffaces:: HMap.HashMap Int (HHalfFace hf),
hmesh_get_faces:: HMap.HashMap Int (HFace f),
hmesh_get_cells:: HMap.HashMap Int (HCell c),
hmesh_get_vertices_name_id:: Int,
hmesh_get_halffaces_name_id:: Int,
hmesh_get_faces_name_id:: Int,
hmesh_get_cells_name_id:: Int,
hmesh_get_dimension:: Int,
hmesh_get_simplex:: Bool,
hmesh_get_manifold_require:: Bool,
hmesh_get_traits:: (Maybe m)
}deriving (Show)
When I create a mesh that contains 10000 triangles,my program runs well.
When I create a mesh that contains 400000 triangle, my program runs so slowly that I can’t wait for it’s result.
The every operation need to alter the mesh, I suspect Haskell needs to recalculate the data HMesh every time.
I want to know how to optimize this problem?I think the key point is to optimize the HashMap to avoid recalculate container.
Maybe you’ll have some luck if you turn on {-# LANGUAGE StrictData #-} at the top of your module. If not then I think we’re going to need to see more code.
Is it possible to optimize Haskell’s program with llvm or other tools?
This library is rewriting of high dimension grid Library in C language,at begining I’m very excited to use Haskell.
Now I’m disappointment. I have to write code interacting with c language,which means I can’t use language of pure function.
You’ll probably want to use strict foldl' instead of foldr as you want to perform all folds. foldr is more appropriate when your function can exit early. Make sure to use foldl' instead of foldl to not build up thunks.
This should at least improve memory efficiency, not sure what to do about the runtime performance.
Normally, a field can contain a suspended computation (called a thunk) that might eventually produce an error, so the errors will only appear if that field is actually used. StrictData will make sure that all the fields of your custom data structures are evaluated the moment they are created. So if the field with the error is not used then without StrictData the error would just remain inside the thunk, with StrictData the error appears when creating the data structure even if it is not used later.
There are still some limitations to StrictData. Most importantly it will only “peel off” one layer of the suspended computation. If you store a normal lazy list in a field then the only thing that will be forced is the first cons cell of the structure of the list (so it will determine whether the list is empty or has at least one element). But the elements of the list and the full structure will not be forced.
Not really, I think this problem needs a mutable solution if you really want it to be fast. I still don’t think C is equivalent to Haskell for writing mutable code. Haskell has more safety guarantees and it obviously integrates better with other higher-level Haskell code, but it can be more annoying to write and there are some performance pitfalls. Maybe Rust is a better middle ground? Although, I think it is easier to combine C and Haskell than Rust and Haskell.