Re: Fast Mutable arrays and a general question about IO
Ron de Bruijn
Why? It's not always necessary to go for maximum speed; do you have a reason for needing it in this case?
Almost any operation in my program works on array's and before the program terminates, there have been an awful lot of operations on it. If there is an other kind of array that mutates and doesn't create a copy of it when changing a value and isn't more than 1,5 times as slow as an array in C++ then that should also be ok. The program would run in a scale of hours or days. And if it's twice as fast, than I could calculate two times as much.
Alright. <snip>
I think you mean `above'. In any case, could you show us some code you have that's not working? That'll make it much easier for us to answer your questions.
Well I don't have really code, because I want to begin programming it.
I will restate my goal: I want to be able to read, update and create arrays in Haskell of type myDataType (suppose my constructor function is Con Int String Int)
Alright. You seem to have the concepts down here, so I would recommend you try to start on your own, and mail us back when you have a problem.
on a way that's fast, preferabily the fastest method.
I don't know what the fastest method is, although I doubt you'll get anything (natively) faster than IOArray, or IOUArray if you only need arrays of primitive types. <snip>
So to put it more concrete: In any Haskell program that does IO there is always some function that has this form:
do x<-someSource putBoundVariableToSomeOtherFunctionThatDoesMonadicOperations (restOfPureFunctionalProgramForExample x)
No.
Why not?
Sorry; I put that reply in the wrong place; I meant it to refer to the item below it (meaning it's not possible to do IO within a value of type Int). You are correct that there must be a function in any program with /at least/ that form (i.e., there could be more statements, but if you want to do processing within pure Haskell, you need to wrap that processing ultimately roughly as shown above). Jon Cast
I am still stuck with the problem of creating an IOArray. I have tried the following: import Data.Ix import Data.Array.MArray import Monad import IO import Data.Array.IO test=newArray (0,1) IOArray But this doesn't work because the dataconstructor is not in scope, although I have imported all imaginable modules. Then I tried: test=newArray (0,1) Lesson GHC told me I needed to create an instance of MArray with it's type, but I had no idea of how to do such thing. So I went experimenting with type classes when I encountered something very strange. data Lesson=Lesson String Int Int String String instance Show Lesson where show (Lesson s1 i1 i2 s2 s3) = show s1 Why does above instance of Show works with Hugs, but not with GHC 5.04.2 (see error below)? {- Compiling Test ( test.hs, interpreted ) test.hs:38: Ambiguous occurrence `show' It could refer to either `Test.show', defined at test.hs:38 or `GHC.Show.show', imported from Prelude at test.hs:1 Failed, modules loaded: none. I now have two pieces of information, at least I think so: I need some instance of my an MArray of my datatype Lesson as an elementtype. And I need some way of integrating the IOArray in that definition. Although this statement is completely easy for an experimented Haskellprogrammer, but it isn't for me. Can somebody please help me with some concrete stuff (I do understand it's better to do it yourself, but I really don't know how to get any further)? Greets Ron __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Ron de Bruijn wrote:
I now have two pieces of information, at least I think so: I need some instance of my an MArray of my datatype Lesson as an elementtype. And I need some way of integrating the IOArray in that definition. Although this statement is completely easy for an experimented Haskellprogrammer, but it isn't for me.
Can somebody please help me with some concrete stuff (I do understand it's better to do it yourself, but I really don't know how to get any further)?
1. Initially it would be simpler to ignore MArray altogether, and just
use IOArray directly.
2. newArray (and newIOArray etc) is a monadic operation, so you have
to use do notation or >>=.
E.g.
module Main where
import IOExts
data Lesson = Lesson String Int Int String String
deriving Show
main = do
test <- newIOArray (0,1) (Lesson "" 0 0 "" "")
...
--
Glynn Clements
module Main where
import IOExts
data Lesson = Lesson String Int Int String String deriving Show
main = do test <- newIOArray (0,1) (Lesson "" 0 0 "" "") ...
-- Glynn Clements
IOExts is a Hugslibrary. Isn't it much slower than GHC's IOArray? P.S. It annoys me that GHC's library's are all compiled. Is there no way I can get there sources, so that they are portable between for instance Hugs or is placing the compiled files in your program folder enough to let Hugs understands the functions of GHC? __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Ron de Bruijn wrote:
import IOExts
data Lesson = Lesson String Int Int String String deriving Show
main = do test <- newIOArray (0,1) (Lesson "" 0 0 "" "") ...
IOExts is a Hugslibrary. Isn't it much slower than GHC's IOArray?
Both GHC and Hugs have IOExts, but only GHC has IOArray. GHC's IOExts module imports IOArray then re-exports it, while Hugs' IOExts provides IOArray directly. So, importing IOExts will work on both, and on GHC provides the same IOArray type as when importing IOArray directly.
P.S. It annoys me that GHC's library's are all compiled. Is there no way I can get there sources, so that they are portable between for instance Hugs or is placing the compiled files in your program folder enough to let Hugs understands the functions of GHC?
AFAIK, the only way to get the source for the GHC libraries is to
download the GHC source code. Some of those files will work with Hugs,
others won't.
--
Glynn Clements
On Saturday 03 May 2003 5:08 pm, Ron de Bruijn wrote:
IOExts is a Hugslibrary. Isn't it much slower than GHC's IOArray?
Just in case there's any confusion. Hugs' array implementation uses linear lists which means that you get linear-time access to arrays in Hugs. If you're using large arrays in Haskell and care about performance, use GHC or NHC. -- Alastair Reid ps Since you were asking about libraries provided by different compilers. The last release of Hugs includes many of the GHC libraries. Future releases will include even more.
participants (4)
-
Alastair Reid -
Glynn Clements -
Jon Cast -
Ron de Bruijn