Hacker News Reader

Comment by miki123211 | Hacker News Reader

Why do Open BSD developers in 2023 care about architectures like alpha and sparc64? What are their use cases? Why would anybody pick those over Intel / ARM? What do those architectures provide that makes people care? Is it just existing hardware that people already have and don't want to throw away, or is there an actual reason one would buy such a processor over the more popular competition? I get the arguments for Riscv for example, but the rest are a mystery for me.

I'm not criticizing here, but actually seeking to understand.

View on HN

Big-endian CPUs were once the dominant clients in TCP/IP networking, and these machines define the hton and ntoh C macros as no-ops. This means that the network itself is big-endian.

Here is an old HP-UX machine running on PA-RISC:

  # grep ntoh /usr/include/netinet/in.h    
  #ifndef ntohl
  #define ntohl(x)        (x)
  #define ntohs(x)        (x)

On x86_64, this is a byte-swap:

  $ grep bswap /usr/include/netinet/*.h         
  /usr/include/netinet/in.h:#   define ntohl(x) __bswap_32 (x)
  /usr/include/netinet/in.h:#   define ntohs(x) __bswap_16 (x)
  /usr/include/netinet/in.h:#   define htonl(x) __bswap_32 (x)
  /usr/include/netinet/in.h:#   define htons(x) __bswap_16 (x)

SPARC is big-endian, and the memory is not in the same order as it is on x86. This can coax bugs out of software that are otherwise not seen on little-endian systems.

Alpha is litte-endian, but it has its own exotic problems.

> Alpha is litte-endian, but it has its own exotic problems.

At least some models of the Alpha were bi-endian, selectable via a pin on the package, IIRC. I believe the Cray T3E ran the chips big-endian.

I think MIPS and POWER could also do this.

Arm (both 32 and 64-bit) supports both BE and LE. Switchable at runtime so that you can have a BE VM on an LE host just fine.

Apple Arm chips however are LE only, but all of Arm's Cortex-A/Neoverse and NVIDIA's cores support both LE and BE operation.

Theo De Raadt has expressed that compiling and testing on CPUs that are "not boring" helps them to find bugs earlier.

Running on many many architectures is an another way of testing code robustness. Code that runs on X could crash on Y because it always had a bug that the quirks of X hid. The weirder the architecture the better, kind of.

Or somebody may just think it’d be a fun challenge to do and so it supports it. That’s all.

There are a lot of mistakes that make it in to common code when people only test with one architecture.

Also, the environmental cost of manufacturing new hardware is often greater than even a decade of running less efficient, older hardware longer.

To add to that, Alphas and older Sun systems are actually proper server hardware. There are differences that you may never learn about in the x86 world. I've been running an AlphaServer DS25 for years now, and it's worlds better hardware quality than any x86 server product you can buy now.

I am having trouble believing that the environmental impact of a running a server from 2002 is lower than buying a machine that is 2-3 orders of magnitude more efficient.

I doubt that the machine is even one order of magnitude less efficient.

The power supplies on that Alpha are 500W and even fairly low end Supermicro systems have 600W supplies.

The biggest differential is probably the efficiency of the power supply.

Better in what sense?

How would you characterize the differences?

Well, for one thing people still sell sparc machines. But beyond that, they care to catch bugs that an architecture monoculture misses/ignores. For example, the OpenBSD folks have said a number of times SPARC64 is a good way to catch memory alignment problems. Diversity in testing is a good thing.

Reply on news.ycombinator.com