Re: NVidia GF GTX 280 vs. ATI Radeon HD4870 X2

Am 26 Nov 2008 03:47:43 GMT schrieb Joseph Terner:

Dirk Wolfgang Glomp wrote:
Am 25 Nov 2008 23:51:19 GMT schrieb Joseph Terner:
Dirk Wolfgang Glomp wrote:
Am 25 Nov 2008 16:38:06 GMT schrieb Joseph Terner:
Dirk Wolfgang Glomp wrote:
Am 24 Nov 2008 12:45:36 GMT schrieb Joseph Terner:
Dirk Wolfgang Glomp wrote:
Am Mon, 24 Nov 2008 06:13:18 +0000 schrieb Benjamin Gawert:
* Dirk Wolfgang Glomp:

Kann ich mir nicht denken. Im 64Bit-Mode müllt der L1+L2-cache noch
schneller voll

Nein.
[...]
Natürlich gibt es auch für mich noch Vieles zu lernen, aber mit dieser
speziellen Art deiner häufig anzutreffenden Behauptung ich hätte wieder
einmal in so einem offensichtlich eindeutig erkennbaren Sachverhalt
etwas nicht verstanden, machst du dich langsan aber sicher zum Trottel.
[...]
Nix Unsinn, du bist entweder total bescheuert oder leidest unter einem
enormen Minderwertigkeitskomplex. Bist du so blöd, oder kannst du nicht
halbieren?

/* No comment */

Huch was ist denn mit dir los, hat es dir dir Sprache verschlagen?

Daten (Text, Pixel, Audio-Samples, whatever) sind nicht
plötzlich halb so groß, weil sie nicht auf einem 64-Bit-System
verarbeitet werden.

Ja und was haben krümelige Kekse mit einem 64Bit-Pointer zu tun,
ja gar nichts ebensowenig wie deine Audio-Samples auf der CD.
Mit derartigen Kaspereien kannst du vieleicht deine Oma beglücken,
dem aufmerksamen Leser wirst du jedoch kein X zum U machen.

Außer Zeigern wird nichts größer im Long Mode.

Ja und wie ist es mit 64Bit immidiate Operanden?

Und Zeiger als
Selbstzweck haben die wenigsten datenverarbeitenden Programme.

Ach du bist ja lustig.

Programmcode und Nutzdaten füllen hauptsächlich den Cache.

Hahaha, ja was denn sonst?

Der Rest bleibt bei LLP64 ja 32 Bit.

Letzendlich müllt der 64Bit-Mode den Cache mehr voll und bremst somit die
gesamte Ausführung schon etwas mehr aus bei gleicher Cachegröße, wenn der
gewünschte Zugriff auf den betreffenden Code, oder die Daten sich nicht
mehr im Cache befinden. Das ist zwar auch im 32Bit-Mode so, doch es ist
ja wohl offensichtlich das doppelt so große Pointer, 64Bit-Daten und
nicht zu vergessen auch 64Bit große immidiate Operanden den Cache
zwangsläufig schneller füllen.

Daß Du keine blasse Ahnung von AMD64-Assembler hast, hast Du hiermit
unter Beweis gestellt.

Ich brauche hier allerdings gar nichts beweisen, aber jetzt verate uns doch
mal ganz schnell was dieser Umstand mit dem Cache moderner 64-Bitter
zu tun hat. Wenn du keine Argumente mehr hast fängst du an rumzunölen und
mit fadenscheinigen Unsinn vom Thema abzulenken.

Nagut, wenn Du darauf insistierst, bloßgestellt zu werden:

|In 64-bit mode, immediates and displacements are generally only 32 bits
|wide. NASM will therefore truncate most displacements and immediates to
|32 bits.

Ja schön dann zeige doch mal wie ein 0FFFFFFFFFFFFFFFFh zum 32Bit-Wert
wird.

|The only instruction which takes a full 64-bit immediate is:
|
| MOV reg64,imm64

Ja sag ich ja, neben den 64bit-Pointer müllen 64-bit immediate Operanden
den Cache weit aus schneller voll als 32bit-Pointer und 32-bit immediate
Operanden.

<http://www.nasm.us/doc/nasmdo11.html>

Und selbst diesen Opcode (7 oder 10 Byte lang) braucht man nur dann,
wenn der Immediate tatsächlich größer als 32 Bit ist, sonst nimmt man
das ganz normale 5 Byte lange MOV reg32,imm32.

Ja logisch.

Damit ist »64-Bit-Code müllt den Cache zu« abschließend abgehandelt.

Ja der Cache wird schneller vollgemüllt und dein Widerspruch ging
hier vollends in die Hose und damit hast du dich jetzt selber
bloßgestellt. Aber warum du das tust hast du uns noch nicht veraten.

Das
Problem existiert in der realen Welt nicht, weil es sowohl beim
Entwerfer als auch bei den Verwendern von x86_64 nicht an Clue mangelt.

Du bist echt ein Spinner.

Und welchen reinen AMD64-Assembler benutzt du denn gewöhnlich
(gibt es so etwas überhaupt)?

<http://www.gnu.org/software/binutils/>
<http://www.nasm.us/>
<http://www.tortall.net/projects/yasm/>

x86_64 hat ja nun schon ein paar Jahre auf dem Buckel und ist heute
ungefähr so neu wie der 80386 bei Erscheinen des Intel Pentium.

Ja war wohl auch nichts mit deinem angeblichen AMD64-Assembler,
denn ebenso kann man damit für Intel-CPUs Programme erzeugen.

und nur wenn mehr als 4GB Arbeitsspeicher vorhanden sind,
macht der 64Bit-Mode überhaupt erst wirklich Sinn.

Auch falsch. Ein 64bit-OS macht sich schon mit 4GB positiv bemerkbar

Wo denn genau?

(immerhin sind dann die kompletten 4GB verfügbar),

Ist das nicht auch schon mit dem 32Bit-Mode möglich?

Nein, da sind es je nach Hardware 2 bis 3,5 GiB.

Aber mit PAE die vollen 4GB.

PAE ist kein »32Bit-Mode«, sondern ein 36-Bit-Mode.

Huch, gibt es denn auch einen 20Bit-Mode, falls mmn im 16Bit-PM
PAE verwenden möchte?

Du kannst im 16Bit-PM kein PAE verwenden.

Das bezweifel ich, ich bezweifel auch langsam das du den Unterschied
zwischen dem 32Bit-Mode und dem 16-Bit-Mode schon begriffen hast.

Der 80286 kann 16 MiB (24 Bit) adressieren. Andere x86-CPUs haben keinen
16Bit-PM.

Wer hat dir denn diesen Nonnsen erzählt?

Na logisch kann man auch mit einem modernen 64Bitter in den PM schalten
und den 16Bit-Adressmode verwenden. Nun sehe ich meine Zweifel das du
immer noch nicht den Unterschied zwischen den 32Bit und 16Bit-Mode
verstanden hast bestätigt. Mann o Mann du brichst dir hier aber
ein Zacken nach dem anderen aus der Krone.

und auch mit 2GB kann
es durchaus Sinn machen, denn gerade bei Vista kommt die 64bit-Version
mit zusätzlichen Goodies (höhere Sicherheit).

Höhere Sicherheit als im 32Bit-Mode, wie das?

Address space layout randomization etc.

Ah so, weil der 32Bit-Kernel strukturelle Defizite aufweist, nutzt man nun
den größeren Adressbereich um so diese darauf erfolgenden
Angriffsmöglichkeiten zu minimieren.

Das »strukturelle Defizit« ist, daß eine 48-Bit-Zahl (281474976710656)
einfach mal 131072mal größer ist, als eine 31-Bit-Zahl (2147483648). Und
damit ungleich schwerer zu erraten. Das ist simple Zahlentheorie.

Ja das Prinzip mit dem Verstecken in einem noch gößeren Heuhaufen habe ich
verstanden, nur warum dichtet man den Kernel nicht erstmal richtig ab, so
das die Scheunentore durch den die Angriffe erfolgen geschlossen werden.
Das ist doch handerklicher Irrsin ein riesiges Loch im Eimer zu haben und
statt das Loch zu flicken, den Wasserhahn einfach mehr zu öffnen in der
Hoffnung, den Eimer irgend einmal bis zum Rand gefüllt zu bekommen.
Das ein Datenspeicher in einen Codebereich überlaufen kann ist absoluter
Bockmist der hier zusammen geschustert wurde, anders kann man diese
Kernel-Schlamperei gar nicht bezeichnen.

Das »Loch« nennt sich von oben nach unten wachsender Stack und das ist
keine Kernelschlamperei, sondern inhärenter Bestandteil der
Intel-x86-Architektur.

Hast du schon mal etwas von Zugriffsrechten gehört und warum man den
Protect-Mode(PM) überhaupt so nennt?

Erstmal nennt man ihn Protected Mode.

Ach das ist ja auch ein so gewaltiger Unterschied, so das du nun überhaupt
nicht mehr verstehst was ich damit meine, sowas aber auch.

Merke dir mal eine Sprache kann jeder so verwenden wie es beliebt und deine
Sprachlehrergedönse kannst du an den Nagel hängen, es gab hier nie ein
Mißverständnis mit dem betreffenden Begriff.

Zweitens nutzt kein modernes
Betriebsystem dessen Segmentation,

Ach du gibts jetzt plötlich zu, das eine moderne 64Bit-CPU doch
in den 64-Bit-PM schalten kann?

weshalb moderne CPUs mit der Annahme
cs = ds = ss entworfen werden (in anderen Fällen werden sie langsam) --
man nennt das auch den Flat Mode.

Ja nur diesen Flatmode kann man ebenso im 16Bit-Mode verwenden und das
habe ich dir auch schon mal versucht zu erklären, wie man sieht mit wenig
Erfolg.

Da cs = ss ist der Stack ausführbar,
erst die CPU-Erweiterung NX verhindert das.

Auf welches schmale Brett du dein Halbwissen aufbaust ist ja nun
ersichtlich.

All die ganzen Zugriffsrechte helfen aber nichts gegen Return-to-libc.
Da bringt nur ASLR etwas.

Deine Sicht auf die Funktionsweise der CPUs ist noch sehr bescheiden
und dein eingebrachtes Geschnacke über irgendwelche Softwarebibliotheken
lassen auch keinen tiefere Erkenntnis über die CPUs-Funktionalität
durchblicken. Mir persöhnlich ist es egal, ob du dich weiterhin dein
Halbwissen mit irrwitzigen Ablenkungsversuchen und fadenscheinigen
Phrasen dekorieren möchtest, doch über allen deinen persöhlichen
Profilierungsversuchen als CPU-Guru zu wirken, kannst du nicht mal
eifache Tatsachen als gegeben akzeptieren. Ich selber habe nichts davon
wenn du nur dein Halbwissen hier ablädst, besser wäre es da für mich
wenn du wirklich die Bereiche einfach mal lernen würdest, als hier
immer wieder die selben Kindereien zu veranstalten.

Dirk
.

Loading