Re:Larry Wall has approved renaming Perl 6 to Raku
by weff_ on Friday October 11, 2019 @05:54PM
(#21228830)
I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
[ Parent
| on HN ]
Re:Larry Wall has approved renaming Perl 6 to Raku
by nuclear_eclipse on Friday October 11, 2019 @06:54PM
(#21229198)
If it's entirely CPU bound, you can use multiprocessing to negate most of the GIL issues, and transparently send inputs/outputs between the parent and child processes. If it's I/O bound, then AsyncIO is a great way to express asynchronous workflows. If it's a combination of both I/O and CPU bound workloads, there are ways to mix multiprocessing and AsyncIO to better saturate your cores without losing the simplicity or readability of Python: https://github.com/jreese/aiomultiprocess
Re:Larry Wall has approved renaming Perl 6 to Raku
by weff_ on Friday October 11, 2019 @08:41PM
(#21229691)
Very true, I had not even thought about the multiprocessing package; it's sometimes not as convenient as multithreading but it'll get those other cores working.
Re:Larry Wall has approved renaming Perl 6 to Raku
by Grinnz on Friday October 11, 2019 @06:05PM
(#21228921)
Indeed and as a Perl developer I make use of XS/external libraries, cooperative multitasking (event loops/promises), and forking to cover these use cases. It doesn't preclude wanting the additional option to take advantage of threads in a useful way, since they do exist.