Illumos Dropping SPARC, Allows For Newer Compiler + Eventual Use Of Rust In The Kernel

[phoronix]

Phoronix: Illumos Dropping SPARC, Allows For Newer Compiler + Eventual Use Of Rust In The Kernel

The Illumos project born out of the former Sun Microsystems OpenSolaris codebase has decided to end support for SPARC hardware...

https://www.phoronix.com/scan.php?page=news_item&px=Illumos-Drops-SPARC

[pracedru]

I tried the new rfelease of Open Indianna Hipster and i was surprised at how much RAM it was using compared to an equivalent Linux desktop.
Does anyone know why OI Hipster is so RAM thirsty?

[tildearrow]

Because it's a toy OS with no serious talent working on it.

I wonder if OpenIndiana is benchmarkable now or still not...

[pracedru]

Because it's a toy OS with no serious talent working on it.

For a toy os it is working pretty well.

[acobar]

I tried the new rfelease of Open Indianna Hipster and i was surprised at how much RAM it was using compared to an equivalent Linux desktop.
Does anyone know why OI Hipster is so RAM thirsty?

Probably because ZFS. It is something OpenZFS tried to tame.

[ezst036]

It's a shame that OpenSPARC didn't take off years ago, there wouldn't be any need to reinvent the wheel with RISC-V.

[squash]

Sparc was always the more interesting piece of the Sun pie, even if it was often poorly executed. Outside of ZFS, Solaris really didn't bring much to the table. They gradually added features that their competitors had for years and while it wasn't a "bad" OS it was almost always quite uninteresting.

Sparc on the other hand was an early adopter of 64 bit architectures (1995!), so early in fact they had to disable it on their first gen of products because of a cpu bug that would easily grant root. These days, everyone has 64 bit.

They took multicore/multtithread to a new level with their Niagara in 2005, with an 8 core 32 thread monster at 1.4ghz. Of course they shared some unfortunate components such as a single FPU for the entire chip, giving single core comparable performance to a 2 generation prior 450mhz UltraSparc IIe, but if you had an easy job like compiling, service static files over web or nfs, it was a monster. These days everyone does multicore+multithread but 32 threads on a single chip in 2005 was revolutionary.

UltraSparc IV would scale up to 72 sockets, up to 144 cores and half a terabyte or RAM, in 2005... Sure the previous generation could house more physical processors but they were single core, so this was a good jump. This scale of beast required a full 6 foot rack, giving you a level of cpu/memory capacity we can today fit easily into 1U... But in 2005 that was a massive system capable of running a single operating system rather than as a cluster.

Ultrasparc V and up were essentially Fujitsu products that Oracle happened to also sell, with notable improvements in 2012 and 2014, after which Fujitsu announced they were moving to ARM instead of doing Oracle's work for them.

[pracedru]

Probably because ZFS. It is something OpenZFS tried to tame.

I was comparing it with F34 Mate edition (almost same desktop) which uses BTRFS. Is BTRFS really using that much less memory than ZFS?
I was comparing the intial RAM consumption after boot and the peak RAM consumption while installing Libreoffice.
After boot it was:

• OI Hipster: 1600 MB RAM
• Fedora 34: 800 MB RAM

During LO install the peak was:

• OI Hipster: 4000 MB RAM
• Feedora 34: 950 MB RAM

Can the difference between ZFS and BTRFS really be the only explaination?

[skeevy420]

I was comparing it with F34 Mate edition (almost same desktop) which uses BTRFS. Is BTRFS really using that much less memory than ZFS?
I was comparing the intial RAM consumption after boot and the peak RAM consumption while installing Libreoffice.
After boot it was:

• OI Hipster: 1600 MB RAM
• Fedora 34: 800 MB RAM

During LO install the peak was:

• OI Hipster: 4000 MB RAM
• Feedora 34: 950 MB RAM

Can the difference between ZFS and BTRFS really be the only explaination?

Yes.

ZFS can be tuned to use a minimal amount of memory. IIRC, by default it'll use 50% of the ram and is designed to be able to free up ram and give it to the system if it needs it. Using more ram when idle or during file system operations like installing a program is to be expected with ZFS. If the memory is there why not use it?

IMHO, lots of free ram isn't necessarily a good thing. Minimal ram usage at the expense of system responsiveness and performance falls under that category. It's like the early Android years where you had to do tricks like forcing your home launcher to stay in ram and keep on running in the background or else you'd have to wait a few seconds any time you'd exit an app or hit the home button. ZFS is like that with frequently accessed files, directory layouts, etc so things like spinny hdd mirrors are snappy (for certain things) even though you haven't navigated to any of those directories in a week.

[pracedru]

Yes.

ZFS can be tuned to use a minimal amount of memory. IIRC, by default it'll use 50% of the ram and is designed to be able to free up ram and give it to the system if it needs it. Using more ram when idle or during file system operations like installing a program is to be expected with ZFS. If the memory is there why not use it?

IMHO, lots of free ram isn't necessarily a good thing. Minimal ram usage at the expense of system responsiveness and performance falls under that category. It's like the early Android years where you had to do tricks like forcing your home launcher to stay in ram and keep on running in the background or else you'd have to wait a few seconds any time you'd exit an app or hit the home button. ZFS is like that with frequently accessed files, directory layouts, etc so things like spinny hdd mirrors are snappy (for certain things) even though you haven't navigated to any of those directories in a week.

Look I understand the sentiment.
But if your system with 4GB RAM is beginning to swap RAM to disk, when the only thing you are doing is installing libreoffice, then it is so bad that it is on the verge of being completely unusable.