Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Gambit and Gerbil, fix #78921 #80224

Merged
merged 3 commits into from Feb 28, 2020
Merged

Update Gambit and Gerbil, fix #78921 #80224

merged 3 commits into from Feb 28, 2020

Conversation

fare
Copy link
Contributor

@fare fare commented Feb 16, 2020

Motivation for this change

Upstream update + bug fix

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@7c6f434c
Copy link
Member

@GrahamcOfBorg build gambit-unstable gerbil-unstable

@fare
Copy link
Contributor Author

fare commented Feb 19, 2020

Looks as good as it'll ever get... timeout on aa64 :-(

@fare
Copy link
Contributor Author

fare commented Feb 21, 2020

While we're waiting, I just updated gerbil-unstable to the upstream

@fare
Copy link
Contributor Author

fare commented Feb 21, 2020

@GrahamcOfBorg build gerbil-unstable

@fare
Copy link
Contributor Author

fare commented Feb 25, 2020

@GrahamcOfBorg build gambit gerbil gambit-unstable gerbil-unstable

@fare fare force-pushed the fare branch 2 times, most recently from 7c90803 to 1260afa Compare February 25, 2020 01:33
@@ -38,6 +38,10 @@ stdenv.mkDerivation rec {
#--enable-inline-jumps
#--enable-char-size=1" ; default is 4
)
export CC=${gcc}/bin/gcc CXX=${gcc}/bin/g++ \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MacOS's stdenv uses clang by default. Depending on gcc means that using gambit might need to build all of gcc.

$CC should already be set, although without a full path, meaning you should be able to say export CC="$(command -v $CC)" CXX="$(command -v $CXX)" ... and so forth, and not depend on gcc. I did something like this for plan9port
here.

This way, the reference to gcc can be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember how much slower clang-generated code it, but it's a significant factor. 200MB of space is cheap these days, speed is not. If you want a slow Scheme, there is plenty of competition to Gambit.

Can you try the two recipes and compare the generated code on some benchmarks?

And even if we pick clang, we probably want the path hardcoded with some CC= statement, instead of randomly inherited from the $PATH.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the CC= statement, etc., is important, because IIUC, the values are persisted in the installation as default values.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Thus gambit knows where to find a C toolchain that is compatible with what it used to compile its own code.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I have seen comparisons of latest-at-the-time releases where Clang was generating noticeably faster code. For some input code bases and target CPUs… I think these comparisons coexisted with the opposite comparisons for the same compiler versions.

I would not be surprised if Clang is 10% faster (for the current versions in Nixpkgs). Or 10% slower.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, GCC -O2 is also slower than GCC -O1? In addition to Clang taking longer than GCC to compile which is … not the expected situation. Maybe GCC-efficient support for unrestricted reenterable continuations leads to unique idioms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, now I need to compile with -O1, -Os, -O2 and see what works better. Until I do my own benchmark, I should probably follow Marc's advice and leave it at -O1.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it is even worth a comment that the Gambit codebase manages to violate the basic assumptions about the compiler performance and compiled-code performance…

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will, in my next PR (or this one, if still not merged), after I confirm the benchmarks...
It takes over 1h to run the benchmarks at https://github.com/ecraven/r7rs-benchmarks, plus maybe half an hour to recompile gambit, so say 2h per configuration, 4h for the next two configurations (-O1 and -Os)...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my benchmarks, -Os clearly wins over both -O1 and -O2 most of the time (as far as the generated code goes), so that's what I'll use.

Copy link
Contributor

@eraserhd eraserhd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reference, here's what I have so far, though I have quite a few more issues to work through:

https://github.com/NixOS/nixpkgs/compare/master...eraserhd:gambit-updates?expand=1

(Don't worry about conflicts, I'll rebase off your branch when I have time).

@fare fare force-pushed the fare branch 2 times, most recently from 46b403e to c240182 Compare February 25, 2020 02:57
@fare
Copy link
Contributor Author

fare commented Feb 25, 2020

@eraserhd I've integrated some of your suggestions in the current version of my branch.

For other ones... I need be convinced.

@fare
Copy link
Contributor Author

fare commented Feb 25, 2020

Success! @7c6f434c or @thoughtpolice can you review and merge? (Thank you so much for your precious time!)

@NixOS NixOS deleted a comment from fare Feb 25, 2020
#--enable-char-size=1" ; default is 4
)
./configure ''${options[@]}
postConfigure = ''
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Locally, on NixOS, this does not run. You'll need to avoid overriding configurePhase, which you should be able to do by setting environment variables in preConfigure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean. The build recipe works for me and for the borg. What "does not run"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe «does not run» is about just the postConfigure part. The build might succeed without this part being run.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, what @7c6f434c said - the default code for configurePhase runs postConfigure. Setting configurePhase prevents it from running. https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L1002

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, is it better now?

export CC=${gcc}/bin/gcc CXX=${gcc}/bin/g++ \
CPP=${gcc}/bin/cpp CXXCPP=${gcc}/bin/cpp LD=${gcc}/bin/ld \
XMKMF=${coreutils}/bin/false
unset CFLAGS LDFLAGS LIBS CPPFLAGS CXXFLAGS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's this about?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're using GCC anyway, we might take advantage of it to bootstrap 10x faster (as per the 2 year old benchmark I posted).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean unsetting CFLAGS, LDFLAGS, etc.

I'm pretty sure Nix doesn't set any of these in the first place, but what are you trying to avoid?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that is both a way to document which flags Gambit depends on, and a way to ensure it all works even in an impure nix shell?

Comment on lines 61 to 62
--replace /usr/local/opt/openssl/lib "${openssl}/lib" \
--replace /usr/local/opt/openssl@1.1/lib "${openssl}/lib"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
--replace /usr/local/opt/openssl/lib "${openssl}/lib" \
--replace /usr/local/opt/openssl@1.1/lib "${openssl}/lib"
--replace /usr/local/opt/openssl/lib "${openssl.out}/lib" \
--replace /usr/local/opt/openssl@1.1/lib "${openssl.out}/lib"

Without this suggestion:

jfelice@crunch /tmp
$ gsc -verbose -exe foo.scm
Parsing:
  "expr"
  "expr"

Compiling:

Dumping:
  #<primitive foo#>

Compilation finished.
/nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc  -Os    -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64   -D___SINGLE_HOST  -I"/nix/store/6w4rkrclxcdivy9jhc25zx6l166g2a13-gambit-4.9.3/include" -c -o "foo.o"  foo.c
/nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc  -Os    -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64   -D___SINGLE_HOST  -I"/nix/store/6w4rkrclxcdivy9jhc25zx6l166g2a13-gambit-4.9.3/include" -c -o "foo_.o"  foo_.c
/nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc     -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64   -rdynamic  -D___SINGLE_HOST  -I"/nix/store/6w4rkrclxcdivy9jhc25zx6l166g2a13-gambit-4.9.3/include"  -o "foo"   foo_.o foo.o "/nix/store/6w4rkrclxcdivy9jhc25zx6l166g2a13-gambit-4.9.3/lib/libgambit.so" -lutil -ldl -lm  -L/nix/store/7i3k8k854al6ci160syrq2xld97kz4ci-openssl-1.1.1d-bin/lib -lssl -lcrypto
/nix/store/ffi3j388c39qbbskfqg1zw0x2lmbzhnk-binutils-2.31.1/bin/ld: cannot find -lssl
/nix/store/ffi3j388c39qbbskfqg1zw0x2lmbzhnk-binutils-2.31.1/bin/ld: cannot find -lcrypto
collect2: error: ld returned 1 exit status
*** ERROR IN ##main -- target link failed while linking "/tmp/foo_.o" "/tmp/foo.o"

With this suggestion:

jfelice@crunch /tmp
$ gsc -verbose -exe foo.scm
Parsing:
  "expr"
  "expr"

Compiling:

Dumping:
  #<primitive foo#>

Compilation finished.
/nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc  -Os    -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64   -D___SINGLE_HOST  -I"/nix/store/9h6nzjy120q0ls0srfb6fr4iw26b6afm-gambit-4.9.3/include" -c -o "foo.o"  foo.c
/nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc  -Os    -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64   -D___SINGLE_HOST  -I"/nix/store/9h6nzjy120q0ls0srfb6fr4iw26b6afm-gambit-4.9.3/include" -c -o "foo_.o"  foo_.c
/nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc     -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mpc64   -rdynamic  -D___SINGLE_HOST  -I"/nix/store/9h6nzjy120q0ls0srfb6fr4iw26b6afm-gambit-4.9.3/include"  -o "foo"   foo_.o foo.o "/nix/store/9h6nzjy120q0ls0srfb6fr4iw26b6afm-gambit-4.9.3/lib/libgambit.so" -lutil -ldl -lm  -L/nix/store/i8l8gcnz3jya1dr4205gbb92akay3f1f-openssl-1.1.1d/lib -lssl -lcrypto

jfelice@crunch /tmp
$ ./foo
hello, world

(it tries to find the libs in the bin package)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup. I saw that and I fixed it. The naming of package outputs can be confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Thanks!)

Use -Os rather than -O2 as our compilation flag, document why.

Document why we always use gcc over clang.

Fix openssl path in gambit.
Stop trying to make static openssl.
@fare
Copy link
Contributor Author

fare commented Feb 27, 2020

It's approved and passes tests... who's role is it to merge?

@7c6f434c
Copy link
Member

Givn that @eraserhd has made a lot of helpful comments on the previous versions of this, I personally will only merge about some times has elapsed in case there are some further remarks. Hopefully I will come back to it when looking at the recently-participated list in a day or two.

Let Gerbil Scheme find its GERBIL_HOME where Nix put it
when the environment variable is left unspecified.

Comment out work in progress for static linking.

Notes about working on macOS.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants