As for autonomy, Waymos have LIDARs which at least provides more redundancy.

I see these as different design tradeoffs so no judgment implied.

This is precisely what leads to the "forgot to multiply 2pi or 1/(2pi)" problem in the EE / signal processing domain where you FFT and s-/fourier-transform back and forth. Heck, I can never remember which convention any particular library / package decides to adopt (esp. mathematica vs. matlab which IIRC caused tons of confusion and headache during my undergrad).

Early 2000s RTS games (Starcraft 1, Warcraft 3, CnC franchise) continue to amaze me in how well their seemingly comical "game physics" model the intrinsic dynamics of real world conflicts, almost prophetically.

The tradeoff with these unified LPDDR machines is compute and memory throughput. You'll have to live with the ~50 token/sec rate, and compact your prefix aggressively. That said, I'd take the effortless local model capability over outright speed any day.

Hope the popularity of these machines could prompt future models to offer perfect size fits: 80 GiB quantized on 128 GiB box, 480 GiB quantized on 512 GiB box, etc.

https://awsdocs-neuron.readthedocs-hosted.com/en/latest/abou...

https://awsdocs-neuron.readthedocs-hosted.com/en/latest/nki/...

Eight NeuronCore-v4 cores that collectively deliver:

    2,517 MXFP8/MXFP4 TFLOPS
    671 BF16/FP16/TF32 TFLOPS
    2,517 FP16/BF16/TF32 sparse TFLOPS
    183 FP32 TFLOPS

SRAM: 32 MiB * 8 = 256 MiB (ignoring 2 MiB * 8 = 16 MiB of PSUM which is not really general-purpose nor DMA-able)

Interconnect: 2560 GB/s (I think bidirectional, i.e. Jensen Math™)

----

At 3nm process node the FLOP/s is _way_ lower than competition. Compare to B200 which does 2250 BF16, x2 FP8, x4 FP4. TPU7x does 2307 BF16, x2 FP8 (no native FP4). HBM also lags behind (vs ~192 GiB in 6 stacks for both TPU7x and B200).

The main redeeming qualities seem to be: software-managed SRAM size (double of TPU7x; GPUs have L2 so not directly comparable) and on-paper raw interconnect BW (double of TPU7x and more than B200).

Same logic when NVidia quote the "bidirectional bandwidth" of high speed interconnects to make the numbers look big, instead of the more common BW per direction, forcing everyone else to adopt the same metric in marketing materials.

I'd categorize this as more of a portrait lens (than "normal" as the 50mm moniker implies).

Many Lidar visualization software will happily pseudocolor the intensity channel for you. Even with a mechanically scanning 64-line Lidar you can often read a typical US speed limit sign at ~50 meter in this view.

I vaguely remember (from 10+ years ago) that class selectors are much more performant than property selectors?

See Rivian's intro on their ECU design and Zonal architecture: https://youtu.be/6ZBko4TvfJY?t=137&si=-SKL_iFqZFnHE8nQ

This might sound like purely implementation detail, but having the (non-safety-critical) "business logic" of a car as software gives the manufacturer flexibility to late-bind behavior as new use cases / demands inevitably get discovered.

Something can simultaneously be a good idea, buzzword'd by marketing, and/or deviate from the original intentions.

OTOH, ABS and ESP systems can achieve similar or even better results with less complexity because motor torque control is inherently low-latency, which can also complement brake deployment (hydraulics is not as well behaved as e-motor).

You do get rid of emissions control and tiny little sensors / flap actuators sprinkled all around the engine bay, so yeah, probably overall still a simplification win, but I doubt you can get very far without "massive amounts of [Mechatronics] engineering".