Giters

coq-community / docker-coq

Docker images of the Coq proof assistant (see also: https://github.com/coq-community/docker-coq-action) [maintainers=@erikmd,@himito]

Home Page:https://hub.docker.com/r/coqorg/coq/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Images don’t seem to enable flambda

Blaisorblade opened this issue · comments

commented

Crosspost from https://coq.zulipchat.com/#narrow/stream/237663-coq-community-devs.20.26.20users/topic/flambda-using.20Docker-Coq.20images, now that I found this issue tracker (🤦 , #9):

Hi @Erik Martin-Dorel, thanks again for your Coq images! I wanted to use 8.11-ocaml-4.09-flambda, but I'm not sure it actually enables flambda — it just uses the flambda version of ocaml, but doesn't pass the flambda flags to Coq, because it runs opam install coq and that doesn't enable flambda yet. The same applies to images using 4.07.1-flambda.

Maybe this can be fixed by something like ocaml/opam-repository#16779

Otherwise, we'll need one of the workarounds in https://coq.discourse.group/t/install-notes-on-coq-and-ocaml-versions-configuration/713.

I've built my own opam overlay fixing this (example), but you're not supposed to depend on (EDIT) my overlay: I haven't committed to maintaining it for public use, nor documented its quirks (tags in version numbers are a really poor encoding of flags).

commented

Thank you @Blaisorblade for raising this ! fortunately I have received your notification from Zulip (much more convenient than when discussions happened on Gitter!) but did not have the time to have a look.

This is indeed a concern; I confirm that currently, the docker-coq installation procedure for non-4.05.0 ocaml versions blindly relies on the standard opam package installed in the desired switch.

Before diving into workarounds, as this issue is basically an upstream issue, at first sight I'd suggest that you adapt your PR ocaml/opam-repository#16779 to only insert the 2 flags if the ocaml-version is ≥ 4.07 (as this was the main point raised by @ejgallego in ocaml/opam-repository#16779 (comment)):

"-flambda-opts" {ocaml:version >= "4.07"} "-O3 -unbox-closures" {ocaml:version >= "4.07"}

or even, one could write this to have a slightly more restricted constraint:

"-flambda-opts" {ocaml:version >= "4.07" & ocaml-variants:installed} "-O3 -unbox-closures" {ocaml:version >= "4.07" & ocaml-variants:installed}

And this could ideally be done for the following (released) versions of Coq that support 4.07.1:

  • coq.8.7.0
  • coq.8.7.1
  • coq.8.7.1+1
  • coq.8.7.1+2
  • coq.8.7.2
  • coq.8.8.0
  • coq.8.8.1
  • coq.8.8.2
  • coq.8.9.0
  • coq.8.9.1
  • coq.8.10.0
  • coq.8.10.1
  • coq.8.10.2
  • coq.8.11.0
  • coq.8.11.1
  • coq.8.11.2
commented

@Blaisorblade @ejgallego, do you think the filters {ocaml:version >= "4.07" & ocaml-variants:installed} I suggested are a proper solution? or do you have another suggestion.

commented

IIUC, since the flambda options are ignored by non-flambda compilers:

  • Checking for an flambda compiler is unnecessary AFAIK (so I _guess ocaml-variants:installed can be skipped)?
  • Checking the OCaml version would certainly prevent some problems, so 👍
  • Even on later OCaml compilers, flambda + native-compiler has some concerns:
    coq/coq#11107 (comment). My answer is to disable native-compiler, but I'm wary of imposing it on native-compiler users.
  • For older Coq releases, it'd be great to know if they were tested with flambda.

FWIW: right now there's also a PR ocaml/opam-repository#16619 to enable flambda for entire switches with a new compiler variant with different settings.

commented
  • Indeed it is not needed to check for flambda compilers as the options are ignored, it is thus safe to use them.
  • Checking the OCaml version is indeed nice thing todo.
  • We only started testing Coq + flambda in 8.10, so 8.7-8.9 are basically untested with flambda [I tested them from time to time, but they were not in the CI] That being said, there should not be a lot of problems, note that if you pick a flambda compiler already you are using the flambda backend, -O3 etc... only provide some options that seem to help Coq; it is likely that if someone would spend time playing with flambda options they would find even a better set.
commented

I think the blocker, for me, is still whether to disable native-compute, or whether to ignore the problem. Probably the latter is safer, and we'll just accept the risk that some coq installs on flambda switches might in fact become slower. At least we'll get more testing and reports.

I guess we take some small risk either way.

commented

We are gonna see what we do with that problem, if you are not using native in your lib, the slowdown shouldn't happen.

commented

I'm not sure I'm getting all the details right tho, so maybe we can chat on Zulip a bit more interactively?

commented

We now have flambda images https://hub.docker.com/r/coqorg/coq/; closing.