Alphas allerletzte Inkarnation
- Ersteller Bokill
- Erstellt am
Die allerletzten Alphas bekommen einen Refresh.
Das Modell 21364 darf nun mit 1,15 MHz (Serie ES47, ES80 Model 8) und 1.3 MHz antreten (System GS1280) .
Ein gewisser anderer Hersteller hat so ziemlich viel vom Alpha 21364 abgeschaut.
Zwar hat der K8 nur drei Aussenverbindungen mit HyperTransport, aber wenn man die SRQ als ganz speziellen Sonderfall zum HTr dazuzählt sind wir ganz fix bei dem North, South, East, West Konzept wie beim Alpha
Eigentlich sind`s immer noch echte Leckerlies.
So war es mit den Alphas schon sehr lange (vor dem K8) möglich, sowohl fetten Speicher per Speicherkontroller on Die (im CPU-Kern, wie der K8) zu kontrollieren,
1. AlphaServer ES47/ES80 Systeme von 16 bis hin zu 64 GB RAM
2. AlphaServer GS1280 Systeme mit bescheidener Maximalbestückung von 64 Alphas und 512 GB RAM (Billiger PlunderRAMBUS ?)
als auch viele AGP zu kontrollieren. Multi AGP war kein Fremdwort für Alpha. Das System ES80 Model 8 konnte damals schon maximal 8 AGP-Karten kontrollieren.
Aber der Alpha-Tod war mit dem Kauf von Compaq, seitens HP beschlossene Sache.
HP verkauft aber demnach immer noch Alphas, die scheinen doch recht zählebig zu sein, wie Katzen
HP hat derzeit 4 verschieden 64Bit Plattformen:
Alpha, Itanium, Opteron und deren Eigenentwicklung HP PA-RISC ... würde mich nicht wundern, wenn sie irgendwo noch`n MIPS in deren Keller haben.
Das war bestimmt mal anders geplant.
Ich gebe einigen auch Recht, damit, dass AMD einiges abgeschaut hat, aber nicht alles ist von intel abgelugt worden ...
Zufälligerweise sind mit dem Deal HP-Compaq die Entwickler vom Alpha von einer anderen grossen Firma mit dem "i" übernommen worden ...
aus "Kartellrechtlichen Gründen"
Die Inspiration zu diesem Posting ist die Meldung vom Inquirer Alpha EV7z finally arrives
Der EV-79 hingegen ist eben nicht herausgekommen, warum wohl?
Nachtrag: Wie eine konsequete Weiterentwicklung aussehen kann, demonstriert IBM beispielhaft mit der Power Familie (Workstation/Server-Bereich) und den kleinen PPC Bauern für den Heim-Markt (THX HenryWince
). Siehe exemplarisch in Interview IBM`s PPC5; A Talk with Pratap Pattnaik, oder dort Abartiger Power5; Monsterwuchs. Über SUN kann man ähnliches konsequentes Weiterentwickeln seiner SPARCs nachsagen, siehe auch Sun`s SPARCs: Familienbande.
MFG Bokill
Das Modell 21364 darf nun mit 1,15 MHz (Serie ES47, ES80 Model 8) und 1.3 MHz antreten (System GS1280) .
Ein gewisser anderer Hersteller hat so ziemlich viel vom Alpha 21364 abgeschaut.
Zwar hat der K8 nur drei Aussenverbindungen mit HyperTransport, aber wenn man die SRQ als ganz speziellen Sonderfall zum HTr dazuzählt sind wir ganz fix bei dem North, South, East, West Konzept wie beim Alpha
Eigentlich sind`s immer noch echte Leckerlies.
So war es mit den Alphas schon sehr lange (vor dem K8) möglich, sowohl fetten Speicher per Speicherkontroller on Die (im CPU-Kern, wie der K8) zu kontrollieren,
1. AlphaServer ES47/ES80 Systeme von 16 bis hin zu 64 GB RAM
2. AlphaServer GS1280 Systeme mit bescheidener Maximalbestückung von 64 Alphas und 512 GB RAM (Billiger PlunderRAMBUS ?)
als auch viele AGP zu kontrollieren. Multi AGP war kein Fremdwort für Alpha. Das System ES80 Model 8 konnte damals schon maximal 8 AGP-Karten kontrollieren.
Aber der Alpha-Tod war mit dem Kauf von Compaq, seitens HP beschlossene Sache.
HP verkauft aber demnach immer noch Alphas, die scheinen doch recht zählebig zu sein, wie Katzen
HP hat derzeit 4 verschieden 64Bit Plattformen:
Alpha, Itanium, Opteron und deren Eigenentwicklung HP PA-RISC ... würde mich nicht wundern, wenn sie irgendwo noch`n MIPS in deren Keller haben.
Das war bestimmt mal anders geplant.
Ich gebe einigen auch Recht, damit, dass AMD einiges abgeschaut hat, aber nicht alles ist von intel abgelugt worden ...
Zufälligerweise sind mit dem Deal HP-Compaq die Entwickler vom Alpha von einer anderen grossen Firma mit dem "i" übernommen worden ...
aus "Kartellrechtlichen Gründen"
Die Inspiration zu diesem Posting ist die Meldung vom Inquirer Alpha EV7z finally arrives
Der EV-79 hingegen ist eben nicht herausgekommen, warum wohl?
Nachtrag: Wie eine konsequete Weiterentwicklung aussehen kann, demonstriert IBM beispielhaft mit der Power Familie (Workstation/Server-Bereich) und den kleinen PPC Bauern für den Heim-Markt (THX HenryWince
). Siehe exemplarisch in Interview IBM`s PPC5; A Talk with Pratap Pattnaik, oder dort Abartiger Power5; Monsterwuchs. Über SUN kann man ähnliches konsequentes Weiterentwickeln seiner SPARCs nachsagen, siehe auch Sun`s SPARCs: Familienbande.MFG Bokill
Zuletzt bearbeitet:
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
komischerweise ist recht bekannt dass 3/4 des Umsatzes bei HP durch Drucker entstehen
Der Alpha ist nach wie vor eine der beliebtesten CPUs, und es ist verdammt schade, dass der nach und nach tot gemacht wurde... Intel hat da durch irgendwelche Patente auch Schuld dran, denen gefällts natürlich, dass sie ihren x86 und Itanium Quatsch überall verhökern können.
Der Alpha ist nach wie vor eine der beliebtesten CPUs, und es ist verdammt schade, dass der nach und nach tot gemacht wurde... Intel hat da durch irgendwelche Patente auch Schuld dran, denen gefällts natürlich, dass sie ihren x86 und Itanium Quatsch überall verhökern können.
PuckPoltergeist
Grand Admiral Special
Der Tod war faktisch schon nach der Übernahme von DEC durch Compaq sicher.
Sollten sie, da ihnen mit der Übernahme von Compaq auch die NonStop-Himalaya-Server zugefallen sind. Die sind MIPS-basiert.
Ein beachtlicher Teil der Entwickler hatte Compaq schon lange vor der Übernahme durch HP verlassen, u.a. in Richtung AMD. Wenn ich nicht irre, kam Fred Weber auch von DEC/Compaq.
Jepp ...
Allerdings hat nicht intel irgend jemand verklagt, sondern intel hatte Alpha an den Hacken.
Möglicherweise ist HT (Hyperthreading) SMT nicht beim Williamette freigeschaltet worden, weil sie aus Patentrechtlichen Gründen eine Klage am Hacken hatten.
Ein gewisser Herr Elmer hat da eine nette Doku zu SMT geschrieben ...
basierend auf dem EV-8
Nach dem Deal von Compaq mit HP schaltete intel jedenfalls ganz fix HT ein. So ein Zufall aber auch ...
Nachtrag:
@BUGGI1000 wenn du unter dem Stichwort "Zufall" und "Alpha" suchst, dann wirst du vermutlich schon diverse Andeutungen zum Deal mit Compaq, HP und intel bekommen ... (Das wahre Motiv im Thread
)MFG Bokill
Zuletzt bearbeitet:
mad_mueller
Fleet Captain Special
Moin.
Alpha's haben zwar einen geilen IPC, aber selbst die sind nicht mehr in MHz getaktet.
Wir haben hier in der Firma drei recht neue HP ES47 Alpha Server mit OpenVMS 7.3 und die rocken das Haus 8).
Nur der Support von HP ist ziemlich ... naja, reden wir nicht drüber.
Bin mal gespannt wie es im HPC-Bereich bei HP weitergeht, ich denke mal mit dem Itanium. Steht halt Intel dran.
Oder pushen Sie doch ihre PA-RISC Prozessoren
Alpha's haben zwar einen geilen IPC, aber selbst die sind nicht mehr in MHz getaktet.
Wir haben hier in der Firma drei recht neue HP ES47 Alpha Server mit OpenVMS 7.3 und die rocken das Haus 8).
Nur der Support von HP ist ziemlich ... naja, reden wir nicht drüber.
Bin mal gespannt wie es im HPC-Bereich bei HP weitergeht, ich denke mal mit dem Itanium. Steht halt Intel dran.
Oder pushen Sie doch ihre PA-RISC Prozessoren
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Original geschrieben von mad_mueller
Bin mal gespannt wie es im HPC-Bereich bei HP weitergeht, ich denke mal mit dem Itanium. Steht halt Intel dran.
Oder pushen Sie doch ihre PA-RISC Prozessoren
Nein, der PA-8800 soll der letzte sein. Eigentlich sollte schon nach dem 8700 schluss sein, nur kam da der Itanium noch nicht nach. Und auch mit dem Itanium muss da nicht unbedingt Intel drann stehen.
@BUGGI1000
THX
Dauert eigentlich nur ne Minute ...
Wichtig ist, dass da schon das Oberthema mitschwingt ... ohne alles zu verraten. GOOOGLETAUGLICH sollte es aber auch sein 8) ... sonst geht`s unter im Meer der Worte
ach ja ... noch was ... der Thread ist eigentlich Recycling, nur der Anlass fehlte.
Das Grundthema wurde in dem Thread Frage zum CPU Cache schon angesprochen.
Eigentlich habe ich das alte, sehr alte ... ewig alte Posting Marktdominanz, AMD PDF`s, Analystenperspektive
nochmals sehr scharf angebraten.
Das Kochrezept ist folgendes :
Die Grundidee wird mit etwas frischer Newsmeldung versehen, selbstverständlich mit erdiger nussiger Linkangabe, dazu uralte Postingsojasauce und leicht prickelnden Titelsekt (könnte ja gut sein, dass diese Alphas doch nicht die letzten ihrer Art sind).
Wichtig ist dass dazu weitere ergänzendes Threads vorhanden sind. So bekommt man ein wohlschmeckenden nahrhaften Threadsalat.
MsFG Bokill
THX
Dauert eigentlich nur ne Minute ...
Wichtig ist, dass da schon das Oberthema mitschwingt ... ohne alles zu verraten. GOOOGLETAUGLICH sollte es aber auch sein 8) ... sonst geht`s unter im Meer der Worte
ach ja ... noch was ... der Thread ist eigentlich Recycling, nur der Anlass fehlte.
Das Grundthema wurde in dem Thread Frage zum CPU Cache schon angesprochen.
Eigentlich habe ich das alte, sehr alte ... ewig alte Posting Marktdominanz, AMD PDF`s, Analystenperspektive
nochmals sehr scharf angebraten.
Das Kochrezept ist folgendes :
Die Grundidee wird mit etwas frischer Newsmeldung versehen, selbstverständlich mit erdiger nussiger Linkangabe, dazu uralte Postingsojasauce und leicht prickelnden Titelsekt (könnte ja gut sein, dass diese Alphas doch nicht die letzten ihrer Art sind).
Wichtig ist dass dazu weitere ergänzendes Threads vorhanden sind. So bekommt man ein wohlschmeckenden nahrhaften Threadsalat.
MsFG Bokill
Zuletzt bearbeitet:
mad_mueller
Fleet Captain Special
Ahso, danke, alles klar.
Hm? Irgendwie blick ich das jetzt nicht.Original geschrieben von PuckPoltergeist
Und auch mit dem Itanium muss da nicht unbedingt Intel drann stehen.
Ich meinte, dass Intel den Itanium entwickelt und deshlab der Prozessor "Vorteile" hat. Weil Intel "dran" steht.
treten wieder seine Totengräber und Scharfrichter auf ... der Itanium.
HP und Intel entwickelten gemeinsam den Itanium mit EPIC, wobei das erste Design (meines Wissens nach) sogar von HP entstammt für den ItaniumI. HP kam mit der ISA Idee EPIC.
In einem Nebenthread habe ich da etwas zu EPIC und PIC & Clipper, Intergraph 8)
Jahre später...
Die Plattform für den HP PA-8800 kann auch für den Itanium genutzt werden.
Der Gedanke war, dass der Itanium die Architekturen von HP beerben sollte. Mit dem intel-Kauf der Entwicklungs-Abteilung der Alphas wurde eifrig versichert, dass auch die Portierbarkeit von den Alphas zu dem Itanium sichergestellt sei.
Auch wurde dem Alpha noch eine gewisse Endlebensdauer zugesichert, nur HP hatte nie mehr so richtig fette PR für den Alpha EV7 gemacht auch das geschrinkte Modell ist kaum beworben worden EV-79 ( Nachtrag: und EV-79 ist niemals verwirklicht worden )
Der angedachte Nachfolger EV-8 21464 ist nie aus dem Projektstadium herausgekommen.
Der wäre heute sicherlich ein bärenstarker Gegner gegen den Power5 gewesen, der ja erst (siehe Thread IBMs Power5 mit 8Cores mit je 1.92Ghz und insgesamt 144MB Cache ) vor kurzem auch endlich auf dem Markt kam.
Angekündigt wurde der Power5 schon sehr lange vorher ... siehe auch Abartiger Power5; Monsterwuchs
MFG Bokill
HP und Intel entwickelten gemeinsam den Itanium mit EPIC, wobei das erste Design (meines Wissens nach) sogar von HP entstammt für den ItaniumI. HP kam mit der ISA Idee EPIC.
In einem Nebenthread habe ich da etwas zu EPIC und PIC & Clipper, Intergraph 8)
Jahre später...
Die Plattform für den HP PA-8800 kann auch für den Itanium genutzt werden.
Der Gedanke war, dass der Itanium die Architekturen von HP beerben sollte. Mit dem intel-Kauf der Entwicklungs-Abteilung der Alphas wurde eifrig versichert, dass auch die Portierbarkeit von den Alphas zu dem Itanium sichergestellt sei.
Auch wurde dem Alpha noch eine gewisse Endlebensdauer zugesichert, nur HP hatte nie mehr so richtig fette PR für den Alpha EV7 gemacht auch das geschrinkte Modell ist kaum beworben worden EV-79 ( Nachtrag: und EV-79 ist niemals verwirklicht worden )
Der angedachte Nachfolger EV-8 21464 ist nie aus dem Projektstadium herausgekommen.
Der wäre heute sicherlich ein bärenstarker Gegner gegen den Power5 gewesen, der ja erst (siehe Thread IBMs Power5 mit 8Cores mit je 1.92Ghz und insgesamt 144MB Cache ) vor kurzem auch endlich auf dem Markt kam.
Angekündigt wurde der Power5 schon sehr lange vorher ... siehe auch Abartiger Power5; Monsterwuchs
MFG Bokill
Zuletzt bearbeitet:
DEC`s letzter grosser Versuch die Masse zu erreichen war die Übersersetzungssoftware FX!32.
Was hat die Software FX!32 mit dem Jahre 2004 zu schaffen?
Nun erst mal gar nichts, da Alpha fast Geschichte ist und vor allem die Alphas nicht mehr mit x86 Code beschickt werden. Ich schätze mal, dass die derzeitigen Alphas feinsten nativen Alphacode bekommen.
Aber die Grundidee in Echtzeit Code zu kompilieren und zugleich damit die Plattform langfristig damit zu optimieren, war revolutionär.
Das Wissen darüber war und ist heute noch Gold wert
DEC hatte aber ambitionierte Pläne
Schon die Namensgebung der Alphafamilie war fast schon vermessen.
a. 21 für die Architektur des 21 Jahrhunderts
b. die kommende Zahl für die fortlaufende Modellnummern
c. 64 für die 64Bit Architektur
Damit sie wollten den Server Markt bedienen. Mit der Emulationssoftware FX!32 wollten sie den Low-End-Server/Workstationmarkt bedienen.
Dort lümmelten sich damals, mit wachsender Begeisterung, die PentiumPro herum. Und der Markt wollte solche Low-End Massenserver/Workstations.
DEC`s Hoffnungen
DEC versprach, dass mit einem WinNT4 für die Alphas 21164PC und x86 Software ca. 70% der Leistung eines Alphas mit nativer Software für den Alpha leisten könnte.
Der Witz war: Es klappte auch.
FX!32 konnte die x86 Instruktionen recht gut übersetzen. Wenn man Paul DeMone glauben mag, dann konnte der übersetzte Code teilweise auf der Alphaplattform in Form der übersetzten Alpha DLL`s (Alpha RISC Code) sogar schneller laufen, als ihre Ursprungspedants auf x86 in x86 Software ( CISC Code) .
Die Geschichte mit RISC vs CISC ist sehr nett von HenryWince im Thread Instruction Set Architektur und Mikroarchitektur von CPUs sehr kompakt und eindeutig wiedergegeben worden. Unbedingt empfehlenswert
Auch wenn ich nicht so eloquent und mit garantiert weniger Wissen, wie Paul de Mone von realworldtech.com , darüber sprechen kann, so hilft doch ansatzweise sein Diagramm und Artikel "Wölfe im CISC-Kleid" über die Funktionsweise von FX!32 weiter.
Schematische Funktionsblöcke von FX!32 (von realworldtech.com)
http://www.realworldtech.com/includes/images/articles/CISC-Wolves-fig1.gif
Die Einzelnen Elemente sind:
1. x86 Code
2. Transperancy Agent
3. Runtime Emulator
4. Translated Alpha Code
5. Profile Data
6. Database + Server
7. Binary Translator
FX!32. Kurze ÜbersichtZum Funktionsaufbau des RISC Alpha Übersetzungsprogramms zum Übersetzen des x86 Code in Alphacode.
Ich mache mal einen Versuch die Elemente zu verdeutschen und etwas zu erläutern.
1. x86 Code: X86 Software reinstes CISC
2. Transperancy Agent: Dieses Programm im Betriebssystem schaut nach nativen Alphacode, wenn x86 Code kommt, dann ruft diese das FX!32 Programm auf. Die Übersetzung beginnt ...
3. Runtime Emulator: In Echtzeit wird der x86 Code übersetzt, zugleich wird nach alten Übersetzungen (5. 6.) geschaut)
4. Translated Alpha Code: In vorherigen Arbeitsgängen entstandener übersetzter nativer Alphacode.
5. Profile Data: Tabellarische Auflistung schon übersetzter x86 Software.
6. Database + Server:
7. Binary Translator: Die eigentliche Übersetzung von x86 zu Alpha-RISC.
FX!32: Ein Versuch des Vergleichs
Dieser Emulator läuft beständig im Hintergrund des Betriebssystems. Das Betriebssystem ist aber in Alphacode geschrieben.
FX!32 hat daher eine ähnliche Stellung wie WoW64 - Microsofts Starthilfe für 64-Bit Windows im Detail ...
Mit dem ganz wesentlichen Unterschied, dass vollkommen unterschiedliche ISA`s "mal so eben" übersetzt werden. Zusätzlich greift FX!32 "mal so eben" auf schon kompilierte DLL`s zurück die ehemal x86 waren und nun reinster Alpha-RISCcode sind (so weit geht WoW64 meiner Meinung nach nicht).
Im Gegensatz zum Transmeta bleibt der Code higegen aber auch dann RISC. FX!32 wollte ja reinen Code für seinen Alpha erzeugen. Die Datenbank hilft beständig schon übersetzte Elemente schneller nachzuladen. Dieses nativen DLL`s laufen schneller, als das Echtzeitübersetzen von x86 nach RISC.
Dies bedeutet, dass nach längerer Nutzung der Rechner schneller wird. Im Unterschied zum Transmeta hingegen bleibt aber auf der Maschine der Ursprungsx86 Code erhalten
Der Transmeta hingegen übersetzt in Echtzeit (wie FX!32), transformiert intern (wie FX!32), und übersetzt zurück in X86 (NEU).
Allerdings ist die Rückübersetzung nicht mehr 1:1 sondern, nach Transmetagesichtspunkten optimiert (Ebenfalls NEU). Falls die Rückübersetzung mal wieder geladen wird, so soll der frischere x86 Code schon mundgerechter für den Transmeta vorliegen.
Transmetakompilat: Bodenwellen für andere x86 Familien?
Gut möglich, dass solch ein Transmeta x86 Code die Horrorschau für den P4 ist. Täte mich nicht wundern, wenn ein K6 mit solch einem Kompilat vergleichsweise gut klarkommt. Der K6 sollte ja auf verschiedensten Terrain klarkommen. Selbst grausame Sprünge kann die kurze Pipeline des K6 ohne grosse Verzögerung einstecken. Die für damalige Verhältnisse gigatsiche Sprungvorheransageeinheit (besser als die vom K7) bestärkt solche Vermutungen.
Grundgrössen des FX!32 (Emulators)
Wie leistungsstark ist denn FX!32? Das Emulieren soll pro einer x86 Instruktion etwa 45 RISC Instruktionen benötigen.
Tabellarischer Vergleich
Da der Alpha eine Taktfrequenz von 500 MHz hat, im Vergleich zum PentiumPro 200, ist der Taktvorteil auf Seiten des Alphas. Er ist auch notwendig, da eigentlich nur Lotus Freelance und Corel Draw sehr gut Skalieren. Andere Anwendungen schreien weniger nach RISC, und Paradox scheint sogar Gift für ALPHA RISC zu sein, bzw. für dem Emulator.
Mittel der Wahl: Takt, Takt, Takt ...
Damals schlug auch dort wieder die Waffe intels zu, wie ein Vorschlaghammer konnte intel mit verbesserter Fertigungstechnik den Taktfrequenz den Wettkampf langfristig für sich entscheiden. Denn DEC selber gab früh seine Fertigung auf und liess für sich andere FABs schuften. Sie und auch die Auftragsfertiger waren aber nicht auf den Fertigungsstand von intel.
Intel selber war aber auch mal Phasenweise Auftragsfertiger für Alpha, aber da war das Rennen vermutlich schon entschieden.
Eine entscheidende Anregung bot der Artikel Wolves in CISC Clothing mit recht erstaunlichen Einsichten über die Grösse von CISC Code zu RISC Code auf der Alphaplattform und auch der Organisation der Übersetzung auf RISC Software.
Auch der gestiegene Bedarf an Speicher wurde hier mal endlich beschrieben.
Vermutlich gilt dies heute noch für andere RISC Architekturen auch.
MFG Bokill
Was hat die Software FX!32 mit dem Jahre 2004 zu schaffen?
Nun erst mal gar nichts, da Alpha fast Geschichte ist und vor allem die Alphas nicht mehr mit x86 Code beschickt werden. Ich schätze mal, dass die derzeitigen Alphas feinsten nativen Alphacode bekommen.
Aber die Grundidee in Echtzeit Code zu kompilieren und zugleich damit die Plattform langfristig damit zu optimieren, war revolutionär.
Das Wissen darüber war und ist heute noch Gold wert
DEC hatte aber ambitionierte Pläne
Schon die Namensgebung der Alphafamilie war fast schon vermessen.
a. 21 für die Architektur des 21 Jahrhunderts
b. die kommende Zahl für die fortlaufende Modellnummern
c. 64 für die 64Bit Architektur
Damit sie wollten den Server Markt bedienen. Mit der Emulationssoftware FX!32 wollten sie den Low-End-Server/Workstationmarkt bedienen.
Dort lümmelten sich damals, mit wachsender Begeisterung, die PentiumPro herum. Und der Markt wollte solche Low-End Massenserver/Workstations.
DEC`s Hoffnungen
DEC versprach, dass mit einem WinNT4 für die Alphas 21164PC und x86 Software ca. 70% der Leistung eines Alphas mit nativer Software für den Alpha leisten könnte.
Der Witz war: Es klappte auch.
FX!32 konnte die x86 Instruktionen recht gut übersetzen. Wenn man Paul DeMone glauben mag, dann konnte der übersetzte Code teilweise auf der Alphaplattform in Form der übersetzten Alpha DLL`s (Alpha RISC Code) sogar schneller laufen, als ihre Ursprungspedants auf x86 in x86 Software ( CISC Code) .
Die Geschichte mit RISC vs CISC ist sehr nett von HenryWince im Thread Instruction Set Architektur und Mikroarchitektur von CPUs sehr kompakt und eindeutig wiedergegeben worden. Unbedingt empfehlenswert
Auch wenn ich nicht so eloquent und mit garantiert weniger Wissen, wie Paul de Mone von realworldtech.com , darüber sprechen kann, so hilft doch ansatzweise sein Diagramm und Artikel "Wölfe im CISC-Kleid" über die Funktionsweise von FX!32 weiter.
Schematische Funktionsblöcke von FX!32 (von realworldtech.com)
http://www.realworldtech.com/includes/images/articles/CISC-Wolves-fig1.gif
Die Einzelnen Elemente sind:
1. x86 Code
2. Transperancy Agent
3. Runtime Emulator
4. Translated Alpha Code
5. Profile Data
6. Database + Server
7. Binary Translator
FX!32. Kurze ÜbersichtZum Funktionsaufbau des RISC Alpha Übersetzungsprogramms zum Übersetzen des x86 Code in Alphacode.
Ich mache mal einen Versuch die Elemente zu verdeutschen und etwas zu erläutern.
1. x86 Code: X86 Software reinstes CISC
2. Transperancy Agent: Dieses Programm im Betriebssystem schaut nach nativen Alphacode, wenn x86 Code kommt, dann ruft diese das FX!32 Programm auf. Die Übersetzung beginnt ...
3. Runtime Emulator: In Echtzeit wird der x86 Code übersetzt, zugleich wird nach alten Übersetzungen (5. 6.) geschaut)
4. Translated Alpha Code: In vorherigen Arbeitsgängen entstandener übersetzter nativer Alphacode.
5. Profile Data: Tabellarische Auflistung schon übersetzter x86 Software.
6. Database + Server:
7. Binary Translator: Die eigentliche Übersetzung von x86 zu Alpha-RISC.
FX!32: Ein Versuch des Vergleichs
Dieser Emulator läuft beständig im Hintergrund des Betriebssystems. Das Betriebssystem ist aber in Alphacode geschrieben.
FX!32 hat daher eine ähnliche Stellung wie WoW64 - Microsofts Starthilfe für 64-Bit Windows im Detail ...
Mit dem ganz wesentlichen Unterschied, dass vollkommen unterschiedliche ISA`s "mal so eben" übersetzt werden. Zusätzlich greift FX!32 "mal so eben" auf schon kompilierte DLL`s zurück die ehemal x86 waren und nun reinster Alpha-RISCcode sind (so weit geht WoW64 meiner Meinung nach nicht).
Im Gegensatz zum Transmeta bleibt der Code higegen aber auch dann RISC. FX!32 wollte ja reinen Code für seinen Alpha erzeugen. Die Datenbank hilft beständig schon übersetzte Elemente schneller nachzuladen. Dieses nativen DLL`s laufen schneller, als das Echtzeitübersetzen von x86 nach RISC.
Dies bedeutet, dass nach längerer Nutzung der Rechner schneller wird. Im Unterschied zum Transmeta hingegen bleibt aber auf der Maschine der Ursprungsx86 Code erhalten
. Meiner Meinung nach wächst beständig die Datenbank (6. ) mit ständig nachwachsenden Alpha-RISCcode.
Der Transmeta hingegen übersetzt in Echtzeit (wie FX!32), transformiert intern (wie FX!32), und übersetzt zurück in X86 (NEU).
Allerdings ist die Rückübersetzung nicht mehr 1:1 sondern, nach Transmetagesichtspunkten optimiert (Ebenfalls NEU). Falls die Rückübersetzung mal wieder geladen wird, so soll der frischere x86 Code schon mundgerechter für den Transmeta vorliegen.
Transmetakompilat: Bodenwellen für andere x86 Familien?
Gut möglich, dass solch ein Transmeta x86 Code die Horrorschau für den P4 ist. Täte mich nicht wundern, wenn ein K6 mit solch einem Kompilat vergleichsweise gut klarkommt. Der K6 sollte ja auf verschiedensten Terrain klarkommen. Selbst grausame Sprünge kann die kurze Pipeline des K6 ohne grosse Verzögerung einstecken. Die für damalige Verhältnisse gigatsiche Sprungvorheransageeinheit (besser als die vom K7) bestärkt solche Vermutungen.
Grundgrössen des FX!32 (Emulators)
Wie leistungsstark ist denn FX!32? Das Emulieren soll pro einer x86 Instruktion etwa 45 RISC Instruktionen benötigen.
Der RISC Code vom Alpha soll etwa um den Faktor 2 grösser sein wie X86 CISC Code
FX!32 braucht nach der Emulation aber immer noch 4,4 Instruktionen pro x86 Instruktion nach der erfolgten Übersetzung.
Tabellarischer Vergleich
Da der Alpha eine Taktfrequenz von 500 MHz hat, im Vergleich zum PentiumPro 200, ist der Taktvorteil auf Seiten des Alphas. Er ist auch notwendig, da eigentlich nur Lotus Freelance und Corel Draw sehr gut Skalieren. Andere Anwendungen schreien weniger nach RISC, und Paradox scheint sogar Gift für ALPHA RISC zu sein, bzw. für dem Emulator.
Mittel der Wahl: Takt, Takt, Takt ...
Damals schlug auch dort wieder die Waffe intels zu, wie ein Vorschlaghammer konnte intel mit verbesserter Fertigungstechnik den Taktfrequenz den Wettkampf langfristig für sich entscheiden. Denn DEC selber gab früh seine Fertigung auf und liess für sich andere FABs schuften. Sie und auch die Auftragsfertiger waren aber nicht auf den Fertigungsstand von intel.
Intel selber war aber auch mal Phasenweise Auftragsfertiger für Alpha, aber da war das Rennen vermutlich schon entschieden.
Eine entscheidende Anregung bot der Artikel Wolves in CISC Clothing mit recht erstaunlichen Einsichten über die Grösse von CISC Code zu RISC Code auf der Alphaplattform und auch der Organisation der Übersetzung auf RISC Software.
Auch der gestiegene Bedarf an Speicher wurde hier mal endlich beschrieben.
Vermutlich gilt dies heute noch für andere RISC Architekturen auch.
MFG Bokill
Zuletzt bearbeitet:
Ich wundere mich, dass niemand es wagte mir zu wiedersprechen.
In: Fortsetzung: Der FX!32 x86 Übersetzer
Da waren zumindest fragwürdige Dinge drin.
1. Wie kann Code von der Festplatte (6. Database + Server) schneller sein als eine Emulation direkt in der CPU?
Festplatte und Ausgelagerter Speicher gehören so zu den langsamsten Bestandteilen einer Rechnerarchitektur überhaupt (abgesehen vom Nutzer vor dem Bildschirm)
2. Weswegen schrieb ich Übersetzung in Echtzeit, wenn übersetzter Code erst mühsam wieder von der Datenbank geschaufelt werden muss?
Da steht zwar in der CISC-RISC Emulation 45 Instruktionen nativ gegen 4,4 Instruktionen (AlphaRISC), aber der Festplatten/Speicher Zugriff müsste doch die 4,4 Instruktionen gnadenlos langsam machen.
Antworten?
Und hier genau fängt spätestens die Genialität der Alphadesigner an. Sie kennen ihren Alphacode genauestens, daher ist es vermutlich auch gut möglich ihren Prozessor auf vorhersagbaren Code zu tunen. In dem Originalartikel Wolves in CISC Clothing war der unscheinbare Nebensatz, dass der Emulator genauestens Bescheid weiss über den Prozessorcache. Damals war der L1 Cache bei dem Alpha 8KB gross.
Hier ein Zitat von Hannibal Stoke aus dem Artikel "Understanding CPU Caching and Performance"
Der L1 Cache kommt so selten in Gefahr vollständig leerzulaufen. Offensichtlich schaffte das Alphateam sehr geschickt diese beständigen Nachladeoperationen zu verstecken.
Wie gross die Zeitverzögerung ist, zeigt die etwas betagte Tabelle von arstechnica.com. Die Grössenordnungen kommen aber in etwa noch hin.
Quelle: http://arstechnica.com/paedia/c/caching/caching-2.html
Auch hier hat heutzutage weniger die Zeit, als vielmehr die Latenz an Bedeutung gewonnen. Zeit ist zwar wichtig, aber mit optimierter Latenz kann hier noch viel LEISTUNG herausgeholt werden.
MFG Bokill
In: Fortsetzung: Der FX!32 x86 Übersetzer
Da waren zumindest fragwürdige Dinge drin.
1. Wie kann Code von der Festplatte (6. Database + Server) schneller sein als eine Emulation direkt in der CPU?
Festplatte und Ausgelagerter Speicher gehören so zu den langsamsten Bestandteilen einer Rechnerarchitektur überhaupt (abgesehen vom Nutzer vor dem Bildschirm)
2. Weswegen schrieb ich Übersetzung in Echtzeit, wenn übersetzter Code erst mühsam wieder von der Datenbank geschaufelt werden muss?
Da steht zwar in der CISC-RISC Emulation 45 Instruktionen nativ gegen 4,4 Instruktionen (AlphaRISC), aber der Festplatten/Speicher Zugriff müsste doch die 4,4 Instruktionen gnadenlos langsam machen.
Antworten?
Und hier genau fängt spätestens die Genialität der Alphadesigner an. Sie kennen ihren Alphacode genauestens, daher ist es vermutlich auch gut möglich ihren Prozessor auf vorhersagbaren Code zu tunen. In dem Originalartikel Wolves in CISC Clothing war der unscheinbare Nebensatz, dass der Emulator genauestens Bescheid weiss über den Prozessorcache. Damals war der L1 Cache bei dem Alpha 8KB gross.
Deswegen und auch wegen der sehr bemerkenswerten Artikel von arstechnica.com mit dem Autor Jon Hannibal Stoke könnte man die sehr gute Leistung bei bestimmten Aplikationen erklären.
Hier ein Zitat von Hannibal Stoke aus dem Artikel "Understanding CPU Caching and Performance"
Wenn der Code bekannt ist (Lokalität der Daten) dann kann der Alpha schon vorher, die Daten, genauer die Instruktionen, von dem Speicher und Festplatte holen. Dem Mantra von Hannibal Stoke filgend, werden die Latenzen sehr geschickt verdeckt durch spekulatives rechtzeitiges Hervorholen der Instruktionen.
Der L1 Cache kommt so selten in Gefahr vollständig leerzulaufen. Offensichtlich schaffte das Alphateam sehr geschickt diese beständigen Nachladeoperationen zu verstecken.
Wie gross die Zeitverzögerung ist, zeigt die etwas betagte Tabelle von arstechnica.com. Die Grössenordnungen kommen aber in etwa noch hin.
Code:
Level Access Time Typical Size Technology Managed By
Registers 1-3 ns 1 KB Custom CMOS Compiler
Level 1 Cache (on-chip) 2-8 ns 8 KB-128 KB SRAM Hardware
Level 2 Cache (off-chip) 5-12 ns 0.5 MB - 8 MB SRAM Hardware
Main Memory 10-60 ns 64 MB - 1 GB DRAM Operating System
Hard Disk 3,000,000 - 10,000,000 ns 20 - 100 GB Magnetic Operating System/UserAuch hier hat heutzutage weniger die Zeit, als vielmehr die Latenz an Bedeutung gewonnen. Zeit ist zwar wichtig, aber mit optimierter Latenz kann hier noch viel LEISTUNG herausgeholt werden.
MFG Bokill
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
@bokill
> DEC hatte aber ambitionierte Pläne
> Schon die Namensgebung der Alphafamilie war fast schon vermessen.
Die Architektur ist immer noch Top. Wenn man die Randbedingungen (Finanzierung, Engineering-Manpower, verfügbare Produktions-Prozesse, Management-Commitment) ansieht ist es schon erstaunlich, dass sich die Alphas so gut gehalten haben. Daran ist vor allem das AXP ISA Schuld -- das ist nach wie vor das sauberste das ich kenne.
> Ich wundere mich, dass niemand es wagte mir zu wiedersprechen.
Wieso wiedersprechen? Passt doch.
> Wie kann Code von der Festplatte (6. Database + Server) schneller sein als eine Emulation direkt in der CPU?
Die Ausführungsgeschwindigkeit hat wenig damit zu tun, wo der ins native AXP Befehlsformt übersetzte Programm-Code gespeichert wird. Bei Programmstart lädt das FX32! System halt statt 100% x86 Code die bereits übersetzten Programmstücke als AXP Code. D.h. ob FX32! 2 oder 4 Sekunden beim Programmstart braucht ist irrelevant. Wichtig ist doch nur, dass Anstelle von 45 native Instructions pro emuliertem x86 Befehl halt nach der Übersetzung 4 native Instructions einen x86 Befehl entsprechen. Wenn die Database bemüht wird passiert das ja auch nicht pro Instruktion, sondern für einen größeren zusammenhängenden Codebereich.
Emulation != Binary-Translation
> 2. Weswegen schrieb ich Übersetzung in Echtzeit, wenn übersetzter Code erst mühsam wieder von der Datenbank geschaufelt werden muss?
Wieso mühsam? Es ist schneller schon mal übersetzten Code in die Datenbank zu werfen und von dort später wieder anzufordern, als den Binary-Translation Prozess nochmal zu machen. Ein weiterer Grund dafür ist, dass hier auch Profiling-Informationen landen, die
dazu genutzt werden können die Performance zu verbessern. Das passiert z.B. durch Branch-Miss Information, die dazu genutzt wird die entsprechenden Branch-Prediction Informationen im übersetzten Code zu tunen. Dieses Tuning ist ein iterativer Prozess, deshalb macht es Sinn die Ergebnisse abzuspeichern. Transmeta's CMS ist in dieser Hinsicht dumm, weil der übersetzte UND optimierte Code nicht in ein Program-Repositiory zurückgeschrieben wird. D.h. bei jedem Neustart muss Transmeta das übersetzen und optimieren von neuem beginnen.
> DEC hatte aber ambitionierte Pläne
> Schon die Namensgebung der Alphafamilie war fast schon vermessen.
Die Architektur ist immer noch Top. Wenn man die Randbedingungen (Finanzierung, Engineering-Manpower, verfügbare Produktions-Prozesse, Management-Commitment) ansieht ist es schon erstaunlich, dass sich die Alphas so gut gehalten haben. Daran ist vor allem das AXP ISA Schuld -- das ist nach wie vor das sauberste das ich kenne.
> Ich wundere mich, dass niemand es wagte mir zu wiedersprechen.
Wieso wiedersprechen? Passt doch.
> Wie kann Code von der Festplatte (6. Database + Server) schneller sein als eine Emulation direkt in der CPU?
Die Ausführungsgeschwindigkeit hat wenig damit zu tun, wo der ins native AXP Befehlsformt übersetzte Programm-Code gespeichert wird. Bei Programmstart lädt das FX32! System halt statt 100% x86 Code die bereits übersetzten Programmstücke als AXP Code. D.h. ob FX32! 2 oder 4 Sekunden beim Programmstart braucht ist irrelevant. Wichtig ist doch nur, dass Anstelle von 45 native Instructions pro emuliertem x86 Befehl halt nach der Übersetzung 4 native Instructions einen x86 Befehl entsprechen. Wenn die Database bemüht wird passiert das ja auch nicht pro Instruktion, sondern für einen größeren zusammenhängenden Codebereich. Emulation != Binary-Translation
> 2. Weswegen schrieb ich Übersetzung in Echtzeit, wenn übersetzter Code erst mühsam wieder von der Datenbank geschaufelt werden muss?
Wieso mühsam? Es ist schneller schon mal übersetzten Code in die Datenbank zu werfen und von dort später wieder anzufordern, als den Binary-Translation Prozess nochmal zu machen. Ein weiterer Grund dafür ist, dass hier auch Profiling-Informationen landen, die
dazu genutzt werden können die Performance zu verbessern. Das passiert z.B. durch Branch-Miss Information, die dazu genutzt wird die entsprechenden Branch-Prediction Informationen im übersetzten Code zu tunen. Dieses Tuning ist ein iterativer Prozess, deshalb macht es Sinn die Ergebnisse abzuspeichern. Transmeta's CMS ist in dieser Hinsicht dumm, weil der übersetzte UND optimierte Code nicht in ein Program-Repositiory zurückgeschrieben wird. D.h. bei jedem Neustart muss Transmeta das übersetzen und optimieren von neuem beginnen.
Psycho-Dad
Admiral Special
Weiß jemand von welcher Firma die Alphas gefertigt werden und was vielleicht auch noch interessant wäre mit welcher Technik.
mfg
Flo
mfg
Flo
Alpha Dec EV6-Bus
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
> Weiß jemand von welcher Firma die Alphas gefertigt werden und was vielleicht auch noch interessant wäre mit welcher Technik.
IBM ist HP's Foundary Partner. Der "neue" 1.25 GHz Chip ist immer noch 180nm. HP hat ja den echten EV79 vor ca. einem Jahr gekillt und an dessen Stelle nur ein schnelleres Speedgrade des EV7 in die (Dead-End)Roadmap genommen.
Ich meine für einen 180nm Chip ist die Leistung immer noch respektabel!
IBM ist HP's Foundary Partner. Der "neue" 1.25 GHz Chip ist immer noch 180nm. HP hat ja den echten EV79 vor ca. einem Jahr gekillt und an dessen Stelle nur ein schnelleres Speedgrade des EV7 in die (Dead-End)Roadmap genommen.
Ich meine für einen 180nm Chip ist die Leistung immer noch respektabel!
Uuups ... mein Motiv wurde erkannt
Tja nur hat der Hersteller DEC wohl vollkommen tranig den Alpha vermarktet, oder die Zeit war nicht reif dafür.
Zu den Herstellern kann ich derzeit nicht viel sagen, aber DEC hat aus Kostengründen recht früh die Fertigung verkauft und dann nur noch über Werksfremde Foundries (wie NVIDIA, ATi, VIA ... ) Aufträger vergeben.
DEC gab auf verkaufte ihr kostbares Wissen an Compaq. In der Meldung wird ja auch die Zusammenarbeit mit intel genennt.
Da war auch irgendwann mal intel zwischenzeitlich dabei, gut möglich dass auch TI und andere mal für DEC und später für Compaq fertigten.
Der Oberwitz ist, dass die Kartellbehörden keinerlei Bedanken hatten, als Wissen und Know-How von Compaq an intel verkauft wurde.
@HenryWince
Das ist wahr? HP steigt dann ja wirklich in jedes Bett hinein
... der Power5, 4+, 4 sind ja ernste Konkurrenten gegen die Alphas, PA-RISC und auch eben gegen den Itanium ... erstaunlich.Vor allem waren dieses Taktfrequenzen eher für 0,13µm vorgesehen ... wirklich erstaunlich ... wie sähe dies mit modernster 0,09µm Technologie aus 8) ?
MFG Bokill
Zuletzt bearbeitet:
Shearer
Grand Admiral Special
DEC hat 1997 seine Fabriken für ca. 1,6 Mrd Dollar an Intel verkauft, dort wurden die Alphas dann weiter produziert.
http://news.com.com/Settlement+good+for+Digital,+bad+for+Alpha/2100-1001_3-204687.html
Shearer
http://news.com.com/Settlement+good+for+Digital,+bad+for+Alpha/2100-1001_3-204687.html
Shearer
Shearer
Grand Admiral Special
Schaut mal auf den Stromverbrauch
http://www.geek.com/procspec/dec/21364.htm
Anscheinend war eine 130nm-Produktion geplant...
http://www.geek.com/procspec/dec/21364.htm
Anscheinend war eine 130nm-Produktion geplant...
PuckPoltergeist
Grand Admiral Special
Werden die nicht grundsätzlich noch bei Intel gefertigt? (Auflagen FTC)
Soweit ich weiß, werden die Chips von Intel und Samsung gefertigt, wobei letztere auch selber verkaufen.
Die Aufgezählten fertigen aber alle nicht selber (bei VIA bin ich mir jetzt nicht ganz sicher), sondern lassen auch fertigen (TSMC, UMC, IBM).
Psycho-Dad
Admiral Special
Ok, der ein Energiewunder ist der Alpha zwar jetzt nicht gerade, aber erstens scheint mir die Meldung doch schon etwas älter zu sein, somit könnte es sein das die aktuellen Specs ganz anders aussehn und zweitens ist die DIE-Fläche auch nicht gerade gering womit sich das alles ein wenig relativiert.
Außerdem, bei dem vielen Geld was die Computer mit diesen Chips kosten dürfte wohl auch das Geld für eine anständige KÜhlung mit verplant sein.
CU
Flo
Außerdem, bei dem vielen Geld was die Computer mit diesen Chips kosten dürfte wohl auch das Geld für eine anständige KÜhlung mit verplant sein.
CU
Flo
Diese Paraphrase ist so notwendig wie ein Kropf:
Bitte vorher überlegen, dann posten. Ich beschrieb ja, dass DEC/Compaq keine eigene Fertigung mehr hatte, so waren sie an Auftragsfertigung angewiesen.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Habe ich nicht vor.
Sorry, hatte dich falsch verstanden. Ich dachte du meinst damit, dass DEC bei den von dir aufgezählten Firmen hat fertigen lassen.
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
> Das ist wahr?
Ja. Von IBM werden auch die PA-8800 hergestellt.
> Werden die nicht grundsätzlich noch bei Intel gefertigt?
Nein. Intel und Samsung haben die letzte Generation (EV-68) hergestellt. Samsung hatte sogar eine AXP Entwicklungslizenz.
> Anscheinend war eine 130nm-Produktion geplant...
Das sollte der EV-79 sein. Dieser Chip sollte schon Anfang 03 auf dem Markt sein, aber HP hat wohl dafür keinen Bedarf gesehen
Nebenbei bemerkt halte ich das HP Management für ziemlich mies: HP hat damal versucht die Schuld am nichterscheinen des EV-79 IBM's Prozesstechnik in die Schuhe zu schieben, aber das ist dann sebst den dümmsten Aufgefallen das das nicht stimmen kann. Wieso sollte der Prozess schuld sein, wenn damit POWER und der HPPA realisiert werden konnten?! Um die Kunden nicht ganz zu vergraulen gibts statt 130nm Technik über 1.5 Jahre später einen neuen Speedgrades den HP zur Tarnung EV-7z nennt. Saubande!
