Slowness in compiling the library

JasonGross commented 10 years ago

When I compile the library with Coq 8.4 and time how long it takes to make each file, I get

0.10    pathnotations
0.17    topos/epis_monos
0.18    limits/terminal
0.20    limits/initial
0.21    HLevel_n_is_of_hlevel_Sn
0.24    limits/aux_lemmas_HoTT
0.31    category_hset
0.43    whiskering
0.46    auxiliary_lemmas_HoTT
0.70    rezk_completion
0.86    precategories
1.03    yoneda
1.12    limits/cones
1.12    sub_precategories
4.71    equivalences
6.99    functors_transformations
9.29    precomp_fully_faithful
32.22   precomp_ess_surj
69.37   limits/pullbacks

(Admittedly, the HoTT library takes around three times as long, and I don't have a good sense of how complicated the constructions in precomp_ess_surj and limits/pullbacks.)

At least a third of the time in limits/pullbacks, probably much more, is spent checking trivial lemmas which are slow due to nested sigma types. It's plausible that Matthieu's polyproj branch fixes this, but if you're interested in fixing it before that lands for 8.5, you can replace nested sigmas with records (or, possibly just define custom projections for each nested sigma, so that you never use the bare projections from a sigma type).

DanGrayson commented 10 years ago

How do bare projections slow things down?

And don't you have to use each bare projection at least once, to define the corresponding unbare ones?

JasonGross commented 10 years ago

Whenever you use something like apply (pr2 (pr2 (pr1 (pr2 (pr2 Pb) e h k H)))). (PullbackArrow_PullbackPr2), Coq duplicates essentially the entire type of the nested sigma for every single projection. If you Set Printing All and Print PullbackArrow_PullbackPr2, you will see a giant term. Coq is bad at giant terms, and gets slow. If instead you define your projections in parts, with the most general types available, Coq will only see a small term at any given point in time. Coq doesn't care what you use under the hood, it only cares about how big the (non-normalized) term is that it sees. There's some more detail in 2.3 and 2.5 of the paper I'm working on at http://people.csail.mit.edu/jgross/category-coq-experience/category-coq-experience.pdf. ( @benediktahrens, this is the current draft of the paper that I sent you a while ago, and that I mentioned to you more recently as including a comparison of formalizations; it's not done yet, but it's getting close). @DanGrayson, if you do take a look at the sections in that paper and find them unclear, could you let me know?

DanGrayson commented 10 years ago

Thanks for the link to the paper! I looked at 2.3 and 2.5, so it seems I should try out defining total2 as a primitive projection and see if it runs Foundations2, etc., faster under Mathieu's polyproj branch with "Set Primitive Projections". Eta for primitive records already works, and that would be useful, too. But short of doing that, I wonder what your suggestion "define your projections in parts, with the most general types available" actually means!

On Sun, Jan 19, 2014 at 4:18 PM, Jason Gross notifications@github.comwrote:

Whenever you use something like apply (pr2 (pr2 (pr1 (pr2 (pr2 Pb) e h k H)))). (PullbackArrow_PullbackPr2), Coq duplicates essentially the entire type of the nested sigma for every single projection. If you Set Printing All and Print PullbackArrow_PullbackPr2, you will see a giant term. Coq is bad at giant terms, and gets slow. If instead you define your projections in parts, with the most general types available, Coq will only see a small term at any given point in time. Coq doesn't care what you use under the hood, it only cares about how big the (non-normalized) term is that it sees. There's some more detail in 2.3 and 2.5 of the paper I'm working on at http://people.csail.mit.edu/jgross/category-coq-experience/category-coq-experience.pdf. ( @bened! iktahrens https://github.com/benediktahrens, this is the current draft of the paper that I sent you a while ago, and that I mentioned to you more recently as including a comparison of formalizations; it's not done yet, but it's getting close). @DanGraysonhttps://github.com/DanGrayson, if you do take a look at the sections in that paper and find them unclear, could you let me know?

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-32720201 .

JasonGross commented 10 years ago

For example, in the issig tactics, using eta3_sigma:

Definition eta3_sigma `{P : forall (a : A) (b : B a) (c : C a b), Type}
           (u : sigT (fun a => sigT (fun b => sigT (P a b))))
  : (u.1; (u.2.1; (u.2.2.1; u.2.2.2))) = u
  := match u with existT x (existT y (existT z w)) => 1 end.

is sometimes an order of magnitude or more faster than regenerating the same proof term on the fly with specific types and arguments filled in---and the definition of eta3_sigma itself takes very little time to Coq. Similarly, if define (pr2 (pr2 (pr1 foo))) as some constant which takes, say an is_pullback (which only takes a few arguments itself), then Coq never sees the implicit arguments to pr2 (pr2 (pr1, and so doesn't slow down because of them.

JasonGross commented 10 years ago

You might also be interested about my brain-dump about speed in Coq at https://github.com/HoTT/HoTT/issues/157#issuecomment-21882467.

DanGrayson commented 10 years ago

Re: "If you Set Printing All and Print PullbackArrow_PullbackPr2, you will see a giant term. "

You were right, and wc showed it had 291000 words in it! I think I have to understand that better. I'll experiment...

benediktahrens commented 10 years ago

precomp_ess_surj contains a quite lengthy proof which I am not going to refactor; also, since it proves an hprop, one can savely opacify it and forget about it. limits/pullbacks is different, and one should try to make it fast. However, I am reluctant to invent a lot of names for particular projections. Speed seems less important for me than conceptual simplicity, and polymorphism (as in polymorphic projections) is one of the features providing simplicity. In summary, I think that work on speed should be made on the level of Coq, not on the level of individual libraries.

Nonetheless, your measurements will help to identify bottlenecks and thus to improve on speed, so thanks a lot!

DanGrayson commented 10 years ago

By the way, one can't always be totally comfortable with tacking a Qed on the end of a proof -- the statement of PullbackArrow_PullbackPr2 itself has up to 4 nested projections, and applying the lemma to arguments might result in a gigantic term, momentarily. I suppose.

DanGrayson commented 10 years ago

Hmm, I find nothing conceptually simple about a term like (pr2 (pr2 (pr1 (pr2 (pr2 Pb) e h k H)))) appearing in a proof. Who can read that?

JasonGross commented 10 years ago

and applying the lemma to arguments might result in a gigantic term, momentarily

Only if you need to unfold it. If you don't unfold it, Coq doesn't care how big it really is, because it's hidden. And Qed actually doesn't help that much, in my experience; it mainly helps when Coq tries (and would fail) to unify two things, one of which is gigantic, but they're not obviously different.

Hmm, I find nothing conceptually simple about a term like (pr2 (pr2 (pr1 (pr2 (pr2 Pb) e h k H)))) appearing in a proof. Who can read that?

To me, it says "there's nothing deep going on here, I'm just defining a projection of Pb", and then I'd try to infer which projection it is from the name of the lemma and its type. I almost certainly wouldn't try to trace the first and second projections.

vladimirias commented 10 years ago

Can someone please post the same table for 8.3? Vladimir.

On Jan 19, 2014, at 3:58 PM, Jason Gross notifications@github.com wrote:

When I compile the library with Coq 8.4 and time how long it takes to make each file, I get

0.10 pathnotations 0.17 topos/epis_monos 0.18 limits/terminal 0.20 limits/initial 0.21 HLevel_n_is_of_hlevel_Sn 0.24 limits/aux_lemmas_HoTT 0.31 category_hset 0.43 whiskering 0.46 auxiliary_lemmas_HoTT 0.70 rezk_completion 0.86 precategories 1.03 yoneda 1.12 limits/cones 1.12 sub_precategories 4.71 equivalences 6.99 functors_transformations 9.29 precomp_fully_faithful 32.22 precomp_ess_surj 69.37 limits/pullbacks (Admittedly, the HoTT library takes around three times as long, and I don't have a good sense of how complicated the constructions in precomp_ess_surj and limits/pullbacks.)

At least a third of the time in limits/pullbacks, probably much more, is spent checking trivial lemmas which are slow due to nested sigma types. It's plausible that Matthieu's polyproj branch fixes this, but if you're interested in fixing it before that lands for 8.5, you can replace nested sigmas with records (or, possibly just define custom projections for each nested sigma, so that you never use the bare projections from a sigma type).

— Reply to this email directly or view it on GitHub.

DanGrayson commented 10 years ago

I get this:

25.37 (v8.4) limits/pullbacks 10.18 (v8.4) precomp_ess_surj 3.08 (v8.4) precomp_fully_faithful 2.40 (v8.4) functors_transformations 1.74 (v8.4) equivalences 0.51 (v8.4) sub_precategories 0.47 (v8.4) limits/cones 0.42 (v8.4) precategories 0.36 (v8.4) rezk_completion 0.35 (v8.4) yoneda 0.25 (v8.4) auxiliary_lemmas_HoTT 0.21 (v8.4) whiskering 0.19 (v8.4) pathnotations 0.17 (v8.4) category_hset 0.15 (v8.4) limits/aux_lemmas_HoTT 0.14 (v8.4) HLevel_n_is_of_hlevel_Sn 0.13 (v8.4) topos/epis_monos 0.13 (v8.4) limits/terminal 0.13 (v8.4) limits/initial

23.56 (v8.3) limits/pullbacks 13.96 (v8.3) precomp_ess_surj 3.72 (v8.3) precomp_fully_faithful 2.50 (v8.3) functors_transformations 1.80 (v8.3) equivalences 0.48 (v8.3) limits/cones 0.44 (v8.3) sub_precategories 0.40 (v8.3) precategories 0.37 (v8.3) yoneda 0.31 (v8.3) rezk_completion 0.22 (v8.3) auxiliary_lemmas_HoTT 0.21 (v8.3) whiskering 0.16 (v8.3) category_hset 0.13 (v8.3) limits/aux_lemmas_HoTT 0.12 (v8.3) topos/epis_monos 0.11 (v8.3) limits/terminal 0.11 (v8.3) limits/initial 0.11 (v8.3) HLevel_n_is_of_hlevel_Sn 0.08 (v8.3) pathnotations

benediktahrens commented 10 years ago

Is there a similarly detailed measurement for Foundations?

On 01/22/2014 03:39 PM, Daniel R. Grayson wrote:

I get this:

25.37 (v8.4) limits/pullbacks 10.18 (v8.4) precomp_ess_surj 3.08 (v8.4) precomp_fully_faithful 2.40 (v8.4) functors_transformations 1.74 (v8.4) equivalences 0.51 (v8.4) sub_precategories 0.47 (v8.4) limits/cones 0.42 (v8.4) precategories 0.36 (v8.4) rezk_completion 0.35 (v8.4) yoneda 0.25 (v8.4) auxiliary_lemmas_HoTT 0.21 (v8.4) whiskering 0.19 (v8.4) pathnotations 0.17 (v8.4) category_hset 0.15 (v8.4) limits/aux_lemmas_HoTT 0.14 (v8.4) HLevel_n_is_of_hlevel_Sn 0.13 (v8.4) topos/epis_monos 0.13 (v8.4) limits/terminal 0.13 (v8.4) limits/initial

23.56 (v8.3) limits/pullbacks 13.96 (v8.3) precomp_ess_surj 3.72 (v8.3) precomp_fully_faithful 2.50 (v8.3) functors_transformations 1.80 (v8.3) equivalences 0.48 (v8.3) limits/cones 0.44 (v8.3) sub_precategories 0.40 (v8.3) precategories 0.37 (v8.3) yoneda 0.31 (v8.3) rezk_completion 0.22 (v8.3) auxiliary_lemmas_HoTT 0.21 (v8.3) whiskering 0.16 (v8.3) category_hset 0.13 (v8.3) limits/aux_lemmas_HoTT 0.12 (v8.3) topos/epis_monos 0.11 (v8.3) limits/terminal 0.11 (v8.3) limits/initial 0.11 (v8.3) HLevel_n_is_of_hlevel_Sn 0.08 (v8.3) pathnotations

Reply to this email directly or view it on GitHub: https://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33028332

DanGrayson commented 10 years ago

89.66 (v8.4) hlevel2/algebra1d 46.61 (v8.4) hlevel2/algebra1b 29.90 (v8.4) hlevel2/algebra1c 26.38 (v8.4) Generalities/uu0 17.76 (v8.4) hlevel2/hq 9.24 (v8.4) hlevel2/hSet 6.51 (v8.4) hlevel2/hz 4.75 (v8.4) hlevel2/finitesets 1.01 (v8.4) hlevel2/algebra1a 0.70 (v8.4) hlevel2/hnat 0.49 (v8.4) hlevel2/stnfsets 0.17 (v8.4) hlevel1/hProp 0.14 (v8.4) Proof_of_Extensionality/funextfun 0.08 (v8.4) Generalities/uuu

14.26 (v8.3) hlevel2/hq 10.73 (v8.3) hlevel2/algebra1c 9.26 (v8.3) Generalities/uu0 7.65 (v8.3) hlevel2/algebra1b 7.09 (v8.3) hlevel2/hz 6.45 (v8.3) hlevel2/algebra1d 3.07 (v8.3) hlevel2/finitesets 0.98 (v8.3) hlevel2/hSet 0.95 (v8.3) hlevel2/algebra1a 0.63 (v8.3) hlevel2/hnat 0.45 (v8.3) hlevel2/stnfsets 0.14 (v8.3) hlevel1/hProp 0.10 (v8.3) Proof_of_Extensionality/funextfun 0.06 (v8.3) Generalities/uuu

JasonGross commented 10 years ago

If you are interested, you can pass COQC = '"/usr/bin/time" -f "$$* (user: %U mem: %M ko)" $$(COQBIN)coqc' to coq_makefile, and then whenever you make, you will get timings. If you want sorted timings, you can do something like make 2>&1 | tee timings && grep user: timings | sed s'/^$.*$ (user: $.*$ mem: $.*$)$/\2s\t\3\t\1/g' | sort -h. I generally add targets to my Makefile so that I can just do something like make pretty-timed or ./make-pretty-timed.sh to make these targets. There is also code at https://github.com/HoTT/HoTT/tree/master/etc/timing for autogenerating a nice table that compares new times to old times, which I include into most commits that I make.

DanGrayson commented 10 years ago

I was wondering how you did that -- under Mac OS X, GNU time is not installed, so I've just installed it.

On Wed, Jan 22, 2014 at 11:40 AM, Jason Gross notifications@github.comwrote:

If you are interested, you can pass COQC = '"/usr/bin/time" -f "$$ (user: %U mem: %M ko)" $$(COQBIN)coqc' to coqmakefile, and then whenever you make, you will get timings. If you want sorted timings, you can do something like make 2>&1 | tee timings && grep user: timings | sed s'/^(.) (user: (._) mem: (.))$/\2s\t\3\t\1/g' | sort -h. I generally add targets to my Makefile so that I can just do something like make pretty-timed or ./make-pretty-timed.sh to make these targets. There is also code at https://github.com/HoTT/HoTT/tree/master/etc/timing for autogenerating a nice table that compares new times to old times, which I include into most commits that I make.

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33041042 .

JasonGross commented 10 years ago

I got the trick from trunk's coq_makefile (rather, from HoTT/coq's), which by default has an option TIMED so that if you pass make TIMED=1, if invokes coqc with that prefix. Also, you may have to play with the number of dollar signs before (COQBIN); two if you pass it from your own Makefile, or one if you pass it from the command line directly.

benediktahrens commented 10 years ago

Thanks, that's very interesting:

in RC, there is no increase in compile time
consequently, in RC the ranking stayed more or less the same between 8.3 and 8.4, whereas in Foundations, it gets all mixed up
some files in RC actually had decreased compile time with 8.4, whereas for Foundations compilation takes longer with 8.4 for all files

Some files in Foundations take 10 times longer (hSet, algebra1d). It might be worthwile investigating what particular construction there takes so much longer, if any can be pointed out.

On 01/22/2014 05:06 PM, Daniel R. Grayson wrote:

89.66 (v8.4) hlevel2/algebra1d 46.61 (v8.4) hlevel2/algebra1b 29.90 (v8.4) hlevel2/algebra1c 26.38 (v8.4) Generalities/uu0 17.76 (v8.4) hlevel2/hq 9.24 (v8.4) hlevel2/hSet 6.51 (v8.4) hlevel2/hz 4.75 (v8.4) hlevel2/finitesets 1.01 (v8.4) hlevel2/algebra1a 0.70 (v8.4) hlevel2/hnat 0.49 (v8.4) hlevel2/stnfsets 0.17 (v8.4) hlevel1/hProp 0.14 (v8.4) Proof_of_Extensionality/funextfun 0.08 (v8.4) Generalities/uuu

14.26 (v8.3) hlevel2/hq 10.73 (v8.3) hlevel2/algebra1c 9.26 (v8.3) Generalities/uu0 7.65 (v8.3) hlevel2/algebra1b 7.09 (v8.3) hlevel2/hz 6.45 (v8.3) hlevel2/algebra1d 3.07 (v8.3) hlevel2/finitesets 0.98 (v8.3) hlevel2/hSet 0.95 (v8.3) hlevel2/algebra1a 0.63 (v8.3) hlevel2/hnat 0.45 (v8.3) hlevel2/stnfsets 0.14 (v8.3) hlevel1/hProp 0.10 (v8.3) Proof_of_Extensionality/funextfun 0.06 (v8.3) Generalities/uuu

Reply to this email directly or view it on GitHub: https://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33037366

JasonGross commented 10 years ago

The trunk version of Coq has a -time flag, which will print out times for each individual statement. This might help.

DanGrayson commented 10 years ago

I happen to have a patched version of the trunk so we can try that out. But remind me what turns off the new convention about whether arguments of constructor are implicit.

On Wed, Jan 22, 2014 at 3:10 PM, Jason Gross notifications@github.comwrote:

The trunk version of Coq has a -time flag, which will print out times for each individual statement. This might help.

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33062261 .

JasonGross commented 10 years ago

I think it's Set Asymmetric Patterns?

-Jason On Jan 22, 2014 12:33 PM, "Daniel R. Grayson" notifications@github.com wrote:

I happen to have a patched version of the trunk so we can try that out. But remind me what turns off the new convention about whether arguments of constructor are implicit.

On Wed, Jan 22, 2014 at 3:10 PM, Jason Gross notifications@github.comwrote:

The trunk version of Coq has a -time flag, which will print out times for each individual statement. This might help.

— Reply to this email directly or view it on GitHub< https://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33062261>

.

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33064680 .

DanGrayson commented 10 years ago

The -time option works, and produces tons of output like this:

Chars 134257 - 134271 [split~with~f.] 0. secs (0.u,0.s)
Chars 134272 - 134327 [assert~(forall~t~:~T,~paths~(g...] 0. secs (0.u,0.s)
Chars 134328 - 134335 [intro.] 0. secs (0.u,0.s)
Chars 134336 - 134365 [apply~homottranspost2t1t1t2.] 2.268 secs (2.266u,0.001s)
Chars 134366 - 134421 [assert~(forall~t~:~T,~paths~(f...] 0. secs (0.u,0.s)
Chars 134422 - 134429 [intro.] 0. secs (0.u,0.s)
Chars 134431 - 134460 [apply~homottranspost2t1t1t2.] 2.326 secs (2.326u,0.s)
Chars 134461 - 134491 [apply~(gradth~_~_~egf~efg).] 0. secs (0.u,0.s)
Chars 134492 - 134501 [Defined.] 2.235 secs (2.234u,0.s)
Chars 134506 - 134680 [Lemma~pathsfuntransposoft1~{T~...] 0. secs (0.u,0.s)
Chars 134681 - 134688 [Proof.] 0. secs (0.u,0.s)
Chars 134689 - 134697 [intros.] 0. secs (0.u,0.s)
Chars 134698 - 134718 [unfold~funtranspos.] 0. secs (0.u,0.s)
Chars 134719 - 134762 [rewrite~(pathsrecomplfxtoy~t1~...] 0.001 secs (0.001u,0.s)
Chars 134763 - 134777 [apply~idpath.] 0. secs (0.u,0.s)
Chars 134779 - 134788 [Defined.] 0. secs (0.u,0.s)

JasonGross commented 10 years ago

You can pipe it through | sed s'/^$Chars .*$ $[^ ]\+ secs$/\2\t\1 /g' | sort -h to get the slowest things at the bottom.

DanGrayson commented 10 years ago

Or just pipe it through sort -gk 6

DanGrayson commented 10 years ago

Here are the top ten offenders:

make topten
./hlevel2/algebra1d.v:38175-38271: [apply~~(rngaddhrelandfun~~~~~(...] 32.521 secs (32.5u,0.022s)
./hlevel2/algebra1d.v:37706-37801: [apply~~(rngmultgtandfun~~~~~(r...] 32.437 secs (32.409u,0.028s)
./Generalities/uu0.v:214875-214884: [Defined.] 6.444 secs (6.438u,0.005s)
./hlevel2/algebra1b.v:76174-76194: [apply~quotrellogeq.] 5.807 secs (5.802u,0.004s)
./hlevel2/algebra1b.v:75748-75767: [apply~quotrelimpl.] 5.784 secs (5.781u,0.003s)
./hlevel2/algebra1c.v:80877-80940: [apply~(invertibilityinabmonoid...] 5.1 secs (5.096u,0.003s)
./hlevel2/hSet.v:72908-72922: [apply~idpath.] 4.81 secs (4.802u,0.007s)
./hlevel2/algebra1c.v:76587-76646: [apply~(commax~(abmonoidfrac~(r...] 2.979 secs (2.971u,0.008s)
./hlevel2/algebra1c.v:80323-80379: [apply~(pr2~(abmonoidfrac~(rngm...] 2.964 secs (2.956u,0.007s)
./hlevel2/algebra1b.v:78413-78433: [apply~isdecquotrel.] 2.897 secs (2.895u,0.002s)

JasonGross commented 10 years ago

Is ./hlevel2/hSet.v:72908-72922 any faster if you use exact idpath rather than apply?

DanGrayson commented 10 years ago

I think I'll work on the big guys first. Often I find that apply in 8.4 is worse than in 8.3, and when it's the problem, as it is here, the first thing to do is to replace it by "exact".

On Wed, Jan 22, 2014 at 9:05 PM, Jason Gross notifications@github.comwrote:

Is ./hlevel2/hSet.v:72908-72922 any faster if you use exact idpath rather than apply?

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33090745 .

DanGrayson commented 10 years ago

I got the two big guys, but using "exact" on idpath didn't help (yet):

make topten
./Generalities/uu0.v:214875-214884: [Defined.] 6.37 secs (6.364u,0.006s)
./hlevel2/algebra1b.v:76239-76259: [apply~quotrellogeq.] 5.803 secs (5.797u,0.006s)
./hlevel2/algebra1c.v:80877-80940: [apply~(invertibilityinabmonoid...] 5.173 secs (5.166u,0.006s)
./hlevel2/hSet.v:72908-72925: [exact~(idpath~_).] 5.164 secs (5.147u,0.01s)
./hlevel2/algebra1c.v:80323-80379: [apply~(pr2~(abmonoidfrac~(rngm...] 3.046 secs (3.038u,0.007s)
./hlevel2/algebra1c.v:76587-76646: [apply~(commax~(abmonoidfrac~(r...] 2.971 secs (2.96u,0.011s)
./hlevel2/algebra1b.v:78501-78521: [apply~isdecquotrel.] 2.91 secs (2.908u,0.002s)
./hlevel2/algebra1b.v:72440-72462: [apply~iseqrelquotrel.] 2.9 secs (2.898u,0.002s)
./hlevel2/algebra1b.v:70939-70960: [apply~issymmquotrel.] 2.9 secs (2.899u,0.001s)
./hlevel2/algebra1b.v:71439-71460: [apply~isreflquotrel.] 2.895 secs (2.894u,0.001s)

DanGrayson commented 10 years ago

That cuts algebra1d from 90 seconds to

28.25 sec, 1782857728 bytes: hlevel2/algebra1d

benediktahrens commented 10 years ago

On 01/23/2014 06:34 AM, Daniel R. Grayson wrote:

That cuts algebra1d from 90 seconds to

28.25 sec, 1782857728 bytes: hlevel2/algebra1d

Awesome. Would it make sense to try with opacified versions of some of the lemmas?

DanGrayson commented 10 years ago

At some point Vladimir must have replaced a lot of Qed's with Opaque's, but I hear that isn't as good. If you think so, too, I could just try reverting all of those.

On Thu, Jan 23, 2014 at 4:54 AM, benediktahrens notifications@github.comwrote:

On 01/23/2014 06:34 AM, Daniel R. Grayson wrote:

That cuts algebra1d from 90 seconds to

28.25 sec, 1782857728 bytes: hlevel2/algebra1d

Awesome. Would it make sense to try with opacified versions of some of the lemmas?

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33110099 .

benediktahrens commented 10 years ago

Why did he change from Qed to Opaque? I don't know the exact difference between those two - from what I remember, Opaque renders opaque for just some . Before doing anything in this direction, it would be good to have some illustrating examples of their respective behaviours. I'll do some reading.

On 01/23/2014 02:55 PM, Daniel R. Grayson wrote:

At some point Vladimir must have replaced a lot of Qed's with Opaque's, but I hear that isn't as good. If you think so, too, I could just try reverting all of those.

On Thu, Jan 23, 2014 at 4:54 AM, benediktahrens notifications@github.comwrote:

On 01/23/2014 06:34 AM, Daniel R. Grayson wrote:

That cuts algebra1d from 90 seconds to

28.25 sec, 1782857728 bytes: hlevel2/algebra1d

Awesome. Would it make sense to try with opacified versions of some of the lemmas?

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33110099 .

Reply to this email directly or view it on GitHub: https://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33125264

benediktahrens commented 10 years ago

From the description on http://coq.inria.fr/distrib/current/refman/Reference-Manual008.html#hevea_default447 it seems that Opaque renders opaque from a user point of view, but not (completely) from the type-checking point of view.

Also, and maybe more importantly, "The scope of Opaque is limited to the current section, or current file, unless the variant Global Opaque qualid1 … qualidn is used." So all the Opaque commands in early algebra files are not retained in the later ones.

On 01/23/2014 02:55 PM, Daniel R. Grayson wrote:

At some point Vladimir must have replaced a lot of Qed's with Opaque's, but I hear that isn't as good. If you think so, too, I could just try reverting all of those.

On Thu, Jan 23, 2014 at 4:54 AM, benediktahrens notifications@github.comwrote:

On 01/23/2014 06:34 AM, Daniel R. Grayson wrote:

That cuts algebra1d from 90 seconds to

28.25 sec, 1782857728 bytes: hlevel2/algebra1d

Awesome. Would it make sense to try with opacified versions of some of the lemmas?

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33110099 .

Reply to this email directly or view it on GitHub: https://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33125264

benediktahrens commented 10 years ago

@DanGrayson: I have copied your Makefile from Foundations2 to RezkCompletion, but make topten does not seem to work for me: when the code is already compiled, I get ahrens@alien:~/git/benediktahrens/rezk_completion$ make topten ahrens@alien:~/git/benediktahrens/rezk_completion$ and after a cleaning, make topten only computes the dependencies. How is make topten supposed to work?

JasonGross commented 10 years ago

The bug report at https://coq.inria.fr/bugs/show_bug.cgi?id=3217 (Implicit Arguments option blows up proof-checking time) might be interesting/relevant.

JasonGross commented 10 years ago

If I understand https://github.com/DanGrayson/Foundations2/blob/for-coq-8.4/Makefile correctly, it looks like the topten target is meant to be run after you run make all.

JasonGross commented 10 years ago

The differences and similarities between Opaque and Qed (the ones that I know):

Opaque:

Reversible
Respected by simpl
Causes unfold to raise an error
Flag ignored by unification (but maybe not in trunk, or maybe not in HoTT/coq, or maybe not in mattam82/coq/branch/polyproj?)
Done after the definition/lemma is proven
Can be global or local
Proofs still loaded even with -dont-load-proofs
Definitions always run in serial

Qed:

Irreversible
Respected by simpl
Causes unfold to raise an error
Flag always respected by unification
Done while finishing definition/lemma
Is always global
Proofs not loaded even with -dont-load-proofs
Proofs can be parallelized in trunk

benediktahrens commented 10 years ago

I get zero output when I run it after make all.

On 01/23/2014 05:23 PM, Jason Gross wrote:

If I understand https://github.com/DanGrayson/Foundations2/blob/for-coq-8.4/Makefile correctly, it looks like the topten target is meant to be run after you run make all.

DanGrayson commented 10 years ago

Compile from scratch with

make COQTIME=yes

first.

On Thu, Jan 23, 2014 at 10:58 AM, benediktahrens notifications@github.comwrote:

@DanGrayson https://github.com/DanGrayson: I have copied your Makefile from Foundations2 to RezkCompletion, but make topten does not seem to work for me: when the code is already compiled, I get ahrens@alien:~/git/benediktahrens/rezk_completion$ make topten ahrens@alien:~/git/benediktahrens/rezk_completion$ and after a cleaning, make topten only computes the dependencies. How is make topten supposed to work?

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33136902 .

DanGrayson commented 10 years ago

And use the patched coq trunk you'll find in my "coq" repository, which includes a working "-time" option since yesterday.

On Thu, Jan 23, 2014 at 11:48 AM, Daniel R. Grayson dan@math.uiuc.eduwrote:

Compile from scratch with

make COQTIME=yes

first.

On Thu, Jan 23, 2014 at 10:58 AM, benediktahrens <notifications@github.com

wrote:

@DanGrayson https://github.com/DanGrayson: I have copied your Makefile from Foundations2 to RezkCompletion, but make topten does not seem to work for me: when the code is already compiled, I get ahrens@alien:~/git/benediktahrens/rezk_completion$ make topten ahrens@alien:~/git/benediktahrens/rezk_completion$ and after a cleaning, make topten only computes the dependencies. How is make topten supposed to work?

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33136902 .

benediktahrens commented 10 years ago

Thanks. Is the native code compilation responsible for that increase in compilation time?

: compiling hlevel2/algebra1b.v ; >hlevel2/algebra1b.timing \time -f "%U sec, %M bytes: hlevel2/algebra1b" coqc -q -R . Foundations -indices-matter -no-sharing hlevel2/algebra1b /tmp/camlasm235e34.s: Assembler messages: /tmp/camlasm235e34.s:2645057: Error: symbol `.L200000' is already defined File "./hlevel2/NFoundations_hlevel2_algebra1b.native", line 1, characters 0-1: Error: Assembler error, input left in file /tmp/camlasm235e34.s Error: Could not compile the library to native code. Skipping. 122.22 sec, 316576 bytes: hlevel2/algebra1b

Is there a way to turn that off, by any chance?

On 01/23/2014 05:52 PM, Daniel R. Grayson wrote:

And use the patched coq trunk you'll find in my "coq" repository, which includes a working "-time" option since yesterday.

On Thu, Jan 23, 2014 at 11:48 AM, Daniel R. Grayson dan@math.uiuc.eduwrote:
Compile from scratch with
make COQTIME=yes
first.

On Thu, Jan 23, 2014 at 10:58 AM, benediktahrens <notifications@github.com

wrote:

@DanGrayson https://github.com/DanGrayson: I have copied your Makefile from Foundations2 to RezkCompletion, but make topten does not seem to work for me: when the code is already compiled, I get ahrens@alien:~/git/benediktahrens/rezk_completion$ make topten ahrens@alien:~/git/benediktahrens/rezk_completion$ and after a cleaning, make topten only computes the dependencies. How is make topten supposed to work?

— Reply to this email directly or view it on GitHubhttps://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33136902 .
Reply to this email directly or view it on GitHub: https://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33143070

JasonGross commented 10 years ago

Did you pass -debug to ./configure? Alternatively, you should pass -no-native-compiler to ./configure. (I can't recall whether removing -debug or adding -no-native-compiler fixed my problems with assembly.)

benediktahrens commented 10 years ago

Commit 98cc2f0784eef764063f3c794352db26872a952b introduces an intermediate projection for pullback, thus reducing the compile time significantly. I guess that as a rule of thumb, one should not compose more than two or three pr{1,2}'s.

benediktahrens commented 10 years ago

It's weird, because I should be able to choose when compiling the Coq library whether I want to have native compilation or not, no? Anyway, I'll try your hints and recompile Coq. Thankfully I was given a new machine...

On 01/23/2014 07:05 PM, Jason Gross wrote:

Did you pass -debug to ./configure? Alternatively, you should pass -no-native-compiler to ./configure. (I can't recall whether removing -debug or adding -no-native-compiler fixed my problems with assembly.)

Reply to this email directly or view it on GitHub: https://github.com/benediktahrens/rezk_completion/issues/8#issuecomment-33150705

JasonGross commented 10 years ago

There might also be an option to pass to coqc, but I've had the problems when compiling the stdlib, so always pass my arguments to ./configure.

benediktahrens commented 10 years ago

" Flag ignored by unification (but maybe not in trunk, or maybe not in HoTT/coq, or maybe not in mattam82/coq/branch/polyproj?) "

This seems to me to be the main question, or with typechecking rather than unification, no?

DanGrayson commented 10 years ago

Qed instead of Opaque speeds Foundations up by 33%, see https://github.com/DanGrayson/Foundations2/commit/21de280c36e478ec51a44c4f3161692335ec2dd1

DanGrayson commented 10 years ago

Native code compilation adds 20% to the time, and turning it off prevents an anomaly when compiling my K-theory stuff.

DanGrayson commented 10 years ago

The option for coqc is called -no-native-compiler.

vladimirias commented 10 years ago

Dan,

did you send this to Matthieu?

V.

On Jan 22, 2014, at 11:06 AM, Daniel R. Grayson notifications@github.com wrote:

89.66 (v8.4) hlevel2/algebra1d 46.61 (v8.4) hlevel2/algebra1b 29.90 (v8.4) hlevel2/algebra1c 26.38 (v8.4) Generalities/uu0 17.76 (v8.4) hlevel2/hq 9.24 (v8.4) hlevel2/hSet 6.51 (v8.4) hlevel2/hz 4.75 (v8.4) hlevel2/finitesets 1.01 (v8.4) hlevel2/algebra1a 0.70 (v8.4) hlevel2/hnat 0.49 (v8.4) hlevel2/stnfsets 0.17 (v8.4) hlevel1/hProp 0.14 (v8.4) Proof_of_Extensionality/funextfun 0.08 (v8.4) Generalities/uuu

14.26 (v8.3) hlevel2/hq 10.73 (v8.3) hlevel2/algebra1c 9.26 (v8.3) Generalities/uu0 7.65 (v8.3) hlevel2/algebra1b 7.09 (v8.3) hlevel2/hz 6.45 (v8.3) hlevel2/algebra1d 3.07 (v8.3) hlevel2/finitesets 0.98 (v8.3) hlevel2/hSet 0.95 (v8.3) hlevel2/algebra1a 0.63 (v8.3) hlevel2/hnat 0.45 (v8.3) hlevel2/stnfsets 0.14 (v8.3) hlevel1/hProp 0.10 (v8.3) Proof_of_Extensionality/funextfun 0.06 (v8.3) Generalities/uuu

— Reply to this email directly or view it on GitHub.

benediktahrens / rezk_completion

Slowness in compiling the library #8