Hacker News Reader

Comment by kasane_teto | Hacker News Reader

it probably wont

OpenAI buys all the RAM driving up the price so their models can shit out poorly optimized software so I have to buy more RAM. Awesome.

Sure, except this time also add on US pressuring Korean companies to not sell their old equipment to Chinese manufacturers, so the supply could actually keep up. But no no, it's all OpenAI's fault for behaving like the capitalistic swines they are. Both suck, but one has a long-lasting impact, the other is just what capitalists always done, and will continue in the future.

And then when China eventually produce not only RAM but the equipment to make it, it'll be shocked Pikachu all round.

Agreed - it's more likely to lead to poor user experience than anything else. Most end-user facing software/service companies will probably bet on the DRAM price peak being temporary.

Software takes a lot of time to build. Codebases live for decades. There's often an impossibly large cost in starting over with a less wasteful architecture/language/etc. Think going from an Electron/Chromium app to something built using some compiled language and native OS GUI constructs that uses 10x less resources.

The impossibly large cost is the difference between hardware and software returns.

Hardware by nature forces redesigns whereas software it's always possible to just keep building on top of old bad designs, and so much cheaper and faster to do so. That's why hardware is 10,000x faster than 30 years ago, and even simple word processors are debatabely faster than 30 years ago. Maybe even slower.

Hardware isn't much better actually. There isn't a good way I can show you this, but every x64 CPU contains an entire ARM CPU whose job is to initialize the x64 CPU. And of course it runs two operating systems - TrustZone and Minix.

It's even worse than that.

The ARM Core starts up, does crypto, Loads the SecureOS and the BIOS, then it starts the x86 CPU - In 16 bit mode! Which then boostraps itself through 32 then 64 bit mode.

So in the first couple sends of power on, your CPU is at various points ARM, i386, x86, and x86_64.

> The ARM Core starts up, does crypto, Loads the SecureOS and the BIOS, then it starts the x86 CPU - In 16 bit mode! Which then boostraps itself through 32 then 64 bit mode.

Well, what if I want to run a 16-bit OS?

Also, I wonder if the transistor count of a literal entire 8086 processor is so small relative to the total that they just do that.

According to https://en.wikipedia.org/wiki/Transistor_count#Microprocesso...:

    1978 Intel 8086:         29,000

    2021 Rocket Lake: 6,000,000,000

So you could fit 200,000+ 8086s on that not-so-cutting-edge silicon.

You should use a 16-bit CPU then, or an emulator.

Compatibility mode doesn't work by having a separate 16-bit core. It's random bits of spaghetti logic to make the core work like a 16-bit core when the 32-bit flag isn't set.

How much overhead (in terms of e.g. transistor count or silicon space) does this add? Surely at most it's a single digit percentage?

There isn't a separate 8086 core in every x64 core. The whole core has "if/then" spaghetti logic scattered throughout to alter its behaviour based on being in 16-bit mode.

At best, they might have been able to confine the needed logic patches to the instruction-decoding front end.

> So in the first couple sends of power on, your CPU is at various points ARM, i386, x86, and x86_64

First I'm learning about this and I'm curious why this needs to be the case? Seems so wild that it works this way, but I'm sure there's a logic to it.

Read up on the Intel Management Engine: https://en.wikipedia.org/wiki/Intel_Management_Engine

It began life as an "out of band" way to administer servers so that an ops. team could do everything (other than actual hardware changes) remotely that would otherwise need a person to be standing in front of the server in the datacenter poking commands into a keyboard.

It then grew in responsibilities to also support the "secure boot" aspect of system startup, and beyond some Intel CPU version point (I do not remember which point), it exists in every Intel CPU produced.

Cheaper to keep it then to fix all the bugs that may come from removing it?

Because

> it's always possible to just keep building on top of old bad designs, and so much cheaper and faster to do so

This is why Intel wants to remove the 16 and 32 bit modes and make 64 bit only CPUs.

I remember being flabbergasted when I worked at the open source development lab and we got our first itanium system in, a multi-core, multi-rack nec system, with its own windows pc to boot up in order to get to linux.

I know IME runs on Minix but that is on a separate 32 bit x86 processor, AFAIK.

What does the ARM CPU do?

Really? That’s like a pony motor! :)

Reply on news.ycombinator.com