February 2008 - jhc - Haskell.org

Substitutions.
by Lemmih 28 Feb '08

28 Feb '08

Hiya, I've encountered something I don't understand in E.Subst. The substitution routine is very eager to inline stuff. It inlines all the simple applications it can find. Consider the following example: (\a -> a+a) expensive The substitution routine will inline that to: expensive+expensive Wouldn't it be prudent to generate this instead: let a = expensive in a + a Whether to inline it further would be decided later on. -- Cheers, Lemmih

3 5

Occurance collection.
by Lemmih 26 Feb '08

26 Feb '08

Hiya, In E.SSimplify.collectOccurance the 'arg' function is used quite often and I can't tell why. The function clears usage information for free variables and is primarily used for types. It would be a great help if you'd add a short description to collectOccurance and collectDs. Any information about invariants and/or what they're trying to do would be appreciated. -- Cheers, Lemmih

2 1

Threading and atoms.
by Lemmih 23 Feb '08

23 Feb '08

Hiya, When I use -threaded and -N2 in jhc, atoms fail in spectacular ways. So far I've seen: >>> internal error: fullCheck': Instance@.iJhc.Monad.return.Jhc.Prim.IO x6598 Strong': ? x6598 Cannot strong: (?, [x6598]) and: stringlib: error alocating memory Are atoms in some way not thread-safe enough? -- Cheers, Lemmih

3 5

darcs patch: Fix bug in E.Subst.
by Lemmih 23 Feb '08

23 Feb '08

Sat Feb 23 15:00:47 CET 2008 Lemmih <lemmih(a)gmail.com> * Fix bug in E.Subst.

1 0

darcs patch: Cache a few items, this gives a 20% speed bump.
by Lemmih 22 Feb '08

22 Feb '08

Fri Feb 22 12:59:49 CET 2008 Lemmih <lemmih(a)gmail.com> * Cache a few items, this gives a 20% speed bump.

1 0

darcs patch: Use an IdMap in E.Demand. This gives an 18% speed-up a...
by Lemmih 22 Feb '08

22 Feb '08

Fri Feb 22 03:14:45 CET 2008 Lemmih <lemmih(a)gmail.com> * Use an IdMap in E.Demand. This gives an 18% speed-up and smaller ho files.

2 1

Atoms, Infos and unique ids.
by Lemmih 22 Feb '08

22 Feb '08

Hiya, TVr's can be large and are duplicated many times over. We avoid duplicating Info and type information by clearing all variables and restoring them from their binding point. Atoms are very similar to Infos in this regard: they're large enough that we don't want to keep multiple copies around. However, atoms are currently dealt with in an unsafe (see 'getMap') and inefficient manner (10mb (40%) in base-1.0.hl is wasted on duplicate strings). It is my understanding that atoms could be stored exactly like Infos. I tried to implement this but, unfortunately, atoms are frequently being relied on for unique ids. Some cases are easy to fix, others less so. John, do you have time to document the intended behavior in the difficult cases? -- Cheers, Lemmih

2 9

jhc backend
by Csaba Hruska 21 Feb '08

21 Feb '08

Hi! Will jhc strictly generate only c code ? I know the llvm compiler framework (llvm.org) and what do you think of using llvm for (imperative) backend instead of current c backend. LLVM can generate c code too and it supports many platforms (X86, IA64, SPARC, ARM, MIPS, SPU, POWERPC) and also handles all platform specific stuff. LLVM uses an intermediate language (typed risk lile language), and uses SSA form. Many optimizations can be done via llvm. and llvm supports JIT (Just In Time ) compilationm, taht can be useful for interactive (interpreters) use of haskell. any opinion ? Cheers, Csaba Hruska P.S.: I'm new here so let me to introduce: My name is Csaba Hruska, i'm in the 5th year in university (BME budapest, hungary). i'm studiyng computer science.

2 1

darcs patch: Makefile wibbles for jhcp and *.hsc
by Lemmih 21 Feb '08

21 Feb '08

Wed Feb 20 19:49:10 CET 2008 Lemmih <lemmih(a)gmail.com> * Makefile wibbles for jhcp and *.hsc

1 0

darcs patch: Cache scoping info, avoid unnecessary maps. (and 2 more)
by Lemmih 21 Feb '08

21 Feb '08

Tue Feb 19 16:14:10 CET 2008 Lemmih <lemmih(a)gmail.com> * Cache scoping info, avoid unnecessary maps. Tue Feb 19 16:15:54 CET 2008 Lemmih <lemmih(a)gmail.com> * Remove debug code. Wed Feb 20 19:40:27 CET 2008 Lemmih <lemmih(a)gmail.com> * Add a comment describing the function of E.Subst.

1 0

Hotspots.
by Lemmih 20 Feb '08

20 Feb '08

Greetings, I've found a few hotspots that'll be working on. I'd be very interested in discussing solutions. Performance flaws: * IdMaps are used to generate new ids. * Ho files contain huge amounts of duplicate information. * Ho files aren't saved lazily. * C code is used for generating atoms. Repeatedly mapping variables to 'const Nothing' is very expensive. It is currently the most expensive procedure in Jhc, taking ~20% CPU time when compiling the base library. The base library contains 65 megabytes of uncompressed data. Most of that is duplicate information that disappears when it is compressed. However, parsing that amount of data takes considerable time. Ho files are completely serialized before they're written to disk. Using C code for generating atoms results in no performance improvement. There are only a few cases where using C is beneficial and this is not one of them. -- Cheers, Lemmih

2 3

Infos.
by Lemmih 20 Feb '08

20 Feb '08

Hi, In Ho/Build.hs, TVr's are stripped of Type and Info information before the Ho files are saved. I experimented with omitting Info information when saving TVr's and everything appeared to work as expected. Is there some corner case where saving the Info list is necessary? -- Cheers, Lemmih

2 1

Optimization.
by Lemmih 19 Feb '08

19 Feb '08

Greetings, The attached patch is a two-step optimization: 1) Only call 'getType' 100,000,000 times instead of 600,000,000 times. 2) Greatly simplify the actual loop. Without this patch, compiling base-1.0.hl takes 19 minutes. With this patch, compile time is down to 11 minutes. Feedback would be greatly appreciated. -- Cheers, Lemmih

3 9

Re: Ids in Jhc.
by John Meacham 16 Feb '08

16 Feb '08

(I'm gonna forward this response to the jhc list too, if that's okay) On Thu, Feb 14, 2008 at 12:26:49AM +0100, Lemmih wrote: > I've been wondering about your use of Ids in Jhc. > As far as I can see, the rules for Ids goes as following: > * named ids are odd > * unnamed ids are even > * id '0' has special significance. > > Can you tell me a bit about how unnamed ids are used, why id '0' has > special meaning, and how you generate new, unique unnamed ids. Yes. that is correct. named and unnamed ids behave the same way, except named ids get a pretty name when printed out as opposed to just a numebr and are generally derived from a user supplied name. Also, all 'top level' names are always 'named' to ensure they remain globally unique. named Ids are odd, these are looked up in a table that is implemented via a hash table written in c in the StringTable/ directory. due to an intentional quirk of its implementation, it only generates odd, positive values. Conversion between a number and its string form is constant time in both directions. zero is a 'special' id in that it can be treated normally except it can never appear in an expression, only in a binder. so \ v0 -> ... is okay, but \ x -> .. v0 ... is not. This means you can always use 0 as a binder when you know a value is not used without worrying about shadowing a real definition. unnamed ids are arbitrary positive even numbers, there is no particular need to allocate them in a special way, they are _not_ globally unique so you just need to ensure you don't shadow any existing variables when assigning new ones. in general, this consists of having a set of 'in scope' names (which is often something you need to keep track of anyway) and you choose some value that is not in the 'in scope' set and add it to the set. this ensures ids don't shadow each other, but not that they are unique. negative ids are used inside of a few specialized routines internally and should never make it out into the world. for instance, in the unification algorithm they are used to represent alpha-renamed values so we don't need to scan for used names before hand, however the terms returned have their original ids restored. hope this helps... It is quite bothersome to me that 'Id' is just an Int and not a newtype... that is something I have been slowing getting the code ready to fix for a while now.. John -- John Meacham - ⑆repetae.net⑆john⑈

3 12

Darcs patch.
by Lemmih 14 Feb '08

14 Feb '08

The latests broke the makefile rule for jhcp. -- Cheers, Lemmih

1 0