Semi-off-topic, but...
Is the release of this why Google's share price is down 4.5%?
HN user
Software Dev
(Ex-CG/VFX renderer dev)
Semi-off-topic, but...
Is the release of this why Google's share price is down 4.5%?
Thanks!
Out of interest, is that all that's required for the power negotiation handshake? I would have expected more complexity?
Note: in some cases (not completely sure if it applies in this situation as I haven't looked into the details of this code enough), using pre-increment AND when the value is used is a dependency on that operation, so "+= 1" is actually faster for out of order execution.
So yeah, as you say, compilers can be very sensitive to this, and in the past (although more than 10 years ago now, so might not be relevant now), ICC often used to generate better (faster executing) code when using "val += 1" vs "++val".
Semi-off-topic but...
On my sites, I see ClaudeBot consistently (and has been like this for over a year) ask for "${SITE}.com/base_dir1" and then get the redirect (Caddy does this automatically) to get "${SITE}.com/base1/base_dir1/" (trailing slash).
The hrefs on my sites include the trailing slashes for directories, so looks like ClaudeBot's internal code is stripping them off before requesting them, and therefore essentially makes almost 2x the requests to my sites for directories, half of them ending up being redirects back to the same url but with the trailing slash.
If would likely need to track them well (not sure from this article/video if that's the case?) to be useful in that scenario...
Drawing a splodge in roughly the location (not sure if there's range info either? I doubt it if it's passive) overlaid on the video likely won't cut it...
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:
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).