[jhc] what to work on next?

[Rick R]

I don't know if you follow haskell cafe, but there was a lot of buzz over a
new iPhone target. for GHC. It apparently took some hacks of the ghc source
to get it into that state. There is a lot of interest in being able to
easily target other platforms, if it supported JVM that would be huge.
Compiling to C/Native for the arm platform would be pretty great as well.

I'm sorry to hear about the region based GC. It would be neat if it worked.
As an idea, it seems like the holy grail of GC. But everyone I've talked to
says that it seems easy at 1st, but bucketing objects into regions seems to
frequently place too much into the global pool.

Timber sports a nice, incremental garbage collector that can be made to
guarantee sub millisecond response times. Perhaps one could take some
inspiration from it as a replacement for the current GC.


On Tue, Jun 23, 2009 at 9:02 PM, John Meacham <john at repetae.net> wrote:

> On Tue, Jun 23, 2009 at 05:29:23PM -0700, Corey O'Connor wrote:
> > Outside of the compiler itself: A JHC equivalent to ghc-pkg would be
> > nice. That, I'd imagine, would require some Cabal library integration.
>
> The equivalent of ghc-pkg is delightfully simple.
>
> to list the packages you have installed, do a
>
> ls ~/lib/jhc
>
> to install new ones, simply do a
>
> cp package.hl ~/lib/jhc
>
> (the ~/lib/jhc is configurable, that is just where I keep my jhc
> packages)
>
> Any hl files in jhc's search path are considered available, jhc has no
> issues with package conflicts as it uses a hash of the API to uniquely
> identify packages, the human readable name is just a convinience.  This
> and the portability of jhc libraries  means the equivilant of something
> like cabal-install would simply be to list the dependencies and 'wget'
> them if they don't exist.
>
> This would probably be a pretty straightforward project if someone
> wanted to work on it, you would just need to add simple hooks to jhc to
> dump a list of package dependencies as hashes, and get the hash-name for
> a given hl file. The downloader could be a separate program then, called
> jhc-pkg.
>
>
> > As for the compiler:
> >
> > 0. The performance of the jhc compiler is sometimes downright slow.
> > Given your description of how JHC works it makes sense why the compile
> > times can be long. Looking into optimizing this would be nice.
>
> Indeed. This is a major issue that I have not payed enough attention
> too. Back when lhc was a fork of jhc they did some very good profiling
> work and found some bottlenecks and I backported their fixes into jhc.
>
> I would love some help here. The makefile should generate a profiled
> build of jhc, just do 'make jhcp'. I have no doubt there are a lot of
> low hanging fruit that can be found and fixed.
>
> > 1. Additional documentation of the compiler source. This isn't much of
> > a problem given the code is quite clear.
>
> Thanks! I tried to make it pretty clear, there are some huge ugly bits,
> but hopefully they are sectioned off. distressingly, Main.hs is one of
> those ugly files which can turn people off if they don't start looking
> in other files. Cleaning up Main would be nice.
>
> >
> > 2. Improved garbage collector? This might just be a documentation
> > issue. The documentation states the region-based garbage collector
> > leaks memory. And the configure script hints at being able to use a
> > standard Boehm garbage collector library. Does the region based
> > garbage collector still have issues? When should one be used over the
> > other?
>
> yeah, to compile with the boehm collector, simply add the -fboehm
> command to the command line when compiling. alternatively you can add a
> gc=boehm line to your targets.ini file to choose the collector on a
> target by target basis.
>
> This probably is the major issue with jhc right now. static analysis is
> fine for short running programs, but no good if your program runs a
> while. boehm works, but is pretty slow. This is tied in to #3 below
> actually. For some potential back ends (JVM,cmm) garbage collection
> becomes a lot easier to implement. So perhaps my time is better spent
> working on alternate back ends, on the other hand, the gcc back end is
> more 'universal' and works pretty well in practice. Now that jhc emits
> loops directly rather than relying on tail calls, GC really is the only
> thing that using gcc hurts.
>
> > 3. Direct code generator instead of relying on the C compiler. In
> > addition to opening up some generated code optimization possibilities
> > this may tie in with #0 above. Perhaps some compiler performance
> > optimizations are only possible with a native code generator?
>
> It probably won't help much with #0, We would still have to perform the
> grin translations to get the code into a form we can send out as
> assembly and actually calling 'gcc' doesn't take much time relative to
> the rest of jhc.
>
> I definitely want to have multiple 'blessed' back ends in jhc. The main
> ones I have been interested in are a c-- back end and at least one 'VM'
> style back end. such as the JVM, .NET, or Dalvik. Dalvik actually looks
> like it might be the easiest, but targeting JVM might be more useful.
>
>
> > I would like to get involved in JHC more and see me mostly able to
> > contribute to #0 and #1. Specifically I plan on attacking #0 and
> > documenting everything I read in the source along the way.
>
>
> That would be excellent!
>
> If you find yourself writing a lot and want to add a chapter to the
> manual, simply add comments like so
>
> {- at ChapterName
>
> markdown formatted text
>
> -}
>
> in the appropriate file then add ChapterName to utils/stitch.prl in the
> list depending on where you want it to go. multiple sections with the
> same chaptername are merged, you can add a section number after the
> chapter name to force an explicit order on the sections during merging.
>
>        John
>
> --
> John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
> _______________________________________________
> jhc mailing list
> jhc at haskell.org
> http://www.haskell.org/mailman/listinfo/jhc
>



-- 
"The greatest obstacle to discovering the shape of the earth, the
continents, and the oceans was not ignorance but the illusion of knowledge."

- Daniel J. Boorstin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/jhc/attachments/20090623/72f5ba4c/attachment-0001.html