tag:blogger.com,1999:blog-3971202189709462152.post6595343388141556320..comments2024-03-11T12:50:02.036+01:00Comments on PyPy Status Blog: Multicore Programming in PyPy and CPythonCarl Friedrich Bolz-Tereickhttp://www.blogger.com/profile/00518922641059511014noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-3971202189709462152.post-59891183190241031872015-09-22T08:53:45.214+02:002015-09-22T08:53:45.214+02:00Ammm... Jython 2.7.0 !
All pure Python syntax usi...Ammm... Jython 2.7.0 !<br /><br />All pure Python syntax using threading instantly go MULTI-CORE! All you need to do is replace the 'p' with a 'j' in your command and voila!<br /><br />;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-36519165028132148322012-09-06T22:02:43.118+02:002012-09-06T22:02:43.118+02:00I really believe that concurrency - like memory al...I really believe that concurrency - like memory allocation, GC and safe arrays - should be done without the user thinking about it...<br /><br />Languages like Erlang, ABCL and Concurrent Object Oriented C solves this quite elegant.<br /><br />Just make every Object a "process" (thread/greenlet) and every return value a Future and your are done :-)Anonymoushttps://www.blogger.com/profile/13558027109535076027noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-33180676725990990882012-09-06T16:04:45.199+02:002012-09-06T16:04:45.199+02:00I'm a little late, but regarding the simple le...I'm a little late, but regarding the simple let's-do-the-loop-concurrently example, if pypy-stm ends up working out as hoped, would it be relatively easy for pypy to do it automatically without having to use parallel loop thing explicitly?<br /><br />I have a hunch the answer would be yes, but that the hard part is figuring out when it makes sense and how to do the split (each thread needs a good chunk to work on).<br /><br />On the other hand, GCC has OpenMP which does seem really convenient and also looks like it has (or rather an implementation of that would have to have) solved part of this problem.<br /><br />Many years ago, I read about research in auto-parallellising compilers and it stroke me as a really hard problem. But if you can just do some magic with the loops, perhaps it's an attainable goal?Ole Laursenhttp://people.iola.dk/olau/noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-20534515551870678642012-08-19T12:58:39.552+02:002012-08-19T12:58:39.552+02:00@Mark D.: I don't know if "a dozen memory...@Mark D.: I don't know if "a dozen memory modification" comes from real work in the field or is just a guess. My own guess would be that Intel Haswell supports easily hunderds of modifications, possibly thousands. Moreover the built-in cache coherency mechanisms should be used here too, in a way that scales with the cache size; this means they should not be "prohibitively expensive".<br />Of course I know that in 0.1 seconds we do far more than thousands writes, but I think that nothing strictly limits the progression of future processors in that respect.<br /><br />The occurrence of conflicts in large transactions depends on two factors. First, "true conflicts", which is the hard problem, but which I think should be relatively deterministic and debuggable with new tools. Second, "false conflicts", which is the HTM/STM mechanism detecting a conflict when there is none. To handle large transactions this should occur with a probability very, very close to 0% for each memory access. In pypy-stm it is 0%, but indeed, with HTM it depends on how close to 0% they can get. I have no data on that.Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-69291537092253080582012-08-16T05:23:46.202+02:002012-08-16T05:23:46.202+02:000.1 second transactions? With hardware transactio...0.1 second transactions? With hardware transactional memory the general idea is transactions about ten thousand times smaller. A dozen memory modifications maybe. <br /><br />It would be prohibitively expensive, hardware wise, to implement conflict detection for transactions much larger than that, to say nothing of the occurrence of conflicts requiring rollback and re-execution if such enormously large transactions were executed optimistically.Mark D.noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-24673619791103628392012-08-14T22:50:30.942+02:002012-08-14T22:50:30.942+02:00Damn. And I thought I was being original. I can al...Damn. And I thought I was being original. I can already spot a few key places where kernel-based support would be superior (not only raw performance, but also transparency), but in general, that's exactly what I was talking about, sans transaction retrials.<br />klaussfreirehttps://www.blogger.com/profile/05255172019231560487noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-25088841623906772252012-08-14T21:18:38.213+02:002012-08-14T21:18:38.213+02:00@klaussfreire
is this perhaps what you are lookin...@klaussfreire<br /><br />is this perhaps what you are looking for: http://plasma.cs.umass.edu/emery/grace<br /><br />Cheers,<br />WimWim Lavrijsenhttps://www.blogger.com/profile/07891333377712029026noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-51738704883818418122012-08-14T16:43:25.251+02:002012-08-14T16:43:25.251+02:00@Armin, well, Python itself does know.
In my half...@Armin, well, Python itself does know.<br /><br />In my half-formed idea in my head, python would use thread-local versions of the integer pool and the various free lists, and allocation of new objects would be served from an also thread-local arena (while in a transaction).<br /><br />Read-write access to shared objects, yes, would be a little bit unpredictable. That's why I was wondering how good (if at all) it would work for Python.<br />klaussfreirehttps://www.blogger.com/profile/05255172019231560487noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-32554997294829060692012-08-14T10:12:32.728+02:002012-08-14T10:12:32.728+02:00@klaussfreire: that approach is a cool hack but un...@klaussfreire: that approach is a cool hack but unlikely to work in practice in a language like Python, because the user doesn't control at all what objects are together with what other objects on the same pages. Even with the reference counts moved out of the way I guess you'd have far too many spurious conflicts.Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-73812722530064053372012-08-14T00:35:12.904+02:002012-08-14T00:35:12.904+02:00Option 5, implement STM on the operating system. L...Option 5, implement STM on the operating system. Linux already has COW for processes, imagine COW-MERGE for threads.<br /><br />When you start transactional mode, all pages are marked read-only, thread-private and COW. When you commit, dirty pages are merged with the processes' page maps, unless conflicts arise (the process already has dirty pages).<br /><br />A simple versioning system and version checks would take care of conflict detection.<br /><br />I just wonder how difficult it would be designing applications that can run on this model (conflicts at page level vs object level). <br /><br />Thread-private allocation arenas are entirely possible to avoid new objects from creating conflicts all the time, so it would be a matter of making read-only use of objects really read-only, something I've done incrementally in patches already. Reference counts have to be externalized (taken out of PyObject), for instance.<br />klaussfreirehttps://www.blogger.com/profile/05255172019231560487noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-10985838616640576252012-08-12T09:26:11.265+02:002012-08-12T09:26:11.265+02:00There are two key concurrency patterns to keep in ...There are two key concurrency patterns to keep in mind when considering Armin's STM work:<br /><br />1. Event-loop based applications that spend a lot of time idling waiting for events.<br /><br />2. Map-reduce style applications where only the reduce step is particularly prone to resource contention, but the map step is read-heavy (and thus hard to split amongst multiple processes)<br /><br />For both of those use cases, splitting out multiple processes often won't pay off due to either the serialisation overhead or the additional complexity needed to make serialisation possible at all.<br /><br />Coarse-grained STM, however, should pay off handsomely in both of those scenarios: if the CPU bound parts of the application are touching different data structures, or are only *reading* any shared data, with any writes being batched for later application, then the STM interaction can be built in to the event loop or parallel execution framework.<br /><br />Will STM help with threading use cases where multiple threads are simultaneously reading and writing the same data structure? No, it won't. However, such applications don't exploit multiple cores effectively even with free threading, because their *lock* contention will also be high.<br /><br />As far as "just kill the GIL" goes, I've already written extensively on that topic: http://python-notes.boredomandlaziness.org/en/latest/python3/questions_and_answers.html#but-but-surely-fixing-the-gil-is-more-important-than-fixing-unicodeAnonymoushttps://www.blogger.com/profile/14824694805745746190noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-52368353615678589202012-08-10T23:04:41.032+02:002012-08-10T23:04:41.032+02:00@Benjamin: a user program might be optimized to re...@Benjamin: a user program might be optimized to reduce its memory usage, for example by carefully reusing objects instead of throwing them away, finding more memory-efficient constructs, and so on. But in many cases in Python you don't care too much. Similarly, I expect that it's possible to reduce the size of transactions by splitting them up carefully, hoping to get some extras in performance. But most importantly I'd like a system where the programmer didn't have to care overmuch about that. It should still work reasonably well for *any* size, just like a reasonable GC should work for any heap size.<br /><br />If I had to describe the main issue I have against HTM, it is that beyond some transaction size we loose all parallelism because it has to fall back on the GIL.<br /><br />Well, now that I think about it, it's the same in memory usage: if you grow past the RAM size, the program is suddenly swapping, and performance becomes terrible. But RAM sizes are so far much more generous than maximum hardware transaction sizes.Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-39298211765718471712012-08-10T22:17:27.976+02:002012-08-10T22:17:27.976+02:00@Armin I'd love to hear your thoughts (benefit...@Armin I'd love to hear your thoughts (benefits, costs, entrenched ideas, etc.) on large vs small transactions at some point. Though I suspect that would be a post unto itself.Benjaminhttps://www.blogger.com/profile/11979252184749589064noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-41953950075525172142012-08-10T19:15:47.813+02:002012-08-10T19:15:47.813+02:00Transactional programming is neat. So are Gorouti...Transactional programming is neat. So are Goroutines and functional-style parallelism. On the other hand, I think that C and C++ (or at least C1x and C++11) get one thing completely right: they don't try to enforce any particular threading model. For some problems (like reference counts, as you mention), you really do want a different model. As long as other languages force me to choose a single model, my big projects will stay in C/C++.Unknownhttps://www.blogger.com/profile/14315189513110054064noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-23066650262406923162012-08-10T09:57:57.141+02:002012-08-10T09:57:57.141+02:00@Anonymous: "So you may do all the book-keepi...@Anonymous: "So you may do all the book-keeping yourself in software, but then at commit time use HTM.": I don't see how (or the point), can you be more explicit or post a link?<br /><br />@Anonymous: I'm not saying that STM is the final solution to all problems. Some classes of problems have other solutions that work well so far and I'm not proposing to change them. Big servers can naturally handle big loads just by having enough processes. What I'm describing instead is a pure language feature that may or may not help in particular cases --- and there are other cases than the one you describe where the situation is very different and multiprocessing doesn't help at all. Also, you have to realise that any argument "we will never need feature X because we can work around it using hack Y" is bound to lose eventually: at least some people in some cases will need the clean feature X because the hack Y is too complicated to learn or use correctly.<br /><br />@Benjamin: "atomic" actually means "not decomposable", not necessarily "as small as possible". This focus on smallness of transaction IMO is an artefact of last decade's research focus. In my posts I tend to focus on large transaction as a counterpoint: in the use cases I have in mind there is no guarantee that all transactions will be small. Some of them may be, but others not, and this is a restriction. In things like "one iteration through this loop = one transaction", some of these iterations go away and do a lot of stuff.Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-15926290367313416592012-08-10T08:27:37.456+02:002012-08-10T08:27:37.456+02:00I get the overall goals and desires and I think th...I get the overall goals and desires and I think they are fabulous. However, one notion that seems counterintuitive to me is the desire for large atomic operations.<br /><br />Aside from the nomenclature (atomic generally means smallest possible), my intuition is that STM would generally operate more efficiently by having fewer roll-backs with small atomic operations and frequent commits. This leads me to assume there is some sort of significant overhead involved with the setup or teardown of the STM 'wrapper'.<br /><br />From a broader perspective, I get that understanding interlacing is much easier with larger pieces, but larger pieces of code don't lend themselves to wide distribution across many cores like small pieces do.<br /><br />It seems, to me, that you're focusing heavily on the idea of linearly written code magically functioning in parallel and neglecting the idea of simple, low-cost concurrency, which might have a much bigger short-term impact; and which, through use, may shed light on better frameworks for reducing the complexity inherent in concurrency.Benjaminhttps://www.blogger.com/profile/11979252184749589064noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-47122625150305578442012-08-09T22:27:13.617+02:002012-08-09T22:27:13.617+02:00@Anonymous.
I welcome you to work out how to make...@Anonymous.<br /><br />I welcome you to work out how to make pypy translation process parallel using any techniques you described.Maciej Fijalkowskihttps://www.blogger.com/profile/11410841070239382771noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-83666534313685324412012-08-09T20:59:31.897+02:002012-08-09T20:59:31.897+02:00template processing. lol.template processing. lol.Anonymoushttps://www.blogger.com/profile/07463865744282267557noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-65967029681979562572012-08-09T20:54:47.023+02:002012-08-09T20:54:47.023+02:00Jesus Christ why don't we all just spend 5 min...Jesus Christ why don't we all just spend 5 min fiddling with the multiprocessing module and learn how to partition execution and queues like we partition sequences of statements into functions? So sick of GIL articles and the obsession with not learning how to divide up the work and communicate. In some ways the need to recognize narrow channels where relatively small amounts of data are being channeled through relatively intense blocks of execution and create readable, explicit structure around those blocks might actually improve the comprehensibility of some code I've seen. Getting a little tired of seeing so much effort by excellent, essential, dedicated Python devs getting sucked up by users who won't get it.<br><br />I think users are driving this speed-for-free obsession way to far. If anything bugs in a magical system are harder to find than understanding explicit structure and explicit structure that's elegant is neither crufty nor slow. Eventually, no interpreter will save a bad programmer. Are we next going to enable the novice "Pythonista" to forego any knowledge of algorithms? <br><br />We -need- JIT on production systems to get response times down for template processing without micro-caching out the wazoo. These types of services are already parallel by nature of the servers and usually I/O bound except for the few slow parts. Cython already serves such an excellent roll for both C/C++ API's AND speed AND optimizing existing python code with minimal changes. JIT PyPy playing well with Cython would make Python very generally uber. Users who actually get multiprocessing and can divide up the workflow won't want a slower implementation of any other kind. Getting a somewhat good solution for 'free' is not nearly as appealing as the additional headroom afforded by an incremental user cost (adding some strong typing or patching a function to work with pypy/py3k).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-42607993077760804092012-08-09T18:32:12.972+02:002012-08-09T18:32:12.972+02:00What does 'just killing the damn GIL' mean...What does 'just killing the damn GIL' mean without something like STM? Do you consider it acceptable for Python primitives not to be threadsafe?<br /><br />If you intend to run 64 cores, then what is the exact reason you need threading and can't use multiprocessing?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-23114705505089768362012-08-09T17:37:50.261+02:002012-08-09T17:37:50.261+02:00No. We really do want a GIL-free Python. Even if t...No. We really do want a GIL-free Python. Even if that means we sometimes need to deal with locks.<br /><br />Right now a high end server can have 64 cores. That means that parallel python code could run faster than serial C code.<br /><br />STM and other high level abstractions are neat, but they're no substitute for just killing the damn GIL.Nat Tucknoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-46903846934035159772012-08-09T16:53:53.668+02:002012-08-09T16:53:53.668+02:00With HTM you don't have to have a one-to-one m...With HTM you don't have to have a one-to-one mapping between your application transactions and the hardware interface. You can also have an STM, that is implemented using HTM. So you may do all the book-keeping yourself in software, but then at commit time use HTM.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-46105852411367558712012-08-09T13:55:40.500+02:002012-08-09T13:55:40.500+02:00@John: I didn't foresee this development at th...@John: I didn't foresee this development at the start of the year, so I don't know. It's a topic that would need to be discussed internally, likely with feedback from past donators.<br /><br />Right now of course I'm finishing the basics of pypy-stm (working on the JIT now), and from there on there is a lot that can be done as pure Python, like libraries of better-suited data structures --- and generally gaining experience that would anyway be needed for CPython's work.Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-46948233144493726902012-08-09T13:29:28.892+02:002012-08-09T13:29:28.892+02:00A question: does a “donate towards STM/AME in pypy...A question: does a “donate towards STM/AME in pypy” also count as a donation towards the CPython work? Getting the hooks in CPython to allow exploration and implementation of this seems at least as important as the pypy work. In fact, I think it’s quite a bit more important.JohnLentonhttps://www.blogger.com/profile/14649043170344448278noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-12420799555138793772012-08-09T10:41:46.140+02:002012-08-09T10:41:46.140+02:00This comment has been removed by the author.Armin Rigohttps://www.blogger.com/profile/06300515270104686574noreply@blogger.com