Showing posts with label x64. Show all posts
Showing posts with label x64. Show all posts

Monday, November 11, 2019

Building OpenJDK Under Solaris SPARC and x64

[logo, courtesy OpenJDK]

Building OpenJDK Under Solaris SPARC and x64

[Duke Thinking]

Abstract:

There has been must discussion regarding Java and Solaris, both SPARC, Intel x86, and AMD x64. Oracle had released Java into the wild, under a fast continuous release plan, and paid support plans for long term releases. OpenJDK is the reference release of JavaSE since Java 7. Once concern in the industry has been, how to we compile the latest versions of Java, and this has been discussed in detail by various authors to be cited.
[Duke Plugging]

Building OpenJDK 12 under Solaris:

Guest Author Petr Sumbera had published an article on Oracle's Solaris Blog on how to compile your own version  of OpenJDK 12. What is interesting is that it uses an existing JDK to perform that process!

To compile OpenJDK 12, SPARC Solaris requires JDK 8 under Intel Solaris and JDK 11 under SPARC Solaris. In addition, you will need Oracle Solaris Studio 12.4.

[Duke Drawing]

OpenJDK on SPARC Solaris:

In  March 2019, Oracle Author Martin Mueller also published an article on Building OpenJDK Java Releases on Oracle Solaris/SPARC. In addition, you will need Oracle Solaris Studio 12.4. This article may help in the build of of OpenJDK for SPARC.

[Duke Plumbing]

OpenJDK on Intel or AMD Solaris:

In February 2019, Birkbeck College, Computer Science Department, Author Andrew Watkins also published an article on Building OpenJDK 12 on Solaris 11 x86_64. This followed on his October 2018 article on  Building OpenJDK 11 on Solaris 11 x86_64. This followed on his September 2018 article on Building OpenJDK 10 on Solaris 11 x86_64. These articles may help in the building of OpenJDK for Intel or AMD systems.

Conclusions:

The availability of the latest Java, license & support free, is available if one wants to roll their own. If commercial support is desired, Java can can still be acquired from Oracle with a Long Term Support (LTS) contract.

Monday, January 23, 2012

Virtualizations: LPARs, LDoms, Xen, KVM, VMWare, and HyperV


Virtualizations: LPARs, LDoms, Xen, KVM, VMWare, and HyperV

IBM LPARs
IBM LPARs is a premium proprietary virtualization technology which sits on top of IBM POWER architecture. It leverages the Virtual I/O Server (VIOS) in order to manage operating system resource requests from other domains.

https://www.ibm.com/developerworks/wikis/display/virtualization/VIO
"This allows a single machine to run multiple operating system (OS) images at the same time but each is isolated from the others. POWER4 based machines started this in 2001 by allowing many Logical Partitions (LPAR) to run on the same machine using but each using different CPUs, different memory sections and different PCI adapter slots. Next came with POWER4, the ability to dynamically change the CPU, memory and PCI adapters slots with the OS running. With the introduction of POWER5 in 2005, further Virtualization items have been added."
http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/iphb1/iphb1_vios_virtualioserveroverview.htm
"The Virtual I/O Server is software that is located in a logical partition. This software facilitates the sharing of physical I/O resources between client logical partitions within the server. The Virtual I/O Server provides virtual SCSI target, virtual fibre channel, Shared Ethernet Adapter, and PowerVM™ Active Memory Sharing capability to client logical partitions within the system. As a result, client logical partitions can share SCSI devices, fibre channel adapters, Ethernet adapters, and expand the amount of memory available to logical partitions using paging space devices. The Virtual I/O Server software requires that the logical partition be dedicated solely for its use. The Virtual I/O Server is part of the PowerVM Editions hardware feature."

SPARC LDOM's or Oracle VM for SPARC
SPARC LDOM's (or now referred to as Oracle VM for SPARC) is analagous to IBM's LPARs. IBM's VIOS appears to be analagous to Control Domain under. The LDom Control Domain can be subdivided between Control, Service, and I/O Domains - to architect redundancy and additional performance in a SPARC platform. LDom's are a free Solaris SPARC bundled virtualization technology.

http://www.oracle.com/us/technologies/virtualization/oraclevm/oracle-vm-server-for-sparc-068923.html
"Oracle VM Server for SPARC (previously called Sun Logical Domains) provides highly efficient, enterprise-class virtualization capabilities for Oracle's SPARC T-Series servers. Oracle VM Server for SPARC allows you to create up to 128 virtual servers on one system to take advantage of the massive thread scale offered by SPARC T-Series servers and the Oracle Solaris operating system. And all this capability is available at no additional cost."
http://en.wikipedia.org/wiki/Logical_Domains
"The Control domain, as its name implies, controls the logical domain environment. It is used to configure machine resources and guest domains... The control domain also normally acts as a service domain. Service domains present virtual services, such as virtual disk drives and network switches, to other domains… Current processors can have two service domains in order to provide resiliency against failures. I/O domain has direct ownership of and direct access to physical I/O devices, such as a network card in a PCI controller… Control and service functions can be combined within domains."
There are basic technologies available through LDOM's to developers and architects such as cluster-in-a-box, redundant I/O domains, etc.
http://docs.oracle.com/cd/E19316-01/820-4676/ggtcs/index.html
"In this logical domains (LDoms) guest domain topology, a cluster and every node within that cluster are located on the same Solaris host. Each LDoms guest domain node acts the same as a Solaris host in a cluster. To preclude your having to include a quorum device, this configuration includes three nodes rather than only two."

Xen
There are some similarities to the way these former hypervisors and Xen is architected. Various implementations of Xen exist, such as Citrix Hypervisor, Oracle VM for x86, and OpenSolaris based Xen (now a project under Illumos.) Xen is an open-sourced hypervisor.

http://xen.org/files/Marketing/WhyXen.pdf
"A critical benefit of the Xen Hypervisor is its neutrality to the various operating systems. Due to its independence, Xen is capable of allowing any operating system (Linux, Solaris, BSD, etc) to be the Domain0 thereby ensuring the widest possible use case for customers. For example, many hardware manufacturers leverage NetBSD as their OS of choice for Domain0 and are able to deploy Xen in the manner of their choosing."

"This separation of hypervisor from the Domain0 operating system also ensures that Xen is not burdened with any operating system overhead that is unrelated to processing a series of guests on a given machine. In fact, more are beginning to break up the Domain0 from a single guest into a series of mini-OS guests each with a specific purpose and responsibility which drives better performance and security in a virtualization environment."

KVM
No, this is not a Keyboard switch. Late to the game was a Linux and OpenSolaris based virtualization technology, unfortunately called KVM, for Kernel Virtual Machine. First implemented under Linux.
http://wiki.linuxplumbersconf.org/_media/2010:02-lpc-kvmstoragestackperformance.pdf

Modern OS features such as DTrace and ZFS are now available to KVM after it was quickly ported to OpenSolaris source code base by Joyent for their Open Source SMARTOS cloud operating system and cloud offering
http://www.phoronix.com/scan.php?page=news_item&px=OTc5Ng
"Joyent has announced today they have open-sourced their SmartOS operating system, which is based on Illumos/Solaris. Additionally, this cloud software provider has ported the Linux KVM (Kernel-based Virtual Machine) to this platform.

Being derived from Illumos and in-turn from Solaris, SmartOS does ship with ZFS support, DTrace, and other former Sun Microsystems technologies."



Microsoft HyperV
Some vendors came very late to the hypervisor game. Microsoft HyperV have a similar architecture, available only under Intel & AMD processors, depend on hardware acceleration available under only certain CPU chips from both of those vendors.


VMWare ESXi
VMWare has a great deal of experience in hypervisors, growing out of a software-driven solution, before hardware handlers became popular (and leveraged) in the Intel/AMD world. They provide some of the best backwards-compatibility in the Intel/AMD world.

Monday, April 5, 2010

Itanium: The Death of Microsoft Windows Support



Itanium: The Death of Microsoft Windows Support

Announcement:


History:

See former blog entry when Red Hat Linux discontinued their Itanium support.

Network Management Implications:

None. There were no serious Network Management products using Microsoft Windows on Itanium. There are really only HP operating systems left on this CPU platform, a single isolated software vendor on a single isolated chip supplier.

Why Few Implications:

Single vendor processors (IBM POWER and Intel Itanium) are somewhat more risky, when there is a gap in the development cycle due to human error. Specialized software vendors looking for longevity often look for multiple suppliers when producing a product, to ensure that a single vendor glitch does not damage their product marketing.

In the areas of server processors, there really only seems to be two multi-vendor CPU vendors left: SPARC (Oracle/Sun and Fujitsu) and x64 (Intel and AMD.)

Who Will Be Affected?

Probably, the people who will be most affected by this move will be businesses who depended on Microsoft SQL Server on Itanium.

Had those vendors chosen another database vendor, who supports multiple architectures (i.e. Oracle RDBMS) - a migration to another Operating System (i.e. an HP Operating System) on the same hardware could have been done, to extend the life of the asset, and any desired hardware architecture could have been chosen to migrate to later (i.e. SPARC, POWER, Intel x64, AMD x64.)

Friday, December 18, 2009

Itanium: The Death of Red Hat Linux Support

Itanium: The Death of Red Hat Linux Support

Announcement

As reported on The Register, Red Hat quietly announced RHEL 5 as the "end of the line" for Intel Itanium.

The History
The processor market as basically split between two comodity CISC (Completed Instruction Set Computing) chip makers, Intel (x86) and Motorola (68K) where high-end workstation & server vendors consolidated in Motorola (68K) with PC makers leveraging Intel (x86).


Motorola indicated an end to their 68K line was coming, x86 appeared to be running out of steam. A new concept called RISC (Reduced Instruction Set Computing) was appearing on the scenes. Wholesale migration from Motorola was on, many vendors creating their own very high performance chips based upon this architecture. Various RISC chips were born, created by vendors, adopted by manufacturers, each with their own operating system based upon various open standards.
  • SUN/Fujitsu/Ross/(various others) SPARC
  • IBM POWER
  • HP PA-RISC
  • DEC Alpha
  • MIPS MIPS (adopted by SGI, Tandem, and various others)
  • Motorola 88K (adopted by Data General, Northern Telecom, and various others)
  • Motorola/IBM PowerPC (adopted by Apple, IBM, Motorola, and various others)
There was reletively small volume shipments to most vendors of full fledge processors, although the computing prices allowed for continued investment to create increasingly smaller chips to enhance performance. Many of these architectures were cooperative efforts, with cross licensing, to increase volume, and create a viable vendor base. The move to 64 occurred in most of these high-end vendors. As the costs for investment continued to rise, in order to shrink the silicon chip dies, a massive consolidation started to occur, in order to save costs and continue to be profitable.

The desktop market continued to tick away with 32 bit computing at a lower cost, with 2 primary vendors: Intel and AMD.


A massive move to consolidate 64 bit RISC processors from the minority market shareholders from their smaller shares to a common, larger, Intel based 64 bit Itanium VLIW (Very Long Intruction Word) processors. This was a very risky move, since VLIW was a new architecture, and performance was unproven. The consideration by the vendors was Intel had deep enough pockets to fund a new processor. Some of the vendors, who consolidated their architectures into Itanium included:

  • HP - PA-RISC
  • DEC, purchased by Compaq, Purchased by HP - Alpha
  • DEC, purchased by Compaq, Purchased by HP - VAX
  • Tandem, purchased by Compaq, Purchased by HP - MIPS
  • SGI -> MIPS
Many of the RISC processors did not go away, they just moved to embedded environments, where many of the more complex features of the chips could continue to be dropped, so development would be less costly.
 
[Sun Microsystems UltraSPARC 2]

[Fujitsu SPARC64 VII]
[IBM Power]
Majority RISC architecture market share holds in the desktop & server arena seemed to consolidate during the fist decade of 2000 around RISC architectures of an open consortium driven by specifications called SPARC (predominately SUN and Fujitsu) and proprietary final proprietary single vendor drive POWER (predominately IBM)
 

[AMD Athlon FX 64 Bit]
AMD later released 64 bit extensions to the aging Intel x86 instructions (which all vendors, including Intel, had basically written off as a dead-end architecture) - creating what the market referred to as "x64". Intel was later forced into releasing a similar processor, competing internally with their Itanium. Much market focus started, consolidating servers onto this proprietary x64 based systems, sapping vitality and market share from RISC and VLIW vendors.

Network Management Implications

HP really drove the market to Itanium, after acquiring many companies. There was a large number of operating systems, which needed to be supported internally, so the move to consolidate those operating systems and reduce costs became important.

HP OpenView is one of those key suites of Network Management tools, which people don't get fired for purchasing. HP made announcements of their proprietary operating system HP-UX, Microsoft proprietary Windows, and open source Linux support for Intel Itanium. HP was never able to get OpenView traction with it under Linux under Itanium or Windows under Itanium, although they were able to provide support for their own proprietary HP-UX platform, as well as Linux under x86 architecture.

With Open Source Red Hat Linux going away on Itanium. Itanium as a 64 bit architecture is clearly taking a severe downturn in the viable 3rd party architectures, and Network Management from OpenView will obviously never become a player in a market that will no longer exist.
The IBM POWER architecture, even though it is one of the last two substantial RISC vendors left, has never really been a substantial vendor in Network Managment arena, even with IBM selling Tivoli Network Management suite. Network Management will most likely never be a substantial power under POWER.

"Mom & Pop" shops run various Network Management systems under Windows, but the number of managed nodes is typically vastly inferior to the larger Enterprise and Managed Services markets. The software just does not scale as well.

Sun SPARC Solaris (with massive vertical and horizontal scalibility) and Red Hat Linux x68 (typically limited to horizontal scalibility) are really the only two substantial multi-vendor Network Management platform players for large Managed Services installations left. Red Hat abandoning HP's Itanium Linux only continues to solidify this position.

Tuesday, March 24, 2009

Oracle Database Licensing: Cuts Own Throat

Oracle Database Licensing: Cuts Own throat

The Register in the UK posted an odd article concerning the licensing change to Oracle
Oracle raises software prices on IBM's Power6 iron
Odd statement regarding IBM POWER6
The Oracle price hike on Power6 chips seems unfair given that the quad-core Sparc64 VII processors used in Sun and Fujitsu machines have the same 0.75 scaling factor
The Power6 processor gains most of it's horsepower from an increase in clock rate (POWER6: 2.2GHz to 5.0Ghz, while SPARC64 processors gain their throughput through an increase in number of cores (SPARC64: 2 to 4 cores), while the CoolThreads SPARC T processor gain their throughput through a massive increase in threads per core (T: 32 threads to 64 threads.)

Multiple SPARC cores for Oracle has been a FREE LUNCH at the expense of SPARC customers.

Odd statement regarding Fujitsu SPARC64
It will be interesting to see what Oracle does when Sun and Fujitsu roll out the Sparc64 VII+ quad-core chips, which they are expected to do soon
I don't know why it would prove interesting. It is not like the clock speed will double, as POWER5 to POWER6. Right now, the core multiplier is completely out-of-whack for the SPARC64 chips, just completely.

Odd statement regarding Intel Itanium
Intel gets its quad-core "Tukwila" Itaniums out the door in June or July. The Tukwila chips should certainly get their scaling factor removed, but given that HP and Intel do not have a database software business, I would venture that Tukwilas might sneak by with a 0.75 scaling factor.
There is a popular & competitive Microsoft SQL Server on those platforms. The scaling factor may remain, to just be competitive with Microsoft SQL Server. If the clock rate doubles, removing the scaling factor removal may be a reasonable thing, but I doubt the clock rate would double.

Odd statement regarding SUN SPARC ROCK
various other Sparc, and other chips have a 100 VUP rating. ...it is hard to imagine a 16-core "Rock" UltraSparc-RK chip not being in the same range when it comes out sometime in the fall.
I highly doubt a 16 core RK chip will be 16x faster than a SPARC64 V, VI, or VII core. This being the case, IBM cranking up the VUP rating would be completely "off the chain". I think this analyst clearly has mistaken expectations from either SUN or IBM.

Reasonable statement regarding Oracle
To be fair, Oracle should run a database benchmark test on each processor and come up with a literal scaling factor based on possible clock speeds of all processors and make the scale all relative to the performance of one machine that it picks as the gold standard.
I agree with this sentiment. Just comparing POWER and the SPARC processors... In the words of President Obama, "to be FAIR":

scaling factor for POWER6 should be 1.50 instead of 0.75
scaling factor for SPARC64 should be 0.50 instead of 0.75
scaling factor for SPARC-T should be 0.50 instead of 0.75

Even with the chart above, POWER would still have an advantage of scaling factor of 0.50 per core over SPARC64 due to IBM's incredibly high clock rate!!!

This clearly demonstrates how far out-of-whack the pricing is for Oracle Databases on systems today.

Oracle cuts their own throat

Former substantial cross-platform vendors like Informix and Sybase are not the large players, like they used to be, resulting in databases being closely aligned to Hardware or OS vendors. Most applications that require a third-party database will use a major commercial vendor, like: Oracle Database, IBM DB2, or Microsoft SQL.

Oracle's continuing punishment of SUN and "giving the farm" away to IBM has always seemed odd, considering that IBM is a direct commercial competitor, while SUN's MySql is not a direct commercial competitor. The migration of Oracle RDBMS to IBM DB2 is something that IBM's professional services is something that they would LOVE to do, while there is no equivalent professional services group in SUN to move Oracle RDBMS to MySQL.

It is just a matter of time before Oracle continues to modify their processor core scaling factors, since they are cutting their own throats by advocating platforms who have extremely strong competing databases... but perhaps that is why Oracle has been able to charge a premium for SPARC - because there was no serious database competition.

By Oracle abusing their near-monopolistic licensing policies on SUN, because Oracle could, Oracle is being forced to compete against other databases on their home turf, instead of on the turf which Oracle could have an advantage (SUN SPARC Solaris has no real commercial competing database vs IBM's DB2 on IBM hardware vs Microsoft SQL on Intel Itanium or Intel x64.)

SUN, Solaris, Linux, and Growth

The Past 10 Years for SUN

SUN's investment into Linux, historically, to blunt Microsoft, has cut it's own throat since 2000. Without SUN's investment into Linux, UNIX like environments could have become irrelevant, however, with Microsoft's NT operating system release and IIS - so I think no matter what SUN did, it was a lose-lose situation... but SUN's backing of x86 Linux was a more strategic move than just ceding the position to Microsoft & x86, giving them a better position to compete later.

Linux and The Future

SUN's more recent targeted investment into Debian Linux to endorse Ubuntu and now adopt a variant of Debian packaging, may be an attempt to stop the bleeding of Solaris into RedHat and create more "choice" - which helps keep Solaris relevant under x64.

I think the adoption of Debian Linux packaging was a mistake by SUN, I believe they could have adopted new standards using a limited SVR4 format to achieve the same goals and back-port the new standard packaging to Linux for all of their OpenSource products (i.e. OpenOffice, NFS, ZFS, MySQL, GlassFish, Java, etc.)

Competition with Linux & Solaris under x64 and T Processors

Is Linux needed needed on the T processors to compete with x64?

Considering that SUN's hardware T market running Solaris has double the volume of the x64 market running combined Linux, Solaris, and Windows, Linux does not seem that important, to drive SUN sales (more on this later, with a quarterly report graph.)

Since the same software is available under Linux as it is under Solaris, perhaps not. I think the competition between the T and x64 processors is a more significant issue, with Linux impact. A single Solaris socket T processor no longer outruns Linux quad socket x64 processors on web serving workloads.

If Web Serving is the typical Linux workload, then the SPECWeb indicates that the T processors have been outperforming x64 for years on a price/performance ratio, until benchmarks published just a few months ago (with a single socket T2 outrunning quad sockets x64... but now quad socket hex core Intel chips are pushing 25% higher performance over a single socket T2) making x64 Linux price competitive with Solaris & SPARC T.
http://spec.org/cgi-bin/osgresults?conf=web2005&op=fetch&proj-COMPANY=256&proj-SYSTEM=256&proj-PEAK=256&proj-HTTPSW=256&proj-CORES=256&proj-CHIPS=256&proj-CORESCHP=256&proj-CPU=0&proj-CACHE1=0&proj-CACHE2=0&proj-CACHE3=0&proj-MEMORY=0&proj-NETNCTRL=0&proj-NETCTRL=0&proj-NNETS=0&proj-NETTYPE=0&proj-NETSPEED=0&proj-TIMEWAIT=0&proj-DSKCTRL=0&proj-DISK=0&proj-SCRIPTS=0&proj-WEBCACHE=0&proj-OS=0&proj-HWAVAIL=0&crit2-HWAVAIL=Jan&proj-OSAVAIL=0&crit2-OSAVAIL=Jan&proj-SWAVAIL=0&crit2-SWAVAIL=Jan&proj-LICENSE=0&proj-TESTER=0&proj-TESTDAT=0&crit2-TESTDAT=Jan&proj-PUBLISH=256&crit2-PUBLISH=Jan&proj-UPDATE=0&crit2-UPDATE=Jan&dups=0&duplist=COMPANY&duplist=SYSTEM&duplist=CORES&duplist=CHIPS&duplist=CORESCHP&duplist=CPU&duplist=CACHE1&duplist=CACHE2&duplist=CACHE3&duplist=NETTYPE&dupkey=PUBLISH&latest=Dec-9999&sort1=PEAK&sdir1=-1&sort2=SYSTEM&sdir2=1&sort3=CORESCHP&sdir3=-1&format=tab

This being said, in the carrier markets, with the 1U high dual T2+ platforms, there are no 8 socket 1U high hex-core Intel platforms to compete with it. Also, a 4U high quad socket T platform from sun scaling up to the equivalent of 4 T sockets, three quad socket X64 units would be required to compete (with dozens of NIC cards.) The modern x64 competition is starting to press the 1 & 2 year old T chips now. SUN really needs a T refresh (T3 should get them to be about 2-3x as fast as the T2 per-socket an restore the performance lead to 1x T socket being faster than 4x x64 sockets, to compete in this workload arena effectively.)

If SUN can release a T processor for embedded consumer or network devices, I think Linux may be a requirement, or a significantly slimmed down Solaris, in order to compete. I think that SUN avoiding this space has been disastrous decision, seeing the Apple had become largely relevant again, through this angle.

Profitability of the SUN SPARC T Processors

Some believe it is a "wild guess" to suppose the T family is profitable, but I think we can analyze the quarterly results to come up with a conclusion based closer to reality. SUN's product gross margins seem to float between 35% and 50%.
http://www.sun.com/aboutsun/investor/images/earnings_slides/img10_lg.jpg


It seems the T processors make up about 375 Million (in Q2-2009) vs non-T SPARC at about 700 Million.
http://www.sun.com/aboutsun/investor/images/earnings_slides/img07_lg.jpg


Everything else looks about equal. Take these two product sets (T SPARC, non-T SPARC), with increasing revenue on T and decreasing revenue on non-T, plot both against the Products gross margin... it looks like the T processors are not as profitable as the Non-T processors, but still reasonable. Clearly, SUN needs a refresh in the non-T processors (SPARC64 VII+ or RocK), to stabilize the downward trend, since this is the lion-share of the product revenue.

The "Other Systems" trend, seems to be inversely proportional to the T SPARC revenues... this bothers me historically, since any growth in the T SPARC seems to be getting canceled out by this other legacy category over the past 2 years, but this legacy category does not really exist any longer, as a proportion of significant revenue, so I don't believe it is worth tracking, moving forward.

If the T revenue can become in-parity with the non-T sales or supercede the non-T sales, then the unpredictability of SUN's quarterly profits & losses will be suppressed, improving the suitability for longer term investors.