pixel_fcker

Go's CPU floor is lower compared to the naive Rust port (roughly 20% vs 23% from eyeballing). Their optimized Rust version is shown in the next series of graphs as being ~12%.

looking at the amount of time she’s tagged as sleep all I can think is that she has no idea how easy she’s got it.

Not really: it doesn’t account for specular reflections. It’s more like if you took the objects out of the water and then used a polarising filter to remove the highlights.

I think the answer, as always, is to measure on your own workloads. I’ve seen real-world production code get significant speed ups by switching to spinlocks from mutexes.

Very interesting post though. I’ve never considered the idle latency before.

I think the key difference here is that in your code you’re saying you “know” that it’s safe to write to these certain sections of the array from different threads. That’s an invariant that‘s held in your memory (or in a comment maybe).

The rust equivalent is doing the exact same thing but requires you to formalise that invariant in your code by using one of the methods defined above.

I can see how initially this looks like an extra hoop to jump through but after using it for a while I’ve found the opposite is true: because those invariants are checked by the compiler it’s one less thing I have to keep in my head and I can concentrate on the real problem.

Or maybe there are just a lot of people who like using rust because it fits their use cases very well and are excited about the release of a big new feature that’s been in development for a long time?

“I know this code I’ve just written is safe” is the opening verse for the thousands of security vulnerabilities we see every year.

Unless you're playing it on a 75MHz Pentium, I think those people are right.

Yeah but you could buy a 24MP camera and a whole kit of high quality glass for the same price as this body.

The difference is the let key word makes it obvious you’re rebinding the name.

Shadowing is one of those things that intuitively raises a red flag first time you see it but actually is extremely helpful. It dramatically reduces noise e.g. in functions where you take an input parameter and want to convert it to a different type to work with it. No more prefixing or suffixing the variable name, you just rebind it which makes the intent clear (at least to me).

scrolling doesn't appear to work at all for me on Chrome 71, macOS

I'm always curious about this as well. On Ubuntu 16 at least installation is just selecting an option in the software manager. After that it just works.

My late 2013 with the same GPU is still going strong but it's going to need replacing at some point. I'll have to move off Apple at that point as Nvidia (CUDA) is a must for me.

1 play on radio 1 could easily be 1 million listeners for which they get 100 quid you say, whereas this band say they got $5000 for a million listens on Spotify.

29 hours wallclock is long for a render but not uncommon.

There’s not really a vendor here since macOS is free. Linux isn’t exactly free from the need to choose well-supported hardware either, particularly of you need to run a more stable distro

They will absolutely invest money in new IP just as soon as shitty superhero crap and Star Wars stop making billions of dollars.

Dwivedi is brute force. It’s just a sampling strategy.

there was a paper recently caching sparse radiance results and using ML to predict important paths from that. I believe the latest version of Octane might do something like that if you read between the lines of their marketing guff.

That’s using fully digital versions of those actors though. We’re a long way from being able to use AI for those kind of performances yet.

I’m using Ubuntu 16.04 LTS on a MBP and I cannot get the trackpad to work properly (right-click in the corner). I have to hand-edit confit files, the settings involved are undocumented, and it doesn’t work and I don’t know why. Even regular movement just feels janky compared to macOS.

I’m not quite sure of what you’re asking exactly here? What do you mean by constant brdfs?

It actually means a lot more than that in offline VFX. It was the games industry that decided it meant “use the Disney shader”.

Physically based rendering is _not_ the Disney shader and renaming your diffuse maps to albedo because it sounds more sciencey.

It’s about the wholesale switch to a fully path-traced framework with a consistent mathematical foundation as opposed to the layered system of hacks and chained prepasses that prevailed in the early 2000’s

I believe strongly in an equal distribution of opportunity between the sexes. How would you propose fixing the gap that the paper describes? Simply paying women drivers 7% more? Would that be fair?

I'm implying that it doesn't need to be corrected.

Should interventions be made to reduce the gap?

You can tell that from a tiny compressed gif?

It's interesting work but it does seem like the speedup they get is pretty poor (1.3x to 2.3x) when going from 1 to 16 SIMD lanes. It seems like the overhead from all the queue management and AOSOA transformation must negate most of the benefit of the parallelization?

They also mention the fact that programming the system is hard, and plugins must fall back on single-lane code paths until they can be coded into the system proper.

I would assume all the ray sorting makes it extremely difficult to use any bidirectional methods as well.

Isn’t déjà vu just your brain storing something in memory quicker than another part of your brain “looking it up”? In other words it’s a race condition on a dictionary insert.