Tweet
I'm a former Solaris admin (of Solaris 10 u1, released Jan 2006. I've had accounts on Sol 5-9 machines, too, but I've never touched openSolaris and don't really know much about it. People who replied to this have pointed out that some important things have changed with OpenSolaris. I stand by everything I said before, just be aware that it doesn't all apply to OpenSolaris, and that people with mindsets other than mine probably like some of the things I dislike. I editted this first paragraph to put this big disclaimer up front, since I don't want to slag things that don't deserve it.)
I was never impressed by the ancient 32bit free software they ship. If you wanted anything to run fast, you compiled it with Sun's Studio compiler (which is now free but not open source/Free software, but used to cost money).
So yeah, crappy old gcc, probably 32bit only, no wonder it got killed. It probably wasn't doing much multithreading. Compiling stuff on Solaris is a big pain in general, because you have to find all the right libraries to link in. A bunch of stuff that's just in the standard libc is in other libs on Solaris (e.g. -lnsl or something.) My guess is that the Phoronix test suite didn't get the high performance versions of any openMP libraries.
Besides all that, gcc4 can vectorize for SSE2, but gcc 3.4 couldn't. So maybe that's what helped LAME and oggenc, and some of the other benches to a lesser degree.
x64 Solaris = 64bit kernel, and the same 32bit userspace they ship for 32bit x86 Solaris, with 64bit versions of a few key libraries available. (But _not_ of most libraries, so if you want to compile a 64bit binary of something, you often need to install your own 64bit versions of any libraries it wants, other than libc, libm, and maybe some numeric performance libs. IIRC, Solaris doesn't provide a 64bit libncurses even. And the sunfreeware libreadline and so on are all ancient. And 32bit only. Just like the blastwave.org packages, although they're at least more up to date.)
Solaris is probably ok for a server that doesn't get any interactive command line use, so it doesn't matter that the Unix environment is crappy and old and not nice to use if you're used to recent GNU/Linux. It's patches and updates are totally designed around a "set it up and modify as little as possible" mindset. Which is the exact opposite of what I like and am used to, with Debian's and Ubuntu's stable releases where a security update isn't a patch, but a whole new version of a package you can install normally. And where you upgrade to new stable releases of the OS quite painlessly. I realize some of the reasons I don't like Solaris are just because I don't know it well, so I get annoyed with it when it's just different from what I'm used to, not that everything about it is intrinsically worse. However, I would totally not recommend it for interactive use if you care about things like having a non-ancient version of GNU sed. (Let alone not having to worry about all the crappy non-GNU unix utilities, and what order to put things in in your $PATH.)
Installing Solaris updates tends to break other things esp. the N1 System Manager provisioning system, but also other stuff that depends on Java sometimes has hard-coded paths involving an exact version number of Java, so it breaks when you install Java updates. Again with my point about being good for setup and don't touch, opposite of Debian updates and proposed-updates being generally a good thing to install.
If anyone feels inclined to defend Solaris, that's fine. I'm trying to be clear that the things I don't like about it are deal-breakers for me, but don't bother some people too much. My ideas of how I want a system to work revolve around something that updates easily to the latest stable version, which is why I use Debian and Ubuntu. My idea of what a package is is based on years of Debian experience, so that made me very unhappy with Solaris's apparently different concept.
BTW, the Bork file encryption benchmark, which was the only one Solaris did well on (not counting the CPU-bound ones where all 3 basically tied, but where Solaris lost probably because it has more crap running in the background slowing it down.)... Anyway, Solaris probably did well on Bork because ZFS is pretty good. ext4 is good, too, compared to Intrepid's ext3. IIRC, previous articles have shown that Bork is mostly I/O limited on most machines. So that's what that bench tells us.
I was never impressed by the ancient 32bit free software they ship. If you wanted anything to run fast, you compiled it with Sun's Studio compiler (which is now free but not open source/Free software, but used to cost money).
So yeah, crappy old gcc, probably 32bit only, no wonder it got killed. It probably wasn't doing much multithreading. Compiling stuff on Solaris is a big pain in general, because you have to find all the right libraries to link in. A bunch of stuff that's just in the standard libc is in other libs on Solaris (e.g. -lnsl or something.) My guess is that the Phoronix test suite didn't get the high performance versions of any openMP libraries.
Besides all that, gcc4 can vectorize for SSE2, but gcc 3.4 couldn't. So maybe that's what helped LAME and oggenc, and some of the other benches to a lesser degree.
x64 Solaris = 64bit kernel, and the same 32bit userspace they ship for 32bit x86 Solaris, with 64bit versions of a few key libraries available. (But _not_ of most libraries, so if you want to compile a 64bit binary of something, you often need to install your own 64bit versions of any libraries it wants, other than libc, libm, and maybe some numeric performance libs. IIRC, Solaris doesn't provide a 64bit libncurses even. And the sunfreeware libreadline and so on are all ancient. And 32bit only. Just like the blastwave.org packages, although they're at least more up to date.)
Solaris is probably ok for a server that doesn't get any interactive command line use, so it doesn't matter that the Unix environment is crappy and old and not nice to use if you're used to recent GNU/Linux. It's patches and updates are totally designed around a "set it up and modify as little as possible" mindset. Which is the exact opposite of what I like and am used to, with Debian's and Ubuntu's stable releases where a security update isn't a patch, but a whole new version of a package you can install normally. And where you upgrade to new stable releases of the OS quite painlessly. I realize some of the reasons I don't like Solaris are just because I don't know it well, so I get annoyed with it when it's just different from what I'm used to, not that everything about it is intrinsically worse. However, I would totally not recommend it for interactive use if you care about things like having a non-ancient version of GNU sed. (Let alone not having to worry about all the crappy non-GNU unix utilities, and what order to put things in in your $PATH.)
Installing Solaris updates tends to break other things esp. the N1 System Manager provisioning system, but also other stuff that depends on Java sometimes has hard-coded paths involving an exact version number of Java, so it breaks when you install Java updates. Again with my point about being good for setup and don't touch, opposite of Debian updates and proposed-updates being generally a good thing to install.
If anyone feels inclined to defend Solaris, that's fine. I'm trying to be clear that the things I don't like about it are deal-breakers for me, but don't bother some people too much. My ideas of how I want a system to work revolve around something that updates easily to the latest stable version, which is why I use Debian and Ubuntu. My idea of what a package is is based on years of Debian experience, so that made me very unhappy with Solaris's apparently different concept.
BTW, the Bork file encryption benchmark, which was the only one Solaris did well on (not counting the CPU-bound ones where all 3 basically tied, but where Solaris lost probably because it has more crap running in the background slowing it down.)... Anyway, Solaris probably did well on Bork because ZFS is pretty good. ext4 is good, too, compared to Intrepid's ext3. IIRC, previous articles have shown that Bork is mostly I/O limited on most machines. So that's what that bench tells us.
I've only ever worked with Solaris 10 u1 (released Jan 2006) on a rack of dual-CPU dual-core Opterons. Yeah, I didn't realize that OpenSol was that different, so I needed to be more clear that I was talking about old Solaris. I'll go edit that in at the top of my post.
Anything would be better than Sun's old update system. Thanks for clearing up my misconceptions re Solaris vs. OpenSolaris.
Comment