HN user

frogblast

597 karma
Posts1
Comments56
View on HN

Often not elusive bugs, but elusive performance. GPU compilers are hard: Once you've done the basics, trying to do further transforms in a mature compiler will almost always produced mixed results. Some kernels will go faster, some will go slower, and you're hoping to move the balance and not hit any critical kernel too hard in your efforts to make another go faster.

An optimization with a universal >=0 speedup across your entire suite of tests is a really hard thing to come by. Something is always going to have a negative speedup.

My experience is with non-Nvidia GPU systems, but this feels like a familiar situation. They probably found something that has great outcomes for one set of kernels, terrible outcomes for another, and no known reliable heuristic or modeling they could use to automatically choose.

IMO the problem is that H1B employees are stuck at the employer for the duration of their green card process, and so end up both paid lower and unable to escape abuse.

I think a very high application fee is actually part of a good solution, but is useless by itself.

A flawed proposal:

* Dispense with the 'need to search for a qualified American' which just complicates the process without achieving the stated goal, and includes a ton of legal and bureaucratic expense and time.

* A large application fee paid from the company to the federal government.

* The worker's relocation expenses must also be covered by the company.

* The worker gets a 10 year work authorization on the day of their arrival.

* The worker gets to leave their sponsoring employer on the day of their arrival, if they choose to. The employment contract may not include any clawbacks of anything.

The latter bullet is the key one. That's the one that uses market forces to truly enforces this person is being paid above market wages, and is being treated well, at their sponsoring employer. (which in turn means they don't undercut existing labor in the market).

It also means that employers don't really look abroad unless there really is a shortage of existing labor. But when there is a true shortage and you're willing to spend, the door is open to act quickly.

The obvious defect is that it creates an incentive for the employee to pay the federal fee themselves (hidden) plus more for the privilege of getting sponsored, and the company basically being a front for this process. Effectively buying a work authorization for themselves. I'm not sure how to overcome that. Then again, the current system could also suffer that defect (I don't know how common it is).

My prius (2006 model) finally had the traction battery (NiMh) start to loose modules at about 250K miles. It was clearly getting weaker, but drivable at that time. Then Covid hit, and it sat for 2 months without being driven / charge cycled. That pushed it over the edge.

That isn't predictive at all of NMC or LFP chemistries though (and I'm not going through multiple charge cycles per drive), but a fun anecdote. It was an entertaining project opening up the battery pack and identifying/replacing the bad modules.

In the end, other parts of the car were dying too, and the final straw was California's refusal to allow aftermarket catalytic converter replacements, and the Toyota's price (with no competition) was more than the vehicle was worth.

So far my two EVs, both NMC chemistry (Kia and Rivian) are at 80,000 and 30,000 miles respectively, with no noticeable degradation.

You can still use the app. You get asked both to have the app get access to the MAID, and get access to location. If this is a problem, it is a problem because you said Yes to both. You could have said No. You can change that choice now.

If you go to Settings -> Privacy, the top two options in iOS 18 are:

* Auto-deny Advertising ID access

* Which apps have location access ("X always, Y while using the app" is summarized right at the top)

Given the conclusions in these articles, I'd expect insurance prices for larger vehicles to be substantially higher, because the underwriters have a large incentive to get this right.

My own policy has two drivers with a long flawless history, and several vehicles, including a heavy duty pickup truck and a compact crossover.

The truck policy prices for bodily injury is 8% higher than the crossover, while property damage coverage costs 20% less for the truck.

There appears to be a material difference in conclusion between my insurance underwriters and the producers of these studies on the danger of these vehicles.

Yes but the police can't start occupying my house or deny me access to it because I wasn't home to let them in

With a search warrant, they can. You can be kept out of your home until they complete the search and seizing of the items named in the warrant. Depending on what is being searched for (excavating your basement looking for bodies?) that could take quite some time.

So the Tesla situation getting press isn't because the precedent is new, it's because most Americans (many in this thread included) don't understand what the law has already been since long before Teslas ever existed, and are surprised at what they find.

Without first hand knowledge, I'll take a guess: if the owner of the vehicle isn't available or cooperating, then getting access to the USB drive requires opening up the vehicle without a key, which could require some time or specialized tools, or cooperation from the manufacturer.

But in general, this isn't really much new. If you have home cameras, and police can obtain a search warrant, then you can be compelled to provide the video, or they can seize any device (such as entire computer, your server closet, etc) that could reasonably contain the video.

Correction: There is a big scaleup of capacity that's coming online exactly as BEVs are growing in popularity slower than many previous forecasts (hence lots of press about some carmakers having to scale back BEV production, while still moving more BEVs than last year). That is a US-centric statement. BEV demand is still quite explosive in China and Europe.

https://www.energy.gov/eere/vehicles/articles/fotw-1329-febr...

In the end, this tech just takes control from you.

In these difficult scenarios, the alternative photo I'd get using such a small camera without this kind processing would be entirely unusable. I couldn't rescue those photos with hours of manual edits. That may be "in control", but it isn't useful.

If you're interested in more background about one user-visible problem being directly attacked by this new GPU architecture, that could be "shader compilation stutter" (although there are many others).

These are two excellent posts that go deep on this:

The Shader Permutation Problem - Part 1: How Did We Get Here?

The Shader Permutation Problem - Part 2: How Do We Fix It?

In particular, the second post has the line:

  We probably should not expect any magic workarounds for static register allocation: if a callable shader requires many registers, we can likely expect for the occupancy of the entire batch to suffer. It’s possible that GPUs could diverge from this model in the future, but that could come with all kinds of potential pitfalls (it’s not like they’re going to start spilling to a stack when executing thousands of pixel shader waves).
... And some kind of 'magic workaround for static register allocation' is pretty much what has been done.

https://therealmjp.github.io/posts/shader-permutations-part1...

https://therealmjp.github.io/posts/shader-permutations-part2...

Even if you're not memory bandwidth bound, leveraging these 2x FLOPs on recent designs is hard, often due to issues like register bank clashes.

They are low utilization, but apparently still worth it because process node changes have made more ALUs take relatively little area. So doubling the ALU count, even with low utilization is still apparently an overall benefit (ie, there wasn't something better to spend that die space on).

As you state, GPU latency hiding is basically equivalent to hyper threading, just with more threads per core. For example, for a 'generic' modern GPU, you might have:

A "Core" (Apple's term) / "Compute Unit" (AMD) / "Streaming Multiprocessor" (Nvidia) / "Core" (CPU world). This is the basic unit that gets replicated to build smaller/larger GPUs/CPUs

* Each "Core/CU/SM" supports 32-64 waves/simdgroups/warps (amd/apple/nvidia termology), or typically 2 threads (cpu terminology for hyperthreading). ie, this is the unit that has a program counter, and is used to find other work to do when one thread is unavailable. (this blurred on later Nvidia parts with Independent Thread Scheduling.)

* The instruction set typically has a 'vector width'. 4 for SSE/NEON, 8 for AVX, or typically 32 or 64 for GPUs (but can range from 4 to 128)

* Each Core/CU/SM can execute N vector instructions per cycle (2-4 is common in both CPUs and GPUs). For example, both Apple and Nvidia GPUs have 32-wide vectors and can execute 4 vectors of FP32 FMA/cycle. So 128 FPUs total, or 256 FMAs/cycle Each of these FPUs what Nvidia calls a "Core", which is why their core counts are so high.

In short, the terminology exchange rate is 1 "Apple GPU Core" == 128 "Nvidia GPU Cores", on equivalent GPUs.

DOTS/ECS has nothing to do with geometry LODs. Those are purely optimizing CPU systems.

Even if DOTS was perfect, the GPU would still be entirely geometry throughput bottlenecked.

Yes, UE5 has a large competitive advantage today for high-geometry content. But that wasn’t something Unity claimed could be automatically solved (so Unity is in the same position as every other engine in existence apart from UE5).

The developer should have been aware from the beginning of the need for geometry LOD: it is a city building game! The entire point is to position the camera far away from a massive number of objects!

Despite the original post talking about DOTS rough edges, I didn't see anything in that article that actually suggested DOTS was the cause: that would cause CPU overhead, but it seems like they simply have a bunch of massively over-detailed geometry, and never implemented any LOD system.

Maybe they could have gotten away with this with UE5's Nanite, but that much excessive geometry would have brought everything else to its knees.

Ideally they know exactly how it will perform: Every part of the chip, including the caches, memory controller, and DRAM is implemented in a cycle accurate simulator. There are often multiple versions of that simulator, one written in C/C++ that matches the overall structure of the eventual hardware, and then simulations of the actual RTL (hardware source code, networks of gates).

The C-model and RTL model outputs are often also compared with each other as a correctness validation step, as they should ideally never diverge. (ie, implement twice, by two teams, and cross-check the results).

Those simulations are terrifically slow for larger chips, so there is a surprisingly small number of workloads that can be run through them in reasonable time. So there tend to be even more simulator implementations that sacrifice perfect performance emulation for 'good enough' performance correlation (when surprises can happen). Being able to come up with a non-exact simulator that perf-correlates with real hardware is an art in itself.

You're making the single most common misunderstanding of the United State's ICBM defense capability, because you assume the goal is to "defend every city".

The real goal is quite different. The math starts to look very different when the defender can choose where to defend.

Assume a first strike against the US. The US has ~400 siloed missiles and a handful of airbases that can launch bombers. A reasonable goal for a first strike is to destroy those, preventing or substantially limiting a counterattack. Assuming some failure rate, using 2 warheads per silo gives you some redundancy, so 800 warheads needed for this phase of the attack.

What good is 40 intercepters against 800 incoming warheads? The US can choose which of those 800 to target. 40 intercepters can protect 20 silos from two incoming each. And that means the US can counterattack. To guarantee killing every single silo, the attacker must now have 20+2 warheads targeted at every single silo. The attacker has to build far far more offensive weapons than the defender needs to build intercepters, if the attacker wishes to avoid a counterattack.

Protection of the population comes from MAD alone, not by interception. (this of course isn't a reassuring thought, so this case isn't really made to the public).

That is why maneuvering hypersonics are considered such a threat: it removes the predictability of which warheads are going to land where, preventing that kind of choice of where to defend.

I was wondering if a “chain of custody” law for personal information can make this enforceable.

You can request your personal information from a holder of it, and along with that comes the identity of where/when/who that data was acquired from (and transitively who they got it from).

Then you can tell who sold it, both to gauge violations and also to name and shame.

And if they don’t have the chain of custody, then they are immediately in violation, and it is easily proven.

I strongly suspect the reason Nvidia trees are so shallow is that NSight simply isn't showing the actual tree structure, probably because Nvidia considers that proprietary. It appears to just list all the leafs of a tree in a big flat list. But there definitely is a tree in there.

It is available via public APIs, but the hardware instructions themselves are not documented. This lets the instructions change in future CPUs, vs having the ISA be baked in stone forever.

Example: AMX predated the standard ARM matrix multiply instructions. Perhaps Apple will add the ARM versions someday and now can remove AMX without breaking compatibility. Or maybe there will be a non-additive AMXv2.