3 ms·
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? Wha
by miki123211 3y ago
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.
- deleted 3y ago[deleted]
- Findecanor 3y agoTheo De Raadt has expressed that compiling and testing on CPUs that are "not boring" helps them to find bugs earlier.
- chasil 3y agoBig-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.
- KMag 3y ago> 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.
- chasil 3y agoI think MIPS and POWER could also do this.
- my123 3y agoArm (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.
- johnklos 3y agoThere 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.
- miki123211 3y agoBetter in what sense? How would you characterize the differences?
- saagarjha 3y agoI 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.
- bsder 3y agoI 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.
- aomix 3y agoRunning 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.
- kjs3 3y agoWell, 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.