3 ms·

> When your render times are 6 hours per frame Ok, let's say we're rendering at 8K (32 megapixels), 200 rays per pixel, 20 bounces per ray. And rendering that

by clarry 7y ago

> When your render times are 6 hours per frame Ok, let's say we're rendering at 8K (32 megapixels), 200 rays per pixel, 20 bounces per ray. And rendering that frame takes 6 hours. How many (mega)bytes of random data do we need per second? ; (32*10^6) * 200 * 20 / (6*60*60) / (1024^2) ~5.65140335648148148148 Six whopping megabytes per second, for the entire job, across all cores! Well, that assumed you only need one byte per bounce. Maybe you need a few bytes? And here I can pull an order of magnitude more and then some (180 megabytes/s) via /dev/urandom on OpenBSD (i.e. Chacha20, no hardware accel), using a single core of a few-years-old fanless mini PC (some Intel Celeron with "U" postfix). I generally don't buy the argument that your PRNG needs to be super duper fast, because usually the simulation is doing much more than just generating random data, and all that work is so much more expensive than even a relatively expensive CSPRNG. At least my ray tracers are. Generating rays is actually trivial compared to traversing, intersecting and shading the scene.. goodness gracious if I need to do actual texture & normal map lookups at a high resolution, so many cache misses :( That said, a simple and fast PRNG with little internal state can make life easier if you want reproducibility.. and it might be easier to build a reproducible simulation if your RNG gives exactly one word the size you need, instead of requiring you to generate a big block (and then extract things out of it somehow). This is especially the case with threaded sims. So yeah. But in this case, I wouldn't be looking at something like XorShift, I'd be looking at a random map that allows me to use (e.g.) the pixel's coordinates and a frame & bounce counter as the input and get matching (constant) output. Now it no longer matters which thread renders which pixel and when, the result will be all the same. It's not hard to build such functions, but they will be slower than XorShift if you want comparable quality. Speed should be no problem though.

littlestymaar 7y ago
It's amazing how much efforts people are willing to invest to contradict others' experience on the Internet. The GP is giving a real-life example (people having complained about something being too slow compared to xorshift) and yet you try to do the math to prove it couldn't happen…
- clarry 7y ago
  The math was just the prelude to my real world experience. Please try to read and comprehend the rest of my post. If you can't comprehend it, then feel free to ask for clarification or just leave it be without adding any snide remarks. People having complained is not a real-life example of an actual performance issue. Until otherwise proven, it's a real-life example of someone complaining about some microbenchmark that, based on my real life experience, would be completely irrelevant if they actually developed their real world problem-solving program which totally shifts the bottleneck to something that actually matters. Alternatively, it's a real-life example of poor implementation or usage, and not necessarily poor performance of the underlying primitive. This also happens a lot. "Foo is slow!" is true for a lot of things if you use them wrong. Maybe it's simply the user's ignorance, or maybe the API isn't well designed to support their case. Maybe it's poor documentation. Also, this is a technical forum. There's absolutely nothing wrong with people doing back of the envelope calculations to analyze the scale of a problem. If more people did that while pointing at real examples with concrete numbers, maybe we'd actually know things instead of just relying on hearsay and religion. Whatever, it's a cargo cult industry. Here's the good part: if someone who knows better comes along, they find those numbers and can tell us why we're wrong. Otherwise, let's just take everything on faith? It's amazing how often people (like you, who haven't contributed anything except noise to the discussion) just don't want to understand a problem and if someone comes along trying to understand it and do the math, they're called a lunatic. And this is why some of the code I get to work on is so terrible, people are wasting time and complicating code to micro-optimize things that are completely irrelevant (a conclusion one could come to either by a ballpark-estimate or a quick profile), while massive bottlenecks sit unattended.

by clarry 7y ago

littlestymaar 7y ago

It's amazing how much efforts people are willing to invest to contradict others' experience on the Internet. The GP is giving a real-life example (people having complained about something being too slow compared to xorshift) and yet you try to do the math to prove it couldn't happen…

clarry 7y ago
The math was just the prelude to my real world experience. Please try to read and comprehend the rest of my post. If you can't comprehend it, then feel free to ask for clarification or just leave it be without adding any snide remarks. People having complained is not a real-life example of an actual performance issue. Until otherwise proven, it's a real-life example of someone complaining about some microbenchmark that, based on my real life experience, would be completely irrelevant if they actually developed their real world problem-solving program which totally shifts the bottleneck to something that actually matters. Alternatively, it's a real-life example of poor implementation or usage, and not necessarily poor performance of the underlying primitive. This also happens a lot. "Foo is slow!" is true for a lot of things if you use them wrong. Maybe it's simply the user's ignorance, or maybe the API isn't well designed to support their case. Maybe it's poor documentation. Also, this is a technical forum. There's absolutely nothing wrong with people doing back of the envelope calculations to analyze the scale of a problem. If more people did that while pointing at real examples with concrete numbers, maybe we'd actually know things instead of just relying on hearsay and religion. Whatever, it's a cargo cult industry. Here's the good part: if someone who knows better comes along, they find those numbers and can tell us why we're wrong. Otherwise, let's just take everything on faith? It's amazing how often people (like you, who haven't contributed anything except noise to the discussion) just don't want to understand a problem and if someone comes along trying to understand it and do the math, they're called a lunatic. And this is why some of the code I get to work on is so terrible, people are wasting time and complicating code to micro-optimize things that are completely irrelevant (a conclusion one could come to either by a ballpark-estimate or a quick profile), while massive bottlenecks sit unattended.