Archiv verlassen und diese Seite im Standarddesign anzeigen : Intels neues 64 bit nicht AMD64 Kompatibel
jau titel sagts schon
was ist den da genau das problem?
nur stepping?
oder haben sie einen andere umsetzung genommen, also kein bug?
Es ist 99% kompatibel. Die Inkompatibilität geht eigentlich nur das System was an, somit dürften da keine großen Probleme auftreten für die Benutzer.
Das größte Problem für das OS ist, dass Intel keien IOMMU zur Verfügung stellt, wodurch mehr als 4GB RAM ziemlich langsam werden können.
gbm31
2004-06-30, 08:50:40
ich frage mich, was intel zu diesem schritt bewegt hat.
wozu 64bit, wenns doch wieder an an den 4gb hängenbleibt?
oder eher ne kleine strategie nach dem motto: schaut, jetzt haben wir den amd-salat implementiert, und es läuft nicht gut. unser eigenes 64bit-süppchen ist doch viel besser...
[gehört vieleicht eber ins speku-forum]
Original geschrieben von gbm31
ich frage mich, was intel zu diesem schritt bewegt hat.
wozu 64bit, wenns doch wieder an an den 4gb hängenbleibt?
oder eher ne kleine strategie nach dem motto: schaut, jetzt haben wir den amd-salat implementiert, und es läuft nicht gut. unser eigenes 64bit-süppchen ist doch viel besser...
[gehört vieleicht eber ins speku-forum] ne das gehört hier rein steht heute ja auch in den news.
ich wollte ja wissen ob es ein technologisches prob bei intel ist, vielleicht wissen zecki oder demi was darüber.
Original geschrieben von Coda
Es ist 99% kompatibel. Die Inkompatibilität geht eigentlich nur das System was an, somit dürften da keine großen Probleme auftreten für die Benutzer.
Das größte Problem für das OS ist, dass Intel keien IOMMU zur Verfügung stellt, wodurch mehr als 4GB RAM ziemlich langsam werden können. na super!
Aber könnte ja sein das ms eine geniue amd abfrage drin hatt :embara: das währe mal ein hammer;)
das mit geht nur dem sys was an kannst du das mal verdeutlichen?
Danke
gbm31
2004-06-30, 12:50:07
Original geschrieben von Gast
ne das gehört hier rein steht heute ja auch in den news.
das hier:
Original geschrieben von gbm31
oder eher ne kleine strategie nach dem motto: schaut, jetzt haben wir den amd-salat implementiert, und es läuft nicht gut. unser eigenes 64bit-süppchen ist doch viel besser...
meinte ich gehört ins speku.
Es geht ja nicht nur um mehr als 4GB RAM, auch der virtuelle Raum wird ja größer, also wird man es bei Speicherallokationen sehr viel einfacher haben größere freie Blöcke zu finden, außerdem ist dann Fragmentierung praktisch egal (bei 2^64 is genügend Platz :D).
Derzeit kann man ja nur 2GB je Thread überhaupt benützen unter Windows, weil der Rest fürs OS eingeblendet wird.
Tigerchen
2004-06-30, 13:41:01
Original geschrieben von Coda
Es geht ja nicht nur um mehr als 4GB RAM, auch der virtuelle Raum wird ja größer, also wird man es bei Speicherallokationen sehr viel einfacher haben größere freie Blöcke zu finden, außerdem ist dann Fragmentierung praktisch egal (bei 2^64 is genügend Platz :D).
Derzeit kann man ja nur 2GB je Thread überhaupt benützen unter Windows, weil der Rest fürs OS eingeblendet wird.
Bleibt die Frage was das soll. Unvermögen oder Böswilligkeit gegenüber dem kleinen Konkurrenten?
Für richtigen 64Bit-Support avisiert Intel immer noch die Intanium-Reihe.
Mal was anderes, gibt es schon irgendwelche Benches, die zeigen wie langsam/schnell Intels 32e im Vergleich zu AMD64 ist?
Original geschrieben von Zool
Für richtigen 64Bit-Support avisiert Intel immer noch die Intanium-Reihe.
Mal was anderes, gibt es schon irgendwelche Benches, die zeigen wie langsam/schnell Intels 32e im Vergleich zu AMD64 ist? nö weil die 64 bit erweiterung von intel nich gangbar ist.
GloomY
2004-06-30, 20:14:15
Original geschrieben von Gast
na super!
Aber könnte ja sein das ms eine geniue amd abfrage drin hatt :embara: das währe mal ein hammer;)
das mit geht nur dem sys was an kannst du das mal verdeutlichen?
Danke Von hier (http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release-notes/as-amd64/RELEASE-NOTES-U2-x86_64-en.html):
Software IOTLB — Intel® EM64T does not support an IOMMU in hardware while AMD64 processors do. This means that physical addresses above 4GB (32 bits) cannot reliably be the source or destination of DMA operations. Therefore, the Red Hat Enterprise Linux 3 Update 2 kernel "bounces" all DMA operations to or from physical addresses above 4GB to buffers that the kernel pre-allocated below 4GB at boot time. This is likely to result in lower performance for IO-intensive workloads for Intel® EM64T as compared to AMD64 processors.
Original geschrieben von GloomY
Von hier (http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release-notes/as-amd64/RELEASE-NOTES-U2-x86_64-en.html):
jo ist schon älter, aber danke.
bin nur verwirrt warum es erst jetzt ans tageslicht kommt. Vorallem weil win64 ja nicht als endkunden version kommen soll.
nja egal solange es keine dsp sondern nur oem wird kann sie ja jeder im fachhandel kaufen.
Aqualon
2004-07-01, 00:15:25
Original geschrieben von Zool
Mal was anderes, gibt es schon irgendwelche Benches, die zeigen wie langsam/schnell Intels 32e im Vergleich zu AMD64 ist?
Ja, in der c't 14/04 auf Seite 17.
Unter Suse Linux 64Bit traten ein 2x Opteron 248 (2.2GHz) und ein 2x 3.4GHz Xeon FSB800 gegeneinander an.
Bei SPEC CINT2000_rate_base gewann der Opteron mit 27,9 zu 22,8 und bei SPEC CFP2000_rate_base gewann ebenfalls der Opteron mit 30,9 zu 22,0.
Zum Vergleich: Ein 2x 3.6GHz Xeon FSB800 unter Windows XP 32Bit kommt auf 30,1 bzw. 23,7 währenddessen ein 2x Opteron 250 (2.4GHz) ebenfalls unter XP auf 33,5 und 28,5 kommt.
Differenz Windows XP Opteron - Xeon
CINT2000_rate_base 11,3%
CFP2000_rate_base 19,4%
Differenz Linux 64Bit Opteron - Xeon
CINT2000_rate_base 22,4%
CFP2000_rate_base 40,5%
Die Werte sind wegen der unterschiedlichen Systeme nicht 100%ig vergleichbar und es kam für 64Bit auch kein optimierter Intel-Compiler zum Einsatz, da dieser noch im Beta-Stadium war und die SPEC-Suite nicht kompilieren wollte.
Compiler XP 32Bit: Intel Compiler 8.0 für C/C++ und Fortran.
Compiler Linux 64Bit: Suse GCC 3.3 für CINT2000 und PGI-5.1 für CFP2000.
Kompatibilitäts-Probleme traten keine auf, d.h. sowohl der Opteron als auch der Xeon wurden mit denselben Binärdateien getestet.
Auf jedenfall hat Intel noch aufzuholen, wenn es um 64Bit Performance geht. Mal schauen, was der finale Intel-Compiler noch verändern kann.
Aqua
saaya
2004-07-04, 00:04:57
Original geschrieben von Coda
Es ist 99% kompatibel. Die Inkompatibilität geht eigentlich nur das System was an, somit dürften da keine großen Probleme auftreten für die Benutzer.
Das größte Problem für das OS ist, dass Intel keien IOMMU zur Verfügung stellt, wodurch mehr als 4GB RAM ziemlich langsam werden können.
99% sind nicht die 100% von denen intel gesprochen hat.
1% inkompabilität kann n riesen unterschied machen wenn es ernste unterscheide sind. so weit ich weiss emuliert die cpu intern einige funktionen die sie nicht hardwaremässig unterstützt, ist also keine echte 64bit cpu sondern eine 32bit cpu die auch(!) 64bit code verarbeiten kann.
BlackBirdSR
2004-07-04, 00:38:52
Original geschrieben von saaya
99% sind nicht die 100% von denen intel gesprochen hat.
1% inkompabilität kann n riesen unterschied machen wenn es ernste unterscheide sind. so weit ich weiss emuliert die cpu intern einige funktionen die sie nicht hardwaremässig unterstützt, ist also keine echte 64bit cpu sondern eine 32bit cpu die auch(!) 64bit code verarbeiten kann.
huh, was ist eine echte 64Bit CPU?
Nein im Ernst.
würde eine CPU mit 2x32Bit ALUs und 64Bit Registern als 64Bit durchgehen?
Ist ja immernoch nicht geklärt, wie die ALUs von Nacona jetzt funktionieren.
saaya
2004-07-04, 00:57:26
meiner meinung nach ist es keine 64bit cpu, da sie eben intern die 64bit in 2x32bit verarbeitet, das sie deswegen in vielen fällen super lahm ist is intels problem, aber wenn sie nichtmal mehr als 4-6gb unterstützt und die extra 64bit register langsamer sind als wenn man 32bit register benutzt und nicht schneller wie beim a64, dann kann man doch wirklich nicht mehr von ner "echten" 64bit cpu reden!
eine cpu die alle vorteile die eine 64bit cpu mit sich bringt nicht unterstützt ist doch keine 64bit cpu...
es ist ne 32bit cpu die AUCH 64bit rechnen kann, aber nur über umwege und emulation.
BlackBirdSR
2004-07-04, 01:06:36
Original geschrieben von saaya
meiner meinung nach ist es keine 64bit cpu, da sie eben intern die 64bit in 2x32bit verarbeitet, das sie deswegen in vielen fällen super lahm ist is intels problem, aber wenn sie nichtmal mehr als 4-6gb unterstützt und die extra 64bit register langsamer sind als wenn man 32bit register benutzt und nicht schneller wie beim a64, dann kann man doch wirklich nicht mehr von ner "echten" 64bit cpu reden!
eine cpu die alle vorteile die eine 64bit cpu mit sich bringt nicht unterstützt ist doch keine 64bit cpu...
es ist ne 32bit cpu die AUCH 64bit rechnen kann, aber nur über umwege und emulation.
hmm jetzt wirds aber happig.
Wo steht dass die CPU super lahm ist im 64Bit Modus?
WO steht, dass man nicht mehr als 4GB unterstützt?
Wo steht dass die 64Bit Register langsamer sind?
Ok, zum klarstellen:
Nocona KANN mehr als 4GB Speicher addressieren, das ist gar keine Frage.
Was die Northbridge aber nicht hat ist eine IOMMU, die es bei 32-bit PCI Karten ermöglicht die Buffer in höhere Speicherbereiche zu legen.
Bei Linux wird das jetzt mit umkopieren gelöst, was langsamer ist.
Das hat aber nix mit Inkompatibilität zu tun, sondern ist eher ein Chipsatzproblem
saaya
2004-07-04, 08:36:27
Original geschrieben von BlackBirdSR
hmm jetzt wirds aber happig.
Wo steht dass die CPU super lahm ist im 64Bit Modus?
WO steht, dass man nicht mehr als 4GB unterstützt?
Wo steht dass die 64Bit Register langsamer sind?
NOCH steht das nirgends als in emails ;)
:D
und ja, nocona KANN mehr als 4Gb addressieren, aber benutzen die nicht den gleichen trick wie beim xeon?
is nich das gleiche wie beim A64, oder doch? bin mir jetzt auh nicht so sicher... ich glaub ich bring den mit dem gallatin durcheinander ?-) :lol:
Wenn Nocona die gleiche Technik wie die Xeons nutzt, kann es sich eigentlich nur um das üble PAE handeln. Ist eigentlich auch nur ne Krücke und erinnert sehr stark an das alte Page-Swapping von Himem und EMM.
zeckensack
2004-07-04, 09:36:17
Wenn Nocona PAE benutzen müsste, um mehr als 4GiB zu addressieren, dann wäre er nicht AMD64-kompatibel. Und zwar nicht nur DMA-verklemmt, sondern absolut, definitiv, total nutzlos inkompatibel.
Das kann man IMO direkt ausschliessen.
GloomY
2004-07-04, 14:42:50
Nochmal was zu PAE: Dies erweitert den physikalischen Adressraum auf 36 Bit. Der virtuelle Adressraum bleibt für jeden Prozess aber weiterhin bei 4 GiB. Eine lineare Adressierung für mehr als 4 GiB Speicher ist damit also nicht möglich.
Bei x86-64 (und Intels Abkömmling) kann man locker 1 Terrabyte linear adressieren, ohne Paging wie bei PAE. Dass das Paging langsam ist, sollte jedem klar sein, denn es müssen ja in den Adressraum unter 4 GiB immer wieder die Daten in die vorgesehenen Fenster reinkopiert werden, die überhalb der 4GiB Grenze liegen. Sollten die benötigten Daten nicht in dem (den) Fenster(n) liegen, so muss das aktuelle Fenster zurückkopiert werden und die Inhalte aus einem anderen Bereich überhalb von 4 GiB werden in das Fenster reinkopiert.
Bei zufälligen Zugriffsmustern wird dort eine Unmenge an Speicherkopier-Aktionen fällig, was die Performance ziemlich nach unten ziegt. Schneller als eine Festplatte ist es aber dennoch, also kann PAE in einzelnen Fällen (Cache für HDD) doch noch seine Berechtigung haben. Für eine generelle Adressierungsmethode ist es aber nicht nur zu langsam sondern auch viel zu kompliziert gegenüber linearer Adressierung.
saaya
2004-07-04, 17:04:30
das problem ist das der nocona ,anders als der a64/opteron , keinen hardware support für "iommu" hat sondern bounce buffer benutzt werden müssen. iommu muss beim nocona vom OS emuliert werden, ansonsten geht nüscht. keins der derzeitigen OS unterstützt dieses feature , win xp-64 genauso wenig with knoppix64 oder server2003 64bit edition(offiziell ja, aber laut MS wird der support für emt-64 erst später integriert)
ohne hardware und ohne ein os was iommu emuliert ,können nicht mehr als 4gb addressiert werden. wenn man versucht eins der 64bit OS zu installieren gibts immer n fehler oder der install schmiert ab.
na sauber intel :asshole:
kann mir jemand erklären was jetzt bitte der unterschied von pae un iommu is?
also für mich hört sich iommu nach pae 2.0 an, was jetzt auch 64bit an stelle von vorher nur 36bit addressierung unterstützt.
BlackBirdSR
2004-07-04, 23:42:43
[B]kann mir jemand erklären was jetzt bitte der unterschied von pae un iommu is?
also für mich hört sich iommu nach pae 2.0 an, was jetzt auch 64bit an stelle von vorher nur 36bit addressierung unterstützt.
Das eine hat mit DMA Operationen zu tun und nicht mit einer 4GB Hauptspeichergrenze, das Andere mit der Adressierung des Hauptspeichers von der CPU aus.
BlackBirdSR
2004-07-04, 23:43:21
null
saaya
2004-07-05, 04:49:37
Original geschrieben von BlackBirdSR
null
null was? :D
kann mir jemand erklären was jetzt bitte der unterschied von pae un iommu is?
also für mich hört sich iommu nach pae 2.0 an, was jetzt auch 64bit an stelle von vorher nur 36bit addressierung unterstützt.
Nein, nein und nochmals nein.
Das sind zwei komplett verschiedene Dinge. PAE ist ein Feature der CPU und nicht des Chipsatzes. Die IOMMU (Input/Output Memory Managment Unit) ist eben dafür zuständig I/O Geräten die nur 32 bit addressieren können zu "helfen". Es ist nur so das die PCI Geräte ohne IOMMU ihre Buffer nicht in >4GB legen können, sonst gibt es keine weiteren Einschränkungen.
Nocona kann definitiv über 4GB RAM addressieren (und tut es auch)
Wie gesagt das ist eher ein "Chipsatzproblem". Intel könnte ihren AGP Gart wohl ähnlich modifizieren, müsste bis zum nächsten Chipsatz auch geschehen sein.
saaya
2004-07-05, 09:40:27
Original geschrieben von Coda
Nein, nein und nochmals nein.
wow wow, SORRY das ich gefragt hab, lol, ihr seit alle ziemlich gereizt hier hab ich den eindruck :lol:
Original geschrieben von Coda
Das sind zwei komplett verschiedene Dinge. PAE ist ein Feature der CPU und nicht des Chipsatzes. Die IOMMU (Input/Output Memory Managment Unit) ist eben dafür zuständig I/O Geräten die nur 32 bit addressieren können zu "helfen". Es ist nur so das die PCI Geräte ohne IOMMU ihre Buffer nicht in >4GB legen können, sonst gibt es keine weiteren Einschränkungen.
Nocona kann definitiv über 4GB RAM addressieren (und tut es auch)
Wie gesagt das ist eher ein "Chipsatzproblem". Intel könnte ihren AGP Gart wohl ähnlich modifizieren, müsste bis zum nächsten Chipsatz auch geschehen sein.
super! danke für die erklährung! :D :bier:
BlackBirdSR
2004-07-05, 10:13:05
Original geschrieben von saaya
wow wow, SORRY das ich gefragt hab, lol, ihr seit alle ziemlich gereizt hier hab ich den eindruck :lol:
Liegt nicht direkt an dir, keine Sorge.
Es ist vielmehr, dass viele Seiten sich auf solche Meldungen wie Haie auf verwundete Fische stürtzen.
Da wird munter drauflos gelabert, man liest irgendwas von 4GB nicht möglich, und der umgebende Rest ist dann völlig egal.
Schon steht die Sensationsmeldung, mehr als 4GB bei Intel nicht möglich.
Die Seiten, sie das wenigstens noch schreben, werden Opfer der eigeninitiative der User.
Entweder überlesen sie selbst den wichtigen Teil, oder basteln sich aus diversen Meldungen ihre eigene Wahrheit.
Das ist prinzipiell zwar zu wünschen, aber nicht bei so technischen Sachen.
Im Endeffekt, gibt es jetzt in nahezu jedem Harwareforum unzählige User die rumlaufen und posten, dass Intel nicht mehr als 4GB Speicher mit EMT64 nutzen kann.
Nach dem 15. Mal Verbessern hat man dann einfach die Nase voll. Das ist alles ;)
mrdigital
2004-07-05, 10:39:52
Original geschrieben von GloomY
Nochmal was zu PAE:
...
Sollten die benötigten Daten nicht in dem (den) Fenster(n) liegen, so muss das aktuelle Fenster zurückkopiert werden und die Inhalte aus einem anderen Bereich überhalb von 4 GiB werden in das Fenster reinkopiert.
...
Muss wirklich der Inhalt von >4GiB in ein Fenster <4GiB umkopiert werden? Oder wird eben die MMU in der CPU in einen "Translationsmodus" versetzt, d.h. die oberen 4 Adressbits werden über einen "Trick" gesetzt (was auch Zeit kostet aber nicht so schlimm wäre wie umkopieren)?
saaya
2004-07-05, 14:08:53
Original geschrieben von BlackBirdSR
Liegt nicht direkt an dir, keine Sorge.
Es ist vielmehr, dass viele Seiten sich auf solche Meldungen wie Haie auf verwundete Fische stürtzen.
Da wird munter drauflos gelabert, man liest irgendwas von 4GB nicht möglich, und der umgebende Rest ist dann völlig egal.
Schon steht die Sensationsmeldung, mehr als 4GB bei Intel nicht möglich.
Die Seiten, sie das wenigstens noch schreben, werden Opfer der eigeninitiative der User.
Entweder überlesen sie selbst den wichtigen Teil, oder basteln sich aus diversen Meldungen ihre eigene Wahrheit.
Das ist prinzipiell zwar zu wünschen, aber nicht bei so technischen Sachen.
Im Endeffekt, gibt es jetzt in nahezu jedem Harwareforum unzählige User die rumlaufen und posten, dass Intel nicht mehr als 4GB Speicher mit EMT64 nutzen kann.
Nach dem 15. Mal Verbessern hat man dann einfach die Nase voll. Das ist alles ;)
hahaha, ja dass kenn ich auch. jetzt nicht unbedingt von microcode und cpu funktionen mit denen ich mich wirklich kaum auskenne, aber von anderen themen.
also ich poste dann einfach immer nur nen link zu der post in der ich das schonmal erklärt habe :)
spart zeit und mühre :)
GloomY
2004-07-05, 15:35:41
Original geschrieben von mrdigital
Muss wirklich der Inhalt von >4GiB in ein Fenster <4GiB umkopiert werden? Oder wird eben die MMU in der CPU in einen "Translationsmodus" versetzt, d.h. die oberen 4 Adressbits werden über einen "Trick" gesetzt (was auch Zeit kostet aber nicht so schlimm wäre wie umkopieren)? Darüber habe ich lange nachgedacht und gegoogelt, aber ohne Erfolg. Über die MMU könnte man das natürlich sehr viel effizienter lösen. Wenn man einen Speicherbereich > 4GiB ansprechen will und dieser nicht im momentanen Fenster befindet, ruft man mit den entsprechenden Parametern die OS API auf (unter Windows die Address Windowing Extensions (AWE) API), die einfach nur den Eintrag in der (36 Bit) MMU ändert, so dass der virtuelle Speicherbereich des Fensters auf den gewünschten physikalischen Speicherbereich gemappt wird.
Als Overhead gegenüber linearer Adressierung hätte man dann nur noch die API Aufrufe und kein Umherkopieren mehr :)
edit: Ich war wohl mit meiner Sichtweise zu sehr darauf fixiert, was die Applikation "sieht". Und dort sieht es wirklich danach aus, als ob der Inhalt des Speichers immer wieder in das Fenster reinkopiert wird...
mrdigital
2004-07-05, 19:50:29
ja die App greift immer auf das selbe Fenster zu, aber der Inhalt des Fensters ändert sich halt und dieses Fenster zeigt nach irgendwo >4GiB. Also wie in good old DOS times mit EMS. Aber das geht ja wirklich ohne umkopieren. Wie gross können denn die Fenster sein?
zeckensack
2004-07-05, 20:02:59
Original geschrieben von GloomY
Darüber habe ich lange nachgedacht und gegoogelt, aber ohne Erfolg. Über die MMU könnte man das natürlich sehr viel effizienter lösen. Wenn man einen Speicherbereich > 4GiB ansprechen will und dieser nicht im momentanen Fenster befindet, ruft man mit den entsprechenden Parametern die OS API auf (unter Windows die Address Windowing Extensions (AWE) API), die einfach nur den Eintrag in der (36 Bit) MMU ändert, so dass der virtuelle Speicherbereich des Fensters auf den gewünschten physikalischen Speicherbereich gemappt wird.
Als Overhead gegenüber linearer Adressierung hätte man dann nur noch die API Aufrufe und kein Umherkopieren mehr :)
edit: Ich war wohl mit meiner Sichtweise zu sehr darauf fixiert, was die Applikation "sieht". Und dort sieht es wirklich danach aus, als ob der Inhalt des Speichers immer wieder in das Fenster reinkopiert wird... Der Sinn und Zweck einer MMU ist es doch gerade, auch die API-Aufrufe zu eliminieren, sodass das ganze für die Applikation transparent wird.
Wenn der gerade "gemappte" Speicherbereich die benötigten Daten nicht enthält, wirft der Prozessor eine Exception, die wiederum wird vom OS aufgefangen, und dort wird dann veranlasst das der benötigte Speicher eingeblendet wird. Von all dem kriegt die Applikation nichts mit (was gut ist, denn sie muss darauf keine Rücksicht nehmen).
Die IOMMU macht im Prinzip genau das gleiche, nur eben für DMA-Puffer, und erstmal ohne OS-Intervention. Eine Exception wird nur dann ausgelöst, wenn der Zielort für den Transfer auf die Festplatte ausgelagert wurde. Auch dies kann dann vom OS (bzw dem passenden Treiber für den DMA-Controller) abgefangen und korrigiert werden.
Umkopieraktionen sind nicht nötig. Die DMA-Transfers werden einfach "on the fly" an die richtige virtuelle Zieladresse "umgelenkt".
Ohne die IOMMU kann ein 32 Bit-Busmaster nicht in einen Speicherbereich schreiben, der eine (virtuelle) Adresse >4GiB hat, selbst wenn dieser Speicher aktuell "eingeblendet", und damit physikalisch sofort ansprechbar ist.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.