Strategische Überlegungen64Bit; IBM SUN AMD Intel

Opteron · 20.04.2009

PuckPoltergeist schrieb:
Abwarten. Chris Mason hat heute diesbezüglich auf der ML geschrieben, dass sich bezüglich btrfs nichts ändert. Es ist wohl weiter für Oracle ein primäres Projekt. (habs gerade gelesen)
Davon abgesehen arbeitet ja Oracle auf btrfs-Basis schon an einem Cluster-FS. Ist allerdings Closed Source.

Das hört sich immer mehr nach nem Hase und Igel spiel an:
Wie bei btrfs arbeitet man "nur" dran, und Sun hat schon (längst) was:

Sun Microsystems, Inc. (NASDAQ: JAVA) today, October 2, 2007, announced it has completed its acquisition of certain assets of Cluster File Systems, Inc. By acquiring the assets of Cluster File Systems, Inc., the leading parallel file system provider, Sun will add support for the Solaris Operating System (Solaris OS) on Lustre and plans to continue enhancing Lustre on Linux and Solaris OS across multi-vendor hardware platforms.The agreement further extends Sun's momentum in open source and Solaris and complements the Company's current direction to provide the industry's most complete end-to-end High Performance Computing (HPC) storage solution.

http://www.sun.com/software/clusterfs/

Das war 2007, seitdem wird doch hoffentlich was passiert sein ^^

Der Oracle Chef ist - soweit ich weiss - für unpopuläre Entscheidungen und markige Sprüche bekannt, würde mich bei dem Chef nicht wundern, wenn er die Linux Abteilung plötzlich einfach zumacht. Wenn das eh closed source sein wird, muss man ja nun wirklich nicht das Rad neu erfinden.
Oder übersehe ich wieder neue "features"

ciao

Alex

PuckPoltergeist · 20.04.2009

Opteron schrieb:
Das hört sich immer mehr nach nem Hase und Igel spiel an:
Wie bei btrfs arbeitet man nur dran, und Sun hat schon (längst) was:

http://www.sun.com/software/clusterfs/

Das war 2007, seitdem wird doch hoffentlich was passiert sein ^^

Lustre arbeitet meines Wissens immer noch auf Basis von ext3. Allerdings verfolge ich das nicht all zu aktiv.

Opteron · 20.04.2009

PuckPoltergeist schrieb:
Lustre arbeitet meines Wissens immer noch auf Basis von ext3. Allerdings verfolge ich das nicht all zu aktiv.

Jo sieht wohl so aus, wenn man die OS Support List anschaut:

Operating Systems:

Red Hat Enterprise Linux 4, 5

SUSE 9, 10

Linux 2.6 kernels

http://www.sun.com/software/products/lustre/specs.xml

Aber es arbeitet eben schon ..

ciao

Alex

PuckPoltergeist · 20.04.2009

Opteron schrieb:
Jo sieht wohl so aus, wenn man die OS Support List anschaut:

http://www.sun.com/software/products/lustre/specs.xml

Aber es arbeitet eben schon ..

Klar arbeitet es schon. Wenn Oracle Lustre oder SGI gekauft hätte, hätten sie jetzt auch schon ein arbeitendes Cluster-FS. Die Frage ist, was will man erreichen. Es wird ja mit btrfs nicht ganz grundlos ein vollkommen neues FS aus dem Boden gestampft. Der Anforderungskatalog ist da von Oracle bestimmt einigermaßen an den eigenen Bedürfnissen ausgerichtet worden. Wenn Lustre die zufrieden stellen würde, würde man dies dafür nehmen. Macht man ja nicht. Ergo scheint es irgendwo noch Bedarf nach anderen Features zu geben.

Opteron · 20.04.2009

PuckPoltergeist schrieb:
Klar arbeitet es schon. Wenn Oracle Lustre oder SGI gekauft hätte, hätten sie jetzt auch schon ein arbeitendes Cluster-FS. Die Frage ist, was will man erreichen. Es wird ja mit btrfs nicht ganz grundlos ein vollkommen neues FS aus dem Boden gestampft. Der Anforderungskatalog ist da von Oracle bestimmt einigermaßen an den eigenen Bedürfnissen ausgerichtet worden. Wenn Lustre die zufrieden stellen würde, würde man dies dafür nehmen. Macht man ja nicht. Ergo scheint es irgendwo noch Bedarf nach anderen Features zu geben.

Bist Du Dir da so sicher ?
Ich würde erstmal die nächsten 2-3 Wochen abwarten.

ZFS + Lustre ist Laut Plan Mitte 2009 fertig:

http://www.hpcuserforum.com/presentations/Tucson/SUN Lustre_Update-080615.pdf
http://arch.lustre.org/index.php?title=Architecture_ZFS_for_Lustre

Glaube kaum, dass btrfs + Cluster bis dahin fertig ist.

Edit:
Lol, Lustre ist wohl auch nicht besser, was die Planung angeht, die sind gerade noch bei Version 1.8:

Lustre 1.8 is in the final cycles of release testing and expected to GA in April 2009. Lustre 1.8 will introduce several robust, new features including:

http://wiki.lustre.org/index.php/Main_Page

Hmm hübsch, Oracle scheint ganz gut mit den Sparc CMT Chips zu laufen:
http://blogs.sun.com/glennf/resource/Optimizing_Oracle_CMT_v1.pdf

Beispiel aus dem pdf: ebay:
http://www.sun.com/customers/servers/ebay.xml

Was mir gerade da auch noch einfällt ist Bobos & mein Lieblingsthema:

Transactional Memory
http://channelsun.sun.com/video/mark+moir+presents+at+sun+labs+open+house+2008/1902609855

Das sollte mal an MySQL angepaßt werden, da wird eine Oracle Anpassung jetzt sicher eine höhere Priorität haben.
Selbiges könnte auch die Killerapp (=Rettung) für die Sparc Abteilung sein

ciao

Alex

PuckPoltergeist · 20.04.2009

Opteron schrieb:
Bist Du Dir da so sicher ?
Ich würde erstmal die nächsten 2-3 Wochen abwarten.

Sicher bin ich mir das. Lustre ist nicht neu. Dazu haben sie mit OCFS noch eine weitere ext3 basierte und dazu noch hauseigene Technik im Repertoire. Wenn das die Bedürfnisse erfüllen würde, würden sie nicht was neues entwerfen.

edit:Ich muss mich hier wohl berichtigen. CRFS soll mitnichten ein Cluster FS werden. Das Akronym steht für 'Coherent Remote File System', was also eher ein NFS-Ersatz ist.

ZFS + Lustre ist Laut Plan Mitte 2009 fertig:

http://www.hpcuserforum.com/presentations/Tucson/SUN Lustre_Update-080615.pdf
http://arch.lustre.org/index.php?title=Architecture_ZFS_for_Lustre

Glaube kaum, dass btrfs + Cluster bis dahin fertig ist.

Mit Sicherheit nicht. Aber was sagt das? Dann gibt es Lustre mit ZFS Backend, für diejenigen, die Solaris einsetzen wollen. Das ist für btrfs erstmal relativ uninteressant. Zumal der Clusteransatz hier vollkommen von Lustre unabhängig ist.

Das sollte mal an MySQL angepaßt werden, da wird eine Oracle Anpassung jetzt sicher eine höhere Priorität haben.
Selbiges könnte auch die Killerapp (=Rettung) für die Sparc Abteilung sein

Möglich, wobei MySQL und Oracle als zwei getrennte Bereiche aufgefasst werden sollten. Die werden sich auch weiterhin unabhängig voneinander entwickeln.

edit2: Ganz nebenbei, SGI springt gerade auch über die Klinge
http://www.heise.de/ix/SGI-steht-vor-Uebernahme-durch-Konkurrenten--/news/meldung/135609
http://staging3.rackable.com/news/pressrelease.aspx?prid=672

Opteron · 21.04.2009

PuckPoltergeist schrieb:
edit2: Ganz nebenbei, SGI springt gerade auch über die Klinge
http://www.heise.de/ix/SGI-steht-vor-Uebernahme-durch-Konkurrenten--/news/meldung/135609
http://staging3.rackable.com/news/pressrelease.aspx?prid=672

Jo ist ja nicht das erste Mal *lol*

Nochmal zu dem Solaris / ZFS vs. Linux / btrfs Thema. So wies ausschaut haben die da bei Oracle nen sehr "pragmatischen" Ansatz:

Oracle is a tough place. It routinely evaluates the performance of staff and chops around 10 per cent. Acquired staff and products must also justify their place in this Dawnian environment or they'll get chopped or boxed.

For example, Oracle spiked its own Java application server having bought the rival WebLogic Server from BEA Systems, because WebLogic was the better application server. It canned development of BEA's WebLogic Workshop development environment.

http://www.theregister.co.uk/2009/04/21/oracle_sun_open_source/

Möge der Bessere gewinnen *buck*

Bin gespannt was am Ende für ein bunter Haufen vom Linux / Solaris Softwarestack alles übrig bleibt. *lol*

ciao

Alex

PuckPoltergeist · 21.04.2009

Opteron schrieb:
Jo ist ja nicht das erste Mal

Ja, aber diesmal wohl endgültig. Ist ja nix mehr da, was man kurzfristig veräußern könnte, um die Schulden zu bedienen. Nach dem das Tafelsilber verscherbelt wurde und nach der Umfirmierung von Silicon Graphics zu SGI war ja keine klare Linie mehr zu erkennen. Ok, man hat sich auf die Nische des HPC zurück gezogen. Aber da waren sie derart massiver Konkurrenz ausgesetzt, die auch noch wesentlich besser aufgestellt ist (IBM, HP). Massive SMP-Systeme alleine reichen offenbar nicht aus. Bin gespannt, was Rackable daraus macht. Ob sie damit was anfangen können, oder ob sie die Reste von SGI filetieren und verkloppen. Um so manches wäre es ja doch schade.

Bobo_Oberon · 22.04.2009

Opteron schrieb:
... Nochmal zu dem Solaris / ZFS vs. Linux / btrfs Thema. So wies ausschaut haben die da bei Oracle nen sehr "pragmatischen" Ansatz:
http://www.theregister.co.uk/2009/04/21/oracle_sun_open_source/ ...

Tja, das wird man noch sehen, wie pragmatisch Oracle mit dem Tafelsilber von Sun umgeht.

Es hat sich etwas getan bei MySQL. Offenbar hat der Systempartner Google nicht nur irgendwelche billigen x86-PCs bei sich in der Server-Farm stehen, sondern offenbar auch einen Gerätepark mit SPARC-Kisten.

Google hat Patches für MySQL geschrieben, die Sun offenbar in einer neuen Revision 5.4 einpflegt. Dabei wird bei höherer Threadzahl eine Leistungssteigerung bei den SPARCs, aber auch den neuen Nehalem-Linien beobachtet.

In so fern macht sich bezahlt, dass Sun viel Erfahrung mit SMT- und Multisockelsystemen hat. An anderer Stelle hier im Forum wurde ja grundsätzlich bezeweifelt, dass Datenbanken-Software per se keinen Nutzen aus SMT-Technik ziehen könne.

...Durch die Google-Patches soll sich vor allem die Skalierbarkeit von InnoDB-Anwendungen verbessert haben. Durch atomare Instruktionen anstelle von Mutexes sollen Read-Write-Locks schneller geworden sein. Konkurrierende Threads können jetzt ohne Locks synchronisiert werden

-> "Sun überrascht mit MySQL 5.4" [Heise.de]. Ein Leistungsgewinn von etwa 15 Prozent wenn eine gewisse Mindestanzahl an Threads bearbeitet wird.

In wie weit das auch für Oracles Datenbanken gilt und vor allem in wie weit auch der Rock noch eine Rolle spielt, darüber kann nur spekuliert werden.
Wünschenswert wäre es schon, wenn Suns kommende Technologie "Simultaneous speculative threading (SST)" zum Einsatz käme.

Mit Suns Tools wie DTRace scheint jedenfalls noch Luft in MySQL zum Tunen drin zu sein.

Opteron · 24.04.2009

Bobo_Oberon schrieb:
Tja, das wird man noch sehen, wie pragmatisch Oracle mit dem Tafelsilber von Sun umgeht.

Im Moment noch ganz artig und brav:

Phillips and Screven also attempted to re-assure employees that Oracle's not about to sell of the hardware business, saying Oracle's not as inexperienced at working with hardware as many think. According to Philips, Oracle's experience comes from tuning its software to partners' hardware. Oracle engineers have also helped develop the Linux kernel.
(...)
"We have a track record of saying we know what to do. We are not going to kill off any product. It makes no sense to spend billions of dollars and start killing off products(*). We want to let as many survive as possible," he said.
(...)
"We know a little bit more about hardware than people think because we have to port across all these product lines...it seems like we just build software and throw it over the wall, but it's not the way it works," Philips said.
(...)
As for specific x86, mid-range of high-end Sparc processors, Phillips again avoided details but claimed all Sun's processors look appealing. Screven added: "When we were considering the acquisition we studied the processor lines and benchmarked things - we needed to be comfortable with the fact these were hardware platforms, systems, that we were going to keep selling and developing...we are very comfortable."
(...)
"In 55 acquisitions, we have never spun off anything," Phillips added.

http://www.theregister.co.uk/2009/04/23/oracle_sun_town_hall/

Klingt ja erstmal alles ganz nett, aber warten wir mal was davpn übrig bleibt. Immerhin ist noch was brauchbares dabei, MySQL und JAVA sind auf alle Fälle in Sicherheit.

Mich wundert da eher, dass Solaris nicht auch (schon) mit dabei ist ...

ciao

Alex
(*) Für Oracle nicht, für IBM schon, mal ein Vorteil Pro Oracle

Bobo_Oberon · 06.05.2009

Börsianisch:
Die Oracle-Geschichte scheint ja nun über die Bühne zu gehen und die Kurswerte von Sun liegen immer noch bei 6,85 US Dollar. Die chronischen 2,xy Dollar der letzten Jahre haben meine Einschätzung zum unterbewerteten Kurs eine unerwartete Wende mit dem Oracle-Aufkauf bekommen.

Tourisch:
Was ist bemerkenswert an dieser Tour? Zum einen, dass die Ankündigung vom Aufkauf mitten in der Präsentation statt fand - die Reaktion war im Publikum und bei den Mitarbeitern eher wohlwollend.

Die PDFs zeigen im Grundsatz wenig neues, wenn man etwas zum Nehalem erfahren will (Xeon 3500 Einzelsockelsysteme (3. S. 4), Xeon 5500 Zweifachsockelsysteme), bzw. 4 Sockelsysteme (als 2x 2 Sockel in einem Gerät, 3. Seite 3).

Flash-HDDs:
Interessant war, dass Sun stark auf Flash-Festplatten (3. Seite 10) , bzw. spezielle Flash-Module setzt (3. Seite 11 im Blade X6275), bzw. in Kombination von konventionellen Festplatten zusammen mit Flash, die als Datencache für die Storage-Produkte dienen. In diesem Fall spricht Rolf Kersten (1.) von einem erhöhtem Durchsatz um den Faktor x8 (S. 11, 13). An anderer Stelle (5.) ist die Rede von einem Faktor x4, bzw. x5,5 in High Performance Computing-Umgebungen (Seite 11).

Virtuelle Maschinen: Container vs VMware
Solaris kann im Gegensatz zu VMware deutlich mehr Virtuelle Maschinen laufen lassen. In den Containern von Solaris 10 sollen bis zu 8192 damit möglich sein. Bei VMware sinds 192 (und Microsoft rühmt sich mit dem Windows 2008 SR2 dass es über 64 Prozessoren skalieren werde). Skalieren mit vielen Sockeln ist zwar etwas anderes, als skalieren mit vielen VMs, aber ich denke schon, dass Solaris hier einen traditionellen Vorteil zeigt.

In House-Tuning:
Auch die eigenen Tunig-Tools, wie dem Sun Studio, können den eigenen Systemen den gewissen kleinen Mehrwert bringen gegenüber FRemdlösungen, die im Grunde genommen die gleiche Hardware nutzen (5.) (Seite 10). Das können dann schon mal 10 bis 20 Prozent mehr sein.

MySQL - HyperThreading - RedHat vs Solaris:
Was MySQL und Solaris angeht (5. Seite 13), so scheint es über zwei Sockel sehr ordentlich zu skalieren (Faktor: + 1,87 Lesen, + 1,77 Prozent Lesen/Schreiben). Auch HyperThreading (Intels SMT-Technik) skaliert zusätzlich (+ 35 Prozent Lesen, + 30 Prozent Lesen/Schreiben).
Unter RedHat Linux sind zwar mit MySQL die Lese/Schreibraten unter Spitzenlast vergleichbar mit Solaris, allerdings bricht die Skalierung bei zunehmenden Threads bei Suns eigenen Betriebssystem nicht so leicht zusammen. Zusätzlich ist bei reiner Lese-Last Solaris deutlich vorne. Bei Lastspitze sind hier doppelt so viele Transaktionen möglich, bei noch mehr anfallenden Threads ist sogar die gemessene Leistung um den Faktor x7 höher.

Die Papers sind zwar durch die Grau-blaue Firmenbrille von Sun vorgefiltert, aber ich denke, es gibt doch interessante Anregungen für weitere Diskussionen hier im Form, ganz gleich ob in diesem Thread, oder auch in anderen.

MFG Bobo(2009)

Link

1. "Sun: x86 Infrastruktur – heute und in Zukunft" (PDF 1,05 MB)
2. "Intel: Introducing Intel Xeon Processor 5500 Series" (PDF 0,54 MB)
3. "Sun: Vorstellung und Vorteile der Intel Xeon Prozessor 5500 Systemfamilie" (PDF 1,36 MB)
4. "Sun: Von x86 Servern zu x86 Systemen: Open Solaris, Open Storage, Flash ... " (PDF 1,55 MB)
5. "Intel: Intel Technology Benefits" (PDF 1,29 MB)
6. "Sun: Sun+Intel Vorteile für Ihren Anwendungsbereich" (PDF 0,89 MB)
"DNS: DNS GmbH – die Nr. 1 in Sachen Sun" (PDF 1,73 MB)
7. "Sun: Testen und optimieren Sie jetzt Ihre Applikationen auf den neuen Systemen" (PDF 0,89 MB)

Opteron · 08.05.2009

Interview mit dem Oracle Chef:
http://www.oracle.com/sun/lje-oracle-sun-faq.pdf

Sparc bleibt wirklich erhalten:

Q:"Why does Oracle, a company that prides itself on high-margins, want to get into the low-margin hardware business? Are you going to exit the hardware business? ".

A: No, we are defnitely not going to exit the hardware business. While most hardware businesses are low-margin, companies like Apple and Cisco enjoy very high-margins because they do a good job of designing their hardware and software to work together. If a company designs both hardware and software, it can build much better systems than if they only design the software. That’s why Apple’s iPhone is so much better than Microsoft phones.

Q: Alright, Oracle’s done integrated hardware and software design with the Exadata database machine. But Exadata
uses standard Intel chips. Are you going to discontinue the SPARC chip?

A: No. Once we own Sun we are going to increase the investment in SPARC.
(...)
We want to work with Fujitsu to design advanced features into the SPARC microprocessor aimed at improving Oracle database performance.

Na wenigstens was, Rock kann also kommen und hoffentlich auch dem Itanium das Leben schwer machen. ^^
Das die Investitionen sogar vergrößert werden sollen verwundert ja fast schon ... aber der letzte Satz klingt ja ziemlich stark nach Transactional Mem.

ciao

Alex

P.S: Seit wann stellt MS Telefone her ... *chatt*

Wahrscheinlich meint er wohl Handys mit Windows mobile ...

PuckPoltergeist · 11.05.2009

So, zumindest das Unternehmen SGI ist jetzt Geschichte:

Rackable und Silicon Graphics jetzt unter der Marke SGI vereint

Allerdings, wenn ich so was lese:

Rackable zahlt nur 42,5 Millionen US-Dollar für die seit Jahren defizitäre Firma SGI, die Anfang April zum zweiten Mal nach 2006 Gläubigerschutz nach Chapter 11 beantragen musste. Allerdings übernimmt die im letzten Geschäftsjahr und auch im ersten Quartal 2009 selbst defizitäre Firma Rackable auch die SGI-Verbindlichkeiten.

So gut ist Rackable also auch nicht aufgestellt. Ob das dauerhaft gut geht?

Bobo_Oberon · 11.05.2009

PuckPoltergeist schrieb:
... So gut ist Rackable also auch nicht aufgestellt. Ob das dauerhaft gut geht?

Das ist schon selten, dass eine aufkaufende Firma sich umbenennt nach dem aufgekauftem Unternehmen. Offenbar ist das Brand "SGI" hochwertiger, als von der Stammfirma Rackable.

Gestern war übrigens eine Heise-Meldung, dass Anteilseigner von Sun gegen die Übernahme dreifach klagen werden: "Aktionäre klagen gegen Übernahme von Sun durch Oracle"

Bemerkenswert ist die Bewertung von dem Heise-Leser wer-wolf mit dem Posting "Re: Voller Hals", bzw. sorgfältig ausformuliert im Posting: "Re: Oracle vs "OpenSource"-Kurs?", denn er versteht den Standpunkt der Aktionäre.
Deren Vorwurf lautet "Untreue" gegenüber der Sun-Geschäftsleitung. Der Leser horchte ganz besonders auf, weil Oracle schon nach einem Jahr über 1 Milliarde Gewinn erwarten will ... das passt nicht zusammen mit den vielen roten Quartalen der letzten Jahre.

In seinem Posting steht auch drin, was weitere Motive zu einem Firmenkauf sind:
- Knowledge (Wissen, Patente, Methoden)
- Markennamen

Ob Rackable das Kleingeld hat das neue Unternehmen vorm Untergang zu bewahren, ist so gesehen fraglich. Seiner Meinung nach ist eine grundlegende Neuorientierung teuer und benötigt einen langen Atem für neue Produkte und Methoden. Vermutlich schmeisst Rackable die Produktkörbe, aktuelle Aufträge und Kunden zusammen und gehen mit eisernen Personalbesen durch die Reihen ... der Rest ist Hoffnung.

MFG Bobo(2009)

Bobo_Oberon · 13.05.2009

Heise meldet, wie es zu der Fusion von Oracle mit Sun kam. Es hat ganz den Anschein, dass vor allem IBM (Partei "A") und etwas später HP (Partei "B") an einer Fusion interessiert waren. Am Anfang waren Gespräche am 6. November 2009 mit IBM.

Zwischen den vielen Vorgesprächen kam der Datenbank-Riese hinzu und wollte zuerst lediglich die Software-Sparten kaufen. Wenn man Bloomberg glauben will, dann war Partei B HP und laut dem Wall Street Journal IBM Partei A. Jedenfalls schlüsselt das Heise so auf in der Meldung: "Sun schildert Hintergründe des Übernahmepokers".

Die US-amerikanische Börsenaufsicht SEC hat jedenfalls nun ein Dokument zu den Hintergründen der Fusion ins Netz gestellt:

... Background of the Merger

We and Oracle sell complementary products and services and have collaborated on sales and otherwise worked together in many ways over the last twenty years.

On November 6, 2008, the Chief Executive Officer of Party A, a competitor of ours, approached Jonathan Schwartz, our President and Chief Executive Officer and a member of our board of directors, and suggested a possible business combination transaction.

During the period between November 6, 2008 and December 19, 2008, our management and our outside legal counsel, Wilson Sonsini Goodrich & Rosati (which we refer to as Wilson Sonsini), held a number of discussions with Party A and its legal counsel and discussed on several occasions with our board of directors and audit committee the possibility of a business combination transaction with Party A, our stand-alone alternatives as an independent company and the possibility of engaging with parties other than Party A concerning a possible business combination.

During this period, our management, at the direction of our board, approached the management of Party B and certain other parties, to explore their interest in a possible transaction with us. Party B indicated that it was interested in exploring a transaction, but that pursuing a transaction in the near term was not optimal for Party B at that time. Our management and advisors also approached or were approached by other parties during the first quarter of 2009, but except in the case of Party A, Party B and Oracle, no meaningful process for exploration of a possible transaction evolved from any of these discussions.

At Party A’s request, our board determined to permit Party A to conduct due diligence prior to submitting a proposal for our board’s consideration and, on December 19, 2008, we and Party A entered into a confidentiality agreement after which Party A commenced its due diligence investigation of the company. ...

Wirklich lesenswert, wie sich solche Geschäfte im Vorfeld abspielen. Ein Stück IT-Geschichte. Im April 2009 überschlugen sich jedenfalls die Ereignisse, bis es dann am 19. April sich Sun und Oracle einig waren.

HP schien recht lustlos an den Deal heranzugehen, während IBM wohl zu sehr gepokert hat und sogar am 29. März von 10 US-Dollar auf 9,4 US-Dollar, bzw. 9,10 US-Dollar im Preis herunterging.

Jedenfalls wurde die Oracle-Offerte heiss und fettig am 6. April parallel zu HPs Angbeot vom 9. April 2009 überdacht.
Sun formulierte so etwas wie eine Deadline, bis wann konkrete Angebote vorliegen sollten. Das war der 17. April 2009.
Oracle legte am 17. April das Angebot vor, auf 9,5 US-Dollar für die Gesamtfirma Sun ... und dann war es zwei Tage später auch so weit zur Vertragsunterschrift.

MFG Bobo(2009)

Desti · 14.05.2009

Opteron · 15.05.2009

Bitte immer gleich mit Quell-Link, ich les mir gerne das google-japanisch durch ^^

http://translate.google.de/translat...90514_168533.html&sl=ja&tl=en&hl=de&ie=UTF-8>

ciao

Alex

Bobo_Oberon · 15.05.2009

Erst mal Danke ... Ihr faulen Säcke^^

Da hätte ich gestern doch auf News-Jagt gehen sollen, anstatt meinen Glossarbeitrag zu Sun zu aktualisieren - das ist vermutlich bald abgeschlossene IT-Geschichte

Für alle die nicht den Link nicht anklicken wollen,

SPARC64 VIIIfx - Nativer Octacore nit neuer Vectorerweiterung HP-ACE
Fujitsu stellte einen Nachfolger des SPARC64 VII vor. Der SPARC64 VIIIfx ist ein Octacore und bekam zusätzlich noch eine neue SIMD-Erweiterung namens HP-ACE High Performance Arithmetic Computational Extensions. Der Codename lautet Venus. Gefertigt wird der neue Chip von Fujistus selber in 45 nm.

Der neue Fujitsu SPARC basiert auf dem Vorgänger SPARC64 VII (Rechenleistung 40 GFLOP), aber es wird beschrieben, dass der Achtkerner die dreifache Rechenleistung besitzt (128 GFLOP). Schon ein schlichte Verdoppelung wäre gut (da doppelt so viel Kerne). Offenbar hat Fujitsu gehörig am Stammdesign gearbeitet und nicht nur eine Vektor-Erweiterung angeflanscht.

Strombedarf im Vergleich
Fujitsu betont auf der Hausmesse, dass der neue auch sehr genügsam Strom konsumiert. Der Venus soll ein Drittel weniger Strom benötigen (oder gar nur ein Drittel?) als Intels Core i7. Dabei soll der neue Fujitsu SPARC aber die Rechenleistung um den Faktor 2,5 gegenüber den aktuellen Nehalem-Flaggschiffe übertreffen.
So gesehen sind die Vorgänger Quadcore SPARC64 VII knapp unterhalb der Rechenleistung der Nehalems und vermutlich in etwa auf Augenhöhe der AMD Shanghais.

Japans HPC-Hoffnungsträger Keisoku Keisan-ki
Der neue Prozessor ist für Multisockelbetrieb ausgelegt. Auf der Hausmesse wurden Module für 4 Sockel gezeigt, die auch in Japans HPC-Hoffnungsträger Keisoku Keisan-ki (PDF) installiert werden sollen. Der geplante neue (hybride)Supercomputer wird vom japanischen RIKEN-Institut projektiert. Dummerweise ist NEC ausgestiegen, die einen Vektorprozessor beisteuern wollten. NEC gehört zu den wenigen Herstellern, die auch echte Rechner Vektorprozessoren herstellten (SX-Reihe).

Ach ja, Heise hat auch schon darüber geschrieben: "SPARC64 VIIIfx: 128-GFlops-CPU für japanischen Supercomputer".

Was bedeutet das für die SPARC-Zukunft?
Nun, eine weitere SPARC-Generation scheint in trockenen Tüchern. Die klassischen SPARC-Linien bei Fujitsu und vermutlich auch Sun liegen mit diesem Hauptprozessor an der Weltspitze. Die Niagaras, der Rock und nun der Venus sind zwar Nischenprodukte, aber richtig positioniert haben alle ihre Daseinsberechtigung. Zumindest was den Strombedarf angeht scheinen Sun (mit den Niagaras (1,2), beim Rock muss das noch abwarten) und Fujitsu ihre Hausaufgaben gemacht zu haben.

Auf der anderen Seite MUSS der Abwärtstrend bei den klassischen SPARCs auch aufhören. Genau dieses Geschäftsfeld hat bei Sun ganz besonders stark zu den Defiziten beigetragen, welche die Niagaras nicht kompensieren konnten. Mal schauen in wie weit Oracle mit den Fujitsu "Venus" arbeiten will. Schon seit 2007 setzt Sun ja auf die japanischen SPARC64n statt der UltraSPARC aus dem eigenen Hause. Es gibt also noch eine reelle mittelfristige Zukunft der SPARCs.

ISC 2009 Hamburg (23. - 26.06.09)
Wir sehen wohl derzeit schon die ersten Vorzeichen zur ISC 2009 (23. Juni - 26. Juni), da könnten noch ein, zwei Überraschungen die nächsten Wochen kommen. Traditionell macht Sun kurz davor eine kleine Hausmesse. Und was IBM angeht, da habe ich schon länger nichts mehr gehört, wird Zeit, dass sie erste EIGENE Produkte in 45 nm vorstellen. Eventuell zeigt Nvidia was nettes auf der Ausstellung in Hamburg.

MFG Bobo(2009)

Opteron · 15.05.2009

Bobo_Oberon schrieb:
Der neue Fujitsu SPARC basiert auf dem Vorgänger SPARC64 VII (Rechenleistung 40 GFLOP), aber es wird beschrieben, dass der Achtkerner die dreifache Rechenleistung besitzt (128 GFLOP). Schon ein schlichte Verdoppelung wäre gut (da doppelt so viel Kerne). Offenbar hat Fujitsu gehörig am Stammdesign gearbeitet und nicht nur eine Vektor-Erweiterung angeflanscht.

Naja die Vektor Einheiten würden aber doch schon ausreichen ... Flops steht schließlich für "Floating Point Operations Per Second", von was sonst als der Vector Einheit sollten die abhängen

Wie auch immer der Chip bzw. die Erweiterung sind schon toll ... 512 64bit Register ... x86 gurkt mit 16 128bit Registern rum und die AVX Verdopplung ist dann immernoch nur ein Achtel der Sparc Menge.

Faktisch gibts natürlich mehrere Hardwareregister, die durch Register Renaming eingeblendet werden ... aber das ist wieder nur ne typische x86 Umständlichkeit.

a) braucht es Hardware -> Die Platz dafür und
b) hätte der Compiler auch mehr Luft für Optimierungen, wenn er alle Register sehen könnte.

Naja, was soll man sagen .. x86 halt, wieso einfach, wenns auch kompliziert geht.

Edit:
Nachdem das hier auch ein Intel Thread ist, passt das auch, Insider Infos über die Itanium Entwicklung:
http://hardware.slashdot.org/comments.pl?sid=1129041&cid=26870323

Da gings anscheinend wirklich drunter und drüber ..

His hand-picked successor lasted about 1 week before "family reasons" caused his resignation. I assume he looked at the state of the now 2 year delayed chip and ran.

.. und der Grund für Itanium war wohl wirklich nur das Ende der bösen x86 Mitbewerber, wie es einer in einer Antwort, weiter untem im Thread erwähnt:

All of the IA64 IP was held by a third company, and then licensed back to Intel and HP. That way, none of the IP would be covered by existing Intel or HP cross-licensing agreements. Then the architecture had to be sufficiently different that it would be fully covered by that IP, and none of the essentials covered by anything else.

So the initial design point was driven by legal and marketing concerns, and technical considerations were a distant third place, if that high.

Teil 2 (Itanium2) gibts auch noch:

4) AMD moved into Fort Collins,CO about a year later and stole the best of the Itanium II team. Even the Captain of Itanium II jumped ship!

http://hardware.slashdot.org/comments.pl?sid=1129041&cid=26872629

Alles in Allem schlimmer als ich es selbst erwartet hätte ... Itanium ist sch...lecht, aber dass es hinter den Kulissen gleich so miserabel ausgesehen hat ... wow, intel hat echt ne tolle Marketingabteilung

ciao

Alex

PuckPoltergeist · 15.05.2009

Opteron schrieb:
Wie auch immer der Chip bzw. die Erweiterung sind schon toll ... 512 64bit Register ... x86 gurkt mit 16 128bit Registern rum und die AVX Verdopplung ist dann immernoch nur ein Achtel der Sparc Menge.

Faktisch gibts natürlich mehrere Hardwareregister, die durch Register Renaming eingeblendet werden ... aber das ist wieder nur ne typische x86 Umständlichkeit.

a) braucht es Hardware -> Die Platz dafür und
b) hätte der Compiler auch mehr Luft für Optimierungen, wenn er alle Register sehen könnte.

Naja, was soll man sagen .. x86 halt, wieso einfach, wenns auch kompliziert geht.

Die Frage ist, was bringts am Ende. AMD hat bestimmt nicht ohne Grund die Anzahl der Register nur verdoppelt. Bei der CISC-ISA bringen mehr Register nicht unbedingt mehr Leistung. Und dazu kommt noch, hast du mal darüber nachgedacht, wie teuer ein Kontextswitch mit derart vielen Registern wird? Die müssen alle gesichert und auch wieder zurück geschrieben werden. Das ist nicht ohne.

Opteron · 16.05.2009

PuckPoltergeist schrieb:
Die Frage ist, was bringts am Ende. AMD hat bestimmt nicht ohne Grund die Anzahl der Register nur verdoppelt. Bei der CISC-ISA bringen mehr Register nicht unbedingt mehr Leistung. Und dazu kommt noch, hast du mal darüber nachgedacht, wie teuer ein Kontextswitch mit derart vielen Registern wird? Die müssen alle gesichert und auch wieder zurück geschrieben werden. Das ist nicht ohne.

Jo bei x86 wirds teuer ... aber wie so oft gibts ne einfache Lösung. Bevor man stur einfach alle Register sichert und sich nicht um den Inhalt schert, sichert man bei Sparc nur die wirklich benützten Register.

Wenn man für 08/15 Software wenig braucht hat man schnelle Wechsel, ansonsten wirds natürlich auch teuer, aber dann überwiegt sicherlich der Vorteil der vielen Register. Auszug aus dem Sparc v9 Handbuch von 1992:

We’ve also helped context switching. What we’ve done here is allow the machine to save or restore fewer registers during a context switch. The way we have done this is in both integer and floating point registers, we can tell more efficiently what registers are actually being used. The floating point registers now have a floating point enable bit that is split into two pieces with a "dirty bit" for the upper and lower part of the registers.

So if you haven’t written into the registers recently, when you do to do a context switch, there’s no need to save them away. So the fastest way to save registers is to not save them at all.

We can also use integer registers in the same way by using register windows as banks of registers. So you could find that in a future SPARC processor, you’re doing a context switch without the need to save any registers away, either on the integer or floating point sides. That makes for very fast context switching.

http://research.sun.com/features/tenyears/volcd/papers/1Ditzel.pdf

Venus ist ein v9 Chip, von daher werden die das sicher genauso handhaben.

Natürlich benötigt man auch OS Unterstützung ... aber wenn das Solaris nicht unterstützt würde ich mich mich sehr wundern.

ciao

Alex

PuckPoltergeist · 16.05.2009

Opteron schrieb:
Jo bei x86 wirds teuer ... aber wie so oft gibts ne einfache Lösung. Bevor man stur einfach alle Register sichert und sich nicht um den Inhalt schert, sichert man bei Sparc nur die wirklich benützten Register.

Wenn man für 08/15 Software wenig braucht hat man schnelle Wechsel, ansonsten wirds natürlich auch teuer, aber dann überwiegt sicherlich der Vorteil der vielen Register.

Zum Vergrößern anklicken....

Sparc ist als RISC-Architektur aber auch wesentlich stärker auf die größere Register-Anzahl angewiesen. x86 kompensiert das als CISC-Architektur sehr stark mit vielen Befehlen, die direkt auf dem Speicher arbeiten können.

Auszug aus dem Sparc v9 Handbuch von 1992:

http://research.sun.com/features/tenyears/volcd/papers/1Ditzel.pdf

Venus ist ein v9 Chip, von daher werden die das sicher genauso handhaben.

Natürlich benötigt man auch OS Unterstützung ... aber wenn das Solaris nicht unterstützt würde ich mich mich sehr wundern.

Zum Vergrößern anklicken....

Natürlich wird Solaris das nutzen, wohl ebenso wie alle anderen Betriebssysteme, die darauf laufen. Wäre ja sonst schön blöd. Wobei das aber halt auch wieder Kosten verursacht.
Was noch interessant dazu wäre, sind die Register jetzt alle frei verfügbar? Weil, bisher waren sie das ja nicht. Und wenn da nur der Register Stack vergrößert wurde, frage ich mich, was es am Ende bringt. Davon abgesehen frage ich mich eh, was 512 Register bringen. Welche Applikation kann das ausnutzen?

Opteron · 16.05.2009

PuckPoltergeist schrieb:
Sparc ist als RISC-Architektur aber auch wesentlich stärker auf die größere Register-Anzahl angewiesen. x86 kompensiert das als CISC-Architektur sehr stark mit vielen Befehlen, die direkt auf dem Speicher arbeiten können.

Möglich, wobei die SIMD Erweiterung ja jetzt auch wieder CISC ist, oder wie soll man das einorden ? Z.B. gibts da jetzt auch FMA Befehle, über dies gerade im AMD Thread wg. SSE5 ging.
Abgesehen davon, was meinst Du mit "Speicher" ? Das hört sich für mich erstmal schlechter an, denn selbst ein L1 Zugriff ist langsamer als ein Registerzugriff

Natürlich wird Solaris das nutzen, wohl ebenso wie alle anderen Betriebssysteme, die darauf laufen. Wäre ja sonst schön blöd. Wobei das aber halt auch wieder Kosten verursacht.

Hehe, klar, deswegen hab ichs auch nicht nachgeprüft

Komisch - naja vielleicht sollte man eher sagen typisch - ist, dass es bei Intel auch etwas zum leichteren Context Switch gibt, ein Task Register:
http://en.wikipedia.org/wiki/Task_State_Segment

Nur wird das weder von Linux noch Windows genützt *suspect*

Irgendwo in nem andren Wikipedia Artikel stand, dass man damit nur die INT Register sichern könne ... wenn das stimmt frag ich mich, wozu das gut sein soll ... Eventuell hat AMD bei AMD64 nachgebessert, aber viel steht nicht im wiki Artikel, und ich hab jetzt auch keine große Lust mehr zu suchen ^^

Was noch interessant dazu wäre, sind die Register jetzt alle frei verfügbar? Weil, bisher waren sie das ja nicht. Und wenn da nur der Register Stack vergrößert wurde, frage ich mich, was es am Ende bringt. Davon abgesehen frage ich mich eh, was 512 Register bringen. Welche Applikation kann das ausnutzen?

HPC ... das Ganze ist wie besagt eine Vector Einheit, verglichen mit der Tarantula Erweiterung des EV8+ ist das immernoch winzig. Bei vielen/großen Matrizen kann man das schon brauchen.

Frei verfügbar sind die Vector Register, aber die sind nur angeflanscht, wie die SSE Register bei x86, die restlichen, alten Register bleiben so wie immer.

ciao

Alex

PuckPoltergeist · 16.05.2009

Opteron schrieb:
Möglich, wobei die SIMD Erweiterung ja jetzt auch wieder CISC ist, oder wie soll man das einorden ? Z.B. gibts da jetzt auch FMA Befehle, über dies gerade im AMD Thread wg. SSE5 ging.
Abgesehen davon, was meinst Du mit "Speicher" ? Das hört sich für mich erstmal schlechter an, denn selbst ein L1 Zugriff ist langsamer als ein Registerzugriff

Die Ergebnisse werden schon in Registern gespeichert. Aber die Operanden müssen nicht erst aus dem Speicher in ein Register geladen werden, sondern können direkt aus dem Speicher adressiert werden. Bei RISC ist das prinzipbedingt nicht möglich. CISC ist da ja flexibler, was aber das Design verteuert.

Hehe, klar, deswegen hab ichs auch nicht nachgeprüft
Komisch - naja vielleicht sollte man eher sagen typisch - ist, dass es bei Intel auch etwas zum leichteren Context Switch gibt, ein Task Register:
http://en.wikipedia.org/wiki/Task_State_Segment

Nur wird das weder von Linux noch Windows genützt
Irgendwo in nem andren Wikipedia Artikel stand, dass man damit nur die INT Register sichern könne ... wenn das stimmt frag ich mich, wozu das gut sein soll ... Eventuell hat AMD bei AMD64 nachgebessert, aber viel steht nicht im wiki Artikel, und ich hab jetzt auch keine große Lust mehr zu suchen ^^

Ok, heben wir uns das für später auf. Müssen ja auch morgen noch spekulieren können.

HPC ... das Ganze ist wie besagt eine Vector Einheit, verglichen mit der Tarantula Erweiterung des EV8+ ist das immernoch winzig. Bei vielen/großen Matrizen kann man das schon brauchen.

Frei verfügbar sind die Vector Register, aber die sind nur angeflanscht, wie die SSE Register bei x86, die restlichen, alten Register bleiben so wie immer.

Ah ok, hab nicht zu Ende gelesen. Wenn man das vektoriell nutzt, erscheint die Registeranzahl gleich in einem ganz anderen Licht.

rkinet · 16.05.2009

PuckPoltergeist schrieb:
Sparc ist als RISC-Architektur aber auch wesentlich stärker auf die größere Register-Anzahl angewiesen.
x86 kompensiert das als CISC-Architektur sehr stark mit vielen Befehlen, die direkt auf dem Speicher arbeiten können.

Nun x86 decodiert intern nach RISC und als x86-64 gibts auch mehr verfügbare Register.

Wobei die Benchmarks bisher wenig Vorteile durch mehr Register für Programmierer zeigten.
Ich tippe darauf, dass einfach die Decodierung von x86 nach intern Risc durch interen Register bereits sich Vorteile schon seit Jahren sichert. Intern wird eigentlich bei x86 schon soviel umsortiert und neu kombiniert dass die Hardware mit guten internen Code gefüttert wird.

Strategische Überlegungen64Bit; IBM SUN AMD Intel

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Moderator☆☆☆☆☆☆

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Grand Admiral Special

Ähnliche Themen

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Moderator
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆