Hacker News new | past | comments | ask | show | jobs | submit login
PyPy JIT for 64-bit ARM (morepypy.blogspot.com)
113 points by bratao 28 days ago | hide | past | web | favorite | 26 comments



I'm surprised and humbled that a project of this importance doesn't have their own physical ARM machine for benchmarking. Compare that to the computer and human time saved across all the places it could be used!


The problem is that ARM hardware with enough RAM for their needs is extremely rare.


This work was sponsored by ARM itself, though, so it is a bit surprising they didn't supply suitable hardware from one of their licensees (they must have some to do benchmarks themselves).


PyPy is a little bit of a pathological case of their benchmark suite requires that much DRAM though


SolidRun has a MiniITX board supporting up to 2x32GB for around $1000 [0]. They also have a preproduction units for another board for $550 supporting as much RAM [1].

They probably had their reasons, but I'm just showing what's available.

https://www.solid-run.com/product/SRLX216S00D00GE064C13CH/

https://www.solid-run.com/nxp-lx2160a-family/honeycomb-works...


Why does the benchmark suite need so much RAM ?

I would expect benchmarks to match typical usage, if PyPy can't run in a couple of GB then choose a better language.


Compiling pypy is memory intensive, I don't believe it can be done in 2GB which is where most of the really affordable ARM devices seem to cap out.


But why do you have to compile PyPy on the same machine you’re testing it on?


Well cross-compiling (aka "cross translation) is made complicated because PyPy doesn't use a normal toolchain, but that's not the problem here. The PyPy benchmark suite itself takes that much memory to run.


You can build OpenJDK with the Hotspot JIT on a 2GB ARM64 system.


So the use cases for this project must also be extremely rare?


Don't want to be rude (nor rehash old topics) but is pypy used that much to be considered important? People with performance goals go to C, whether its a library or some Cython.

Don't get me wrong, i love pypy and the rpython jit.


When I want productivity and performance I go to pypy.


We're going to urgently need these ports for things like PyPy, Graal, etc, when Apple suddenly switches from Intel to ARM.


I think apple urgently needs them and should probably fund them.


Apple tends to dive head-first into these things and lets the community catch-up after the release in their own time. So it could come a day when MacBooks are suddenly only available with ARM architectures (with dynamic binary translation or something to support the transition, I'm sure, but if you're going for performance you wouldn't want that abstraction) so it's up to us to prepare if we don't want to be left out.


Apple isn't going to suddenly only offer ARM Macs and take everyone's Intel Macs away. Look at their past transitions. They transition quickly and firmly, but not that quickly and firmly. Last time it took them about a year (iirc) from the announcement to them even only releasing Intel Macs. They offered a translation layer (which was slower, but enabled all old software to run) and it then took many years for them to stop supporting PowerPC Macs.


Right, but the difference is the last time all the major runtimes already supported Intel, due to it being the predominate architecture, so the software was ready and there was no performance cliff. You may need to hang on to your old Intel MacBook for a while if the software you have performance requirements for isn't available for ARM yet.


And the Intel performance boost on the first released devices was substantial, as the laptops were still running G4s. So anything that relied on the translation layer was usable.

If the ARM chips don't meet Intel peak performance, and I suspect they won't, you're in for a bad time going through similar system.


Good point, the Windows ARM devices on the market today significantly suffer from this.

Apple has a very significant ecosystem advantage, however.


What are Apple’s urgent needs?


Awesome. You can now run PyPy on Rpi!


Not really officially. Raspbian still doesn't support AArch64.


But the 32bit version of PyPy has supported Raspbian since 2.1 [0], so PyPy itself has been around for the Pi for quite a while - since 2013. [1]

[0] https://pypy.readthedocs.io/en/latest/release-2.1.0.html

[1] https://morepypy.blogspot.com/2013/08/pypy-21-considered-arm...


Specifically, for 64 bit ARM. They already had 32 bit: https://morepypy.blogspot.com/2018/11/hello-everyone-at-pypy...

Why take that out of the headline?


Ok, we've put 64 bits up there.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: