4 ms·

Really a pity that Oracle killed off SPARC. They already had 32-core CPUs almost a decade ago but Oracle never really understood the value that SPARC and Solari

Really a pity that Oracle killed off SPARC. They already had 32-core CPUs almost a decade ago but Oracle never really understood the value that SPARC and Solaris brought to the table.

mrbluecoat 2y ago
Ironically, Oracle seems to be the only cloud compute offering Ampere currently.
- geerlingguy 2y ago
  Azure seems to be offering Ampere-based offerings[1], as well as Hetzner[2]. [1] https://azure.microsoft.com/en-us/blog/azure-virtual-machines-with-ampere-altra-arm-based-processors-generally-available/ https://azure.microsoft.com/en-us/blog/azure-virtual-machine... [2] https://www.hetzner.com/press-release/arm64-cloud/ https://www.hetzner.com/press-release/arm64-cloud/
  - mrbluecoat 2y ago
    Oh cool, I thought they had discontinued them.
Tuna-Fish 2y ago
... SPARC was terrible. Really just utter excrement. Having a lot of cores is not a good thing when the cores are too slow. This is an interesting CPU because the cores are actually usably fast. Nearly all programs have a constant memory usage regardless of how fast the core running them is. If you deliberately make your cores half the speed, and double the amount of them, you have approximately doubled the cost of the memory you need. In aggregate, memory already costs so much more than CPUs that this is rarely if ever useful, even if it meant your cpu is free. The starting point of a design that tiles a lot of cores just needs to be ones of the fastest cores available, or it is not commercially viable.
UltraSane 2y ago
SPARC was getting quite slow compared to other architectures and it would have cost a fortune to keep it competitive.
icedchai 2y ago
I was a huge Sun fan for most of the 90's and had several Sun systems at home. By the early 2000's, Sun was no longer competitive. Between Intel and Linux, the writing was on the wall. I haven't seen a Sun system used in production since 2003.
- shrubble 2y ago
  They are still being used in telecom. Not the new SPARC M7 series, but what was shipping in 2004-2005 timeframe is still in the rack and doing stuff (which is pretty crazy).
- elcritch 2y ago
  Bit of a pity now that the most advanced process nodes would be available via TSMC. Solaris seemed to be much more solid than linux overall.
  - acdha 2y ago
    Solaris was more stable in the mid-90s but that advantage had flipped by the turn of the century. It was an order of magnitude more expensive to support, especially at scale because Linux was far ahead on packaging and configuration management by 1998 or so, which in practice meant that no two Solaris boxes were the same unless your organization was willing to spend a lot of money on staffing. Solaris 10 was intended as a catch-up release but the package manager took years to mature. I remember getting racks of systems in the mid-2000s where simply running the updater on brand new servers rendered them unbootable. By then the writing was on the wall. SPARC was similar: the hardware had some neat aspects but what they really needed was the equivalent of a first-class LLVM backend now. Statistically nobody was hand-tuning assembly code to try to get it to be competitive with x86, especially since that meant not only your own code but most other libraries. The reason ARM is doing so well now is that two decades where the most popular computing devices are phones means that you can just assume that anything popular will compile and run well on ARM.
    - simtel20 2y ago
      Yep packaging was a nightmare. The fix for a bug in cron could require you to apply a kernel patch and reboot. But not if you had already applied a different kernel patch beforehand for some specific hardware, but which wasn't available except for particular hardware. But if you just install the patch it may succeed! But it didn't really apply, because the solver that figures out your patches ran separately and doesn't run fast enough to be part of the patch process but the patch has its own script that checks whatever separately to determine that. Oh and if you wait a week your process may break because the -20 version of the patch doesn't fix your problem anymore but it superceded the -12 version you were using anyway. But whichever one you apply, you'll have to reboot. Like, to update cron. Even though through 3 versions of the same patch id, it does and does not fix cron. Pure insanity with no product focus on user experience.

Really a pity that Oracle killed off SPARC. They already had 32-core CPUs almost a decade ago but Oracle never really understood the value that SPARC and Solaris brought to the table.

mrbluecoat 2y ago

Ironically, Oracle seems to be the only cloud compute offering Ampere currently.

geerlingguy 2y ago
Azure seems to be offering Ampere-based offerings[1], as well as Hetzner[2]. [1] https://azure.microsoft.com/en-us/blog/azure-virtual-machines-with-ampere-altra-arm-based-processors-generally-available/ https://azure.microsoft.com/en-us/blog/azure-virtual-machine... [2] https://www.hetzner.com/press-release/arm64-cloud/ https://www.hetzner.com/press-release/arm64-cloud/
- mrbluecoat 2y ago
  Oh cool, I thought they had discontinued them.

Tuna-Fish 2y ago

... SPARC was terrible. Really just utter excrement. Having a lot of cores is not a good thing when the cores are too slow. This is an interesting CPU because the cores are actually usably fast. Nearly all programs have a constant memory usage regardless of how fast the core running them is. If you deliberately make your cores half the speed, and double the amount of them, you have approximately doubled the cost of the memory you need. In aggregate, memory already costs so much more than CPUs that this is rarely if ever useful, even if it meant your cpu is free. The starting point of a design that tiles a lot of cores just needs to be ones of the fastest cores available, or it is not commercially viable.

UltraSane 2y ago

SPARC was getting quite slow compared to other architectures and it would have cost a fortune to keep it competitive.

icedchai 2y ago

I was a huge Sun fan for most of the 90's and had several Sun systems at home. By the early 2000's, Sun was no longer competitive. Between Intel and Linux, the writing was on the wall. I haven't seen a Sun system used in production since 2003.

shrubble 2y ago
They are still being used in telecom. Not the new SPARC M7 series, but what was shipping in 2004-2005 timeframe is still in the rack and doing stuff (which is pretty crazy).
elcritch 2y ago
Bit of a pity now that the most advanced process nodes would be available via TSMC. Solaris seemed to be much more solid than linux overall.
- acdha 2y ago
  Solaris was more stable in the mid-90s but that advantage had flipped by the turn of the century. It was an order of magnitude more expensive to support, especially at scale because Linux was far ahead on packaging and configuration management by 1998 or so, which in practice meant that no two Solaris boxes were the same unless your organization was willing to spend a lot of money on staffing. Solaris 10 was intended as a catch-up release but the package manager took years to mature. I remember getting racks of systems in the mid-2000s where simply running the updater on brand new servers rendered them unbootable. By then the writing was on the wall. SPARC was similar: the hardware had some neat aspects but what they really needed was the equivalent of a first-class LLVM backend now. Statistically nobody was hand-tuning assembly code to try to get it to be competitive with x86, especially since that meant not only your own code but most other libraries. The reason ARM is doing so well now is that two decades where the most popular computing devices are phones means that you can just assume that anything popular will compile and run well on ARM.
  - simtel20 2y ago
    Yep packaging was a nightmare. The fix for a bug in cron could require you to apply a kernel patch and reboot. But not if you had already applied a different kernel patch beforehand for some specific hardware, but which wasn't available except for particular hardware. But if you just install the patch it may succeed! But it didn't really apply, because the solver that figures out your patches ran separately and doesn't run fast enough to be part of the patch process but the patch has its own script that checks whatever separately to determine that. Oh and if you wait a week your process may break because the -20 version of the patch doesn't fix your problem anymore but it superceded the -12 version you were using anyway. But whichever one you apply, you'll have to reboot. Like, to update cron. Even though through 3 versions of the same patch id, it does and does not fix cron. Pure insanity with no product focus on user experience.