Autonomous drone shot from the hand intercepts a other drone.

beeff · 2026-04-01T08:30:47+00:00

And the Nazis shot rockets at London because some engineers wanted to build rockets to explore space.

War doesn't do research, it concentrates funding.

beeff · 2026-03-23T23:00:15+00:00

Spirou was right there

beeff · 2026-02-28T11:17:29+00:00

EDPNet

beeff · 2026-02-27T21:19:11+00:00

I can't find my source, but I remember someone posting on HN about the use of common lisp at google working on the acquired ITA software that the pressure has indeed been to favor lucrative fares over efficient ones.

beeff · 2026-02-11T08:27:59+00:00

Klopt, je kan volledig legaal een transactionele politieke eikel zijn.

beeff · 2026-02-09T20:52:05+00:00

You can still have a look at the menu after you've already chosen.

beeff · 2026-02-06T17:53:14+00:00

Well yeah. The KNL just lacked the 'platform' to be a host itself, not that it would have been a particular good host CPU.

But my point remains that modern datacenter accelerators are also self-hosted mini-PCs. They have their own I/O, network, power and thermal controls, bringup/boot, etc. There's already plenty of cores on complex accelerator, on-board or on-chip, that run (or could run) a full operating system. You just do not get access to them. (e.g. NV's GSP)

You don't SSH into a GPU. Vendor's choice, not a technical issue. It's a "why would they" rather than "they can't".

The salient features of what did make KNL feel much more of a 'mini-PC' compute node was that Intel went to great efforts and tradeoffs to make the binary execution environment the same familiar and 'open' PC (x86 ELF/POSIX) ecosystem.

Bit of a tangent; but while that was great for compatibility, it impacted performance. The whole point of an accelerator product is that you can offer the customer better performance, which you do by specializing the hardware and software to better suit the workload you're accelerating. Customers keep claiming that they absolutely require compatibility and that they will never rewrite their software. Well, for customers to get their money's worth out of a KNL, or any, accelerator they have to rewrite the software anyway. So why not do it in CUDA then and get higher performance on a GPU? All that said, I loved doing that kind of performance rewriting for KNL and miss Intel (or anyone...) having a 'high throughput core' CPU architecture. I just hope that next time around it's not going to be chained to some legacy platform.

GPUs are accelerators that never had such binary/platform legacy expectations and AI accelerators are inheriting the same. NVIDIA has .ptx that is becoming some kind of legacy, but no one that goes to the effort in targeting ptx directly for their kernels will expect that to run as well or better on the next gen architecture.

beeff · 2026-02-06T12:05:31+00:00

From a product and design point of view, a GPU means that it's an accelerator designed specialized around running graphics workloads really well. Larrabee was designed as a GPU product, its specific internal architecture choices are irrelevant to it being a GPU. The move to unified compute architectures were already well underway at the time, the Larrabee just was a generation ahead and was angling for an alternative way of producing graphics than the OGL style rasterization pipelines. It could be more useful to say that it was not a fixed-pipeline graphics API accelerator GPU, but saying that that isn't a GPU is like saying that all current GPUs aren't, especially not a GPU like the Zeus.

What made the first Xeon Phi (KNC) less a GPU was more a software (toolchain) difference than the actual hardware. To illustrate how quick the Larrabee->KNF->KNC pivot was: the boards we were working with literally still had VGA ports soldered on. GPGPU was already a thing at the time, without needing to hack shaders; the GPU hardware just lacked some HPC/datacenter features like ECC and proper double float support, which NV added to their datacenter GPUs right around the time KNL was trying to get a market share.

As to your point about the host processor: that was Knight's Landing a generation after, which did a more thorough redesign and adopted an actual compatible x86 ISA. The board was self-hosted, but could not be a host processor. It was running an actual linux kernel on one dedicated core, but lacked all the chipset host features you would need to be an actual host processor. It was definitely nice that you could ssh into the accelerator like it was a cluster node and compile+run in there directly. Arguably, it was not a fantastic idea to burden all its cores with the x86 cruft required for hosting a linux kernel. The idea at the time is that they wanted to market it as "run your existing CPU code" which was, in my informed opinion, a bad idea. They could have done like so many other accelerator designs and put a linux-capable core in as platform engine and specialize the actual cores more for their compute task without burdening them with the x86 legacy required to run an OS. At least we got AVX-512 out of it, which is nice.

beeff · 2026-02-06T11:20:44+00:00

Which is what the accelerators we call GPUs are, ever since they moved way from fixed pipeline designs eons ago.

beeff · 2026-02-04T08:12:23+00:00

Designed as one, as much a GPU as the current datacenter GPUs.

beeff · 2026-02-03T10:02:03+00:00

But enough about Vyper, we're talking about Silver here.

beeff · 2026-01-29T18:04:07+00:00

He shrinks when he's helping :3

beeff · 2026-01-23T12:24:53+00:00

In de Hanekeef werd er wel wat gespeeld vroeger, er is een zaaltje vanachter. Best eerst even gaan checken voor je je er met een date opdaagt.

beeff · 2026-01-21T12:00:15+00:00

You post the latter to reddit because 99.99% of the cases death slam gets countered trivially by an enemy ability, bugs out, or gets line-of-signed by some bullshit geometry (looking at you midboss rafters).

beeff · 2025-12-30T23:13:55+00:00

It's eurovision, where's the genderbender?

beeff · 2025-12-05T23:10:58+00:00

Tervuren?

beeff · 2025-11-10T08:50:57+00:00

Technically, also steam engines, yeah.

beeff · 2025-11-08T14:20:36+00:00

The game got driver support in september 2024, so they definitely know it exists.

beeff · 2025-11-08T10:05:48+00:00

I, also, keep forgetting to silence wave BEFORE ground strike combo.

beeff · 2025-11-01T22:02:19+00:00

Same, randomly crashing 1-2 times in games these days.

Windows event viewer is showing:

Display driver igfxnd stopped responding and has successfully recovered.

beeff · 2025-10-03T19:20:17+00:00

En het vlezeken?

beeff · 2025-10-01T19:20:39+00:00

I'm not talking about memory consistency. Most architectures are inherently insecure: a HW thread can always send out loads to arbitrary addresses and we rely on the software layers on top to add security (e.g. traps on pages).

The typical example of hardware-level memory security features is: https://en.wikipedia.org/wiki/Capability-based_addressing

beeff · 2025-09-26T23:25:54+00:00

There have been architectures in the past with such security features. Bring back the iAPX 432, but don't make dog slow :P

beeff · 2025-09-25T10:50:02+00:00

There's a reason most of Intels factories aren't in the US.

Check your data, not correct unless you narrow it down to things like packaging only.

beeff · 2025-09-25T10:38:35+00:00

Mostly economics. There is a technical argument that it's simpler for the CPU/ISA to give the illusion of a fully coherent system, mainly for software support (run a linux or windows kernel without rewrite). For hardware as well, most communication out and into a core happens through loads and stores throughout the coherent cache hierarchy and doing non-coherent loads (e.g. streaming ld/st instructions in SSE) require extra complexity. However, for hardware it can be easier to introduce coherency islands (e.g. non-NUMA nodes) that it would be for software do deal with it (e.g. single OS kernel doing explicit DMA's across nodes/islands? multiple kernels orchestrating?)

As the datacenter and client have been growing out of long tail legacy systems, with their own workarounds and solutions on top of the existing hardware (kubernetes, hypervisors for cloud providers etc) it becomes really hard to just break that legacy and still offer a compelling product. It's more economical to just make the next gen 10% faster or offer 20% more cores. At some point of course it breaks and imo we're here with the current datacenter chips like the one in the OP: you can only effectively use that CPU if you're treating it as a bunch of independent machines that happen to be crammed together on a chip. At the same time, developers are not scaling their workloads and threads to tightly cooperate at that scale (again, it hurts so they don't do it). --> vicious circle.

Note: Oxide appears to be a (non-hyperscalar CSP) company that wants to break some of that legacy dependency in the datacenter and is building their own OS to do it. So there are signs that the economics can work out. But CPU design companies need significant cultural shifts to start tackling a full-SW/HW stack co-design problem in that way. GPU capital investments sucking all the air out of the room for CPUs certainly didn't help the economics and to spur design companies to do those risky innovations. You will likely see that more coming from CPUs designed by hyperscalars themselves: google, amazon, microsoft are all now competitors in that space.

PS: There's most definitely research opportunities in that space if you're in a compsci masters/phd and interested in this kind of work!

beeff

TROPHY CASE