- Glasgow-haskell-users

RE: DiffArray Performance
by Simon Marlow 06 Nov '03

06 Nov '03

> > The problem was whether DiffArrays should be thread-safe in the > > Concurrent Haskell sense, which means protecting access to > the DiffArray > > with an MVar. > > Can you give some estimate of the cost of using an MVar in this way? It depends a lot on whether the cost of using the MVar is dwarfed by other costs in the relevant operations. For example, Handles are protected by MVars but this isn't a big deal because you don't usually do lots of tiny operations on a Handle (well, it bites you if you try to implement 'cat' using hGetChar/hPutChar). Compared to an IORef, modifying an MVar is many times more expensive. takeMVar/putMVar are implemented as out-of-line calls, but they could be partially inlined to cover the cases where they don't need to block if efficiency is really critical. > Could some cheaper mechanism be provided for the special case > of a mutex? My guess is that it wouldn't be worth having a special mutex type instead of (MVar ()). Cheers, Simon

1 0

Building GHC on Mac OS X or Fixing readline
by Kennis Koldewyn 05 Nov '03

05 Nov '03

I've attempted to compile GHC 6.01 from sources for Mac OS X, but after a successful configure, make soon grinds to a halt (see "Listing 1" below). I'm looking for either: 1. A brief list of tips and tricks for getting GHC to build on Mac OS X (see "My Mac" below), or 2. A way to fix my broken readline package (see "Listing 2" below). Arthur Baars mentioned on 2003-07-18 (see "Message Link 1" below) that this problem had been fixed in 6.0.1, and the GHC Downloads page mentions that the readline library must be installed. I've installed GHC 6.0.1 using Wolfgang Thaller's Mac OS X package and I (subsequently) installed readline 4.3, but GHCi still panics, and I also tried Arthur's "quick fix" without success. Thanks for any helpful suggestions, - Kennis ----- Kennis Koldewyn (koldewyn(a)cloud9.net) ----- Without computers, it would be virtually impossible for us to accompliowur xow;gkc,mf(&( - Dave Barry ----- Start of Listing 1 ----- ==fptools== make boot - --no-print-directory -r; in /Users/kennis/Downloads/ghc-6.0.1/ghc/utils/ghc-pkg ------------------------------------------------------------------------ /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -cpp -DPKG_TOOL -DWANT_PRETTY Main.hs Package.hs ParsePkgConfLite.hs make all /usr/local/bin/ghc -H16m -O -cpp -DPKG_TOOL -DWANT_PRETTY -c Package.hs -o Package.o -ohi Package.hi Package.hs:1: parse error on input `#' make[4]: *** [Package.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make: *** [build] Error 1 ----- End of Listing 1 ----- ----- Start of My Mac ----- I'm running Mac OS 10.2.8 on an 800 MHz PowerPC G3 12" iBook with 384 MB of memory: [/Users/kennis] uname -a Darwin Voxel.local. 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power Macintosh powerpc [/Users/kennis] gcc --version gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1493) ----- End of My Mac ----- ----- Start of Listing 2 ----- [/Users/kennis] ghci -package util ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package readline ... linking ... /usr/local/lib/ghc-6.0.1/HSreadline.o: unknown symbol `_rl_free_undo_list' ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1): can't load package `readline' ----- End of Listing 2 ----- ----- Message Link 1 ----- http://www.mail-archive.com/glasgow-haskell-users@haskell.org/ msg05041.html ----- End Message Link 1 -----

2 4

RE: DiffArray Performance
by Simon Marlow 05 Nov '03

05 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. Since there seems to have been a bit of confusion in this thread, I thought I ought to clear it up. The issue is not about single vs. multiple CPU operation. GHC only runs code on a single CPU at the moment, due to the difficulties involved in sharing a heavily used resource (the heap) between multiple threads. The problem was whether DiffArrays should be thread-safe in the Concurrent Haskell sense, which means protecting access to the DiffArray with an MVar. Cheers, Simon

2 1

Feature request
by Josef Svenningsson 05 Nov '03

05 Nov '03

Hi, Just a small feature request which has an extremely low priority. When using --show-iface it is potentially useful to be able to print the contents of more than one interface file. Just now I could have had use for such a functionality. As in: ghc --show-iface Foo*.hi Cheers, /Josef

2 1

RE: DiffArray Performance
by Simon Marlow 05 Nov '03

05 Nov '03

> >GHC only runs code on a single CPU at the moment > > Is this true even if compiled with --threaded-rts ? Yes, except that Haskell code may run concurrently with one or more OS threads running C code. The restriction is that there can only be one OS thread running Haskell code at any one time. Cheers, Simon

1 0

RE: DiffArray Performance
by MR K P SCHUPKE 05 Nov '03

05 Nov '03

>GHC only runs code on a single CPU at the moment Is this true even if compiled with --threaded-rts ? regards, Keean Schupke.

1 0

RE: Transmitting Haskell values
by Simon Marlow 05 Nov '03

05 Nov '03

> Simon Marlow wrote: > > Generating a single unified index is entirely possible, > given all the > > .haddock files for the relevant packages. I'll try to get > this into the > > next version of Haddock. > > But only as an option and/or addition, I hope... If index generation was done as a separate operation using the .haddock file, then you have the option of generating a single index for your package or a unified index for multiple packages. There's then the issue of where the index hyperlinks from the documentation should point to. A command-line flag should suffice for redirecting these in the case when you're going to generate a super-index later on. > >>2. Remove the split between "type/class index" and > >>"function/constructor > >>index" in the Haddockish doc-index.html file. > > > > > > Yes, this is also something I'd like to do. > > Hmmm, I actually prefer the current situation: If you don't > even know if you > should look for a type or a function, you probably have more > trouble than > just two indices... :-] I'm afraid you're in the minority here, most people would prefer a single index it seems. Isn't it easier to just look in a single index rather than having to think about whether you're looking for a type or function first? > >>3. Some links in the indexes are bold, others aren't. > > > > > > The bold ones represent the *original* defining module for > the entity, > > as compared to a module which just re-exports it. However, > knowing this > > information isn't very useful, and arguably it shouldn't be > displayed to > > the user at all. I'll change this for the next Haddock version. > > Again, I like the current situation, it saves you the trouble > to look into > simple "collecting modulues" (doing only imports and > re-exports) by giving > the user a clue where the documentation is. The documentation should be at the end of *all* of the index links. But I've just noticed a bug: if an entity is re-exported by 'module M', then it still gets an index entry with a hyperlink for that module. I'll fix that to remove the hyperlink - would that address your complaint? Cheers, Simon

1 0

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