nixpkgs/pkgs/development
Austin Seipp 18839e1cc1 icestorm: improve x86 build/runtime perf with pypy
PyPy3 offers tremendous speedups for IceStorm tools written in Python,
including tools used at compile-time to generate the chip databases, and
runtime tools distributed to users, such as icebox_vlog.

For example, on my ThreadRipper 1950X, build times for IceStorm
consistently go from 2m30s -> 1m30s with this change, a 40% improvement,
simply due to improvements in raw CPU efficiency. (This is also worsened
by the fact the build is currently serial, but that can easily be fixed
anyway.)

On top of that, tools distributed to users are also now run using PyPy.
Utilities such as icebox_vlog are useful for post-bitstream testing, for
instance, and also are improved due to improved CPU efficiency as well.
For example, when "decompiling" an ICE40 bitstream for HX8K devices,
containing a synthesized copy of PicoRV32 (from the NextPNR demos), the
runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently
with this change alone.

Normally, picking a Python interpreter outright for Python-based code is
a "bad idea", but in the case of IceStorm it should be perfectly safe,
and an excellent improvement for users. There are a few reasons for
this:

  - IceStorm uses pure Python 3 and nothing else. There are no
requirements for any 3rd party packages, which might cause annoying
incompatibilities, and PyPy has historically shown very strong core
Python compatibility.

  - IceStorm is NOT a set of Python libraries, it is a set of tools,
some of which, coincidentally, are written in Python. It is (normally)
bad form to fix libraries to certain interpreters versions if the reason
strictly isn't "it doesn't work/isn't compatible". That is not the case
here. These tools may later be used by other programs, such as NextPNR,
but the Python interpreter is ultimately not that important in quesion
for the user. In this sense, there is almost no downside to picking
PyPy explicitly if it offers far better performance.

(Point 2 is not actually strictly true; there are some distributed .py
files that you can import from but they are basically just static
classes that are imported by tools like nextpnr; this is expected.)

Because of this, users should see very little change except better
performance for IceStorm tools on their machines.

Note that PyPy is not supported on aarch64 -- this only applies to
x86_64 machines.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-01-11 18:03:35 -06:00
..
androidndk-pkgs
arduino
beam-modules elixir: link to compatibility table 2019-01-05 12:39:23 +01:00
bower-modules/generic
compilers clasp-common-lisp: update/fix build, 2018-11-28 prerelease (towards 0.9) 2019-01-11 16:29:29 +01:00
coq-modules coqPackages.category-theory: bound build parallelism 2019-01-11 17:24:45 +00:00
dhall-modules
dotnet-modules/patches
em-modules/generic
go-modules
guile-modules
haskell-modules hpc-coveralls: jailbreak for GHC 8.6 2019-01-08 16:30:17 +11:00
idris-modules idris-modules/curses.nix: delete 2019-01-04 13:44:37 +01:00
interpreters Merge pull request #53718 from jlesquembre/clojure 2019-01-11 12:05:09 +00:00
java-modules
libraries boehmgc: avoid mass rebuild due to the parent commit 2019-01-11 20:12:56 +01:00
lisp-modules
lua-modules
misc
mobile
node-packages
ocaml-modules ocamlPackages.ppx_deriving_yojson: 3.1 -> 3.3 2018-12-25 10:43:41 +01:00
perl-modules
pharo
pure-modules
python-modules Revert "libgit2: 0.26.6 → 0.27.7" 2019-01-11 14:58:45 +01:00
r-modules R: update CRAN and BIOC package sets 2019-01-08 09:34:37 +01:00
ruby-modules
tools icestorm: improve x86 build/runtime perf with pypy 2019-01-11 18:03:35 -06:00
web Merge master into staging-next 2019-01-04 21:13:19 +01:00