Ray Tracer in Python (Part 6) - Show Notes of "Firing All Cores"

When it comes to code optimization, there is an overused statement about Premature Optimization. Here is the rarely-shown full quote:

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” – Donald Knuth

I understand this as not worrying about small optimizations all the time. It is best to focus on the areas which have the most return on (time) investment. Usually you need to do extensive performance measurements to find those areas but there are some natural places to look.

So far, we have been not too concerned about performance especially when it affected readability (else we wouldn’t be writing it in Python). However, in the previous part we got a huge speedup by switching to the PyPy interpreter.

To me the next big opportunity lies in using all the cores. As an experienced Python programmer, I know this means using the multiprocessing module. But I also need to explain why other options, notably Python threads, would not help.

To demonstrate this I wrote a multi-threaded C program, a multi-threaded Python program and a multi-processing Python program - all doing the same thing. What was most entertaining was to watch the GIL in action where it allows only one thread to execute at a time.

Race Conditions

Race conditions are often explained using a bank ATM example. I think it can be explained in a non technical way using many real life scenarios. I wanted to explain it using a cooking example. It’s weird how many asynchronous and parallel concepts can be taught using what we do in the kitchen. So much so that technical job interviews can be made more effective by simply checking your culinary skills (“Sorry we don’t have a whiteboard, just a cutting board for you.").

Ideally the entire explanation should be animated. My drawing skills are decent but I cannot animate even a bouncing ball. Don’t laugh, just try it. Firstly, there are several cues that any animated object gives which can be only be detected if you watch in slow motion. The Twelve Principles of Animation is a good start.

Secondly, it is a lot of work. A good animator will know how to give maximum expression with the minimum frames. Timing is also crucial in animation. Even a subtle timing error makes animations look janky or confusing. Mere mortals would need to spend days to eventually produce a 5 second clip.

So I took the safe approach by showing a slideshow. I think it looks decent. I might post it as a separate clip on Race Conditions so that is doesn’t get lost in this video.

These are the topics we will cover in this episode:

• Introduction
  • An Embarrassingly Parallel Problems
  • What’s a Thread?
  • Threads in C
  • Threads in Python
  • Race Condition Animated
  • Why Python has GIL
  • Multi-processing in Python
• Sub-problem: Firing All Cores
• Coding the solution
  • Command-line argument
  • Diving pixels among processes
  • Passing Data via Files
  • Value for Progressbar
  • Bug Hunting
• Performance Comparison
• Topics Not Covered
• Learning More
• Final Words

Here is the video:

Code for part six is tagged on the Puray Github project

Show Notes

Books and articles that can help understand this part:

• The Art of Multiprocessor Programming book
• The Ray Tracer Challenge book
• Ray Tracing in One Weekend free books
• NVIDIA Ray Tracing Essentials

Note: References may contain affiliate links

Wrapping up

This concludes the ray tracing series that I had conceived more than a year back. If you make your own ray tracer, please don’t forget to tag me.