There are quite a few cine cameras that are more than 10x this amount, and there are a few that are 100x. For example, there are Panavision cameras that you can only rent direct from Panavision that require that you have half a million dollars of insurance coverage to rent. There are ARRIs that you can buy from B&H that are $100k. $30k is definitely in the range of something that individual DPs/operators could own, although it’s getting into rental territory for lots of people.
There's lots to laugh at here but my favorite dumb part is talking about wages and wealth inequality:
> But the good news doesn’t stop there. We also get higher wages. This is because, at the level of the individual worker, the marketplace sets compensation as a function of the marginal productivity of the worker. A worker in a technology-infused business will be more productive than a worker in a traditional business. The employer will either pay that worker more money as he is now more productive, or another employer will, purely out of self interest. The result is that technology introduced into an industry generally not only increases the number of jobs in the industry but also raises wages.
and later
> As it happens, this was a central claim of Marxism, that the owners of the means of production – the bourgeoisie – would inevitably steal all societal wealth from the people who do the actual work – the proletariat. This is another fallacy that simply will not die no matter how often it’s disproved by reality. But let’s drive a stake through its heart anyway.
He's just lying! There's no evidence to support this at all in the modern US economy. The gains in wealth from automation over the last 50 years have almost _exclusively_ gone to the owners of the means of production. The median US household income went up less than 20% between 1983 and 2016 while the 95th percentile more than doubled.[0] This is just VC pump-and-dump nonsense pure and simple; it seems incredibly likely that any financial gains from AI making workers more productive will flow directly to the same people who have been reaping all of the gains from our increased productivity: Andreesen and his billionaire colleagues.
> The gains in wealth from automation over the last 50 years have almost _exclusively_ gone to the owners of the means of production
Possibly because it is measured in some economic dollar-figure that removes all quality-of-life figures as part of the measure.
If you were offered to live in the same house you live in, with twice the income BUT you could only buy goods and services at 1970s equivalent prices and 1970s quality and functionality, I wonder how many people would think that was a good bargain? (Ignoring retro-fiends).
I remember a 1970s dishwasher, a 1970s car (certainly not two), 1970s TV, 1970s medical care, 1970s stereo, 1970s occasional takeaway highlight was KFC (I was young), etcetera. A tinny transistor radio that ran out of batteries was the equivalent of EarPods.
You don’t even get a Sony Walkman 50 years ago (plus sound was shit with tape hiss and poor dynamics, and crappy headphones).
What price would a newly produced VW beetle fetch (at 70s features and quality), assuming they had to sell 200000 cars in a year (how many would be bought for scrap)? How many Ford Maverick’s could you sell for $1000?
We all have immense quality gains from automation, we are just blind to the slow improvements in quality of life (and some decreases too).
The past at the same price (adjusted) is a lot lot worse than many modern people think.
What is the consumer surplus of a modern laptop? You couldn’t buy an Apple ][ 50 years ago. Automation has given us a lot, but those gains are not usually measured because we can’t compare because there was no equivalent to most modern technology.
Scroll down for what you could buy 37 years ago (not 50) in Computer Shopper. Multiply the costs by 2.86 to convert dollars to today: http://ascii.textfiles.com/archives/5543
Octane, Redshift, and eevee/Cycles all work on Metal, and Renderman and Mantra are CPU-only for now -- RM/Mantra have beta-versions that are GPU enabled, and Karma is nvidia-only and RM XPU doesn't work on macs at all yet, but I don't think many people are using either in production very much yet. I think the only GPU renderer people are using in production pipelines that's really locked to NVIDIA chips is Arnold, right?
I can't speak for cycles, but Redshift is very slow on OpenCL. I've never heard of using it on Metal. I know it was written for CUDA and didn't even support OpenCL for a long time. Do you know how it runs on Metal?
I don't think V-Ray GPU will run on anything but Nvidia, and if it will then it's definitely slow.
Ah yeah forgot about V-Ray. I haven't tried Redshift on Metal, nope; all my work has been Renderman and Cycles recently. Curious to hear how well it works, people online seem to say it's pretty fast but hard to tell marketing copy from actual performance when it comes to renderers.
FWIW Cycles is definitely slower on my M2 than it was on my 3080 but it's not a huge difference -- maybe 20% slower? I still have to let the render run overnight either way haha.
Most big-budget feature films are cut on Avid and that's been the case for a while now; for indies my impression is that it's 50/50 Premiere and Resolve, yup.
The workflow many post-production studios use for editing/grading is to keep files on a NAS with proxies (i.e., lower-quality transcodes of the video clips in the edit) on a local disk -- that's the workflow I use even with my desktop machine, and I bet it'll work well with this too.
There's a crazy downside to make_shared that I learned recently because of this: if you have a weak pointer to a shared thing, and the refcount for the shared thing drops to zero, the weak pointers will keep the allocation for the object "alive", because they still need access to the remnant and the remnant was created in the same allocation as the object so they can't be freed separately. So now I only use make_shared if I know for sure there won't be a weak_ptr pointing at it (or if the base object has a relatively small memory footprint after it's been destructed).
Won't the object be destructed though? So while the memory for the object is kept, the memory for the object's heap-allocated members is not. I.e. if you have a 100mb string, after only weak references are left you won't have 100mb memory taken, but only sizeof(string) + sizeof(control block).
Depends on the object. As OP notes, `make_shared` with weak pointers is fine "if the base object has a relatively small memory footprint after it's been destructed".
There's lots of cases where the object itself is big, though. Think of objects with big fixed arrays, "god objects" with a bajillion pointers, or objects which themselves allocate data in-line.
Yeah, that's definitely something to be aware of. It's usually not an issue as most objects have small footprint (and any allocations they in turn hold would be released when the strong refcount goes to 0).
Excellent! The fact that there's something as basic as the Boolean Math node [1] kind of shows that this is something evolving into that direction. I will definitely look at it and search for the C-code on GitHub. Thanks.
