Skip to content

macOS Performance: Document multiprocessing limitations and workarounds #2671

@dguido

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

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