December 2004 - Glasgow-haskell-users

RE: did util.memo vanish?
by Simon Marlow 08 Dec '04

08 Dec '04

On 08 December 2004 09:10, Adam Megacz wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> It's still there in module Memo, in the util package. It's scheduled >> for demolition in 6.6. > > Huh... why? It's pretty convenient, especially if you're aware of the > relevant GC issues and don't mind them.... although I do wish that > there were a version of type > > (Storable a, Eq a) => (a -> b) -> (a -> b) > > that would use hash-the-bitserialized-representation equality rather > than pointer/stableName equality. No particularly good reason; my impression is that it isn't used much, performance isn't that great, and it's only of limited applicability (i.e. when you want to use pointer equality rather than any other kind of equality over keys). It needs to be moved into the hierarchical libs somewhere, of course. Cheers, Simon

1 0

RE: did util.memo vanish?
by Simon Marlow 08 Dec '04

08 Dec '04

On 06 December 2004 06:03, Adam Megacz wrote: > Hrm, is the GHC "magic memo function" still around? In 5.0.4 it was > in util, but I can't seem to find it in 6.2.2. It's still there in module Memo, in the util package. It's scheduled for demolition in 6.6. Cheers, Simon

2 1

RE: building cygwin
by Simon Marlow 07 Dec '04

07 Dec '04

On 06 December 2004 21:31, Sven Panne wrote: > Hmmm, having some fragile OS-dependent #ifdefs is not the way to go. > While you are there, every > > #ifdef mingw32_TARGET_OS > > which needs to be changed should be replaced by something > feature-specific like > > #if HAVE_FOO_BAR_FUNCTION Good point, thanks Sven. Simon

1 0

RE: building cygwin
by Simon Marlow 07 Dec '04

07 Dec '04

On 04 December 2004 01:49, Ben Kavanagh wrote: > I'm going to create a standard dist for cygwin. > > In order to do so, according to the porting guide I need to build a > set of .hc files with mingw32(same hardware) and then use hc-build > with those. To create the hc files from mingw32 for use with cygwin I > should just have to define toplevel build.mk as follows is that > correct? > > > GhcLibHcOpts += -keep-hc-files > GhcStage1HcOpts += -keep-hc-files > GhcStage2HcOpts += -keep-hc-files Yes, I think so. > and then use 'find' to pull out all of the .hc files. The target "hc-file-bundle" in the top-level Makefile should do the right thing. > After that It should be fairly simple to get a Cygwin build going > right? -Ben I doubt it'll be trivial - probably lots of #ifdef mingw32_TARGET_OS will need to change to #if defined(mingw32_TARGET_OS) || defined(cygwin_TARGET_OS) but there shouldn't be any major new code to write. I'd proceed by grepping for mingw32_TARGET_OS and checking each one to see whether it should change, otherwise you could end up with hard-to-find bugs that show up months later. Cheers, Simon

2 1

RE: A question about the "awkward squad"
by Simon Marlow 06 Dec '04

06 Dec '04

On 06 December 2004 13:25, Simon Peyton-Jones wrote: >>> and is it (still?) true that GHC never expands them? >> >> I'm not sure if GHC guarantees never to duplicate a redex, Simon PJ >> might know. > > Yes, it's very careful not to duplicate a redex, except for ones of > known bounded size, like x +# y, where sharing the work costs more > than duplicating int. I seem to recall that redexes of "known bounded size" includes case z of (a,b) -> e right? We sometimes push case expressions inside lambdas to bring lambdas together, for example. Cheers, Simon

1 0

RE: A question about the "awkward squad"
by Simon Peyton-Jones 06 Dec '04

06 Dec '04

| > and is it (still?) true that GHC never expands them? | | I'm not sure if GHC guarantees never to duplicate a redex, Simon PJ | might know. Yes, it's very careful not to duplicate a redex, except for ones of known bounded size, like x +# y, where sharing the work costs more than duplicating int. But I'd advise against relying on this guarantee, because it's a pragmatic one rather than a semantic one. Simon

1 0

RE: A question about the "awkward squad"
by Simon Marlow 06 Dec '04

06 Dec '04

On 04 December 2004 04:27, Judah Jacobson wrote: > What exactly are redex's, in this context, Any expression which can be beta-reduced or case-reduced. > and is it (still?) true that GHC never expands them? I'm not sure if GHC guarantees never to duplicate a redex, Simon PJ might know. > Or are there certain types of redex's > that aren't? Or is it just really complicated? :-) For example, if I > understand this right, does it mean that in the classic top-level > unsafePerformIO+NOINLINE hack, the NOINLINE is actually unnecessary in > some or all cases? Probably, yes. The reason being that currently unsafePeformIO itself is marked NOINLINE, so GHC can't see its definition, so it won't ever duplicate an expression of the form (unsafePerformIO e) because that would duplicate an unbounded amount of work. The NOINLINE pragma is useful documentation, though. Cheers, Simon

1 0

did util.memo vanish?
by Adam Megacz 06 Dec '04

06 Dec '04

Hrm, is the GHC "magic memo function" still around? In 5.0.4 it was in util, but I can't seem to find it in 6.2.2. - a -- I wrote my own mail server and it still has a few bugs. If you send me a message and it bounces, please forward the bounce message to megacz(a)gmail.com. Thanks!

1 0

Speed of simple operations with Ptr Word32s
by Ian Lynagh 05 Dec '04

05 Dec '04

Hi all, I was under the impression that simple code like the below, which swaps the endianness of a block of data, ought to be near C speed: -----8<----------8<----------8<----------8<----- module Main (main) where import Word (Word32) import Foreign.Ptr (Ptr) import Foreign.Marshal.Array (mallocArray, advancePtr) import Foreign.Storable (peek, poke) import Bits ((.|.), (.&.), shiftL, shiftR) main :: IO () main = do p <- mallocArray 104857600 foo p 104857600 foo :: Ptr Word32 -> Int -> IO () foo p i | p `seq` i `seq` False = undefined foo _ 0 = return () foo p n = do x <- peek p poke p (shiftL x 24 .|. shiftL (x .&. 0xff00) 8 .|. (shiftR x 8 .&. 0xff00) .|. shiftR x 24) foo (p `advancePtr` 1) (n - 1) -----8<----------8<----------8<----------8<----- However, against this equally simple C code it doesn't fair too well: -----8<----------8<----------8<----------8<----- #include <stdint.h> #include <stdio.h> #include <stdlib.h> int main(void) { uint32_t *p32; int i; p32 = malloc(104857600 * sizeof(uint32_t)); for (i = 0; i < 104857600; i++, p32++) { *p32 = ((*p32 << 24) | ((*p32 & 0xff00) << 8) | ((*p32 >> 8) & 0xff00) | (*p32 >> 24)); } return 0; } -----8<----------8<----------8<----------8<----- $ cat runme.sh rm -f *.o *.hi c H gcc -Wall -O2 c.c -o opt_c gcc -Wall c.c -o c ghc -Wall -O2 H.hs -o H rm -f *.o *.hi ghc -Wall -O2 H.hs -o Hsf -funbox-strict-fields for i in opt_c c H Hsf; do echo $i; /usr/bin/time ./$i; done rm -f *.o *.hi c H $ ./runme.sh opt_c 1.14user 0.40system 0:01.55elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+204888minor)pagefaults 0swaps c 1.47user 0.43system 0:01.90elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+204888minor)pagefaults 0swaps H 6.75user 0.42system 0:07.18elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+204974minor)pagefaults 0swaps Hsf 6.76user 0.41system 0:07.18elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+204974minor)pagefaults 0swaps so we're 3.5-6 times slower, depending on which numbers you want to use. Is there anything I can do to get better performance in this sort of code without resorting to calling out to C? Thanks Ian

3 2

A question about the "awkward squad"
by Judah Jacobson 04 Dec '04

04 Dec '04

Hi, I was reading SPJ's excellent "Tackling the Awkward Squad" paper, which (among other things) uses the operational semantics POV for describing IO formally. It notes at the end of section 2.8 that the implementation type IO a = State -> (a, State) is "a bit of a hack. Why? Because it relies for its correctness on the fact that the compiler never duplicates a redex...In practice, GHC is careful never to duplicate an expression whose duplication might give rise to extra work (a redex)." The paper also gives an example of how a compiler might apply an expansion which is correct according to the above representation but incorrect semantically. What exactly are redex's, in this context, and is it (still?) true that GHC never expands them? Or are there certain types of redex's that aren't? Or is it just really complicated? :-) For example, if I understand this right, does it mean that in the classic top-level unsafePerformIO+NOINLINE hack, the NOINLINE is actually unnecessary in some or all cases? Not to start yet another long TWI debate here...but I do think that this issue of balance between clean outer operational semantics and inner hackery is very interesting as a matter of language design. Thanks in advance, -Judah

1 0