Hacker News Reader

Comment by winReInstall | Hacker News Reader

It seems especially unwise now in the light of Apples M1 M2 arm shining a new light on a old x64x86 world.

Whoever made that decision is going to appear in economic textbooks in the DONT Exampels.

Also, SPARC was one of the rare processors which had an integrated Ethernet interface, which allowed it to interface itself with outside worlds with negligible latency.

First generation Niagara swept the floor with Intel chips on server and XML tasks without breaking a sweat. With massive number of cores and Unstallable Pipelines (extremely fast context switching for its time IIRC), it was a drool-worthy architecture to read and indulge into.

It was good.

Those machines with like a 100 cores were miserable, they were all super slow. So it’s only useful if you have c code or something fast. Any kind of webserving code ran faster on a dual core amd machine

They were designed to be front end machines, and XML parsers. They were meant to handle the incoming workload and handle a lot of light threads. DB and other CRUD stuff was meant to be offloaded to backend servers with beefier processors.

They had shared FPUs, so anything ALU oriented fell flat on them, even Sun openly admitted that.

So they were not meant to be SMP supercomputer nodes, but to reduce number of front end server counts and allowed datacenter floor to be available for more backend servers and storage.

In the Ultrasparc T2 (Niagra 2), each core had its own floating point hardware.

The wiki says that the T2 was over 10x faster than the T1 for floating point arithmetic.

"One floating point unit per core, up from just one FPU for the entire chip... Better floating-point throughput (>10x improvement)... Better floating-point single-thread performance (>5x improvement)"

https://en.wikipedia.org/wiki/UltraSPARC_T2

The T1 and T2 were both open-sourced. I would love to have a dual-core T2 implementation on a Raspberry PI, with completely open hardware.

https://www.oracle.com/servers/technologies/opensparc-t2-pag...

> an integrated Ethernet interface, which allowed it to interface itself with outside worlds with negligible latency

Yes, the MPI ping-pong latency I measured between x2200s was the lowest I ever saw for 1GbE. However, the motherboards in them were a disaster area (unlike any other Sun kit I ever saw).

Unfortunately we were never able to procure SPARC based systems since we are running general purpose clusters, however we were able to get some Sun ZFS 74xx series storage.

We had its smaller sibling 7320 for testing for some time. I was lucky to make the benchmarks and tests on that, and it was unbelievable for its size, so we got its bigger sibling with a pretty hefty configuration.

It had a dtrace based zero overhead real-time monitoring dashboard and, the insights and optimization possibilities were unbelievable for a device of that era. It was basically a proper enterprise storage with all the interfaces, bells and whistles with the practicality of a home desktop NAS device.

Select LUN, select capacity & disk config, select share strategy, select interfaces and it's done. The fun part? It was able to saturate any interface on itself, incl. Infiniband.

It made sense at the time. It was too big for Sun to handle alone (well, with Fujitsu, IIRC). Sun had a lot of things on their plate at the time. Sadly, chip architecture was something they could drop without much loss.

Also remember, this was the era when Apple needed to switch from the PPC to Intel too. There was a major shift in the server market from older architectures (Sparc, Power, Alpha) where everyone was standardizing on x86. It’s only been recently where ARM has been performance competitive. Only then could the power savings from ARM be a killer feature from a $/unit work point of view.

And ARM gets to leverage many different users/fabs for chips. It’s a very different ecosystem than having a single company drive an entire architecture, regardless of how great the tech was. (And support software, porting, etc.)

I think it is different.

The reason ARM is doing well now, is because of massive economies of scale due to being the dominant architecture in phones.

Same with x86 Intel during that time. Because it was the dominant desktop architecture, Intel had a massive advantage in economies of scale and eventually gained such an advantage in fabs, that it made x86 chips the price/performance champs, despite any disadvantages of the actual architecture.

In retrospect, it was a huge mistake for Intel to ignore the mobile sector with x86. Even if it did not have the margins, the mobile sector allowed ARM to gain the economy of scale that it needed to compete with Intel on the desktop/laptop and server

As you mentioned ARM processors sell at lower margin than Intel processors. ARM as a company is not a highly profitable business itself. The company had always struggled as a public company (low valuation) and was finally privatized. The IP is great, but the actual business was not very good.

Look at the BOM cost of a typical Android phone. https://www.notebookcheck.net/The-Samsung-Galaxy-Note-20-Ult... The CPU (AP) is even cheaper than the storage, baseband, and display components. An Intel i5 sells at ~$200 at midrange while a high end ARM chip sells at $57.

If Intel diverted fab production to ARM chips, they would have made less money per chip. This is why Intel sold it’s ARM business in the 2000s. Apple does not care if ARM components are profitable, because they are a vertical and the sum of components is worth more than the individual component costs. Intel is a component maker so they are sensitive to component margin.

Intel attempted an x86 based mobile phone processor in the 2010s, but ultimately failed due to selling the chips at a loss. Making components for the mobile market is cut throat and the margins are too low.

Semiconductors business is extremely tough.

Oracle isn't a hardware company like Apple and Sun. And while RISC has had a renaissance there's no guarantee that would have applied to SPARC given that SPARC's licensing is very different to ARM (and RISC-V).

So I wouldn't say it was a bad management decision to kill SPARC -- putting aside my personal love for the architecture and Sun's technologies in general.

Oracle does do hardware [1] but it is mainly used just to house backend Oracle DB better than much of commodity servers.

https://www.oracle.com/engineered-systems/exadata/

Yeah but isn't Exadata largely just off the shell components? At it's heart it's a high end Intel server running Linux. I wouldn't say this product makes Oracle a hardware company in the same way that Apple and Sun were. This just proves Oracle are a software company like Microsoft (ie they do dabble in hardware but it's the software that makes their margins).

I guess another way of putting it is this:

- do they build the software to sell their hardware,

- or build their hardware to sell their software.

In the case of Apple and Sun, it was the former. In the case of Oracle, it's the latter.

Exadata at least used to use Infiniband hardware inherited from Sun and not on anyone else's shelf.

Sparc != ARM

They are both RISC-ish but ARM has always had a focus on low power, SPARC was marketed for servers

There is no magic in any of them. ARM focused on low power because that was its niche. SPARC focused on performance and/or throughput because that's what Sun was building. And, well, x86 is focused on still being able to run MS-DOS.

Reply on news.ycombinator.com