https://arxiv.org/abs/2603.04782

Skip to main content
Cornell University
We gratefully acknowledge support from the Simons Foundation, member
institutions, and all contributors. Donate
 
arxiv logo > cs > arXiv:2603.04782
[                    ]

Help | Advanced Search

[All fields        ]
Search
arXiv logo
Cornell University Logo
[                    ] GO
quick links

  * Login
  * Help Pages
  * About

Computer Science > Distributed, Parallel, and Cluster Computing

arXiv:2603.04782 (cs)
[Submitted on 5 Mar 2026]

Title:Unlocking Python's Cores: Hardware Usage and Energy
Implications of Removing the GIL

Authors:Jose Daniel Montoya Salazar
View a PDF of the paper titled Unlocking Python's Cores: Hardware
Usage and Energy Implications of Removing the GIL, by Jos\'e Daniel
Montoya Salazar
View PDF HTML (experimental)

    Abstract:Python's Global Interpreter Lock prevents execution on
    more than one CPU core at the same time, even when multiple
    threads are used. However, starting with Python 3.13 an
    experimental build allows disabling the GIL. While prior work has
    examined speedup implications of this disabling, the effects on
    energy consumption and hardware utilization have received less
    attention. This study measures execution time, CPU utilization,
    memory usage, and energy consumption using four workload
    categories: NumPy-based, sequential kernels, threaded numerical
    workloads, and threaded object workloads, comparing GIL and
    free-threaded builds of Python 3.14.2.
    The results highlight a trade-off. For parallelizable workloads
    operating on independent data, the free-threaded build reduces
    execution time by up to 4 times, with a proportional reduction in
    energy consumption, and effective multi-core utilization, at the
    cost of an increase in memory usage. In contrast, sequential
    workloads do not benefit from removing the GIL and instead show a
    13-43% increase in energy consumption. Similarly, workloads where
    threads frequently access and modify the same objects show
    reduced improvements or even degradation due to lock contention.
    Across all workloads, energy consumption is proportional to
    execution time, indicating that disabling the GIL does not
    significantly affect power consumption, even when CPU utilization
    increases. When it comes to memory, the no-GIL build shows a
    general increase, more visible in virtual memory than in physical
    memory. This increase is primarily attributed to per-object
    locking, additional thread-safety mechanisms in the runtime, and
    the adoption of a new memory allocator.
    These findings suggest that Python's no-GIL build is not a
    universal improvement. Developers should evaluate whether their
    workload can effectively benefit from parallel execution before
    adoption.

Subjects:    Distributed, Parallel, and Cluster Computing (cs.DC);
             Performance (cs.PF)
ACM classes: D.3.4; D.3.3; C.4
Cite as:     arXiv:2603.04782 [cs.DC]
             (or arXiv:2603.04782v1 [cs.DC] for this version)
             https://doi.org/10.48550/arXiv.2603.04782
             Focus to learn more
             arXiv-issued DOI via DataCite (pending registration)

Submission history

From: Jose Montoya [view email]
[v1] Thu, 5 Mar 2026 04:01:30 UTC (166 KB)
Full-text links:

Access Paper:

    View a PDF of the paper titled Unlocking Python's Cores: Hardware
    Usage and Energy Implications of Removing the GIL, by Jos\'e
    Daniel Montoya Salazar
  * View PDF
  * HTML (experimental)
  * TeX Source

view license
Current browse context:
cs.DC
< prev   |   next >
new | recent | 2026-03
Change to browse by:
cs
cs.PF

References & Citations

  * NASA ADS
  * Google Scholar
  * Semantic Scholar

export BibTeX citation Loading...

BibTeX formatted citation

x
[loading...          ]
Data provided by:

Bookmark

BibSonomy logo Reddit logo
(*) Bibliographic Tools

Bibliographic and Citation Tools

[ ] Bibliographic Explorer Toggle
Bibliographic Explorer (What is the Explorer?)
[ ] Connected Papers Toggle
Connected Papers (What is Connected Papers?)
[ ] Litmaps Toggle
Litmaps (What is Litmaps?)
[ ] scite.ai Toggle
scite Smart Citations (What are Smart Citations?)
( ) Code, Data, Media

Code, Data and Media Associated with this Article

[ ] alphaXiv Toggle
alphaXiv (What is alphaXiv?)
[ ] Links to Code Toggle
CatalyzeX Code Finder for Papers (What is CatalyzeX?)
[ ] DagsHub Toggle
DagsHub (What is DagsHub?)
[ ] GotitPub Toggle
Gotit.pub (What is GotitPub?)
[ ] Huggingface Toggle
Hugging Face (What is Huggingface?)
[ ] Links to Code Toggle
Papers with Code (What is Papers with Code?)
[ ] ScienceCast Toggle
ScienceCast (What is ScienceCast?)
( ) Demos

Demos

[ ] Replicate Toggle
Replicate (What is Replicate?)
[ ] Spaces Toggle
Hugging Face Spaces (What is Spaces?)
[ ] Spaces Toggle
TXYZ.AI (What is TXYZ.AI?)
( ) Related Papers

Recommenders and Search Tools

[ ] Link to Influence Flower
Influence Flower (What are Influence Flowers?)
[ ] Core recommender toggle
CORE Recommender (What is CORE?)

  * Author
  * Venue
  * Institution
  * Topic

( ) About arXivLabs

arXivLabs: experimental projects with community collaborators

arXivLabs is a framework that allows collaborators to develop and
share new arXiv features directly on our website.

Both individuals and organizations that work with arXivLabs have
embraced and accepted our values of openness, community, excellence,
and user data privacy. arXiv is committed to these values and only
works with partners that adhere to them.

Have an idea for a project that will add value for arXiv's community?
Learn more about arXivLabs.

Which authors of this paper are endorsers? | Disable MathJax (What is
MathJax?)

  * About
  * Help

  * Click here to contact arXiv Contact
  * Click here to subscribe Subscribe

  * Copyright
  * Privacy Policy

  * Web Accessibility Assistance
  * arXiv Operational Status