We've struggled with justifying raising the min spec for our game over the last decade and recently pushed up to 4.2 as well.
Historically the question was always one of which optimizations we would be able to 'compile in' (rather than detect and use if available) and it has been increasingly difficult to justify in recent years: a few ops in 4.1, one op in 4.2, but nothing dramatic and we still can't rely on F16C support yet.
These days, the move to exclude older processors seems more designed to avoid headaches from failing older hardware and performance complaints from systems that might technically qualify for your minimum spec but can't offer a satisfying user experience than it has to do with the software being able to take advantage of instruction set extensions.
The UHS-1 speed really limits what you can do with this; I think you might be able to do some light 4K video on some cameras in limited modes but generally I expect it'll be best for FHD which isn't as storage-hungry to begin with.
I think 4TB of 60FPS FHD ALL-I compression on my Canon R5 would take 38 hours of footage to fill; if you aren't going to do any grading and use a 24/30FPS FHD IPB that number jumps to 97 hours or 4 days of footage.
I also don't know how useful it would be for burst-mode; I filled 256GB in a few hours but that was on a v90 card and I expect on a UHS-1 card I'd have spent a good chunk of that time waiting for the buffer to clear.
I'm sure there's some application for this -- I just can't see it for videography or photography.
Although I agree with you every time I think of that book I'm reminded that Charles Manson read it in prison and it no doubt helped him is his later years.
I thought we'd been using /Oy (Frame-Pointer Omission) for years on Windows and that there was a pdata section on x64 that was used for stack-walking however to my great surprise I just read on MSDN that "In x64 compilers, /Oy and /Oy- are not available."
Does this mean Microsoft decided they weren't going to support breaking profilers and debuggers OR is there some magic in the pdata section that makes it work even if you omit the frame-pointer?
“Recovering a broken stack on x64 machines on Windows is trickier because the x64 uses unwind codes for stack walking rather than a frame pointer chain.”
Microsoft has had excellent universal unwinding support for decades now. I'm disappointed to see someone as prominent as this article's author present as infeasible what Microsoft has had working for so long.
The key thing about all TS-lenses I know of is they only support manual focus; while this may not be a problem for architecture or landscape photography I'm too casual to try to focus a portrait manually (Gregory Heisler talks about doing this in his book "50 portraits" and I love his work).
Rumour has it that Canon's RF-mount tilt-shift lenses will support autofocus though...
I am generally pretty fast with lenses that were designed to do manual focus, like Zeiss Otus and Milvus lenses for Canon (For example). Lenses that come with autofocus does not have a long enough throw to be able to perform manual focus quickly and accurately, but it is definitely doable.
When stopping down you also can use the distance markings on the focus ring effectively (it's easier to do with sufficient depth of field, and with a DSLR you can practice as much as you like). Over time you can do this intuitively, like how a professional focus puller does on a film set.
Another intuitive skill that can be easily practiced on a DSLR is metering by eye. Take a couple test photos to dial in the right exposure for the conditions then use that as a baseline when making adjustments for a reflective subject, areas in shadow, etc. With a modern mirrorless camera and EVF this skill may not be that necessary though.
> Intrinsic vmulq_f32(x, c0, 0) multiplies each lane of register x with lane 0 from register c0.
I don't remember seeing anything like that NEON instruction in AltiVec or SSE so it didn't even occur to me to look for it when I ported some SIMD code to NEON; now I'm going to go back and look for opportunities to use it!
That should be vmulq_lane_f32(), but yeah, lane broadcast is free on a number of NEON operations. Many operations also have built-in narrowing, widening, saturation, and rounding. One of the more ridiculous ones is vqrdmlah_lane_s16(), which translates to: signed saturating rounding doubling multiply accumulate returning high half (with a lane broadcast).
The downside is that the latencies can be a bit high sometimes compared to other CPUs. 128-bit vector integer adds, for instance, have 2c latency even on an Apple M1.
Another thing to watch out for is that some NEON guides are outdated and only tell you about ARMv7 features, missing some goodies added in ARMv8 like horizontal operations (vaddv) and rounding on conversions other than truncate.
On Intel/AMD you need AVX-512 support to get the instructions with broadcast (and many other goodies that are missing from SSE/AVX/AVX2).
Intel had such instructions many years before ARM (i.e. since Larrabee), but they have chosen to provide them only in their high-end CPUs, annoying the programmers that would like high performance but who do not like the burden of developing for a fragmented instruction set.
I dimly recall 10-15 years ago that we saw approximately 10% faster running texture filtering on HT cores in addition to real cores -- I'm hazy on the number and I don't remember which CPU we tested with but it seemed as though for a fetch-heavy workload SMT can help hide a cache-miss on one thread by doing ALU on the twin core. Since it didn't cost anything and we already scheduled work across real cores we didn't complain about the gains being marginal from HT cores and left it enabled.
More recently we did some DirectX 12 MT-rendering tests; since there's more considerable overhead for breaking up the work into more batches so we wanted to be sure so we checked carefully.
On a i7-12700K we found that distributing Dx12 work to SMT or E-Cores had no benefit, even in a contrived rendering stress-test.
However, on an unnamed game console, we found that scheduling additional work to the SMT cores improved draw performance by maybe 7%.
YMMV but my impression is the workload needs stall on memory enough to get signfican gains by interleaving the ALU from another thread and this might benefit low-power systems like laptops or mobile phones more than workstations.
We used to use RTF for walls text in our game launcher (EULA, MOTD etc). We chose RTF because raw Win32 could render it without extra work and we wanted to minimize both launcher complexity and dependencies.
One thing we noticed was that RTF documents made in WordPad instead of Word were much, much smaller and since every byte added to our CDN bill we made a point of re-saving all our files in WordPad before publishing them. Sometimes simple is good.
But we're talking about a computer with several extra gigs lying around running the same game. And specifically that number is for 4K output; anything less and you're under 100MB.
I have a photography side-hustle and I use GIMP occasionally for advanced edits I can't do in my raw developer. In my semi-regular use over the last 3 years I've never found the UI/UX to be a problem but rather find myself coveting features GIMP either doesn't have or doesn't seem to do very well (smart subject masking, context-aware fill, etc). I'm getting what I pay for, so I don't feel I have any right to complain, but as it drifts farther behind the commercial offerings I suspect debates about the UX might not be what GIMP needs.
Historically the question was always one of which optimizations we would be able to 'compile in' (rather than detect and use if available) and it has been increasingly difficult to justify in recent years: a few ops in 4.1, one op in 4.2, but nothing dramatic and we still can't rely on F16C support yet.
These days, the move to exclude older processors seems more designed to avoid headaches from failing older hardware and performance complaints from systems that might technically qualify for your minimum spec but can't offer a satisfying user experience than it has to do with the software being able to take advantage of instruction set extensions.