- Haskell-Cafe - Haskell.org

RE: GHC optimization issue
by Simon Peyton-Jones 29 Dec '05

29 Dec '05

I did look into this a little. There are several things going on * GHC doesn't really expect you to use INLINE and SPECIALISE together. INLINE says to inline a copy of the function at every call site, which is the best possible form of specialisation, so SPECIALISE is a bit redundant if you are happy to do that. (Incidentally, INLINE is ignored for recursive functions, whereas SPECIALISE works fine.) * If you have both INLINE and SPECIALISE, GHC makes a specialised copy of the function, and the specialised copy takes precedence. So a call at the specialised type turns into a call to the specialised function. (A call at any other type would not use the specialisation, and so the un-specialised function would be inlined.) Moreover, the specialised copies are themselves not marked INLINE. * GHC's HEAD in CVS (i.e 6.5) has a new feature {#- SPECIALISE INLINE f :: <type> #-} which tells GHC to specialise f and inline the specialised copy (only). Ordinary, un-specialised calls will not be inlined. * When you delete the pragmas, GHC uses a size-based heuristic to decide when to inline a function at a call site. Oddly, this heuristic decides (just) to inline the un-specialised function, but when it's specialised GHC thinks it's bigger and doesn't inline it. You can increase the threshold for inlining with -funfolding-use-threshold=20, say. http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise .html#options-f This really is a bit odd, but I don't want to fiddle with GHC's inlining heuristics without doing lots of benchmark runs etc. Actually, it'd be quite an easy thing for others to try fiddling with, and I bet there are performance gains to be had. Simon | -----Original Message----- | From: Joel Reymont [mailto:joelr1@gmail.com] | Sent: 22 December 2005 14:09 | To: Haskell-Cafe Cafe | Cc: Simon Peyton-Jones; Simon Marlow | Subject: GHC optimization issue | | Folks, | | I have been trying to improve my byte swapping routines as part of my | effort to speed up serialization. I then tried to look at the core | output from GHC to see what it was converting my code into. Brandon | (skew on #haskell) helped me code a TH version but then I went with a | regular CPP version instead. | | The point of contention is that the logical approach to optimization | does not produce expected results. The only difference between the | following two core outputs is the presence or absence of specialize | and inline pragmas. The code is the same. | | The version without pragmas inlines foo1 into | | Main.foo1 :: GHC.Word.Word16 | [GlobalId] | [Str: DmdType] | Main.foo1 = case GHC.Word.Word16 GHC.Word.$wshift3 __word 3855 (-8) | of ww1_a2eo { __DEFAULT -> | case GHC.Word.Word16 GHC.Word.$wshift3 __word 15 8 of | ww_a2f4 { __DEFAULT -> | GHC.Word.W16# (GHC.Prim.narrow16Word# | (GHC.Prim.plusWord# ww1_a2eo ww_a2f4)) | } | } | | Whereas the version _with_ pragmas produces a function call: | | Main.foo1 :: GHC.Word.Word16 | [GlobalId] | [Str: DmdType] | Main.foo1 = case GHC.Word.Word16 Swap1.$w$sswap16 __word 3855 | of ww1_s1Ia { __DEFAULT -> | GHC.Word.W16# ww1_s1Ia | } | | Is there a reasonable explanation? | | Both versions compiled thusly: ghc --make Foo.hs -O -ddump-simpl > foo | | Swap: | | {-# OPTIONS_GHC -fglasgow-exts -cpp #-} | module Swap1 | ( | swap16 | ) | where | | import Data.Word | import Data.Int | import Data.Bits | | #define BIG_ENDIAN 1 | | {-# SPECIALIZE swap16 :: Word16 -> Word16 #-} | {-# SPECIALIZE swap16 :: Int16 -> Int16 #-} | {-# INLINE swap16 #-} | | swap16 :: Bits a => a -> a | #ifdef BIG_ENDIAN | swap16 v = (v `shiftR` 8) + ((v .&. 0xFF) `shiftL` 8) | #else | swap16 v = v | #endif | | Foo: | | module Main where | | import Data.Word | import Swap1 | | foo1 :: Word16 | foo1 = swap16 0x0f0f | | main = putStrLn $ show foo1 | | Core output for the version WITH pragmas, see the version w/o pragmas | way below | | ==================== Tidy Core Rules ==================== | "SPEC Swap1.swap16" __forall {$dBits_X1Co :: {Data.Bits.Bits | GHC.Int.Int16}} | Swap1.swap16 @ GHC.Int.Int16 $dBits_X1Co | = Swap1.$sswap16 ; | "SPEC Swap1.swap16" __forall {$dBits_X1Cv :: {Data.Bits.Bits | GHC.Word.Word16}} | Swap1.swap16 @ GHC.Word.Word16 $dBits_X1Cv | = Swap1.$sswap161 ; | | | ==================== Tidy Core ==================== | Main.foo1 :: GHC.Word.Word16 | [GlobalId] | [Str: DmdType] | Main.foo1 = case GHC.Word.Word16 Swap1.$w$sswap16 __word 3855 | of ww1_s1Ia { __DEFAULT -> | GHC.Word.W16# ww1_s1Ia | } | | ==================== Tidy Core ==================== | Swap1.$w$sswap16 :: GHC.Prim.Word# -> GHC.Prim.Word# | [GlobalId] | [Arity 1 | NoCafRefs | Str: DmdType L] | Swap1.$w$sswap16 = \ (ww_s1I5 :: GHC.Prim.Word#) -> | case GHC.Prim.Word# GHC.Word.$wshift3 ww_s1I5 | (-8) of ww1_a1Gx { __DEFAULT -> | case GHC.Prim.Word# GHC.Word.$wshift3 | (GHC.Prim.and# ww_s1I5 __word 255) 8 | of ww11_a1Hd { __DEFAULT -> | GHC.Prim.narrow16Word# (GHC.Prim.plusWord# | ww1_a1Gx ww11_a1Hd) | } | } | | Swap1.$w$sswap161 :: GHC.Prim.Int# -> GHC.Prim.Int# | [GlobalId] | [Arity 1 | NoCafRefs | Str: DmdType L] | Swap1.$w$sswap161 = \ (ww_s1HV :: GHC.Prim.Int#) -> | case GHC.Prim.Int# GHC.Int.$wshift2 ww_s1HV | (-8) of ww1_a1Fk { __DEFAULT -> | case GHC.Prim.Int# GHC.Int.$wshift2 | (GHC.Prim.word2Int# | (GHC.Prim.and# (GHC.Prim.int2Word# ww_s1HV) __word 255)) | 8 | of ww11_a1G5 { __DEFAULT -> | GHC.Prim.narrow16Int# (GHC.Prim.+# ww1_a1Fk | ww11_a1G5) | } | } | | Swap1.$sswap16 :: GHC.Int.Int16 -> GHC.Int.Int16 | [GlobalId] | [Arity 1 | Worker Swap1.$w$sswap161 | NoCafRefs | Str: DmdType U(L)m] | Swap1.$sswap16 = __inline_me (\ (w_s1HT :: GHC.Int.Int16) -> | case GHC.Int.Int16 w_s1HT of w1_X1I5 | { GHC.Int.I16# ww_s1HV -> | case GHC.Int.Int16 Swap1.$w$sswap161 | ww_s1HV of ww1_s1I0 { __DEFAULT -> | GHC.Int.I16# ww1_s1I0 | } | }) | | Swap1.$sswap161 :: GHC.Word.Word16 -> GHC.Word.Word16 | [GlobalId] | [Arity 1 | Worker Swap1.$w$sswap16 | NoCafRefs | Str: DmdType U(L)m] | Swap1.$sswap161 = __inline_me (\ (w_s1I3 :: GHC.Word.Word16) -> | case GHC.Word.Word16 w_s1I3 of | w1_X1Ih { GHC.Word.W16# ww_s1I5 -> | case GHC.Word.Word16 Swap1.$w | $sswap16 ww_s1I5 of ww1_s1Ia { __DEFAULT -> | GHC.Word.W16# ww1_s1Ia | } | }) | | Swap1.swap16 :: forall a_a1aQ. (Data.Bits.Bits a_a1aQ) => a_a1aQ -> | a_a1aQ | [GlobalId] | [Arity 1 | NoCafRefs | Str: DmdType L] | Swap1.swap16 = __inline_me (\ (@ a_a1dB) | ($dBits_a1ip :: {Data.Bits.Bits | a_a1dB}) -> | let { | $dNum_s1BO :: {GHC.Num.Num a_a1dB} | [Str: DmdType {a1ip->U | (SAAAAAAAAAAAAAAAAA)}] | $dNum_s1BO = Data.Bits.$p1Bits @ | a_a1dB $dBits_a1ip } in | let { | lit_s1BN :: a_a1dB | [Str: DmdType {a1ip->U | (SAAAAAAAAAAAAAAAAA) s1BO->U(AAAAAAAAS)}] | lit_s1BN = GHC.Num.fromInteger @ | a_a1dB $dNum_s1BO (GHC.Num.S# 255) | } in | \ (v_a1aW :: a_a1dB) -> | GHC.Num.+ | @ a_a1dB | $dNum_s1BO | (Data.Bits.shiftR @ a_a1dB | $dBits_a1ip v_a1aW (GHC.Base.I# 8)) | (Data.Bits.shiftL | @ a_a1dB | $dBits_a1ip | (Data.Bits..&. @ a_a1dB | $dBits_a1ip v_a1aW lit_s1BN) | (GHC.Base.I# 8))) | | | Core output without pragmas: | | Main.foo1 :: GHC.Word.Word16 | [GlobalId] | [Str: DmdType] | Main.foo1 = case GHC.Word.Word16 GHC.Word.$wshift3 __word 3855 (-8) | of ww1_a2eo { __DEFAULT -> | case GHC.Word.Word16 GHC.Word.$wshift3 __word 15 8 of | ww_a2f4 { __DEFAULT -> | GHC.Word.W16# (GHC.Prim.narrow16Word# | (GHC.Prim.plusWord# ww1_a2eo ww_a2f4)) | } | } | | --- | Swap1.swap16 :: forall a_a1aQ. (Data.Bits.Bits a_a1aQ) => a_a1aQ -> | a_a1aQ | [GlobalId] | [Arity 1 | NoCafRefs | Str: DmdType L] | Swap1.swap16 = \ (@ a_a1dB) ($dBits_a1ip :: {Data.Bits.Bits a_a1dB}) -> | let { | $dNum_s1BK :: {GHC.Num.Num a_a1dB} | [Str: DmdType] | $dNum_s1BK = case {GHC.Num.Num a_a1dB} $dBits_a1ip | of tpl_B1 { Data.Bits.:DBits tpl1_B2 | tpl2_B3 tpl3_B4 tpl4_B5 tpl5_B6 tpl6_B7 tpl7_B8 tpl8_B9 tpl9_Ba | tpl10_Bb tpl11_Bc tpl12_Bd tpl13_Be tpl14_Bf tpl15_Bg tpl16_Bh | tpl17_Bi tpl18_Bj -> | tpl1_B2 | } } in | let { | lit_s1BM :: a_a1dB | [Str: DmdType] | lit_s1BM = case a_a1dB $dNum_s1BK | of tpl_B1 { GHC.Num.:DNum tpl1_B2 | tpl2_B3 tpl3_B4 tpl4_B5 tpl5_B6 tpl6_B7 tpl7_B8 tpl8_B9 tpl9_Ba -> | tpl9_Ba Swap1.lvl1 | } | } in | \ (v_a1aW :: a_a1dB) -> | tpl3_B4 | (case a_a1dB $dBits_a1ip | of tpl10_Xy { Data.Bits.:DBits tpl11_XB | tpl12_XD tpl13_XF tpl14_XH tpl15_XJ tpl16_XL tpl17_XN tpl18_XP | tpl19_XR tpl20_Bb tpl21_Bc tpl22_Bd tpl23_Be tpl24_Bf tpl25_Bg | tpl26_Bh tpl27_Bi tpl28_Bj -> | tpl26_Bh v_a1aW Swap1.lvl | }) | (case a_a1dB $dBits_a1ip | of tpl10_Xy { Data.Bits.:DBits tpl11_XB | tpl12_XD tpl13_XF tpl14_XH tpl15_XJ tpl16_XL tpl17_XN tpl18_XP | tpl19_XR tpl20_Bb tpl21_Bc tpl22_Bd tpl23_Be tpl24_Bf tpl25_Bg | tpl26_Bh tpl27_Bi tpl28_Bj -> | tpl25_Bg (tpl12_XD v_a1aW lit_s1BM) Swap1.lvl | }) | | -- | http://wagerlabs.com/ | | | |

1 0

RE: Erlang vs. Haskell (was Re: [Haskell-cafe] binary IO)
by Simon Peyton-Jones 29 Dec '05

29 Dec '05

| Using Haskell for this networking app forced me to focus on all the | issues _but_ the business logic. Type constraints, binary IO and | serialization, minimizing memory use and fighting laziness, timers, | tweaking concurrency and setting up message channels, you name it. That's a disappointing result. Mostly I think Haskell lets you precisely focus on the logic of your program, because lots else is taken care of behind the scenes. You found precisely the reverse. It'd be interesting to understand which of these issues are - language issues - library issues - compiler/run-time issues My (ill-informed) hypothesis is that better libraries would have solved much of your problems. A good example is a fast, generic serialisation library. If you felt able (sometime) to distil your experience under headings like the above, only more concretely and precisely, I think it might help to motivate Haskellers to start solving them. Simon

1 0

RE: [Haskell-cafe] Re: Haskell Speed
by Branimir Maksimovic 28 Dec '05

28 Dec '05

>From: Isaac Gouy <igouy(a)yahoo.com> >To: haskell-cafe(a)haskell.org >Subject: [Haskell-cafe] Re: Haskell Speed >Date: Tue, 27 Dec 2005 20:12:01 -0800 (PST) > >Branimir Maksimovic wrote: > > Of course, first example uses [String] instead of >Data.HashTable > > as other languages do. Imagine C program does not >use > > hash,rather list, how it will perform:) > >And the author comments his program >-- This is a purely functional solution to the >problem. >-- An alternative which keeps a mutable table of >occurences would >-- be faster. > Yes, I saw that but that does not qualifies for benchmark with hash tables. I mean program is ok, but this is aplles to oranges. >We'll be happy to also show a Haskell program that >uses Data.HashTable - first, someone needs to >contribute that program. Ok , i've attached hash table version. As I'm Haskell newbie I suppose there is someone which can do much better. > > > > I didn't look further after that. > >Ideal - you may criticize without the risk that others >will criticize what you do. Attachment follows, you can cricize my poor Haskell skills as much you want :) This version si actually D program trnslated to Haskell + file parsing code from original Haskell program. Now wou can compare no matter how slow it is :) Greetings, Bane. _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0

Shared/Exclusive Locks
by John Goerzen 28 Dec '05

28 Dec '05

Hello, I have the need for a locking object that can provide shared and exclusive locks in much the same manner as the POSIX flock() function. A thread that acquires an exclusive lock has a guarantee that no other thread holds any locks. A thread that acquires a shared lock has a guarantee that no other thread holds an exclusive lock, though any number of other threads hold shared locks. My intuition tells me that this could be implemented in terms of an MVar somehow. (At least, I've used MVars for simple locks for quite some time.) But I can't quite figure out how. Any ideas? Thanks, -- John

4 6

NewBinary on Ptrs
by Pupeno 28 Dec '05

28 Dec '05

Hello, After trying my own code and reading the whole thread I started to understand NewBinary. I'm going to give it a try. My question now is how to turn a Ptr into a BinHandle to use NewBinary on it, or is there another way to do it ? Thanks. -- Pupeno <pupeno(a)pupeno.com> (http://pupeno.com)

2 1

RE: [Haskell-cafe] Haskell vs. Erlang for heavy-duty network apps
by Simon Peyton-Jones 28 Dec '05

28 Dec '05

I've already said to Joel (off-list) how valuable I think his experience of using Haskell for a new kind of real application is. I see no reason in principle why Haskell shouldn't work just fine for his kind of application. But he's pushing hard on parts of the system (both run-time-system and libraries) that have not been as thoroughly exercised as (say) list processing. Quite a few people on the mailing list have helped a lot. My sense is (though I have not followed all the twists and turns) that Joel's experience has exposed immaturity in many of the networking libraries. I hope that people on this list may feel motivated to help improve them. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Joel | Reymont | Sent: 25 December 2005 13:35 | To: Tomasz Zielonka | Cc: haskell-cafe(a)haskell.org; Peter Simons; Bulat Ziganshin | Subject: Re: [Haskell-cafe] Haskell vs. Erlang for heavy-duty network apps | | | On Dec 25, 2005, at 1:14 PM, Tomasz Zielonka wrote: | | > I think your work will be very important and valuable for the | > community. | > You've shown were Haskell could be better, and I believe it will catch | > up eventually, either by improvements in GHC, in libraries or simply | > in documentation. | | Thank you Tomasz! I think eventually will come sooner than you | think :-). | | On my TODO list for the next few weeks: | | 1) Set up a Haskell vs. Erlang heavily-multithreaded serialization | shootout | 2) Work Simon M. to make sure Haskell is on par and try to hack GHC | to add whatever is needed | 3) Add profiling support for STM to GHC (including retainer profiling) | 4) Adapt the Zipper FileServer OS to #1. See if single-threading with | delimited continuations is better than multi-threading with unbound | threads. | 5) If #4 is a yes then investigate why | | And of course I will blog about the whole thing as I go along. | | Thanks, Joel | | -- | http://wagerlabs.com/ | | | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Re: Haskell Speed
by Isaac Gouy 28 Dec '05

28 Dec '05

Branimir Maksimovic wrote: > Of course, first example uses [String] instead of Data.HashTable > as other languages do. Imagine C program does not use > hash,rather list, how it will perform:) And the author comments his program -- This is a purely functional solution to the problem. -- An alternative which keeps a mutable table of occurences would -- be faster. We'll be happy to also show a Haskell program that uses Data.HashTable - first, someone needs to contribute that program. > I didn't look further after that. Ideal - you may criticize without the risk that others will criticize what you do. __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/

1 0

Re: Haskell Speed
by Isaac Gouy 28 Dec '05

28 Dec '05

Jared Updike wrote: > What that means is the results are completely subject to > (1) how good the submission for that tests was Contribute faster more-elegant programs http://shootout.alioth.debian.org/gp4/faq.php#contribute >(2) the choice of tests in the first place Suggest better tests http://shootout.alioth.debian.org/gp4/faq.php#newbench > (3) startup times for loading the binaries into memory (GHC > makes big binaries that are arguably much faster if you do > things in "daemon" mode, for example). Is that just speculation? (Erlang is an application server starting-up and that really is noticeable.) -snip- > it is pretty much a game created to make C win---it already > wins! Which C do you mean - gcc, Intel C, Tiny C? And, no! It is not a game created to make C win (although it is a game). And, no! C does not already win all the games - astonishingly it doesn't even "win" the basic loop and array test nsieve. __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

1 0

Re: Haskell Speed
by Isaac Gouy 28 Dec '05

28 Dec '05

Simon Marlow wrote: > Also, I would like to draw your attention to the fact that GHC > wipes the floor with nearly everyone in the concurrency > benchmark SmartEiffel is so much faster that I'm still trying to figure out if it's doing something different :-) Be interesting to see GHC on the other concurrency benchmark... http://shootout.alioth.debian.org/benchmark.php?test=chameneos&lang=all > Seriously, it's very difficult to draw any meaningful > conclusions from these benchmarks. Is it any easier to draw meaningful conclusions about the relative performance of programming languages from some other benchmarks? __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

1 0

Database mailing list?
by John Goerzen 28 Dec '05

28 Dec '05

Greetings, It seems there are a lot of people working on database-related things in Haskell. HaskellDB, wxHaskell, HDBC, HSQL, etc. I'm wondering if it would make sense to have a haskell-db mailing list to help coordinate efforts? (Or even just to help manage development on these projects without cluttering more general lists) -- John

1 0