111–120 of 147 posts
> (note that you must be using Python 2 for this workshop and not using Python 3. Complete this workshop using Python 2, then read about the small changes if you are interested in using Python 3) Why using legacy Python for this?
I get EOL/deprecation is here but lets not jump the gun to legacy just yet. I just see more 2 than 3 @ Day Job.
Earlier quoted context omitted.
Nothing against zeromq, its good s/w, but like all tools it must be used appropriately. ...also, nanomsg is the 'improved' successor. Also, MPI isn't a 'niche' thing, its the way that a large proportion of high-performance applications have been implemented for a few decades (think Crays & weather prediction). Zeromq has a few simple web-apps using it (I exagerate slightly).
Seems like you know quite a lot about this topic. Do you have any projects of your own that I can see? Or do you only work for your employer or something?
Anyone who has done any scientific or technical computing is highly likely to be familiar with it – it's been around in some form for over 25 years.
Earlier quoted context omitted.
I believe that since the Advent of zeromq, parallelism is possible in almost any language, including python. My library lets you do parallelism in a unique way, where you do message passing parallelism without being explicit about it. https://github.com/pycampers/zproc/
> My library lets you do parallelism in a unique way That's a big claim which you don't really back up as much as you need to. Unique is an extremely high bar in this very busy field. There are several other similar red flags on the linked GitHub; I think your enthusiasm is running away from you a little. You might want to dial the ten-dollar language back a bit – it made me immediately suspicious ("utterly perfect",…
http://zguide.zeromq.org/page:all#Multithreading-with-ZeroMQ
Thought linking it there would make it better, but I'll just remove it...
And you do make a good point. It doesn't really solve anything technically. But would you agree that it exposes a better API for doing much of the same stuff?
Earlier quoted context omitted.
why not re-write the workshop for python3 and require python2 users to wear the pain downgrade brings?
Because python2 is a deprecated language that will EOL?
Earlier quoted context omitted.
Seems like you know quite a lot about this topic. Do you have any projects of your own that I can see? Or do you only work for your employer or something?
MPI is extremely well-known: https://en.wikipedia.org/wiki/Message_Passing_Interface Anyone who has done any scientific or technical computing is highly likely to be familiar with it – it's been around in some form for over 25 years.
I use it everyday for some of my home baked apps, and would love if this really made a difference.
Earlier quoted context omitted.
A whole lot depends on what exactly it is that someone wants to get out of using threading. The GIL means that a single Python interpreter process can execute at most one Python thread at a time, regardless of the number of CPUs or CPU cores available on the host machine. The GIL also introduces overhead which affects the performance of code using Python threads; how much you're affected by it will vary depending on…
> All of this dates back to design decisions made in the 1990s which presumably seemed reasonable for the time ... Hence, the GIL and the set of tradeoffs it makes. Now, of course, we carry multi-core computers ... Hindsight is great at spotting that, but hindsight doesn't give us a time machine to go back and change the decisions. Sadly I don't think this is _quite_ true. I believe GILs are used in a number of inter…
The thing is, in the 90s the choices the produced the GIL as it exists were not bad ones; that's why I went to the trouble of explaining how it affects threaded code and why those effects can be considered reasonable tradeoffs for what was known at the time, in implementing threading (without completely breaking the ecosystem of Python + Python extensions, which was already significant even back then).
Of course, knowing what's known today about the directions computing and the use of Python went in, different decisions might end up being made, but at this point it's very difficult (more difficult than people typically expect) to undo them or make different choices.
Earlier quoted context omitted.
I believe that since the Advent of zeromq, parallelism is possible in almost any language, including python. My library lets you do parallelism in a unique way, where you do message passing parallelism without being explicit about it. https://github.com/pycampers/zproc/
> My library lets you do parallelism in a unique way That's a big claim which you don't really back up as much as you need to. Unique is an extremely high bar in this very busy field. There are several other similar red flags on the linked GitHub; I think your enthusiasm is running away from you a little. You might want to dial the ten-dollar language back a bit – it made me immediately suspicious ("utterly perfect",…
Earlier quoted context omitted.
MPI is extremely well-known: https://en.wikipedia.org/wiki/Message_Passing_Interface Anyone who has done any scientific or technical computing is highly likely to be familiar with it – it's been around in some form for over 25 years.
Do you think using this over zmq in my thingy would really bring much improvement? I use it everyday for some of my home baked apps, and would love if this really made a difference.
The problem here is the claims you're making. You've written some utility classes around 0MQ for some applications, which is a real thing, so I'd rewrite your GitHub readme to just demonstrate what problems you've solved with it (and at what kind of scale). Making big, sweeping claims gets you into these kinds of threads, because extraordinary claims require extraordinary evidence :-)
Earlier quoted context omitted.
> My library lets you do parallelism in a unique way That's a big claim which you don't really back up as much as you need to. Unique is an extremely high bar in this very busy field. There are several other similar red flags on the linked GitHub; I think your enthusiasm is running away from you a little. You might want to dial the ten-dollar language back a bit – it made me immediately suspicious ("utterly perfect",…
Update - I hopefully made the language a little better? https://github.com/pycampers/zproc/blob/master/README.md
Earlier quoted context omitted.
> My library lets you do parallelism in a unique way That's a big claim which you don't really back up as much as you need to. Unique is an extremely high bar in this very busy field. There are several other similar red flags on the linked GitHub; I think your enthusiasm is running away from you a little. You might want to dial the ten-dollar language back a bit – it made me immediately suspicious ("utterly perfect",…
'utterly perfect ' are not my words http://zguide.zeromq.org/page:all#Multithreading-with-ZeroMQ Thought linking it there would make it better, but I'll just remove it... And you do make a good point. It doesn't really solve anything technically. But would you agree that it exposes a better API for doing much of the same stuff?