November 2003 - Glasgow-haskell-users

RE: About unsafeThaw and unsafeFreeze efficiency ....
by Simon Marlow 05 Nov '03

05 Nov '03

> "unsafeThaw :: (Ix i, IArray a e, MArray b e m) => a i e - > > m (b i e) > Converts an immutable array into a mutable array without > taking a copy. This function is "unsafe" because any > subsequent modifications made to the mutable version of > the array will be shared with the immutable version. It > is safe to use, therefore, if the immutable version is > never referenced > again. " The documentation is a bit misleading. It should say something like: Converts an immutable array into a mutable array. The implementation may either simply cast the array from one type to the other without copying the array, or it may take a full copy of the array. The non-copying implementation is supported between certain pairs of array types only; one constraint is that the array types must have identical representations. The following pairs of array types have a non-copying O(1) implementation of unsafeThaw: * UArray -> IOUArray * UArray -> STUArray * Array -> IOArray * Array -> STArray Note that because the array is possibly not copied, any subsequent modifications made to the mutable version of the array may be shared with the immutable version. It is safe to use, therefore, if the immutable version is never referenced again. Note in particular that unsafeThaw to a StorableArray currently doesn't have an efficient implementation. I'll update the docs with the text above. Cheers, Simon

1 0

About unsafeThaw and unsafeFreeze efficiency ....
by heron_carvalho＠bol.com.br 05 Nov '03

05 Nov '03

Hello, in GHC documentation, it is said : "unsafeThaw :: (Ix i, IArray a e, MArray b e m) => a i e - > m (b i e) Converts an immutable array into a mutable array without taking a copy. This function is "unsafe" because any subsequent modifications made to the mutable version of the array will be shared with the immutable version. It is safe to use, therefore, if the immutable version is never referenced again. " I am trying to use unsafeThaw in a parallel program written in a parallel language that I am developing. A process have to transmit a UArray Int Double to another process. I used unsafeThaw to translate the UArray into a StorableArray. Thus, using the function withStorableArray, it is possible to access the array elements (double's) in a contiguos buffer that could be sent directly through MPI. The receiving process fetch the message (MPI_Recv) in a buffer and copy their elements (including array bounds information) in a StorableArray (using withStorableArray and copyArray). Then, using unsafeFreeze applied to the StorableArray, the original UArray Int Double sent by the sender is obtained. But this is efficient only if the conversion from UArray to StorableArray, using unsafe versions of thaw and freeze, does not take a copy, as GHC documentation suggests to the reader. However, my experiments (profiling, measurements, etc.) have detected a source of ineficiency in the application of unsafeThaw and unsafreFreeze. It appears to be more efficient to translate the array to a list (using elems) and then copy the list in a "Ptr" array using pokeArray. unsafeThaw is really "free of copy" ?? Any exception ?? I need a way to access an unboxed immutable array in a contiguos buffer in constant time, in order to minimize marshalling overheads for preparing a message to be sent through a network, using MPI. This is important for parallel scientific code, that makes extensive use of arrays and have to transmitt them between processes. Any suggestion ? Heron __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/

1 0

Re: DiffArray Performance
by MR K P SCHUPKE 04 Nov '03

04 Nov '03

>never used in multi-threaded situation. Erm, nearly all my code in Haskell is multi-threaded. One of the main reasons why I am using haskell is the low-cost light weight multi-threading. Surely this is a big win for Haskell on SMP/Numa machines - which are surely the future - as even Intel have realised they can't just keep ramping up clock speeds and have gone multi-core for their next pentium iteration. Just look at the benchmarks for the multi-cpu opteron machines! I would hesitate to make any type unsafe for multi-threading by default - I think all the guards should be in as standard ... maybe a compile time (or run-time) flag to replace the guards with NO-OPS for single CPU machines might be a sensible option. Regards, Keean Schupke.

3 2

RE: DiffArray Performance
by Simon Marlow 03 Nov '03

03 Nov '03

> Hello again, > > Another thought.. > > Could it be that sTree0 is cyclic that accounts for this > dramatic slow down? I'm not to sure how DiffArray are > implemented, but if it's how I would do it it seems you > would end up with a massive chain of indirections. Possible. It is possible to get an O(n) slowdown by using DiffArrays, but only if you index the original array after making updates to it. If you use the array in a single-threaded way, then indexing should be O(1) and additionally update should be O(1) compared to O(n) for ordinary arrays. It's possible that your use of array here is being implemented as a sequence of updates, which will lead to highly suboptimal behaviour: > > > sTree0 :: STree > > > sTree0 = STree (array (0,9) [(n,(sTree0,[]))| n <- [0..9]]) I haven't checked the DiffArray implementation, though (it would be nice if someone could investigate DiffArray and fix any perf problems they find). Cheers, Simon

2 1

RE: GHC and Kinds
by Simon Peyton-Jones 03 Nov '03

03 Nov '03

| type Kind = Type | | What does this mean? It means that Kinds are represented by Types. Admittedly, Kinds only use a small fragment of what Types can represent, namely Arrow, and type constructor applications. So * is represented by a TyConApp with a TyCon that is called typeCon. The really annoying thing about Kinds is that there's occasionally a bit of sub-kinding. In particular error :: forall a. String -> a We want to allow error "foo" :: Int# so the kind of 'a' can't be *, nor # (the kind of unboxed types). It's an "open" kind, written "?"; both * and # are sub-kinds of ?. You should nevertheless be able to encode your kind system in the same way as GHC does. But I have been thinking that it's over-kill to use Types for Kinds, and leads to no real saving. I may well split the two types in the future. Simon

5 5

RE: mips64 and gmp observation
by Simon Marlow 03 Nov '03

03 Nov '03

> The same is true on IA64, if you look at the configure script there's > a little hack of mine... > > if test "$HaveLibGmp" = "NO"; then > if test "$HostArch_CPP" = "ia64"; then > AC_MSG_ERROR([You need to install libgmp (the in-tree version > does not work on IA64).]) > fi; > fi; > > It's probably broken for 64-bit architectures in general. I guess I should import a more up-to-date GMP at some point. Cheers, Simon

1 0

RE: GHC changes
by Simon Marlow 03 Nov '03

03 Nov '03

> I have made some changes to the GHC source > code (6.0.1) and I would really welcome your > feedback, whether they are ok for my task > (first step: introduce record expressions > of the shape 'struct {x1=e1,x2=e2,...,xn=en}'): > > * added > > ("struct", ITstruct, bit glaExtsBit), > > to ghcExtensionKeywordsFM and > ITstruct to Token in Lex.lhs GHC's lexer is now based on an Alex specification, so this will be different in future GHCs. > 'struct' { ITstruct } > > to the token part of Parser.y (please tell me, why > in the lexer we declare ITstruct to represent > the keyword "struct" and in the parser specification > we turn back to 'struct'), In the parser 'struct' is just a token used in the grammar file, it doesn't represent an actual Haskell string. > How can I speed up the recompilation process? I just want to > check, whether my > changes are compilable or not, is it possible to switch off > optimization and > other time consuming transformations? You should definitely turn off optimisation when developing GHC. The Building Guide describes how to do this: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Cheers, Simon

1 0

RE: Question about profiling in GHC...
by Simon Marlow 03 Nov '03

03 Nov '03

> Yes, it's probably garbage collection. To be sure, you can > run your program > with the "-t" RTS option, which will create a file in the > current working > directory named "foo.stat" if the executable is named "foo". > The resulting > file will contain the total amount of time spent, the mutator > time, and the > GC time. (I recently ran into this problem myself...) The way we normally do this is to add '+RTS -sstderr' to the command line (avoids the pesky foo.stat file). Cheers, Simon

1 0

RE: UArray question....
by Simon Marlow 03 Nov '03

03 Nov '03

> In GHC/FFI, is there some way (is it possible ?) to > access DIRECTLY an array of UArray type (immutable) in a > sequential contiguous memory buffer (in C side, for > example) without to need to copy the array elements one > by one ? GHC hackers and implementors are wellcome... :-) > My interest is to transmit the array over a network using > MPI, but avoiding marshalling overheads. > > It is easy to do this with StorableArray's in the IO > monad, of course, but I need to use UArray. I've been pondering this issue for a while. In fact, I have a replacement for StorableArray which addresses this issue, amongst others. I provide the following function: unsafeStorableArrayToIOUArray :: StorableArray i e -> IOUArray i e This function works in O(1) time in GHC's implementation, because it uses the same representation type for StorableArray and IOUArray (well, in my hacked version of StorableArray this is true). The function has an 'unsafe' prefix, because it only works when the representations of the two arrays are the same (currently true for all 'e' except Bool). >From an IOUArray, you can get a UArray by using unsafeFreeze. A better way might be to have an immutable StorableArray type, that you can get by freezing a StorableArray, and that also supports passing to C. This involves a lot of extra code, though. Cheers, Simon

1 0

mips64-sgi-irix unreg success!
by dons＠cse.unsw.edu.au 02 Nov '03

02 Nov '03

Hey all, mips-sgi-irix builds and runs unregisterised from CVS! $ uname -a IRIX64 edison 6.5 07141529 IP30 mips $ ghc-inplace --version The Glorious Glasgow Haskell Compilation System, version 6.3 $ cat test.hs import System.Info main = do putStrLn System.Info.arch putStrLn System.Info.os $ ghc-inplace test.hs mipseb irix It runs the testsuite unregisterised, not to shabby for a weird box: OVERALL SUMMARY for test run started at Tue Oct 21 18:26:48 PDT 2003 1070 total tests, which gave rise to 1844 test cases, of which 0 caused framework failures 167 were skipped 1520 expected passes 14 expected failures 0 unexpected passes 143 unexpected failures I used the ports of GNU software that come with the "freeware" bundle for Irix, to save booting other software too. Use the following environment, at least on the above variety of mips machine: ghc-6.3 from cvs gcc-3.3 gmake-3.80 external libgmp Then: export MAKE=gmake export LDFLAGS=-L/usr/freeware/lib64 export CPPFLAGS=-I/usr/freeware/include export CFLAGS=-mabi=64 cat >> mk/build.mk <<END SRC_CC_OPTS+=-mabi=64 SRC_HC_OPTS+=-optc-mabi=64 -opta-mabi=64 -optl-mabi=64 SRC_CC_OPTS+=-L/usr/freeware/lib64 SRC_HC_OPTS+=-L/usr/freeware/lib64 END And you will have to comment out the vfork #define in libraries/base/cbits/{system.c,rawSystem.c}, as Irix vfork doesn't appear to be available without some other symbols being present. I will make a bindist available soon. Cheers, Don

10 17