Steve Sistare writes, "How do you scale a general purpose operating system to handle a single system image with 1000's of CPUs and 10's of terabytes of memory? You start with the scalable Solaris foundation. You use superior tools such as Dtrace to expose issues, quantify them, and extrapolate to the future. You pay careful attention to computer science, data structures, and algorithms, when designing fixes. You implement fixes that automatically scale with system size, so that once exposed, an issue never recurs in future systems, and the set of issues you must fix in each larger generation steadily shrinks.

The T5-8 has 8 sockets, each containing 16 cores of 8 hardware strands each, which Solaris sees as 1024 CPUs to manage. The M5-32 has 1536 CPUs and 32 TB of memory. Both are many times larger than the previous generation of Oracle T-class and M-class servers. Solaris scales well on that generation, but every leap in size exposes previously benign O(N) and O(N^2) algorithms that explode into prominence on the larger system, consuming excessive CPU time, memory, and other resources, and limiting scalability. To find these, knowing what to look for helps."

Read of more details.
(Get More Information . .)

Along time Sun employee writes, "I've often heard the term "Slow-laris" applied to Oracle's premier Unix operating system. Most frequently this was in comparison to the Linux OS running on small two socket servers. I will admit that in the Solaris 8 and 9 timeframe engineering decisions were made to benefit scalability to 64 sockets that sometimes penalized smaller servers. In addition, because of Solaris long history and derivation from ATT and BSD Unix code, there was undoubtedly a bit of code labeled, "if it ain't broke, don't fix it."

With the advent of Solaris 10 and Dynamic Tracing, (DTrace) we actually hunted down and killed a number of those legacy code segments using a new philosophy labeled internally, "If Solaris is slower than Linux on the same hardware, it's a bug."

As a result, Solaris 11 provides higher performance than Red Hat Enterprise Linux 6.3 on basically identical 2 socket hardware as measured by the SPECjbb benchmark..."
(Get More Information . .)

A comment by a prospective employee sent Adam Leventhal on a mission. The comment echoed one of the applicant's college professors who asserted that systems programming was at a dead end. Leventhal defined four sorts of "systems programming." Among the four types are:

• supporting systems software
• accidental systems software
• replacement systems software
• intentional systems software

That said, is systems programming truly dead? No, Leventhal responds. "As more and more critical applications build on an interface, the more value there is in improving the systems software beneath it. Systems software is defined by the constraints; it’s a mission and a mindset."
(Get More Information . .)