Python performance

AI race for programming languages

Python, Python, dear Python

Can Python, the language powering most of the AI ecosystem, truly conquer parallelism?

Python, a behemoth in the AI development world, has an undeniable dominance. Yet, a glaring omission has plagued it for years: native, seamless support for parallelism. In an era where hardware boasts multiple cores and users expect snappy responses, this limitation is increasingly conspicuous.

The Need for Speed (and Parallelism):

Past few months, I have been contemplating approaches that can give a performance boost to Google’s Python libraries, for example. I stumbled on issues with the GIL (global interpreter lock). I stumbled upon a problem that I cannot just accept is there in the world, the same as the one described in my earlier PHP’s lack of parallelism blog. We all know the famous stats on how Python is THE most common language in the world, but I am always amazed that it still lacks parallelism out of the box. It was so weird that I am thinking of switching teams internally within Google, rather than being optimistic about changing the state of affairs.

Tackling the Global Interpreter Lock:

The GIL, designed to simplify memory management, becomes a bottleneck in multi-threaded applications. This design choice impacts the performance of CPU-bound tasks, leaving developers to seek workarounds like multiprocessing or leveraging external libraries such as NumPy. While these solutions offer some relief, they don’t address the core issue.

So, as the news suggests, it appears Python version 3.13 (or possibly 3.14), will have no GIL versions. :revolving_hearts: :confetti_ball:

Exploring Alternatives:

Several solutions have been proposed to mitigate Python’s parallelism woes:

  • Multiprocessing: By spawning multiple processes, developers can bypass the GIL. However, this approach has its drawbacks, including increased memory usage and inter-process communication overhead.

  • Asyncio: Suitable for I/O-bound tasks, asyncio enables concurrency without parallelism, allowing developers to write asynchronous code that scales efficiently.

  • Cython: By compiling Python code to C, Cython can help achieve parallelism. It requires additional effort to convert and optimize code, but the performance gains can be significant.

  • Alternative Interpreters: PyPy, a just-in-time compiler, and Jython, which runs on the Java platform (really! but why?), offer performance improvements. Yet, they come with their own set of compatibility issues and limitations.

The Future of Python:

The Python community is actively exploring ways to overcome the GIL. Projects like PEP 554, which proposes multiple sub-interpreters to allow concurrent execution of Python code, are steps in the right direction. However, these changes will take time to mature and be widely adopted.

Python has tentacles too. I am following the pyscript project, which aims to run Python and its packages in a browser environment. Given so much community effort to have Python rule the world, I am sure it has an amazingly fast future. Just that it’s nowhere in sight yet!

Conclusion:

Python’s ease of use, readability, and extensive library support make it a favourite among developers for several years in a row, especially in the AI space. However, its struggle with parallelism remains a significant hurdle and nuisance for developers like me. While workarounds exist, they often complicate development and introduce new challenges. The hope is that ongoing efforts within the Python community will eventually address these issues, allowing Python to fully leverage modern hardware capabilities.

As developers, it’s crucial to stay informed about these developments and adapt our strategies accordingly. While Python’s parallelism problem is a current pain point, its potential solutions promise a brighter, more efficient future.

TECH
Python Parallelism Concurrency Performance

Dialogue & Discussion