https://github.com/jimblandy/rust-mandelbrot
https://github.com/jimblandy/rust-mandelbrot
Last synced: 3 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/jimblandy/rust-mandelbrot
- Owner: jimblandy
- Created: 2016-07-26T20:09:29.000Z (almost 9 years ago)
- Default Branch: master
- Last Pushed: 2016-12-12T16:53:43.000Z (over 8 years ago)
- Last Synced: 2025-03-17T16:03:28.072Z (3 months ago)
- Language: Rust
- Size: 209 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# A Parallel Mandelbrot Set Plotter
This program plots the Mandelbrot set and writes it out as a PNG file. It uses Rust's concurrency primitives to distribute the work across eight threads.
Different commits show different implementation strategies:
- Commit 218c0d6 splits the plotting area up into eight bands, and assigns one
thread to each. This often makes poor use of the threads, because some bands
take significantly longer than others to complete: once a fast thread
completes its band, it twiddles its thumbs waiting for its less fortunate
bretheren to finish their tasks.
- Commit ca5f89b gets an almost perfect linear speedup from its threads. It
splits the plotting area up into many more bands, and then has threads draw
bands from a common pool until the pool is empty. When a thread finishes one
band, it goes back for more work. Since the bands still take different amounts
of time to render, the problem cited above still occurs, but on a much smaller
scale.
- Commit ad81b19 uses Rust's atomic types to implement a lock-free iterator
type, and uses that to dole out bands from the pool instead of a
mutex-protected count. On Linux, this is no faster than the mutex-based
version, which isn't too surprising: on Linux, locking and unlocking an
uncontended mutex *is* simply a pair of atomic operations.