Re: New Class architecture for your consideration

[Ryan Newton]

Oops! Ignore that first one. That was the wrong email address. This
one is correct.

On Wed, Oct 12, 2011 at 10:45 AM, Ryan Newton <rrne...@gmail.com> wrote:
> Hi guys,
>
> I'm copying the mailing list I just made to migrate this thread there.
>
> Cheers,
>  -Ryan
>
>
>
> On Wed, Oct 12, 2011 at 10:40 AM, Ryan Newton <rrne...@gmail.com> wrote:
>> I'm fine with leaving Control.Monad.Par itself just a pointer to a
>> specific default scheduler, not the overloaded version.  I myself am
>> driven nuts by over-typeclassification of a Hackage library I'm trying
>> to learn.  However, I will say that once we move to including the
>> distributed version(s) this will probably require overloading and
>> probably should go in a separate package (monad-par shouldn't depend
>> on cloudhaskell to install).  Also runPar in that case has a type like
>> "Par a -> ProcessM a".
>>
>> I wonder... is there a way with haddock to likewise make the docs for
>> Control.Monad.Par a pointer to another module?  Otherwise I imagine
>> something ugly here just to get the docs in the Control.Monad.Par
>> module.  Under section 3.4.1. of the manual
>> (http://www.haskell.org/haddock/doc/html/ch03s04.html#id565339)
>> touches on this topic but after a brief experimentation it seems that
>> one cannot get documentation into Control.Monad.Par's corresponding
>> HTML file without putting the relevant comments directly in that
>> file...
>>
>> Also there's the question of complex combinators like
>> parMapReduceRangeThreshSource.  Currently those have overloaded
>> interfaces.  Of course they work fine with the default scheduler
>> exported by Control.Monad.Par, but they (and their docs) are contained
>> in Control.Monad.Par.Combinator.
>>
>>> Did you do any measurements comparing the various schedulers?  We made some
>>> improvements in recent GHCs, in particular optimisation of CPS code should
>>> be better than before. (7.2.1 should be better than 7.0.4 in this regard).
>>>  I'm wondering whether my experimental deforested version of the Trace
>>> scheduler is any better than before now.
>>
>> The deforested one was on the "optimise" branch?
>>
>> I'm starting to do scheduler comparisons now.  I want to get the
>> infrastructure fully build-botified.  Because I think only then can I
>> wrap my head around the role of both the GHC version, scheduler, and
>> the HW architecture.
>>
>> For example, I did a benchmark suite run the other day on a 16-core
>> older "Core" architecture and got the mediocre results below.  (I'm
>> accumulating these small text files in a results/ directory in the
>> repo for future data-mining.)
>>
>> # Benchmark, variant, best #threads, best median time, max parallel speedup:
>> # Summary for CoreTigerton_2.93GHz_16core/ghc-7.2.1/results_hulk_2011_10_03_desktop_v1.dat
>>    blackscholes.exe        "10000"    "trace" 15    1.65
>> 9.418181818181818
>>    coins.exe               "8"        "trace" 8     2.02
>> 2.410891089108911
>>    mandel.exe              "2000"     "trace" 4     1.76
>> 1.9318181818181817
>>    matmult/matmult.exe     "768"      "trace" 13    1.96
>> 7.056122448979592
>>    nbody.exe               "13000"    "trace" 16    0.88
>> 7.056818181818182
>>    parfib_monad.exe        "trace"    "trace" 12    7.79
>> 1.6675224646983313
>>    parfib_pseq.exe         "36"       "trace" 7     0.2             3.3
>>    partree/partree.exe     "600"      "trace" 1     3.38            1.0
>>    queens.exe              "14"       "trace" 14    3.15
>> 5.33015873015873
>>    stream/disjoint_working_sets_pipeline.exe "sparks"   "trace" 1
>> 3.35            1.0
>>    sumeuler/sumeuler.exe   "38"       "trace" 16    0.76
>> 7.894736842105263
>>
>> Hmm!
>>
>>  -Ryan
>>
>

[Ryan Newton]

These changes are implemented now. Monad.Control.Par should look just
as before. Let me know if you see anything wrong with it.

Given that Control.Monad.Par is the same as in master, the only substantive
difference in the newClassAPI branch is the factoring of combinators
into Combinator.hs. (The master branch already has garbagey stuff in
ParClass so newClassAPI is a strict improvement.) I therefore propose
to go ahead and merge newClassAPI -> master.

[Simon Marlow]

On 13/10/2011 11:56, Ryan Newton wrote:
> These changes are implemented now. Monad.Control.Par should look just
> as before. Let me know if you see anything wrong with it.
>
> Given that Control.Monad.Par is the same as in master, the only substantive
> difference in the newClassAPI branch is the factoring of combinators
> into Combinator.hs. (The master branch already has garbagey stuff in
> ParClass so newClassAPI is a strict improvement.) I therefore propose
> to go ahead and merge newClassAPI -> master.

Ok, go ahead. I havne't looked at the docs yet, but if any issues arise
with the Control.Monad.Par docs I'm sure we can fix them up.

Cheers,
Simon