Sinn und Unsinn von 64bit
- Ersteller PuckPoltergeist
- Erstellt am
rkinet
Grand Admiral Special
Natürlich ist 64 Bit nur wenige wenige wirklich nötig.
Nur es kommt in wenigen Wochen als prof. Edition und DELL, ALDI & Co. werden bei Billy MS schon für spätestens Herbst'05 geordert haben.
Und dann schließt sich der Kreis von: http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=192760
Bem: http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
MS hat auch /3GB unter IA32e auf '/4GB' erweitert, da ja der PCI-Adressraum und der Speicherbedarf eines 32 Bit OS wegfallen.
Klein aber fein können 32 Bit Programmierer jetzt in 4 GB Blöcken je Applikation denken.
Zudem kann man sich ausrechnen, daß trotz Lieblingssport von Sekretärinen u.ä., möglicht immer gleich ein Dutzend (32 Bit) Anwendungen morgens zu starten, das 64 Bit OS immer noch bis zu 4 GB für wirklich wichtige Programme zur Verfügung stellen kann.
Mit 2 GB echtem RAM dürfte das OS so eine oder zwei 'große' Applikationen und die restlichen Spielereien mit vielleicht zusätzlich 3-4 GB HD-Auslagerung bewältigen können.
Vorteil, obwohl außer dem OS und den Treibern nicht in 32 Bit vorliegt.
Wie sich 32 Bit Viren und Würmer 'freuen', wenn sie auf diesem Tippsen PC keinerlei reale Spuren eines (32 bit) OS finden, da kann wohl nur der Firmen-Admin mit Freude registrieren. 'Stinkefinger' an die Viren Dank 64 Bit und dessen Speicherschutz
Fazit: Ein Herz für Admins, aber keines für 32 Bit Nostalgiger !
xray01
Commodore Special
Sicher wird sich 64bit durchsetzten, aber nicht in einigen Wochen. Ich denke das dies noch Jahre dauern wird.
Gehe jetzt nicht von den "Home Usern" aus sondern von Firmen und Unternehmen.
In unserem Fall würde eine Umrüstung enorme Kosten verursachen, denke in anderen Firmen auch. Zumal viele durch die günstigen Angebote der i865 Chipsätze bereits umgerüstet haben.
Klar wird 64bit schon Sinn machen, in bestimmten Bereichen, aber wie gesagt. es wird nicht so schnell voran gehen.
mfg manfred
Gehe jetzt nicht von den "Home Usern" aus sondern von Firmen und Unternehmen.
In unserem Fall würde eine Umrüstung enorme Kosten verursachen, denke in anderen Firmen auch. Zumal viele durch die günstigen Angebote der i865 Chipsätze bereits umgerüstet haben.
Klar wird 64bit schon Sinn machen, in bestimmten Bereichen, aber wie gesagt. es wird nicht so schnell voran gehen.
mfg manfred
rkinet
Grand Admiral Special
'Neue' Computer raus zu werfen ist natürlich Unsinn.
Auch wird man innerhalb einer Firma ja möglichst einheitliche OS und Treiber fahren.
Aber nach 4 Jahren und Abschreibung der Geräte ist natürlich die Umrüstung sinnvoll.
Firmen, die so ab Ende 2005 einen älteren PC-Fuhrpark haben, dürften aber eine Umstellung prüfen. Sowohl das Virenthema, als auch der deutlich größere Speicher für mehrere Anwendungen oder lokale Daten sind ein wichtiges Argument.
Allerdings, noch weitere Absicherungen wie VT oder Pazifica und Longhorn u.ä. würden die Sache auf 2006/7 verschieben.
----
http://www.the-inquirer.net/?article=21760
Microsoft tauscht - K O S T E N L O S - 32 gegen 64 Bit ,
etwa in/ab 3 Monaten
OEMs können frei wählen und bekommen ebenfalls 32 u. 64 Bit zum gleichen Preis.
tja: http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=192760
Die Prognose von CEO-Ruiz wird immer wahrscheinlicher ...
Natürlich werden die Firmenkunden zeitlich anders denken, aber auch da dürfte 64 Bit zumindest in die Prüfung kommen.
Zuletzt bearbeitet:
Shdow
Vice Admiral Special
junge du regst mich auf... das wird nicht warscheinlicher das wird realität werden!
nu hör doch endlich mal mit dein klugscheiß gelaberauf , als wenn du der messiah persönlich wärst!
wo willst du denn bitte ende des jahres noch eine 32 bit cpu kaufen?
intel will unstellen und amd auch....
sicherlich wird es kleinere serien 32 bit cpus geben aber sicherlich nicht mehr für den normaluser... wer holt sich denn schon eine 32 bit cpu wenn grad alle auf 64 bit umstellen und intel wie wild damit wirbt? wenn intel ruft 64 bit ist super wir brauchen das dann kauft das doch jeder dau....
rkinet
Grand Admiral Special
messias ?
ich gestern über Wasser gerannt, war aber nur 10 mm tief ...
@Shdow,
lies einfach den allerersten Beitrag von PuckPoltergeist.
Und berücksichte, daß er mich seit Anf. 2004 hier und bei heise.de mit immer neuen Gründen gegen 64 Bit überschüttet hat.
Für mich ist x86-64 einige wenige Millionen mehr auf einer CPU - bei der aktuellen Fertigungstechnik kein signifikanter Mehraufwand. Dafür aber ein tägliches Ärgernis für Programmierer, die per unglücklichem x86 Design ihre Software nur gebremst umgesetzt bekommen.
Es macht einfach Freude, wenn sich gute Technik durchsetzt.
Und ich wollte längst den Beitrag hier schließen und nur noch das Thema betrachten, welche Software sinnvoll in 64 Bit wäre.
64 Bit beim Desktop ist durch ...
Shdow
Vice Admiral Special
@ rkinet...
genau das ist es ja das unglückliche x86 design ändert sich ja nicht wie du das immer beschreist...
es wird nur auf 64 bit verbreitert und man kann mehr adressieren das ist aber auch schon alles!
du überbewertest das einfach viel zu viel....
ja ich find das super das 64 bit kommt weil man darauf in 2-6 jahren sowieso angewiesen wäre aber das ändert doch nichts an der x86 architektur...
PS: hast du schonmal in betracht gezogen das Puckpoltergeist aufgrund seiner erfahrung recht haben könnte? ich z.b. bin voll und ganz seiner meinung... alles andere ist marketing geflame ohne den technischen hintergrund VERSTANDEN zu haben.
genau das ist es ja das unglückliche x86 design ändert sich ja nicht wie du das immer beschreist...
es wird nur auf 64 bit verbreitert und man kann mehr adressieren das ist aber auch schon alles!
du überbewertest das einfach viel zu viel....
ja ich find das super das 64 bit kommt weil man darauf in 2-6 jahren sowieso angewiesen wäre aber das ändert doch nichts an der x86 architektur...
PS: hast du schonmal in betracht gezogen das Puckpoltergeist aufgrund seiner erfahrung recht haben könnte? ich z.b. bin voll und ganz seiner meinung... alles andere ist marketing geflame ohne den technischen hintergrund VERSTANDEN zu haben.
rkinet
Grand Admiral Special
Märchen ...
Es gibt an x86-64 nicht mehr auszusetzen,
Genügend Register
Brauchbare, moderne Adressierungsarten.
Intern sehr gut in ein superskalares Design umgesetzt
Gut Altivec übertrifft eine SSE, nur auch Altivec hat im Cell schon Nachfolger.
@Shdow,
die Märchen über x86-64 sind nur noch als lächerlich zu bezeichnen.
Ob man eine CPU mit x86-64 oder direkt mit RISC füttert ist ziemlich egal für die Abarbeitung des Codes. Praktisch am x86-64 Code ist zudem, daß er relativ kompakt ist, was interen Cache geringer belastet und load/store beschleunigt.
Im Unterschied zu x86 verliert x86-64 nicht wg. Registermangel Zeit durch herumschieben der Daten. Gewiß, heutige x86/x86-64 Compiler nutzen diese Möglichkeiten (noch) begrenzt, aber da ist noch Potentialvorhanden.
PuckPoltergeist
Grand Admiral Special
Da steht, dass ich den Sinn und die Notwendigkeit von 64bit auf dem Desktop anzweifle. Dazu habe ich die Frage nach evtl. Sinn in den Raum gestellt, da mir selber nicht wirklich etwas dazu eingefallen ist. Auf diese Frage bist du nicht mal ansatzweise eingegangen. Alles was von dir kam, war die übliche Polemik und Gelaber wie sich 64bit doch durchsetzen (werden).
Damit wären wir wieder beim Thema Textverständnis. Aber ich erwarte von dir schon gar keine sinnvollen Beiträge mehr. Du hast mehr als genug unter Beweis gestellt, das dir jegliches Verständnis der Materie fehlt, und damit auch noch offensiv um dich wirfst. Mehr als bunte Marketing-Papers, die für Analüstentreffen gedacht sind und jeglichen Tiefgang vermissen lassen, ziehst du für deinen Meinungsbildung ja offenbar auch nicht heran.
Oder mal anders gefragt, wenn du doch das entsprechende Wissen hast, wieso hilfst du dann nicht damit nicht anderen Usern in diesem Forum? Ich habe noch nicht einen einzigen Beitrag hier von dir gelesen, in dem du auf Probleme anderer Foren-User eingehst. Alles, was du hier von dir gibst, sind irgendwelche Spekulationen oder Beleidigungen anderer User, die dir widersprechen. Bist du dir zu fein, anderen zu helfen?
Und, hast du einen davon widerlegt? Der Ausgangspunkt dieser Diskussion war ein Post zu einem Newsbeitrag, in dem jemand den Geschwindigkeitsgewinn des K8 den 64bit zugeschrieben hatte. Das hatte ich korrigiert, darauf hingewiesen, dass der Performancegewinn durch die zusätzlichen Register kommt. Zusätzlich habe ich darauf aufmerksam gemacht, dass 64bit GPRs in den meisten Fällen keinen Geschwindigkeitsgewinn bringen, sondern im Gegenteil durchaus auch Einbußen bringen. Ich habe auch Sparch und Mips als Beispiele gebracht, wo trotz 64bit Architektur und OS die meiste Software in 32bit läuft.
Darauf hin war ich dann gleich der Verfechter für 32bit, würde am liebsten gleich zu 8bit-Prozessoren zurück etc.
Den Athlon64, für den du für mich aufgerufen hast, habe ich übrigens immer noch nicht.
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
rkinet
Grand Admiral Special
Deine Wort: http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=192760
Warum sollte ich Mitte 2005 auf dem Desktop 64bit einsetzen?
Brauche ich denn die Leistung, die mir AMD64 zusätzlich bringt, wirklich?
Ob man im 2+ GHz Zeitalter 64 Bit, SSE3, 1-2 MB-L2 oder Dual-Core benötigt ist berechtigt.
Aber da kann man 75% aller Newsberichte zum PC-Thema angreifen.
Die Analystenpapiere von AMD gehen wesentlich mehr in die Tiefe, als vieler Vermutungen in Foren. AMD legt hier die Produktionspläne offen, die für die Firmenbewertung wichtig sind. Da stand im November 2004 schon für 2005 indirekt der Turion 64 & die 25 Watt TDP, da standen kompatible Dual-Core, auch Dual-Core für DTR-Notebooks, die Fab36 produktionsreif ab 2006 für Pazifica & Co. u.s.w.
Vieles, was in Foren auch danach noch angezweifelt wurde.
Die These von Geschwindigkeitseinbußen hat sich nur im Prozentbereich und in einigen Fällen bestätigt. Dafür aber auch ein deutlicher Anstieg bei richtiger 64 Bit Software.
Bereits die Architektur von x86-64 zeigt, wann es welchen Effekt auftritt:
- nutzt man die zusätzlichen Register, steigt die Performance und der Codebedarf sinkt
- nutzt man die Datenregister weiterhin in 32 Bit und arbeitet im normalen Umfang mit absoluten Adressen hat dies keinen Einfluß auf die Performance.
- werden die Datenregister mit 64 Bit genutzt und der Datenverkehr steigt gibt es leichte Einbußen.
Man /der Compiler hat bei allem einen wesentlichen Einfluß. In Summe ist es so, daß immer dann , wenn man bewußt/ versehentlich mehr Leistung durch 64 statt 32 Bit abfordert, dies die CPU auch fordert. Dieser Zusammenhang ist aber derart trivial logisch, daß jeder Kampfdiskussion darüber Unsinn ist.
Bisher haben alle Benchmarks gezeigt, daß die restlichen PC-Komponenten (GraKa, DRAM, Treiberversion) sich deutlicher auswirken als die Kombination 32/32 Bit Anwendung/OS oder 32/64 Bit Anwendung/OS. In der 64/64 Bit Kombination haben wird deutliche Verbesserungen, von Spezialsoftware (z.B. Encoder) bis hin zu Datenbankanwendungen (s. Microsoft-Stellungnahmen).
Daher auch die positive Aufnahme von x86-64 quer durch die Märkte.
@PuckPoltergeist,
Deine Aussage 'das dir jegliches Verständnis der Materie fehlt' , alle bisherigen Posting zum 64 Bit Thema stehen derart im Widerspruch zur weltweiten Reaktion auf 64 Bit und vorhandene Benchmarks das einem nur noch die Luft wegbleibt.
Wenn es Dich ärgert, daß andere mehr Ahnung als Du hast in einigen Bereichen, dann zeigt das herumpoltern und wüste beschimpfem nur noch Charaktermängel.
Was ich Dir seit Anbeginn bei 64 Bit übel nehme ist das fehlen von Links zum Thema, Benchmarks oder auch nur mal Codebeispiele und geschätze Taktcyclen dazu.
Es fehlt Dir fachlich an fast allen zum 64 Bit Thema - Thema klar verfehlt und am Markt vorbei gepoltert
Interessant auch: http://www.planet3dnow.de/vbulletin/showthread.php3?s=&postid=2133719#post2133719
Über 64 Bit 'poltern' und an 'EPIC' beim Desktop träumen.
Da war doch noch der alte Blödsinn von guten und schlechtem 64 Bit ...
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Was hat das eine mit dem anderen zu tun? Du schmeißt mal wieder Sachen zusammen, die nichts miteinander zu tun haben. Die Frage nach der Notwendigkeit bei 64bit bezog sich darauf, dass neben dem Geschwindigkeitsgewinn auch deutliche Nachteile zeigen. Welche Nachteile hat SSE3?
Das sind teilweise Statusmeldungen und vor allem Ziele, die man erreichen will. Die Analysten und Aktionäre interessieren sich nicht dafür, wie DSL funktioniert, sondern was man damit erreichen will. Die Aktionäre sind in den seltesten Fällen Ingenieure, die mit solchen Themen vertraut sind, die Analysten noch viel weniger. Die sind auf den Kapitalmarkt spezialisiert, und wollen wissen, wie man die vorgestellten Techniken zu Geld machen kann.
Dass die Papers trotzdem weiter in die Tiefe gehen als die meisten Vermutungen hier, stimmt dennoch. Die meisten Vermutungen kommen nämlich von dir, und du gehst nicht in die Tiefe, sondern weichst ernsthaften Diskussionen aus.
Richtig, Spezialsoftware! Wieviele Heimanwender lassen ein DBMS auf ihrem Rechner laufen?
Klar, ist ja auch ein prima Marketing-Instrument. Kaufen sie jetzt 64bit statt 32bit, und ihr Rechner ist doppelt so schnell.
Du hast ein bemerkenswertes Talent, dich selber darzustellen.
Was ich Dir seit Anbeginn bei 64 Bit übel nehme ist das fehlen von Links zum Thema, Benchmarks oder auch nur mal Codebeispiele und geschätze Taktcyclen dazu.
Es fehlt Dir fachlich an fast allen zum 64 Bit Thema - Thema klar verfehlt und am Markt vorbei gepoltert
Ich habe von Anfang an dargelegt, wieso 64bit an sich keinen Geschwindigkeitszuwachs auf dem Desktop bringen, sondern meist kontraproduktiv wirken. Das war natürlich nicht gut genug, und Links hatte ich wirklich keine. Ich habe leider den Link zur Diskussion auf der Debian-ML zu AMD64 immer noch nicht wieder gefunden. Es sind aber mittlwerweile reichlich Links gebracht worden, sowie auch Benchmarks. Das hast du bis jetzt geflissen ignoriert.
Hier nochmal extra für dich ein paar davon:
http://www.osnews.com/story.php?news_id=5768&page=1
http://docs.sun.com/app/docs/doc/806-0477/6j9r2e2af?a=view
sowie:
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=181589
Vielleicht liest du es ja diesmal. Vielleicht kommst du dann auch auf den Gedanken, dass ich durchaus schon einiges an Erfahrung mit 64bit habe, nicht nur mit x86_64.
Schon wieder ein Beweis, dass du keine Ahnung von dem hast, worüber du hier schreibst. Was hat EPIC mit 64bit zu tun? Bestimmt genauso viel wie Mips mit 64bit zu tun hat.
Darüber hinaus ist das gleich noch ein Beispiel für dein mangelndes Textverständnis. Wo habe ich da von EPIC auf dem Desktop geträumt? Ich schrieb lediglich, dass das die Pläne von Intel waren. Du solltest aufhören, anderen irgendwelche Worte in den Mund zu legen. Irgendwann könnte das mal jemand als böswillige Unterstellung auffassen.
rkinet
Grand Admiral Special
@PuckPoltergeist - mangelhaft Teil 2 !
- es gibt keine deutlichen Nachteile durch x86-64; bei anderen 64 Bit Designs ist dies teils anders. x86-64 kann so compiliert werden, daß nur minimaler Mehrbedarf an Code bei absoluten Adressen entsteht.
- bei SSE3 Nutzung muss der Programmierer bei CPUs ohne SSE3 noch Ersatzcode mit einbinden, daß aber dann die Performance deutlich mindern kann.
- ob AMD oder bei Intel, die Börseninfos enthalten wichtige, weitgehend verbindliche Infos zur Roadmap einer Firma. Im Unterschied zu anderen Firmeninfos sind die Infos börsenrelavent und SEC-pflichtig bei Änderungen. Schon mehrfach hier angesprochen, verstößt ein Manager gegen solche Informationen kanns bis hin zum US-Gefängnis gehen.
Noch tiefer (runter) geht wohl nicht mehr, oder ?
- Die Links sind schwach ohne Ende. 'osnews' hat nichts mit x86-64 zu tun, SUN spricht nicht von nachteilen; Deinen 'Eigenmessungen' kannst Du an Hasen verfüttern, wie die nachfolgenden Beiträge dort zeigten.
- EPIC und 64 Bit ? Wurde von Intel zur breiten Einführung von 64 statt 32 Bit incl. einer 'Emulation' für 32 Bit entwickelt. Dies sollte der Nachfolger werden statt x86-64, wenn auch erst so 2007ff. im Umkreis der 65nm / eher 45nm Fertigungtechnik. Nachdem die 'Konkurrenz' (IBM, AMD, SUN) aber Multi-Core schon länger favorisiert, wären die EPIC-Boliden auch in 45nm nicht mehr konkurrenzfähig.
Fazit: Du polters wie blöd auf Basis von wenigen popeligen Angaben und keinerlei Bereitschaft von Dir Dich überhaupt mit dem x86-64Design zu beschäftigen.
- es gibt keine deutlichen Nachteile durch x86-64; bei anderen 64 Bit Designs ist dies teils anders. x86-64 kann so compiliert werden, daß nur minimaler Mehrbedarf an Code bei absoluten Adressen entsteht.
- bei SSE3 Nutzung muss der Programmierer bei CPUs ohne SSE3 noch Ersatzcode mit einbinden, daß aber dann die Performance deutlich mindern kann.
- ob AMD oder bei Intel, die Börseninfos enthalten wichtige, weitgehend verbindliche Infos zur Roadmap einer Firma. Im Unterschied zu anderen Firmeninfos sind die Infos börsenrelavent und SEC-pflichtig bei Änderungen. Schon mehrfach hier angesprochen, verstößt ein Manager gegen solche Informationen kanns bis hin zum US-Gefängnis gehen.
Noch tiefer (runter) geht wohl nicht mehr, oder ?
- Die Links sind schwach ohne Ende. 'osnews' hat nichts mit x86-64 zu tun, SUN spricht nicht von nachteilen; Deinen 'Eigenmessungen' kannst Du an Hasen verfüttern, wie die nachfolgenden Beiträge dort zeigten.
- EPIC und 64 Bit ? Wurde von Intel zur breiten Einführung von 64 statt 32 Bit incl. einer 'Emulation' für 32 Bit entwickelt. Dies sollte der Nachfolger werden statt x86-64, wenn auch erst so 2007ff. im Umkreis der 65nm / eher 45nm Fertigungtechnik. Nachdem die 'Konkurrenz' (IBM, AMD, SUN) aber Multi-Core schon länger favorisiert, wären die EPIC-Boliden auch in 45nm nicht mehr konkurrenzfähig.
Fazit: Du polters wie blöd auf Basis von wenigen popeligen Angaben und keinerlei Bereitschaft von Dir Dich überhaupt mit dem x86-64Design zu beschäftigen.
PuckPoltergeist
Grand Admiral Special
Deutlich höherer Speicherverbrauch ist für mich schon ein Nachteil. Da es in dem Thread auch nicht explizit drinn steht, schreib ich es hier direkt hin: Der Speichermehrverbrauch wird hauptsächlich durch das Datensegment verursacht. Kann man aber auch aus dem Beitrag von Dresdenboy herauslesen (Tiny-Model).
Was willst du damit sagen? Dass Programme mit SSE3 langsamer sind als ohne, weil sie zusätzlichen Code für Prozessoren ohne SSE3 mitbringen müssen? Dass diese Programme auf Prozessoren ohne SSE3 langsamer ausgeführt werden, weil sie SSE3 dort nicht nutzen können?
Ersteres ist Blödsinn, und möchtest du bitteschön belegen, letzteres ist logisch. Wo ist also der Nachteil von SSE3?
Fein, dann wird ja die gesamte Intel-Führungsriege bald verhaftet. Schließlich haben sie ja die Anleger getäuscht, als sie behaupteten den P4 auf deutlich über 4GHz hochzuziehen.
Es ging um 64bit, nicht explizit x86_64. Dein Textverständnis lässt immer noch zu wünschen übrig.
64-bit Application Disadvantages
64-bit applications require more stack space to hold the larger registers.
Applications have a bigger cache footprint from larger pointers.
64-bit applications do not run on 32-bit platforms.
Offensichtlich lese ich ein anderes Dokument als du.
Welche Beiträge meinst du? Offenbar lesen wir schon wieder verschiedene Texte.
Wo steht geschrieben, dass EPIC auf 64bit festgenagelt ist? Das ist eine Systemarchitektur und ein Programmiermodell. Ist dir bekannt, dass:
Mips in 32bit und 64bit gibt?
Power ursprünglich als 32bit gestartet wurde?
PPC in 32bit und 64bit gibt?
Das sind alles Architekturen wie EPIC. Keine von denen ist auf eine Registerbreite der GPRs festgenagelt. Wieso sollte das bei EPIC plötzlich so sein?
Dass Intel vielleicht mal vorgehabt hat mit EPIC auch 64bit auf den Desktop zu bringen, sagt noch lange nicht, dass das zwingend so sein muss.
Außerdem fehlt mir immer noch die Stelle, wo ich von den 64bit auf dem Desktop geträumt haben soll.
Wie schon mehrfach angemerkt, beschäftige ich mich durchaus mit dem Design von x86_64. Ich arbeite damit, ich programmiere da drauf. Ich wage irgendwie zu behaupten, dass ich damit deutlich mehr Erfahrung habe, als du.
rkinet
Grand Admiral Special
Genau, will der Programmierer höher auflösende Daten, benötigt er mehr Speicher.
Nur, er muss es nicht so machen. Daher kein Nachteil von x86-64, sondern Absicht des Programmierers
Jede Abfrage kostet Zeit, der Ersatzcode für SSE2 und/oder SSE1 muss extra vorliegen.
Gut natürlich, wenn der aus Vorgängerversionender Software übernommen werden kann.
Sonst doppelte Arbeit für den Programmierer, oder er läßt es einfach mit SSE3 (so wie in der Praxis)
Nein, Intel hat rechtzeit per Pressemeldung und SEC das Ende von 4 GHz für absehbare Zeit verkünden lassen.Fein, dann wird ja die gesamte Intel-Führungsriege bald verhaftet. Schließlich haben sie ja die Anleger getäuscht, als sie behaupteten den P4 auf deutlich über 4GHz hochzuziehen.
Die Stackbelastung ist zutreffend. Beim Wechsel von x86 auf x86-64 entfallen aber auch einige Stackvorgänge, da eben Daten in Registern gehalten werden (so Win XP x64, das 4 neue Register zur Parameterübergabe nutzt). Dies kürzt hier wiederum den OPCode-bedarf - also ein Nullsummenspiel.
'Larger Pointers' müssen in x86-64 nicht sein, man kan auch in 32 Bit indiziert arbeiten
- 64-bit applications - nun die Softwarehersteller müssen zwei Binärcodes pflegen, nutzen aber dafür nur einen Sourcecode zur Pflege. Durch die Fähigkeit von x86-64 die 32 Bit Software in voller Geschwindigkeit abzuarbeiten, aber letzlich einen freie Entscheidung der Softwarehersteller.
Auch - klein, aber fein - unter IA32e steigt der verfügbare Speicherplatz von \3GB compilierter Software auf 4GB an, wobei das OS physikalisch deutlich über 4 GB handhaben kann. So profitieren gerade 'große' 32 Bit Programme von einem 64 Bit-OS unter x86-64, zunächst verblüffend, aber eine enorme Überlebenshilfe für reine 32 Bit Softwarelinien.
Frag mal Intel, ob die noch ein zusätzliches EPIC-32 raus bringen wollen !
Die 32 Bit würden den Cachebedarf und die Performance von EPIC nicht merklich beeinflussen.
Keine Kritik dazu.
Nur, ich kenne den x86-64 Code anhand von Compilaten auf Assembler-Ebene. Und die Adressierarten, sowie OpCodes von x86-64 dazu. Die Antwort dazu ist eindeutig, was auch alle Fachartikel bestätigen.
Einfach ein geniales Design, daß die Mängel des x86-Designs behebt. Ich werde diese Tatsache auch immer wider betonen und doofen Gerüchten über Architekturmängel bei x86-64 entgegentreten. Es bringt einfach nichts, wenn uralte x86-Probleme einfach an x86-64 geklebt werden und stets die heimliche Hoffnung nach einer Verbesserung durch Systemwechsel bei der CPU-Architektur warm gehalten wird.
Mit x86-64 ist die IPC praktisch gleichauf mit anderen 64 Bit-Designs bei Integer/ALU Operationen.
Auch EPIC (http://wwwbode.cs.tum.edu/~gerndt/h...chnerarchitektur/VLIW-EPIC-Multithreading.pdf) hat nicht mehr zu bieten, besonders bei Dual-Core und Multi-Core x86-64 als Konkurrenz. Der kompakte x86-64 Code belastet die externen Speicherzufriffe deutlich weniger, daher kann 'PI mal Daumen' eine Speicherinterface die doppelte Anzahl an x86-64 Cores im Vergleich zu EPIC-VLIW versorgen. Damit bremst sich EPIC-VLIW aber voll aus und verliert seinen Performancevorteile.
Nun, die Beschäftigung mit Assemblercode ist eine Zumutung, ok.
Aber da unten, OpCode um Code wird die Performanceschlacht der CPU-Designs geführt.
Ob RISC oder CISC als Vorlage ist da unten sch...egal;
kompakte OpCodes, die Registerzahl, wenige Abhängigkeiten voneinander im Code ergeben dann Performance.
Alles andere sind Tagträume - und Intel mußte dies auch schmwerzhaft erleben.
PuckPoltergeist
Grand Admiral Special
Ich glaube kaum, dass die Mozilla- oder KDE-Entwickler einen höheren Speicherverbrauch gewollte haben. Dort schlägt der aber recht extrem zu.
Diese Abfrage wird einmal zum Programmstart gemacht. Von da aus wird in die unterschiedlichen Codebereiche verzweigt.
Wieviele Befehle betrifft das denn überhaupt? Nur mal zum Vergleich, die c't-Redakteure haben die SPECint2000 mit dem Intelcompiler übersetzt, und auf SSE3 optimieren lassen. Bei 9 von 12 Benchmarks wurde SSE3 nicht benutzt.
Ich sehe nicht wirklich den Nachteil von SSE3, den du hier beschreibst. Schon gar nicht kann ich den Vergleich zu 64bit sehen.
Sie lagen aber trotzdem falsch. Nichts anderes ist die Grundaussage. Es wurde damals schön optimistisch der GHz-Wahn verkündet, was sich zu Geld machen lässt. Es ging schief, und musste abgeblasen werden. Die Analystentreffen sind nunmal dazu da, zu schauen, wie man mit dem Unternehmen Geld machen kann, nicht um technische Details zu diskutieren. Entsprechend sehen dann auch die Unterlagen dafür aus. Ich habe noch keine Papers von solchen Treffen gesehen, die nur annähernd die Informationen wie z.B. http://www.chip-architect.com/ oder www.sandpile.org haben.
Belege? Ich will nicht sagen, dass es nicht auf Null hinaus läuft (habe dafür selber keine Messdaten), aber der Speichermehrverbrauch muss irgendwo herkommen. Der Stack wird da seinen Teil dazu beitragen.
Zeiger sind unter x86_64 immer 8Byte groß. Wurde schon mehrfach angesprochen, da das auch ein böser Fallstrick bei Portierungen ist. Ich denke du hast dich mit der Architektur beschäftigt?
Der Punkt dabei ist jedoch, dass unter 32bit die zusätzlichen Register nicht zur Verfügung stehen. Das wird für viele Programmierer Grund sein, auf 64bit zu wechseln, auch wenn diese überhaupt nicht notwendig sind.
Außerdem sind die 64bit halt ein prima Marketing-Instrument. 64bit, das klingt doch gleich viel schneller, zumal es doppelt so viel ist wie 32bit. Damals wurden die Rechner mit dem Umstieg auf 32bit ja auch deutlich schneller. Der MediaMarkt-DAU hat von den technischen Hintergründen ja keine Ahnung, sonder lässt sich das aufschwatzen, was am lautesten und buntesten beworben wird.
Wieviele Desktops benötigen das? Welche Anwendungen benötigen auch nur 1GB an Speicher für sich? Damit wären wir wieder bei der Frage, welcher Nutzer ein DBMS auf seinem Desktop laufen lässt. Spezialanwendungen profitieren davon, wobei man auf das Spezial achten sollte.
Wie schon geschrieben, wie Intel das umsetzen wollte, steht auf einem anderen Blatt. Niemand hindert sie daran, EPIC auch mit 32bit auf den Markt zu bringen.
Mich beschleicht der Verdacht, dass das auch wieder mehr an bunten Papern war, als an den Dev-Guides oder Papern/Vorträgen/Ausarbeitungen von Leuten, die sich damit schon sehr lange beschäftigen. Außerdem fehlt dir offenbar trotzdem noch einiges an Hintergrundwissen. Das Problem dabei ist, dass du nicht bereit bist das zuzugeben, sondern dich auf Polemik versteifst.
Das ist falsch! Es macht einen riesigen Unterschied, ob das RISC- oder CISC-Instruktionen (OpCodes) sind. Je nach Art kann die CPU mehr oder weniger optimieren und hat mehr oder weniger Arbeit (Stichwort Dekoder).
Für den Programmierer macht es sicherlich kaum einen Unterschied, der muss eh nehmen, was er da hat. Schließlich kann der aus einer CISC-CPU nicht mal eben ein RISC-System machen.
Zuletzt bearbeitet:
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ein Beitrag zum Sinn von 64bit:
George Woltman portiert zur Zeit den Trial Factoring Code auf 64bit. Dazu hat er seit langem einen Opteron zur Verfügung, den die Teilnehmer von mersenneforum.org gespendet haben. Er erwartet dabei ca. 100% schnellere Berechnung als mit 32bit.
Das läßt sich in die Schublade "Rechnen mit großen Zahlen" einordnen, wie auch RSA.
George Woltman portiert zur Zeit den Trial Factoring Code auf 64bit. Dazu hat er seit langem einen Opteron zur Verfügung, den die Teilnehmer von mersenneforum.org gespendet haben. Er erwartet dabei ca. 100% schnellere Berechnung als mit 32bit.
Das läßt sich in die Schublade "Rechnen mit großen Zahlen" einordnen, wie auch RSA.
rkinet
Grand Admiral Special
Da ist in x86-64 nichts, was 'zuschlagen kann'.
Wenn man dann später ein Flag zur Abfrage nutzt. Realistischer ist es aber, daß jeweils beim Sub-Programmaufruf die SSE-Art geprüft wird.
Hätte Intel z.B. beim Design der SSE wie bei 68000 einfach OpCodes für 'Future Expansion' frei gelassen, wären die zusätzlichen Befehle einfach per Software implementierbar.
So kostet es zeit zur Abfrage - also wird gelassen.
Genau solche Infos kann man sich direkt aus der x86-64 Architektur zusammenrechnen.
Gibts deutlich Abweichungen, dürfte man den 'Fehler' auch im Code wiederfinden.
Nur, 'Anfängerfehler' der Programmierer oder Compilerbauer als heilige Mehrverbrauchskuh durch Foren jagen zu wollen ist schon abartig.
Genau dies trifft nicht (immer) zu. x86-64 kann 32 Bit PC-relativ adressieren (also +- zum 64 Bit Programmzähler eine signed 32 Bit Zahl dazu addieren). Diese Implementierung ist auch eine der interessantes Details, die zum Charakter einer eher 8-32 Bit lastigen Desktop-CPU paßt. Aber @PuckPoltergeist, diese Info habe ich Dir schon 100 mal gegegeben - nur paßt eben nicht zu Deinem x86-64 Feindbild.
Wirklich speicherlastig sind nur (absichtlich) 64 statt 32 Bit Daten und einige nötige 64 Bit Adressen im Code. Das spielt sich aber im Gesamtcode im einstelligen Prozentbereich ab.
Es geht wegen der Kompatibilität nicht, einfach zusätzliche Register in IA32e zur Verfügung zu stellen. Solche Software würde unter einem 32 Bit OS oder/und einer 32 it-CPU nicht laufen.
Dafür lassen sich aber die 64 Bit Register aber einfach mit 32 Bit Daten füllen.
Man hat also sowohl die Vorteile von mehr Registern und 32 Bit, als auch wahlweise eine höhere 64 Bit Auflösung.
PuckPoltergeist, auch Dir schon Dutzende male erklärt.
Die Summe an Speicherbedarf der aktiven Prozesse ist entscheidend. Und das XP-Limit (ohne PAE) liegt bei typ. 2 GB (logisch: physikalisch + ausgelagert).
Da sieht man ein 'EMM64.EXE' per PAE schon aus der Programmierehölle teuflich lachen ...
Sie machen es aber nicht - so die Plazierung (s. auch Börseninfos) dieser Architektur durch die Firma. Und EPIC steht in starker Konkurrenz zu Multi-Core x86-64, wie ich oben schon aufführte. Bei Dual-Core mag EPIC bei 'IPC' noch vorne liegen, bei noch mehr Cores ersäuft EPIC dann in Cachebedarf und wird vom Bus ausgebremst.
Auch dies schon Dutzende Mal an PuckPoltergeist gesagt - perlt aber an ihm einfach ab.
Die Lieblingsbeschäftigung von PuckPoltergeist:
Etwas Spezialwissen zu verkünden, dann haarstäubendes zum allgemeinen Thema und später noch poltern !
Nachdem ein x86 / x86-64 intern seit Ewigkeiten in (breitem) RISC arbeitet, ist diese These schon peinlich zu nennen. Ärgerlich ist bei x86/-64 CISC die Erstdekodierung der Befehle nach RISC, dafür schont CISC aber die Caches durch verminderten Speicherbedarf.
Die Hauptnachteile von x86 entstehen durch die zu geringe Anzahl an CPU-Registern. Man hat zwar Lösungen im Core dagegen gefunden, nur im OpCode lagern viele unnötige Stack und/oder Speichervorgänge dazu.
x86-64 schafft hier Abhilfe und kann zusätzlich noch die Ingenieurtricks aus der x86-Ära nutzen. In Summe ergeben sich heute noch Performanceverluste im einstelligen Prozentbereich z.B. gegenüber gleich getaktete PowerPC Cores in Standard-Benchmarks.
Ich wiederhole mich, aber PuckPoltergeist hat diese Info auch schon dutzendfach von mir erhalten.
Daher, PuckPoltergeist will mit allen Tricks gegen 64 Bit und x86-64 anpoltern.
Vielleicht weil an seinem Schreibtisch ein EPIC-Schema hängt.
Nur, genau dies perlt an mir eben ab ...
Es ist doch immer und überall das selbe.
@rkinet
Wenn du wirklich AMD64 kennen würdest, dann kannst du ja sicher auch aus dem Stehgreif einen kleinen Abschnitt posten um mal die Vorteile die AMD64 gegenüber IA32 hat zu verdeutlichen (selbstgeschrieben wohlgemerkt, mit passenden Erläuterungen).
Ich könnte das und Puck könnte das sicher auch. Deiner Argumentation nach zu urteilen kannst du das nicht.
@rkinet
Wenn du wirklich AMD64 kennen würdest, dann kannst du ja sicher auch aus dem Stehgreif einen kleinen Abschnitt posten um mal die Vorteile die AMD64 gegenüber IA32 hat zu verdeutlichen (selbstgeschrieben wohlgemerkt, mit passenden Erläuterungen).
Ich könnte das und Puck könnte das sicher auch. Deiner Argumentation nach zu urteilen kannst du das nicht.
rkinet
Grand Admiral Special
Eure Hoffnung, durch Polemik mich hier aus dem Forum zu vertreiben ist vergebens.
Die Vorteile von x86-64 und das zugrundeliegende Design sind so seit 2002 in vielen Artikeln beschrieben worden.
Es sind eure Tagträume, nicht belegbare Infos, die ihr verbreiten wollt.
Sorry, sowas ist unseriös und dient meiner Meinung nach nur dazu, daß ihr euch als PC-Gurus profilieren wollt.
Zur Erinnerung:
Niemand hat heute mehr den kompletten Überblick über alle Aspekte von PC-Hardware oder Software. Daher ist der Versuch, sich als Allroundgenie zu vermarkten und andere mit anderer Meinung zu beschimpfen von Grund auf durchschaubar.
Ich kenne mich aus mit Hardware und auch CPU-Designs.
Und kann daher mit Glaubenskriegen zu 64 Bit, RISC, CISC, EPIC oder ähnlichem schon lange nichts mehr anfangen. Wenn ihr diese blödsinnigen Thesen warm halten wollt, ok. Nur für mich sind die reine Ideologie von Null-Ahnung Ideologen jenseits der realen Siliciumpraxis.
Mir geht es um effektive CPU-Designs und da steht x86-64 heute weit vorne.
Daß PowerPC auch gut ist, habe ich Cell-Beitrag auch schon aufgeführt. Nur, es ist unsinnig für 5% mehr an Performance die ganze x86-Software zu shreddern oder per Emulator mit max. 1/3 der Performance laufen zu lassen, nur weil man CISC nicht begreifen will.
Oder 2010 mit gleicher Performance auf eine EPIC-Monster zu plazieren.
AMD, Intel & Microsoft haben den richtigen Weg bei 64 Bit gefunden. Und MS hat diesmal (nicht wie in der EMM386.EXE-Ära) rechtzeitig sich um den nächsten Schritt gekümmert, bevor die ersten Einschränkungen der 32 Bit CPUs zum Vorschein kommen.
Wer das Chaos bei 16/32 Bit kennt, kann hier nur froh sein, daß sich dies nicht noch einmal wiederholt.
Wenn du Ahnung hättest, würdest du einfach irgendein Beispiel bringen und gut ist - das wäre die beste Entgegnung auf meine Frage die du bringen könntest, und auch die überzeugendste.
Aber nein, da wird wieder lamentiert was das Zeug hält. Sprich du willst dich eigentlich profilieren und weichst konkreten Fragen aus... wie immer also.
rkinet
Grand Admiral Special
Dieser Beitrag ist Nr.169 zum Thema 'Sinn und Unsinn von 64 Bit'.
Meines Eindruckes nach in in den vielen Beiträgen eigentlich alles schon gefallen.
In Summe stehen Horrormärchen über 64 Bit realen Benchmarks recht inkompatibel gegenüber.
Die Gründe gegen 64 Bit sind alle widerlegt und der Markt entwickelt sich 2005 in Richtung 64 Bit.
Juni'05 gibts sogar Nero in 64 Bit (http://www.computerbase.de/news/software/brennprogramme/2005/maerz/nero_nerolinux_64-bit-version/).
Gerade an Nero arbeiten hardwarenah denkende Programmierer, die eben genau wissen, was sie mit 64 Bit sich an Problemen aufladen könnten ... eben Null.
Somit ist heute der größte Unsinn zu 64 Bit die Frage 'Sinn und Unsinn von 64 Bit'.
PuckPoltergeist
Grand Admiral Special
Hm, dann bilde ich mir den dreifachen Speicherverbrauch von firefox wohl nur ein? Oder ist das gar ein Bug bei mir im Linuxkernel, welcher den Verbrauch falsch anzeigt? Nein, kann eigentlich nicht sein. Wenn das nur falsch angezeigt würde, hätte die Kiste mit 512MB RAM beim Umstieg auf 64bit nicht so extrem zu swappen angefangen. Muss wohl doch meine Einbildung sein.
Das ist extrem schlechter Programmierstil. Der Intel-Compiler setzt die Abfrage auch zu Beginn des Programms, und nicht an jede Nutzung. Zugegeben, das Compilat verweigert dann aber auch die Arbeit, so kein SSE3 vorhanden.
Auf x86 sind noch jede Menge OpCodes frei. Die haben nur den Nachteil, dass sie jetzt lang werden.
Kann man, wenn man Ahnung von der Materie hat, und auch wirklich alle Dokumente liest.
edit:
Eigentlich kann man das nicht. Das ist ja von Programm zu Programm unterschiedlich, je nachdem, was für Datentypen in welcher Menge verwendet werden.
Sprich, man müßte das für jedes Programm extra machen, bzw. das irgendwo mal mitteln. Nur, nach welchen Kriterien sollte das gemittelt werden?
/edit
http://www.x86-64.org/documentation/abi-0.95.pdf
Seite 12
Hast du dich nun mit x86_64 beschäftigt, oder nicht?
Mal davon abgesehen schmeißt du hier verscheidene Dinge durcheinander. RIP != Pointer in Programmiersprachen. Außerdem ist der RIP im long-mode 64bit.
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf
Seite 56
Wieso geht das nicht? Es wäre "nur" ein zusätzlicher 32bit-mode notwendig, ähnlich den 64bit.
Das bestreite ich auch gar nicht.
Womit wir wieder bei der Frage sind, wer braucht das? Ein 4GB großer virtueller Adressraum ist da noch immer nützlicher, und selbst der wird nicht wirklich benötigt.
Das ist eine Eigenschaft von RISC, und offensichtlich auch nicht wirklich hinderlich (siehe Power).
Sag mal, hast du überhaupt eine Ahnung, wovon du hier sprichst? Meine These ist peinlich, aber im gleichen Atemzug bestätigst du sie?
links?
Nein, ich frage nur, welchen Sinn 64bit auf dem Desktop macht. Offenbar bist du nicht in der Lage, diese Frage zu beantworten.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Wo? Ich sehe nichts dergleichen. Hier sind von dir lediglich durcheinander gewürfelte Aussagen gekommen, die zusammen keinen Sinn ergeben oder teilweise schlicht falsch sind.
dualXPlosion
Lt. Commander
- Mitglied seit
- 15.02.2005
- Beiträge
- 104
- Renomée
- 2
oha , welch geistig verwirrtes Kind bist du denn ? Ich hab mir mal den querschnitt deiner Postings hier im Forum angeguckt und es fällt einem auf das du echt ALLES weißt !! Du bist sozusagen allwissend. Du bist Manager , Techniker , Forscher und Analyst in einer Person , kennst die internas von Intel und AMD wie deine eigene Westentasche, und wenn mich nicht alles täuscht, bist du der Erfinder der IT-Welt. Was zum Henker machst du beruflich ? Du bist für so ziemlich jeden Beruf überqualifiziert.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ich versuche hiermit, in diesen langsam zumüllenden Thread wieder etwas sachliches einzubringen:
Ein älteres Win 64-Review:
http://www.anandtech.com/systems/showdoc.aspx?i=1961&p=4
Mich machte nur stutzig, daß der DivX-Encoder, obwohl immernoch die selbe 32bit-Software (siehe Beschreibung auf der Seite) 15,5% schneller ist.
Der Kommentar:
Die Spielebenchmarks zeigten in dem über 12 Monate alten Review noch starke Rückstände mangels guter DirectX-Implementation.
Ein älteres Win 64-Review:
http://www.anandtech.com/systems/showdoc.aspx?i=1961&p=4
Mich machte nur stutzig, daß der DivX-Encoder, obwohl immernoch die selbe 32bit-Software (siehe Beschreibung auf der Seite) 15,5% schneller ist.
Der Kommentar:
Die Spielebenchmarks zeigten in dem über 12 Monate alten Review noch starke Rückstände mangels guter DirectX-Implementation.
Ähnliche Themen
