Skip to content
This repository was archived by the owner on Jun 24, 2026. It is now read-only.
This repository was archived by the owner on Jun 24, 2026. It is now read-only.

macOS Performance: Document multiprocessing limitations and workarounds #2671

Description

@dguido

Problem

Manticore's multiprocessing capabilities are limited on macOS due to platform differences:

  • Linux uses fork() for fast process creation with copy-on-write memory
  • macOS has deprecated fork() due to safety issues, must use spawn() which is slower
  • Default workaround: Manticore defaults to threading on macOS, limiting parallelism due to Python's GIL

Solution Implemented

We've added support for spawn-based multiprocessing on macOS. While not as fast as Linux's fork, it provides true parallelism and can be significantly faster than threading for CPU-bound workloads.

Usage

Command Line

manticore --core.mprocessing=multiprocessing your_contract.sol

Configuration File (.manticore.yaml)

core:
  mprocessing: multiprocessing
  procs: 4  # Number of worker processes

Python API

from manticore import config
config.get_group("core").mprocessing = "multiprocessing"

Performance Expectations

Mode Best For
threading (macOS default) Small explorations, I/O-bound tasks
multiprocessing (with spawn) Large explorations, CPU-bound tasks
single Debugging, small problems

Typical speedups for CPU-intensive symbolic execution:

  • Small contracts (<100 states): Threading may be faster
  • Medium contracts (100-1000 states): Multiprocessing ~1.5-2x faster
  • Large contracts (>1000 states): Multiprocessing ~2-4x faster

Limitations

  1. Spawn overhead: Each worker must reimport modules (~1-2 seconds startup)
  2. Serialization: All shared state must be pickle-able
  3. Memory usage: Each process has its own Python interpreter

Recommendations

  1. For best performance: Use Linux (native or Docker/VM)
  2. On macOS with large problems: Try multiprocessing mode
  3. For quick tests: Default threading mode is fine
  4. For debugging: Use single mode

Future Improvements

Potential optimizations to explore:

  1. Ray or Dask for better serialization handling
  2. Process pools to reuse workers
  3. Shared memory for large readonly data
  4. Native extensions to avoid GIL

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions