November 2003 - Glasgow-haskell-users

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

06 Nov '03

>This is one good reason they have to be protected by MVars Forgive my stupidity, but arn't the MVar operations (takeMVar, putMVar) IO operation, therefore the locks must be in the IO monad, therefore the code acting on the DiffArray should be in the IO monad... otherwise they can't use the MVar calls? Regards, Keean Schupke.

1 0

RE: DiffArray Performance
by Simon Marlow 06 Nov '03

06 Nov '03

> Could you not provide MVar free calls for use inside a > withMVar function, > minimising locking overhead? Are you suggesting something like withDiffArray :: DiffArray ix e -> (UnlockedDiffArray ix e -> IO a) -> IO a and then a bunch of fast operations on UnlockedDiffArray? The problem with this is that DiffArrays live in the pure world, not the IO world. This is one good reason they have to be protected by MVars: the imperative oeprations happen behind the scenes, so the programmer gets no chance to do his own locking or otherwise ensure that the DiffArray is uesd safely. Functions like withDiffArray don't work too well in the pure world, because you have to arrange that the "inner" part is fully deepSeq'd before you can release the lock. Cheers, Simon

1 0

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

06 Nov '03

Could you not provide MVar free calls for use inside a withMVar function, minimising locking overhead? Keean Schupke.

1 0

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