pixelesque

Advanced Search doesn't work unless you're logged in, but it's been like that for at least a year.

Which isn't particularly helpful if you're moving around a lot.

Would be nice for a preference.

Not quite as easy if you have to hot-desk, and don't always get the same desk each time you're in the office :)

Elonex were another UK-based PC brand that manufactured their own 386/486 boards for their systems in the early 90s.

> ”But Desktop GIS Can Handle It” — No, It Can’t

I feel this is a little disingenuous, especially given it then says QGIS takes ~10 mins to open the same file and then doesn't give a time for ArcGIS.

As much as I have respect for QGIS and what it's capable of (especially given its price point!), it's not always that fast: I recently looked into why drawing polygons interactively was so insanely slow (with the help of perf on Linux) in QGIS, and the code was basically suffering from 'painters algorithm' and is just a really inefficient implementation with loads of redraw and 'find-nearest-point' overhead.

I wouldn't be surprised (as another example: until recent releases, Blender's OBJ format importer was similarly orders of magnitude slower than other DCC apps OBJ importers - e.g. it would take > 2 hours to import a large .obj file other apps could ingest fully in under 30 seconds) if the code path just hasn't been looked at and optimised.

Minor nitpick: Rolls-Royce military jet engines are made at Bristol (ex-Bristol Aerospace), but civilian turbines like the Trent series are made in Derby.

If you care about only capacity and cost yes, but not if you care about performance.

Yes it does.

Third paragraph:

> On June 11th Mark Warner, the vice-chair of the Senate Intelligence Committee, said that General Joshua Rudd, who leads the National Security Agency and the Pentagon’s Cyber Command, had told him that Mythos “broke into almost all of our classified systems, not in weeks, but in hours”.

I've got a 32 GB MBPro, and I set it to 27700, which I haven't seen a problem with so far.

Note you can change the amount of shared (V)RAM reserved for the OS with:

sudo sysctl iogpu.wired_limit_mb=18800

will allow you to use more, but you do need to leave a bit for the OS obviously!

Or just raw pointers, indeed.

std::shared_ptrs can also (because they're implicitly for sharing) alias, so the compiler has to assume the worst and emit loads in other cases, and there's no way (unless a newer C++ version has introduced it and I haven't noticed?) to use '__restrict__' with shared ptrs.

And if you've decided you want to take it a bit more seriously, move on to:

https://www.pbrt.org/

which is effectively the bible, and has been for years (I wrote mine and moved into the VFX industry when the Second edition was still out! - I feel old now)

Yeah, passing std::shared_ptr by value in a multi-threaded setup can have a lot over overhead due to them being copied and destroyed a lot, and the fact that the atomic ref count value modifications effectively cause a write back to cache and can cause contention.

Should pass them by const refs really to avoid this.

Inverse is still 0.0 technically, but yes, there is a trick you can use with Inf and SIMD to mask them out, so Inf is sometimes used.

However, I'd just condition it for the moment.

so:

invDirX = dirX != 0.0 ? 1.0 / dirX : 0.0; etc, etc for each dimension.

Obviously doing the != 0.0 comparison is not great, as it suffers from potential issues again (especially if you have denormals), but you can generally get away with it I've found in most cases.

JFYI: Your inverse ray direction calculation is not NaN-safe: if rays are completely axis-parallel in one dimension, so the direction value is 0.0 for that axis, you'll be doing the val / 0.0 which results in a NaN...

Also, as you're using full double/f64-precision all the time, you're leaving a fair bit of performance on the table: transcendentals (sin(), cos(), etc) in particular - can be a lot slower than when using f32, and generally double precision can be special-cased to particular areas of the renderer that need it (curve, sphere intersection, and some situations where volume scattering produces very small distances).

Love the:

> // Sky-like background

comment for the ground! :) No doubt most of the training data is for sky...

Still getting 1076 errors. Seems to have been down for almost three hours now, at least via the Windows UI...

Yes, as long as you were happy to wait 30s for an exposure (on tripod), by 1850 (most of those photos were > 15 years later than that) there were many photos of good quality.

Look at photos of Crystal Palace in 1851 for example.

Not really, as it's only once per file system mount, whereas those Windows and MacOS files are sprinkled in most directories with images and almost every non-network drive directory respectively.

From other new source:

> The Department of Government Efficiency cut approximately 15,000 USDA jobs and terminated thousands of USAID programs, including a screwworm monitoring project.

Possibly yeah.

Or the per-pixel coord atomic I guess?

It's not new - that was sort of my point with my other comment.

At least if it's progressive (so refines and resolves over time), this has been done with pointclouds in the VFX industry in GPU shaders for years in terms of stochastically drawing different points so eventually the whole point set gets rasterised to a fidelity threshold.

Fair enough, but that's then only absolutely max 1024 threads per SM, which wouldn't get anywhere near 1 million, given 5090 only has 192 SMs...

Future proofing I guess...

> millions of threads

Really?! What OSs can handle that many native threads?

Also, this seems quite similar to stochastic progressive drawing of pointclouds for realtime that has been done for > 15 years in the VFX industry with GPU shaders in a tiled/bucketed fashion, unless this isn't progressive maybe? (The fact it's been accepted for Siggraph likely indicates it's slightly different).

Hardware's not generally a subscription, monthly cost though.

You update it for them every 3/4 years (if they're lucky).

It probably makes a bit more sense to compare it to existing software subscriptions like Office, or the old-school 'per-seat' licenses per user for software.

> and in 2013, it was measured at 43%.

Do you mean 2013 or 2023?

I'd like to think it does, but honestly I have no idea as I have no way of comparing to not doing this.

I personally find Fastmail's spam handling a lot worse than GMail's: and I get a lot more spam in my GMail address, due to it being a 22 year old address, which I still use for initial sign-ups, before then changing account emails to my fastmail one after a few months.

Very likely a lot of the difference is the types of email each address is getting.

It wasn't "all their source code", it was the source code to Claude Code: not really any of their internal secret sauce, at least directly.

Only with things like -ffast-math enabled will compilers do the reciprocal. It can make a fair difference in some cases, but it's often better to selectively use it in code locations you know are acceptable by doing it manually in the code.