On Wed, Jul 30, 2008 at 6:55 AM, zooko <[EMAIL PROTECTED]> wrote: > On Jul 30, 2008, at 7:38 AM, Eric Kow wrote: > > > [b] on a practical front, darcs2 is slower than darcs1 on some stuff. > > It deals *much* better with conflicts (much reduced risk of > > exponential blowup), but day-to-day things are slow enough to be > > annoying > > Could you point us to some of the tickets which are/were most > frustrating to the GHC developers? > > I'm a darcs-2 user, and the performance is acceptable for me, and > dramatically better than darcs-1 for one of my common use cases (a > darcs get of a whole large repository when more or less all the > patches are already in darcs-2's local cache). > > I'm not sure if the darcs-2 performance is acceptable to my > programming partners. If they complain, I will try to open a ticket > showing exactly what is dissatisfying to them.
The GHC devs have been really good about reporting their problems. They found that darcs2 overall performance was inferior to darcs1 and didn't want to convert their repository. Which is too bad, because we have reason to believe switching would solve most, if not all, of their showstopper problems. I have the idea that darcs-2 has not yet benefitted from newly > developed Haskell tools such as profilers. Actually, GHC has a good profiler. Although, I'm not sure if the profiler tracks correctly the performance effects of using mmap which is quite important to correctly optimizing the IO effeciency of Darcs. Ian made a tool to help with this, but I doubt anyone has used it recently. In response to Patrick Waugh's comments, I would *like* to think that > Haskell programs can be optimized at least as well as C++ programs > can be, but I guess this remains to be empirically determined. If micro-benchmarks can be allowed to speak as empirical evidence we could look at the Great Programming Language Shootout: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all As you can see from that, at least on optimized toy problems Haskell performance is better than many candidates and not too far behind C++. It certainly convinces me that it's a myth to say Haskell, especially with GHC, is inherintly slow/inefficient. Note that GHC Haskell almost ties with the fastest Java implementation in the list and does tie with the Intel Fortran entries. It would be interesting to hear people complain that Intel's Fortran implementation is inherently slow! I'm completely convinced that any performance problems with Darcs is due to architecture and not due to GHC/Haskell. As you and Eric say, more profiling would be good. Jason
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
