6 ms·

PyPy 2.1 beta released with ARM JIT

77 points by wkornewald 13y ago

fijal 13y ago
It's maybe worth pointing out that this is the first release that has a full ARM JIT support.
- wkornewald 13y ago
  Right, thanks, I've updated the title.
- hosay123 13y ago
  Changelogs like "Bugfixes to cffi and ctypes" are pretty useless. Do these bugs affect my code? Is my code going to explode horribly if I don't upgrade? Is my code going to explode horribly if I do upgrade? etc.
  - fijal 13y ago
    They're useless for you. It typically means someone posted a bug on the issue tracker and it got fixed. If you did not try PyPy before, you can't know if it affects you. If you did and there were bugs in cffi/ctypes, this is a time to try, if you did and it worked it should continue working. I know this is useless for you, but be a little understanding, most releases that are genuinely useful contain tons of stuff like "we fixed performance of this corner case" or "we fixed this obscure crash" etc. What else would you suggest to put there? Also, how on earth is what you wrote related to ARM JIT support in the title?
  - illumen 13y ago
    Good point. Most projects do it this way, and I think it's kind of good to have a high level summary like this. However, I've also seen projects that also link to specific related issues -- or even better blog pages, or documentation related to it. Mozilla with firefox does it this way for example. Your concern whether this release may break your code is only a test run away ;) But seriously... this is a valid, and common concern. I'd assume they are not intentionally introducing breaking changes, considering it's still targeting CPython compatibility. Also, there are no explicit breaks mentioned -- but I guess it might be good to communicate this explicitly.
  - MostAwesomeDude 13y ago
    As we say so often in the Python commmunity, "Try It And See." Do you use cffi and/or ctypes in your code? Have you run your tests against this newer PyPy?
- phoboslab 13y ago
  Now we just need to wait for Apple to allow the JIT on iOS. Could only take a few more years guys! (Of course having the JIT on Android, Raspberry-Pi and other ARM devices is a huge plus. I'm just frustrated by Apple's paranoia.)
  - justincormack 13y ago
    Hardly "now" - there are ongoing complaints re other JITs, eg LuaJIT, not to mention Javascript... But on the other hand, non executable heap is a reasonably valid defence against some attack types. And Apple don't care about your convenience...
    - mikeash 13y ago
      Non-executable heap is an extremely reasonable default, but not even allowing you to mprotect() a page back to being executable is just annoying.
      - nezza-_- 13y ago
        It actually makes a lot of sense. Preventing pages from being executable makes exploitation so so so much harder... Because you will need to do ROP (Return oriented programming) and Apple is quite good at ASLR (Address space layour randomization).. It also means that malware can't just load external code from a C&C server etc.. And yes, it sucks that all this means that one can't JIT. Edit: Allowing executable pages would also break mandatory code signing.
        mikeash 13y ago
        You'll have to do ROP to get the app to make your data executable anyway. Is it really that much easier?
    - pjmlp 13y ago
      > , not to mention Javascript... JavaScript support has been improved on the upcoming iOS version, even interaction with the Objective-C runtime. Not sure about JIT, though. If you have an Apple account check the JavaScript sessions from WWDC 2013.
Zigurd 13y ago
This could be the missing ingredient in the new entrant mobile OSs: A managed language runtime. This + Qt bindings could make a nice app runtime for an OS like Jolla. Otherwise, in most cases, your choices are Web apps or Qt apps in C++.

77 points by wkornewald 13y ago

fijal 13y ago

It's maybe worth pointing out that this is the first release that has a full ARM JIT support.

wkornewald 13y ago
Right, thanks, I've updated the title.
hosay123 13y ago
Changelogs like "Bugfixes to cffi and ctypes" are pretty useless. Do these bugs affect my code? Is my code going to explode horribly if I don't upgrade? Is my code going to explode horribly if I do upgrade? etc.
- fijal 13y ago
  They're useless for you. It typically means someone posted a bug on the issue tracker and it got fixed. If you did not try PyPy before, you can't know if it affects you. If you did and there were bugs in cffi/ctypes, this is a time to try, if you did and it worked it should continue working. I know this is useless for you, but be a little understanding, most releases that are genuinely useful contain tons of stuff like "we fixed performance of this corner case" or "we fixed this obscure crash" etc. What else would you suggest to put there? Also, how on earth is what you wrote related to ARM JIT support in the title?
- illumen 13y ago
  Good point. Most projects do it this way, and I think it's kind of good to have a high level summary like this. However, I've also seen projects that also link to specific related issues -- or even better blog pages, or documentation related to it. Mozilla with firefox does it this way for example. Your concern whether this release may break your code is only a test run away ;) But seriously... this is a valid, and common concern. I'd assume they are not intentionally introducing breaking changes, considering it's still targeting CPython compatibility. Also, there are no explicit breaks mentioned -- but I guess it might be good to communicate this explicitly.
- MostAwesomeDude 13y ago
  As we say so often in the Python commmunity, "Try It And See." Do you use cffi and/or ctypes in your code? Have you run your tests against this newer PyPy?
phoboslab 13y ago
Now we just need to wait for Apple to allow the JIT on iOS. Could only take a few more years guys! (Of course having the JIT on Android, Raspberry-Pi and other ARM devices is a huge plus. I'm just frustrated by Apple's paranoia.)
- justincormack 13y ago
  Hardly "now" - there are ongoing complaints re other JITs, eg LuaJIT, not to mention Javascript... But on the other hand, non executable heap is a reasonably valid defence against some attack types. And Apple don't care about your convenience...
  - mikeash 13y ago
    Non-executable heap is an extremely reasonable default, but not even allowing you to mprotect() a page back to being executable is just annoying.
    - nezza-_- 13y ago
      It actually makes a lot of sense. Preventing pages from being executable makes exploitation so so so much harder... Because you will need to do ROP (Return oriented programming) and Apple is quite good at ASLR (Address space layour randomization).. It also means that malware can't just load external code from a C&C server etc.. And yes, it sucks that all this means that one can't JIT. Edit: Allowing executable pages would also break mandatory code signing.
      - mikeash 13y ago
        You'll have to do ROP to get the app to make your data executable anyway. Is it really that much easier?
  - pjmlp 13y ago
    > , not to mention Javascript... JavaScript support has been improved on the upcoming iOS version, even interaction with the Objective-C runtime. Not sure about JIT, though. If you have an Apple account check the JavaScript sessions from WWDC 2013.

Zigurd 13y ago

This could be the missing ingredient in the new entrant mobile OSs: A managed language runtime. This + Qt bindings could make a nice app runtime for an OS like Jolla. Otherwise, in most cases, your choices are Web apps or Qt apps in C++.