Pyston VS julia

Just for reference,

* Nuitka[0] "is a Python compiler written in Python. It's fully compatible with Python 2.6, 2.7, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, and 3.11."

* Pypy[1] "is a replacement for CPython" with builtin optimizations such as on the fly JIT compiles.

* Cython[2] "is an optimising static compiler for both the Python programming language and the extended Cython programming language... makes writing C extensions for Python as easy as Python itself."

* Numba[3] "is an open source JIT compiler that translates a subset of Python and NumPy code into fast machine code."

* Pyston[4] "is a performance-optimizing JIT for Python, and is drop-in compatible with ... CPython 3.8.12"

[0] https://github.com/Nuitka/Nuitka

[1] https://www.pypy.org/

[2] https://cython.org/

[3] https://numba.pydata.org/

[4] https://github.com/pyston/pyston

and if you need more speed you can try https://www.pypy.org/ or https://github.com/tonybaloney/Pyjion or https://www.pyston.org/

What efforts have been done come with limitations. PyPy is mostly compatible. Pyston seems mostly compatible but offers only modest speedups. IronPython and Jython run on the .NET and Java runtimes, respectively. They’re JITed as a consequence of that, but that also means they’re stuck in those environments and don’t work with CPython modules that use native code.

https://github.com/pyston/pyston/blob/69b190003f14dfd2f6d276...

Seems easier to use the C functions to do this, rather than rely on system commands.

Releases · pyston/pyston

root@julia-75444d5c79-686cf:/# curl -LO [https://github.com/pyston/pyston/releases/download/pyston\_2.3.2/PystonConda-1.1-Linux-x86\_64.sh](https://github.com/pyston/pyston/releases/download/pyston_2.3.2/PystonConda-1.1-Linux-x86_64.sh) % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 670 100 670 0 0 8072 0 --:--:-- --:--:-- --:--:-- 7976 100 88.2M 100 88.2M 0 0 89.3M 0 --:--:-- --:--:-- --:--:-- 89.3M root@julia-75444d5c79-686cf:/# chmod +x PystonConda-1.1-Linux-x86_64.sh root@julia-75444d5c79-686cf:/# ./PystonConda-1.1-Linux-x86_64.sh Welcome to PystonConda 1.1 In order to continue the installation process, please review the license agreement. Please, press ENTER to continue >>> PystonConda installer code uses BSD-3-Clause license as stated below. Binary packages that come with it have their own licensing terms and by installing PystonConda you agree to the licensing terms of individual packages as well. They include different OSI-approved licenses including the GNU General Public License and can be found in pkgs//info/licenses folders. ============================================================================= Copyright (c) 2021, Anaconda, Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Anaconda, Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ANACONDA, INC BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Do you accept the license terms? [yes|no] [no] >>> yes PystonConda will now be installed into this location: /root/pystonconda - Press ENTER to confirm the location - Press CTRL-C to abort the installation - Or specify a different location below [/root/pystonconda] >>> PREFIX=/root/pystonconda Unpacking payload ... Collecting package metadata (current_repodata.json): done Solving environment: done ## Package Plan ## environment location: /root/pystonconda added / updated specs: - _libgcc_mutex==0.1=conda_forge - _openmp_mutex==4.5=1_gnu - brotlipy==0.7.0=py38h79d3a15_1003 - bzip2==1.0.8=h7f98852_4 - ca-certificates==2021.10.8=ha878542_0 - certifi==2021.10.8=py38hc2d5299_1 - cffi==1.15.0=py38h9a12ab7_0 - charset-normalizer==2.0.11=pyhd8ed1ab_0 - colorama==0.4.4=pyh9f0ad1d_0 - conda-package-handling==1.7.3=py38h79d3a15_1 - conda==4.11.0=py38h4c12d10_0 - cryptography==36.0.0=py38ha252339_0 - freetype==2.10.4=h0708190_1 - idna==3.3=pyhd8ed1ab_0 - jbig==2.1=h7f98852_2003 - jpeg==9e=h7f98852_0 - lerc==3.0=h9c3ff4c_0 - libdeflate==1.8=h7f98852_0 - libffi==3.4.2=h7f98852_5 - libgcc-ng==11.2.0=h1d223b6_12 - libgomp==11.2.0=h1d223b6_12 - libpng==1.6.37=h21135ba_2 - libstdcxx-ng==11.2.0=he4da1e4_12 - libtiff==4.3.0=h6f004c6_2 - libwebp-base==1.2.2=h7f98852_1 - libzlib==1.2.11=h36c2ea0_1013 - lz4-c==1.9.3=h9c3ff4c_1 - ncurses==6.2=h58526e2_4 - openssl==1.1.1l=h7f98852_0 - pip==22.0.3=pyhd8ed1ab_0 - pycosat==0.6.3=py38h79d3a15_1009 - pycparser==2.21=pyhd8ed1ab_0 - pyopenssl==22.0.0=pyhd8ed1ab_0 - pysocks==1.7.1=py38h4c12d10_4 - pyston2.3==2.3.2=0_23_pyston - pyston==2.3.2=3 - python==3.8.12=3_23_pyston - python_abi==3.8=1_23_pyston - readline==8.1=h46c0cb4_0 - requests==2.27.1=pyhd8ed1ab_0 - ruamel_yaml==0.15.80=py38h79d3a15_1006 - setuptools==60.7.0=py38hc2d5299_0 - six==1.16.0=pyh6c4a22f_0 - sqlite==3.37.0=h9cd32fc_0 - tk==8.6.11=h27826a3_1 - tqdm==4.62.3=pyhd8ed1ab_0 - tzdata==2021e=he74cb21_0 - urllib3==1.26.8=pyhd8ed1ab_1 - wheel==0.37.1=pyhd8ed1ab_0 - xz==5.2.5=h516909a_1 - yaml==0.2.5=h7f98852_2 - zlib==1.2.11=h36c2ea0_1013 - zstd==1.5.2=ha95c52a_0 The following NEW packages will be INSTALLED: _libgcc_mutex conda-forge/linux-64::_libgcc_mutex-0.1-conda_forge _openmp_mutex conda-forge/linux-64::_openmp_mutex-4.5-1_gnu brotlipy pyston/linux-64::brotlipy-0.7.0-py38h79d3a15_1003 bzip2 conda-forge/linux-64::bzip2-1.0.8-h7f98852_4 ca-certificates conda-forge/linux-64::ca-certificates-2021.10.8-ha878542_0 certifi pyston/linux-64::certifi-2021.10.8-py38hc2d5299_1 cffi pyston/linux-64::cffi-1.15.0-py38h9a12ab7_0 charset-normalizer conda-forge/noarch::charset-normalizer-2.0.11-pyhd8ed1ab_0 colorama conda-forge/noarch::colorama-0.4.4-pyh9f0ad1d_0 conda pyston/linux-64::conda-4.11.0-py38h4c12d10_0 conda-package-han~ pyston/linux-64::conda-package-handling-1.7.3-py38h79d3a15_1 cryptography pyston/linux-64::cryptography-36.0.0-py38ha252339_0 freetype conda-forge/linux-64::freetype-2.10.4-h0708190_1 idna conda-forge/noarch::idna-3.3-pyhd8ed1ab_0 jbig conda-forge/linux-64::jbig-2.1-h7f98852_2003 jpeg conda-forge/linux-64::jpeg-9e-h7f98852_0 lerc conda-forge/linux-64::lerc-3.0-h9c3ff4c_0 libdeflate conda-forge/linux-64::libdeflate-1.8-h7f98852_0 libffi conda-forge/linux-64::libffi-3.4.2-h7f98852_5 libgcc-ng conda-forge/linux-64::libgcc-ng-11.2.0-h1d223b6_12 libgomp conda-forge/linux-64::libgomp-11.2.0-h1d223b6_12 libpng conda-forge/linux-64::libpng-1.6.37-h21135ba_2 libstdcxx-ng conda-forge/linux-64::libstdcxx-ng-11.2.0-he4da1e4_12 libtiff conda-forge/linux-64::libtiff-4.3.0-h6f004c6_2 libwebp-base conda-forge/linux-64::libwebp-base-1.2.2-h7f98852_1 libzlib conda-forge/linux-64::libzlib-1.2.11-h36c2ea0_1013 lz4-c conda-forge/linux-64::lz4-c-1.9.3-h9c3ff4c_1 ncurses conda-forge/linux-64::ncurses-6.2-h58526e2_4 openssl conda-forge/linux-64::openssl-1.1.1l-h7f98852_0 pip conda-forge/noarch::pip-22.0.3-pyhd8ed1ab_0 pycosat pyston/linux-64::pycosat-0.6.3-py38h79d3a15_1009 pycparser conda-forge/noarch::pycparser-2.21-pyhd8ed1ab_0 pyopenssl conda-forge/noarch::pyopenssl-22.0.0-pyhd8ed1ab_0 pysocks pyston/linux-64::pysocks-1.7.1-py38h4c12d10_4 pyston pyston/noarch::pyston-2.3.2-3 pyston2.3 pyston/linux-64::pyston2.3-2.3.2-0_23_pyston python pyston/linux-64::python-3.8.12-3_23_pyston python_abi pyston/linux-64::python_abi-3.8-1_23_pyston readline conda-forge/linux-64::readline-8.1-h46c0cb4_0 requests conda-forge/noarch::requests-2.27.1-pyhd8ed1ab_0 ruamel_yaml pyston/linux-64::ruamel_yaml-0.15.80-py38h79d3a15_1006 setuptools pyston/linux-64::setuptools-60.7.0-py38hc2d5299_0 six conda-forge/noarch::six-1.16.0-pyh6c4a22f_0 sqlite conda-forge/linux-64::sqlite-3.37.0-h9cd32fc_0 tk conda-forge/linux-64::tk-8.6.11-h27826a3_1 tqdm conda-forge/noarch::tqdm-4.62.3-pyhd8ed1ab_0 tzdata conda-forge/noarch::tzdata-2021e-he74cb21_0 urllib3 conda-forge/noarch::urllib3-1.26.8-pyhd8ed1ab_1 wheel conda-forge/noarch::wheel-0.37.1-pyhd8ed1ab_0 xz conda-forge/linux-64::xz-5.2.5-h516909a_1 yaml conda-forge/linux-64::yaml-0.2.5-h7f98852_2 zlib conda-forge/linux-64::zlib-1.2.11-h36c2ea0_1013 zstd conda-forge/linux-64::zstd-1.5.2-ha95c52a_0 Preparing transaction: done Executing transaction: done installation finished. Do you wish the installer to initialize PystonConda by running conda init? [yes|no] [no] >>> yes no change /root/pystonconda/condabin/conda no change /root/pystonconda/bin/conda no change /root/pystonconda/bin/conda-env no change /root/pystonconda/bin/activate no change /root/pystonconda/bin/deactivate no change /root/pystonconda/etc/profile.d/conda.sh no change /root/pystonconda/etc/fish/conf.d/conda.fish no change /root/pystonconda/shell/condabin/Conda.psm1 no change /root/pystonconda/shell/condabin/conda-hook.ps1 no change /root/pystonconda/lib/python3.8/site-packages/xontrib/conda.xsh no change /root/pystonconda/etc/profile.d/conda.csh modified /root/.bashrc ==> For changes to take effect, close and re-open your current shell. <== If you'd prefer that conda's base environment not be activated on startup, set the auto_activate_base parameter to false: conda config --set auto_activate_base false Thank you for installing PystonConda!

Honestly, even that seems trivial? By my reading of https://github.com/pyston/pyston#installing-packages , the only impact is that when you install (compiled) libraries they need to be recompiled, just like if you use Alpine (which is also ABI-incompatible because it uses musl libc), which is a little bit of pain at build/packaging time but doesn't actually break anything (i.e. there are no libraries that you can't use, just libraries with an extra compile step) and doesn't affect runtime behavior at all.

34. Julia - $74,963

I don't believe there is any official documentation on this, but https://github.com/JuliaLang/julia/pull/49430 for example added prefetching to the marking phase of a GC which saw speedups on x86, but not on M1.

3. dispatch on all the arguments

the first solution is clean, but people really like dispatch.

the second makes calling functions in the function call syntax weird, because the first argument is privileged semantically but not syntactically.

the third makes calling functions in the method call syntax weird because the first argument is privileged syntactically but not semantically.

the closest things to this i can think of off the top of my head in remotely popular programming languages are: nim, lisp dialects, and julia.

nim navigates the dispatch conundrum by providing different ways to define free functions for different dispatch-ness. the tutorial gives a good overview: https://nim-lang.org/docs/tut2.html

lisps of course lack UFCS.

see here for a discussion on the lack of UFCS in julia: https://github.com/JuliaLang/julia/issues/31779

so to sum up the answer to the original question: because it's only obvious how to make it nice and tidy like you're wanting if you sacrifice function dispatch, which is ubiquitous for good reason!

https://github.com/JuliaLang/julia/blob/release-1.10/NEWS.md

Visit official site: https://julialang.org/

No. It runs natively on ARM.

julia> versioninfo() Julia Version 1.9.3 Commit bed2cd540a1 (2023-08-24 14:43 UTC) Build Info: Official https://julialang.org/ release

https://github.com/JuliaLang/julia/issues/51086#issuecomment...

So while this "fixes" the issue, it'll introduce a confusing time delay between you freeing the memory and you observing that in `htop`.

But according to https://jemalloc.net/jemalloc.3.html you can set `opt.muzzy_decay_ms = 0` to remove the delay.

Still, the musl author has some reservations against making `jemalloc` the default:

https://www.openwall.com/lists/musl/2018/04/23/2

> It's got serious bloat problems, problems with undermining ASLR, and is optimized pretty much only for being as fast as possible without caring how much memory you use.

With the above-mentioned tunables, this should be mitigated to some extent, but the general "theme" (focusing on e.g. performance vs memory usage) will likely still mean "it's a tradeoff" or "it's no tradeoff, but only if you set tunables to what you need".

I have asked about Julia's reproducibility story on the Guix mailing list in the past, and at the time Simon Tournier didn't think it was promising. I seem to recall Julia itself didnt have a reproducible build. All I know now is that github issue is still not closed.

https://github.com/JuliaLang/julia/issues/34753

I don't really know what kind of rebuttal you're looking for, but I will link my HN comments from when this was first posted for some thoughts: https://news.ycombinator.com/item?id=31396861#31398796. As I said, in the linked post, I'm quite skeptical of the business of trying to assess relative buginess of programming in different systems, because that has strong dependencies on what you consider core vs packages and what exactly you're trying to do.

However, bugs in general suck and we've been thinking a fair bit about what additional tooling the language could provide to help people avoid the classes of bugs that Yuri encountered in the post.

The biggest class of problems in the blog post, is that it's pretty clear that `@inbounds` (and I will extend this to `@assume_effects`, even though that wasn't around when Yuri wrote his post) is problematic, because it's too hard to write. My proposal for what to do instead is at https://github.com/JuliaLang/julia/pull/50641.

Another common theme is that while Julia is great at composition, it's not clear what's expected to work and what isn't, because the interfaces are informal and not checked. This is a hard design problem, because it's quite close to the reasons why Julia works well. My current thoughts on that are here: https://github.com/Keno/InterfaceSpecs.jl but there's other proposals also.

Doesn't musl have the same issue? https://github.com/JuliaLang/julia/issues/34726#issuecomment...

I also wonder about OSX's libc. Newer versions seem to have some sort of locking https://github.com/apple-open-source-mirror/Libc/blob/master...

but older versions (from 10.9) don't have any lockign: https://github.com/apple-oss-distributions/Libc/blob/Libc-99...