Simon Peyton-Jones
Serge
I take it all back. I've been persuaded that it's best to accept DoCon-sty le instances as they appear, and I've put quite a bit of work into making it so.
So you should not need to change any code. Do try the HEAD (any recent snapshot should do) if you can.
All right, I have tested ghc-6.9.20080910 on docon-2.12-pre. Find the source on http://botik.ru/pub/local/Mechveliani/ghcBugs/docon-2.12-pre.zip It is put there only for testing GHC, and it has the compilation flag denotation in docon.cabal improved for newer Cabal and ghc-6.10. The tet shows the followng. 1. It accepts the DoCon-style overlapping instances (as in docon-2.11) -- in the example of ... => LinSolvRing (Fraction a) that you pointed out below. 2. But in several places DoCon has parasitic additions (similar to the below MulSemigroup (Fraction a)) to the context for overlapping instances. These places are marked in the docon-2.12-pre source with 'overlaps in ghc'. I would like to cancel them, similar as we now cancel the above MulSemigroup (Fraction a) in the context. But ghc-6.9.20080910 does not allow this. So, I wonder: what is the difference? 3. `Making' under -O2 reports for the module Det_.hs several warnings of the kind ... [25 of 83] Compiling Det_ ( Det_.hs, dist/build/Det_.o ) SpecConstr: too many specialisations for one function (see -fspec-constr-count): Function: dt{v X1E1R} [lid] Specialisations: [([sc_s1E2A{v} [lid], sc_s1E2B{v} [lid], ... What might this mean? 4. It has improved: it `makes' docon-2.12 under -O fast enough, without code explosion, the code is as fast as expected. It also `makes' the test Main under -O fast enough (unlike ghc-6.8.3). 5. The same is for -O2. But this does not gain more performance. -O2 -fvia-C also does not gain more performance, but leads to 7 times longer compilation. Anyway, I am satisfied with -O. Regards, ----------------- Serge Mechveliani mechvel@botik.ru ------------------------------------------------------------------- | Good news: I have cured the massive code-explosion problem you | encountere with GHC 6.8. I'm | about to commit a patch for that, so it'll be in GHC 6.10. | | However, I'm now getting a complaint about overlapping instances | (DoCon 2.11). GHC 6.10 is | being a bit more consistent about coherence. Here is one example: | | Fraction.hs:124:48: | Overlapping instances for MulSemigroup (Fraction a) | arising from a use of `inv' at Fraction.hs:124:48-57 | Matching instances: | instance [overlap ok] (GCDRing a) =3D> MulSemigroup (Fraction a) | -- Defined at Fract_.hs:438:9-46 | instance [overlap ok] MulSemigroup (Fraction Integer) | -- Defined at Fraction.hs:260:9-39 | (The choice depends on the instantiation of `a' | To pick the first instance above, use -XIncoherentInstances | when compiling the other instance declarations) | | It's absolutely right! If you wanted the instance for | (MulSemigroup (Fraction Integer)), then | the call to inv could in principle use | MulSemigroup (Fraction Integer) instance, and give | different behaviour. (See the user manual stuff about incoherent- | instances.) | | Possible solutions: | a) add -XAllowIncoherentInstances | b) make the instance declaration look like | instance (MulSemigroup (Fraction a), GCDRing a) => | LinSolvRing (Fraction a) | thereby deferring the choice [..]
Serge D. Mechveliani wrote:
5. The same is for -O2. But this does not gain more performance. -O2 -fvia-C also does not gain more performance, but leads to 7 times longer compilation.
Just to be sure: are you saying that with -O2 the compile time is ok, but when you add -fvia-C it takes 7 times longer? If so, it's probably not a bug (we don't have any control over the speed of gcc). Here's the bug report: http://hackage.haskell.org/trac/ghc/ticket/2609 Sergey, could you clarify please? Cheers, Simon
On Sat, Sep 20, 2008 at 11:25:57AM +0100, Simon Marlow wrote:
Serge D. Mechveliani wrote:
5. The same is for -O2. But this does not gain more performance. -O2 -fvia-C also does not gain more performance, but leads to 7 times longer compilation.
Just to be sure: are you saying that with -O2 the compile time is ok, but when you add -fvia-C it takes 7 times longer? If so, it's probably not a bug (we don't have any control over the speed of gcc). Here's the bug report:
http://hackage.haskell.org/trac/ghc/ticket/2609
Sergey, could you clarify please?
With -O2, the compile time is ok, but when I add -fvia-C, it takes 7 times longer -- this is for ghc-6.9-earlySeptember to compile DoCon-2.12-pre. You do not control over the speed of gcc itself. But a small change in the GHC compiler may, in principle, lead to many times faster compilation by gcc of the code produced by GHC. This may occur some problem in GHC as well as some problem in gcc. This is only my observation, I do not pretend for a bug report in this case. I tried -fvia-C for curiosity: "by occasion, would it increase the code performance?". If this ratio of 7 looks curious to you, you could investigate this. And personally, I am satisfied with -O (without via-C). ------ Sergey
participants (2)
-
Serge D. Mechveliani -
Simon Marlow