exged

Just wondering, what makes NN-512 superior to Intel's oneAPI DNN library?

Almost everything has at least an 8-bit MCU now. 32-bit MCUs are also extremely common now, and even simple ones like the ARM Cortex-M0 are competitive with a 286/386 (albeit with less memory / no MMU).

A rather surprising number of devices run very powerful application processors. An amusing example is Apple's Lightning to HDMI adapter, which has an ARM SoC with 256MB of RAM and boots a Darwin kernel in order to decode a H.264 compressed video protocol. Depending on what exactly they put into it (wouldn't be surprised if they borrowed the Apple TV chip for a relatively low-volume product like this) it may be more powerful than a fairly recent computer.

Aside from very simple use cases, you'd probably struggle to render 800x480 or 1024x768 frames on an MCU. At 1024x768 especially, the pixel rate (47 MP/s at 60Hz) and framebuffer size (2.3MB at 24bpp) are just too big even for large MCUs.

APs are the right tool for the job. It's true that for hobbyists, documentation is lacking and DSI is complex to get started with. The best solution would probably extend DSI with something like EDID. DSI displays can then be plug-and-play (like HDMI / DP) using an universal driver.

Another option is eDP, but it's not so common on cheap APs or screens.

Ehh, not really. I've used both Macs (old 15" rMBP, 12" Macbook, M1 Macbook Air) and Thinkpads (T450s, X1C G7, T14 AMD) and Lenovo just frequently drops the ball on things like display, speakers, touchpad and battery life.

Apple has also made some poor decisions in various areas in the past like poor thermals, power-sucking dGPUs, and of course the butterfly keyboard. The M1 Macbook is very nearly perfect though, and I don't know how any of the PC vendors are going to top it.

Garbage trucks should be possible. They are heavy but no heavier than a semi truck, with a tiny fraction of the range (150 miles vs 500+). Plus, low speed city driving is much more efficient than highway driving with an EV drivetrain.

I get that all else being equal, it's better to put everything in RAM, but what point is it just poor software design? 1TB of RAM is nothing to sneeze at. Is there really such a great need for sub-100us read latencies that commodity NVMe SSDs are insufficient?

The shortage is actually a direct outcome of Intel's problems. Historically Intel had by far the highest capacity for leading edge fabrication processes - just for their own CPU production. It didn't make sense for companies like TSMC to invest in additional fabs as long as Intel had the lead. AMD taking the lead and moving ~25% of x86 CPU production to TSMC is a huge shift.

It's not just some gold coins, it's also the matter of $12.7 million invested in his research endeavor. If you raised $12.7 million to start a company like Theranos you'd also be looking at a steep prison sentence for securities fraud.

Reticle limited on Samsung 8nm means plenty of room is available on TSMC 5nm.

Also, GDDR does not have appreciably higher latencies than DDR memory when measured in nanoseconds. It's just more expensive than DDR and much more limited in terms of capacity.

If Apple does go the "huge SoC" route I'd expect to see HBM2 memory with socketed DDR4 or DDR5. It'd provide the best of both worlds - extremely high bandwidth and low latency for a small portion (say 32-64GB) of the memory, and high capacity for the rest (say 1-2TB), all without compromising the unified memory concept.

This is not without precedent - recent Xeon Phis, for all their other shortcomings, have had a similar memory hierarchy.

I'd expect most things to work and have native versions by next year, with the notable exceptions of virtualization software and package managers like Homebrew.

Virtualization software likely will never be fixed if you expect an x86 guests to work. The hardware obviously cannot natively virtualize x86, nor can Rosetta cannot emulate privileged x86 code. x86 Docker images will also not work.

Homebrew itself will probably be ported to ARM by then. However, there will likely be a long tail of packages that won't have ARM builds for some time.

Minor nit, but what you're describing is loss of color depth. Gamut is how saturated the colors get, which doesn't change much in this scenario.

FB generates around $2 million in annual revenue and $600k in net income per employee (not just engineers). If the only thing you consider is value generated by each employee, then FB should be paying far more. Maybe 400k for a new grad and 1M for a senior engineer?

Below average for someone joining as a new E5 employee, especially if stock refreshers and equity appreciation is taken into account.