PS.: I should add that, in this context, the GO runtime is interesting, as it puts away several of those limitations. So I do understand the rationale behind this I guess. As others above, I don't really see the advantages of simply using GO directly, or any other mature language. My guess is that there is too much Python code around to simply abandon or re-implement it.
Unfortunately, the GIL does not only inhibit performance scaling with threads, it causes performance to scale *negatively* on multicore systems. Don't believe me? Try to run a threaded code on a single core system, and then on multicore systems (`cpusets` come in handy for this test). That holds for I/O bound threads just as well as for CPU bound ones or mixtures thereof. Singlecore systems are hard to find nowadays, and cpusets are not always available (in terms of permission and kernel support), and it impacts process based scaling obviously. Negative scaling is hard to accept (for my use cases at least).
Further, the GIL causes some strangeness (to put it mildly) with respect to signals and interrupt handling -- simply put, signals and interrupts can get lost in multithreaded python codes, which makes mix of threading and processing *very* cumbersome and unstable.
*Only* using multiprocessing is hard, too, for two reasons: not having threads makes async programming difficult (think GUIs). It makes I/O or event driven applications much harder. And, multiprocessing has its own quirks: ever tried to spawn a process in a daemon (hits an `assert`)? Ever tried to pass around a process handle to a central process manager (`wait()` will cease to work)? And some other funny things. Python does not make any serious attempt to provide POSIX level process handling, in my opinion, and that shows for non-trivial use cases.
In summary: people like me whining about the GIL have more reasons than performance. But, performance is one, too. Threading in Python is in a sorry state, and that is a shame. There is no solution in sight.
Python is a neat language. I would not ever (again) recommend it for production code.
I saw the recordings on different outlets -- but here might be the right place to ask: the exit velocity is quite impressive, but in the recordings, it seems to me that to the middle and right end, some structures look almost stationary. Can anyone of you judge if that is a visual artifact of the camera (which would make it somewhat useless I think), or an actual physical phenomenon?
It might be the year of the linux desktop, but I for one do not have root access on the majority of boxes I work on -- so now I will have to chase each individual admin to get screen working again. And explain to them why the have to deviate from default settings. And 'security' popping up on the first google search on why that default now exists.
Thanks very much, I am looking forward to wonderful discussions about non-default security settings on machines for which I need to jump hoops to get on in the first place...:/
... shouldn't be too difficult? Well, as long as you stay away from dependencies, and just limit concurrency to services with the same priority... What is it you worry about?
Unfortunately, the west does seem to care what government exists in Iran, Iraq, Egypt, Lybia, Syria, Afghanistan, Pakistan yada yada. Its not like we leave those countries to sort that out for themselves, do we?
story time:)
I once created a dir in/etc/, by accident, with a control character. The dir was '^.' I stupidly ran 'rm -rf ^.' on that thing. Took quite a while to recover the system (we managed to recover w/o reboot! Yay!)
Slashdot Mirror
PS.: I should add that, in this context, the GO runtime is interesting, as it puts away several of those limitations. So I do understand the rationale behind this I guess. As others above, I don't really see the advantages of simply using GO directly, or any other mature language. My guess is that there is too much Python code around to simply abandon or re-implement it.
Unfortunately, the GIL does not only inhibit performance scaling with threads, it causes performance to scale *negatively* on multicore systems. Don't believe me? Try to run a threaded code on a single core system, and then on multicore systems (`cpusets` come in handy for this test). That holds for I/O bound threads just as well as for CPU bound ones or mixtures thereof. Singlecore systems are hard to find nowadays, and cpusets are not always available (in terms of permission and kernel support), and it impacts process based scaling obviously. Negative scaling is hard to accept (for my use cases at least).
Further, the GIL causes some strangeness (to put it mildly) with respect to signals and interrupt handling -- simply put, signals and interrupts can get lost in multithreaded python codes, which makes mix of threading and processing *very* cumbersome and unstable.
*Only* using multiprocessing is hard, too, for two reasons: not having threads makes async programming difficult (think GUIs). It makes I/O or event driven applications much harder. And, multiprocessing has its own quirks: ever tried to spawn a process in a daemon (hits an `assert`)? Ever tried to pass around a process handle to a central process manager (`wait()` will cease to work)? And some other funny things. Python does not make any serious attempt to provide POSIX level process handling, in my opinion, and that shows for non-trivial use cases.
In summary: people like me whining about the GIL have more reasons than performance. But, performance is one, too. Threading in Python is in a sorry state, and that is a shame. There is no solution in sight.
Python is a neat language. I would not ever (again) recommend it for production code.
I saw the recordings on different outlets -- but here might be the right place to ask: the exit velocity is quite impressive, but in the recordings, it seems to me that to the middle and right end, some structures look almost stationary. Can anyone of you judge if that is a visual artifact of the camera (which would make it somewhat useless I think), or an actual physical phenomenon?
It might be the year of the linux desktop, but I for one do not have root access on the majority of boxes I work on -- so now I will have to chase each individual admin to get screen working again. And explain to them why the have to deviate from default settings. And 'security' popping up on the first google search on why that default now exists. Thanks very much, I am looking forward to wonderful discussions about non-default security settings on machines for which I need to jump hoops to get on in the first place... :/
replying to revert a wrong mod rating - sorry...
thanks for those links -- I was not aware of either distro, and they look neat and usable indeed, will check them out!
Consider that this might say more about what we know about the nature of other forces...
... shouldn't be too difficult? Well, as long as you stay away from dependencies, and just limit concurrency to services with the same priority... What is it you worry about?
They can open a mirror of any OSS project, no matter if it lived on SF to begin with. That does not invalidate the point of the parent poster...
I doubt it ... :P
Unfortunately, the west does seem to care what government exists in Iran, Iraq, Egypt, Lybia, Syria, Afghanistan, Pakistan yada yada. Its not like we leave those countries to sort that out for themselves, do we?
Pastime. Try not to type words you've only heard but never seen in print.
Butt thats the madgority of woords?
you call it vision, I call it nightmare... :/
story time :)
I once created a dir in /etc/, by accident, with a control character. The dir was '^.' I stupidly ran 'rm -rf ^.' on that thing. Took quite a while to recover the system (we managed to recover w/o reboot! Yay!)
"Freiheit ist immer Freiheit der Andersdenkenden."
"Freedom is always the freedom of dissenters."
- Rosa Luxemburg