[Arrays] Random Access Times ?
Hi there, I tested below program with for x filled in 1 and 50000. And I saw that when I used 50000 it took more than ten times more time than when I used 1, to complete the expression. So much for randow access memory(RAM). Isn't there somekind of other array that really works with random access? module Test where import IOExts data Lesson = Lesson String Int Int String String deriving Show main = do testing <- newIOArray (0,60000) (Lesson "Hallo" 0 0 "" "") sequence(map(writeIOArray testing x) (test)) a<-readIOArray testing 0 putStr (decompose a) test::[Lesson] test=(replicate 100000 (Lesson "" 1 2 "" "")) decompose (Lesson s1 _ _ _ _) = s1 Greets Ron __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
This is likely because it takes a while to construct that long list (i.e., test). Moreover, I'm not sure what the 'x' is in your map function (note that it's probably easier to use mapM_ rather than sequence/map. I think the following would fare much better: main = do testing <- newIOArray (0,60000) (Lesson ...) mapM_ (\x -> writeIOArray (Lesson "" 1 2 "" "")) [0..60000] a <- readIOArray testing 0 putStr (decompose a)
main = do testing <- newIOArray (0,60000) (Lesson "Hallo" 0 0 "" "") sequence(map(writeIOArray testing x) (test)) a<-readIOArray testing 0 putStr (decompose a)
test::[Lesson] test=(replicate 100000 (Lesson "" 1 2 "" ""))
decompose (Lesson s1 _ _ _ _) = s1
Greets Ron
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I am still experimenting with array's and I now do it in Hugs. I have created a little program that creates an array with 100001 elements(see below). After each operation I print the time so I can calculate how long it took to execute. As you can see, the times get increasingly bigger. I also swapped the first (0..10000)with the last action (90000..100000) and it seems the relation is dependant of the height of the index. This is strange, isn't it? And although I know have used Hugs, I want to use somekind of array that I can use in GHC, because I have seen some benchmarks of optimized code of GHC and I was quite impressed. Is there anyone else out there, that already has written a program that deals with large fast mutable arrays? I really want to use Haskell for a realworld application, but what I don't want is that I find out after the time that I am halfway programming from somebody:"Why didn't you use the x-array, because that's x-times as fast?" To understand below code somemore: "schrijf" means write. P.S. An array that I could use in GHC and in Hugs would be best, because I kind of like the more friendly look of WinHugs. Greets Ron module Test where import IOExts import CPUTime import Time schrijf arr i = writeIOArray arr i 5 main = do arr<-newIOArray (0,100000) 5 putStr "Arr aangemaakt" x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [0..10000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [10000..20000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [20000..30000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [30000..40000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [40000..50000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [50000..60000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [60000..70000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [70000..80000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [80000..90000]) x<-getClockTime putStr $ show (x) sequence(map(schrijf arr) [90000..100000]) x<-getClockTime putStr $ show (x) putStr "Klaar" Arr aangemaaktSun May 4 15:38:57 West-Europa (zomertijd) 2003Sun May 4 15:38:58 West-Europa (zome rtijd) 2003Sun May 4 15:38:59 West-Europa (zomertijd) 2003Sun May 4 15:39:02 West-Europa (zomerti jd) 2003Sun May 4 15:39:05 West-Europa (zomertijd) 2003Sun May 4 15:39:10 West-Europa (zomertijd) 2003Sun May 4 15:39:16 West-Europa (zomertijd) 2003Sun May 4 15:39:23 West-Europa (zomertijd) 20 03Sun May 4 15:39:32 West-Europa (zomertijd) 2003Sun May 4 15:39:42 West-Europa (zomertijd) 2003S un May 4 15:39:55 West-Europa (zomertijd) 2003Klaar __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
--- Hal Daume III
I am still experimenting with array's and I now do it in Hugs. I have created a little program that creates
Don't use Hugs for testing performance things, especially with arrays.
Well, ok, but I still want to get the fastest array available at this moment and I yet only have one array working with Hugs. If you know a way how I can implement that it in GHC, I would be pleased to hear it. P.S. What does that "unboxed" and "boxed" mean? And ofcource, thanks for the help I already got. Greets Ron __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Well, ok, but I still want to get the fastest array available at this moment and I yet only have one array working with Hugs. If you know a way how I can implement that it in GHC, I would be pleased to hear it.
Well, you can use boxed or unboxed IO Arrays. Unboxed will be faster (depending on what you're doing, around 2-10 times faster). A boxed array means that if you have: IOArray Int Int then this is essentially represented as: int* array[] where each array element holds a pointer to the int. Unboxed means that the array holds the actual elements. Obviously unboxed arrays are strict. They're significantly faster though. You should be able to just use the code you were using in hugs in GHC and it should compile fine. - Hal
--- Hal Daume III
I am still experimenting with array's and I now do it in Hugs. I have created a little program that creates
Don't use Hugs for testing performance things, especially with arrays.
Well, ok, but I still want to get the fastest array available at this moment and I yet only have one array working with Hugs. If you know a way how I can implement that it in GHC, I would be pleased to hear it. P.S. What does that "unboxed" and "boxed" mean? And ofcourse, thanks for the help I already got. Greets Ron __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
On Sat, 3 May 2003 10:37:32 -0700 (PDT)
Ron de Bruijn
Hi there,
I tested below program with for x filled in 1 and 50000. And I saw that when I used 50000 it took more than ten times more time than when I used 1, to complete the expression. So much for randow access memory(RAM).
Isn't there somekind of other array that really works with random access?
module Test where
import IOExts
data Lesson = Lesson String Int Int String String deriving Show
main = do testing <- newIOArray (0,60000) (Lesson "Hallo" 0 0 "" "") sequence(map(writeIOArray testing x) (test)) a<-readIOArray testing 0 putStr (decompose a)
test::[Lesson] test=(replicate 100000 (Lesson "" 1 2 "" ""))
decompose (Lesson s1 _ _ _ _) = s1
Haskell is a lazy language. It may be that Hugs lazily fills the array, in which case writing to index 1 will only force it to write out 3 elements (index 0,1 and what you are writing). Writing to 50000 would force it to write out 0-50000 first. Try touching each element of the array, then timing lookup.
Hi Ron, | I tested below program with for x filled in 1 and | 50000. And I saw that when I used 50000 it took more | than ten times more time than when I used 1, to | complete the expression. So much for randow access | memory(RAM). | | Isn't there somekind of other array that really works | with random access? Are you using Hugs? That might explain your problem. The Hugs runtime system doesn't support allocation of variable length structures such as arrays. To understand why, you should probably read my old report about the implementation of Gofer, and you should bear in mind that Hugs has a long history, being designed to run on (amongst other things) 8086 machines with 640K (or less) RAM. (Historians may recall a brief period in which variable length structures could be allocated in a separate heap called the "flat resource"; that, however, was removed in anticipation of a planned Hugs/GHC merger, which never actually materialized, but did help to prompt the development of GHCi.) Without support for variable length structures, the original Hugs implementation used a linked list representation as a quick way to get support for arrays in place. I suspect the original implementation is still being used today. After all, changing it to do something a little more efficient (e.g., using a balanced binary tree) is unlikely to be a high priority for most people. Hugs was designed for quick experiments, prototyping algorithms, testing on small problems. But there are many sources of overhead in Hugs. It seemed reasonable to assume that users would move to more serious systems like GHC if they needed more serious performance. So if your question was triggered by experiments with Hugs, then I'd encourage you either to switch to some other system, or else to consider replacing the Hugs implementation of arrays with something more efficient. (Have fun hacking C!) And if your problem was triggered by experience with some other system, then perhaps you could remember to mention what you were using next time you post a question like this :-) All the best, Mark
participants (4)
-
Derek Elkins -
Hal Daume III -
Mark P Jones -
Ron de Bruijn