<p>I've seen both, unfortunately. I'm not fond of rays per second as meaning exclusively primary rays and I'd suggest "paths per second" or better yet "samples per second" instead. "Complete ray" is not a common term: a ray is a (potentially unbounded) line segment and a sequence of rays is a path.</p>

<p>Rays per second in your second sense of total ray casts is not well-specified for a path tracer: do shadow rays count, for instance? It's a useful metric for evaluating an acceleration structure or intersection testing framework (i.e. Embree or OptiX) but I'd avoid it for a renderer.</p>

<p>Finally, be aware that samples per second still isn't a great metric of actual performance since sample quality will vary wildly depending on implementation details. It's probably the best thing you can do starting out though, as the better solutions involve fairly complex variance estimates.</p>

CC BY-SA 3.0
2016-05-01T13:59:28.150Z
Great answer. To add to it, since it is hard to come up with one metric that is universally meaningful, I'd suggest you pick one that makes most sense / is most honest for your usage case, and make sure you explain what you mean by your terminology.
Alan Wolfe
CC BY-SA 3.0
2016-05-08T19:42:39.173Z
Yeah right, thank you for clearing my thoughts! Currently I choose the "samples per second" since it is easy to understand and hard to be misunderstood IMO. I'll eventually implement something that can calculate variance and measure rendering performance based on that.
D01phiN
CC BY-SA 3.0
2016-04-30T22:55:42.313Z
2016-04-30T22:55:42.313Z
Karl Schmidt
<p>Recently I'm developing a Monte-Carlo path tracer. To measure my tracer's performance, I decided to implement a simple mechanism to count how many rays can it trace in a second. Then here comes the problem, there are two ways to define a single ray:</p>

<blockquote>
  <ol>
  <li><p>A complete ray, i.e., starting from camera and bouncing around the scene until it terminates.</p></li>
  <li><p>The ray originated from each intersection point.</p></li>
  </ol>
</blockquote>

<p>Although many people use "Rays per Second" to measure ray/path tracer's performance, how they recognize "rays" is unclear to me. Perhaps anybody knows?</p>

CC BY-SA 3.0
2016-04-30T21:20:15.810Z
I've seen both, unfortunately. I'm not fond of ray per second as meaning exclusively primary rays and I'd suggest "paths per second" or  "samples per second" instead. "Complete ray" is not a name you'll find elsewhere: a ray is an unbounded line segment. "Rays per second" is ill specified for a path tracer: do shadow rays count, for instance? It's a useful metric for an acceleration framework (i.e. Embree or OptiX) but not a renderer.
Karl Schmidt
CC BY-SA 3.0
2016-04-30T21:30:43.067Z
Also, be aware that samples per second still isn't a great metric of actual performance since sample quality will vary wildly depending on implementation details. It's probably the best thing you can do starting out though, as the better solutions involve fairly complex variance estimates.
Karl Schmidt
CC BY-SA 3.0
2016-04-30T22:05:09.677Z
@KarlSchmidt I think you should post those comments as an answer ;)
Nathan Reed
CC BY-SA 3.0
2016-04-30T22:56:45.753Z
Probably a good idea, yes. :)
Karl Schmidt
<raytracing><performance><pathtracing><monte-carlo>
How does everyone count "Rays per Second"?
D01phiN
# How does everyone count "Rays per Second"?

(Asked by: username_0 on 2016-04-30)

Recently I'm developing a Monte-Carlo path tracer. To measure my tracer's performance, I decided to implement a simple mechanism to count how many rays can it trace in a second. Then here comes the problem, there are two ways to define a single ray:

> 1. A complete ray, i.e., starting from camera and bouncing around the scene until it terminates.
> 2. The ray originated from each intersection point.

Although many people use "Rays per Second" to measure ray/path tracer's performance, how they recognize "rays" is unclear to me. Perhaps anybody knows?

**Tags:** raytracing, performance, pathtracing, monte-carlo

> **Comments:**
> **username_1**: I've seen both, unfortunately. I'm not fond of ray per second as meaning exclusively primary rays and I'd suggest "paths per second" or  "samples per second" instead. "Complete ray" is not a name you'll find elsewhere: a ray is an unbounded line segment. "Rays per second" is ill specified for a path tracer: do shadow rays count, for instance? It's a useful metric for an acceleration framework (i.e. Embree or OptiX) but not a renderer.  
> **username_1**: Also, be aware that samples per second still isn't a great metric of actual performance since sample quality will vary wildly depending on implementation details. It's probably the best thing you can do starting out though, as the better solutions involve fairly complex variance estimates.  
> **username_2**: @username_1 I think you should post those comments as an answer ;)  
> **username_1**: Probably a good idea, yes. :)  

---

## 1 answers

### Answer by username_1 on 2016-04-30. Score: 4 | Accepted answer

I've seen both, unfortunately. I'm not fond of rays per second as meaning exclusively primary rays and I'd suggest "paths per second" or better yet "samples per second" instead. "Complete ray" is not a common term: a ray is a (potentially unbounded) line segment and a sequence of rays is a path.

Rays per second in your second sense of total ray casts is not well-specified for a path tracer: do shadow rays count, for instance? It's a useful metric for evaluating an acceleration structure or intersection testing framework (i.e. Embree or OptiX) but I'd avoid it for a renderer.

Finally, be aware that samples per second still isn't a great metric of actual performance since sample quality will vary wildly depending on implementation details. It's probably the best thing you can do starting out though, as the better solutions involve fairly complex variance estimates.

> **Comments:**
> **username_3**: Great answer. To add to it, since it is hard to come up with one metric that is universally meaningful, I'd suggest you pick one that makes most sense / is most honest for your usage case, and make sure you explain what you mean by your terminology.  
> **username_0**: Yeah right, thank you for clearing my thoughts! Currently I choose the "samples per second" since it is easy to understand and hard to be misunderstood IMO. I'll eventually implement something that can calculate variance and measure rendering performance based on that.  

---

