tag:blogger.com,1999:blog-3971202189709462152.post8705514488940872802..comments2024-03-11T12:50:02.036+01:00Comments on PyPy Status Blog: Update on STMCarl Friedrich Bolz-Tereickhttp://www.blogger.com/profile/00518922641059511014noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-3971202189709462152.post-53813542603042839332013-10-16T16:55:48.523+02:002013-10-16T16:55:48.523+02:00@Ignacio Hernandez: for HTM, our position is still...@Ignacio Hernandez: for HTM, our position is still as described last year in: http://morepypy.blogspot.com/2012/08/multicore-programming-in-pypy-and.htmlArmin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-48777932698436883512013-10-16T16:22:02.691+02:002013-10-16T16:22:02.691+02:00Are there any plans or experiments going on relate...Are there any plans or experiments going on related to Hardware Transactional Memory?Anonymoushttps://www.blogger.com/profile/01242163120675473685noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-61066236815711942212013-08-22T18:14:46.375+02:002013-08-22T18:14:46.375+02:00@Armin: Ah, I see. Well, from a user's perspec...@Armin: Ah, I see. Well, from a user's perspective, what I most write in python these days is either GUI applications (for which I've never been able to use pypy due to lack of bindings, but that's another issue entirely), or for small services, for which pypy has provided a rather nice speed improvement.<br /><br />In a perfect world, I'd be able to use pypy for both of these tasks, not using STM for my GUI applications, but turning it on for the services I write (well, once they reach a certain point where I'd gain something from concurrency).<br /><br />I suspect having a separate build would make such a use-case awkward.<br /><br />Also, my interest is a bit self-motivated; at work we current use node.js for a lot of our services. Pypy compares decently for a lot of our tasks, but it not 'clearly better'. Once STM is stable, however, several of our services that we've struggled scaling to multiple cores on node.js could be rewritten in pypy STM, and should scale much easier. (Manual process management is painful!)<br /><br />Again, if pypy STM were a seperate build, we'd have to manage having both installed in the case where we have servers running services that need concurrency, or ones that work well enough with a very fast async implementation. Not impossible, just a bit awkward. :)<br /><br />Either way, I'm pretty excited!Anonymoushttps://www.blogger.com/profile/14377563935639716725noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-35074220459255102452013-08-21T10:12:34.697+02:002013-08-21T10:12:34.697+02:00@Anonymous: ah, thanks :-) I think I now learned ...@Anonymous: ah, thanks :-) I think I now learned the difference between "assembler" and "assembly" in English, which was never quite clear to me. Note that in french the same word ("assembleur") is used to mean both terms.Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-52117773733857681052013-08-21T10:05:55.639+02:002013-08-21T10:05:55.639+02:00@Christopher: the slow-down we'll get is still...@Christopher: the slow-down we'll get is still unknown, but I fear it won't really go well under 2x.<br /><br />I see it mainly as a separate build: either you want to run all these barrier instructions everywhere (which gives the slow-down) or not. It could be possible in theory to have a version that has the barriers everywhere, but creates JIT-generated assembler that doesn't, and thus runs almost as fast as a regular PyPy as long as you don't "turn on" STM. We will see if that makes sense.Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-79699795595008608832013-08-20T22:32:31.499+02:002013-08-20T22:32:31.499+02:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/14377563935639716725noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-90853382398276486672013-08-20T22:31:26.620+02:002013-08-20T22:31:26.620+02:00Thanks for the update; glad it's coming togeth...Thanks for the update; glad it's coming together! I'm really looking forward to seeing how it stacks up once the JIT work is complete.<br /><br />Do you think that it'll be possible to ever get better than a 2x slowdown for serial operations? Or is that the minimal possible? Naively, it makes sense that it'll never be as fast, but if 1.5x or lower were possible, that would be very exciting.<br /><br />Also, is the end goal that you would have a module you import to "turn on" STM? Or would it always be a separate build of pypy, just like JIT/JIT-less?Anonymoushttps://www.blogger.com/profile/14377563935639716725noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-63898347969060280112013-08-19T12:06:38.747+02:002013-08-19T12:06:38.747+02:00*assembly*assemblyAnonymousnoreply@blogger.com