Archiv verlassen und diese Seite im Standarddesign anzeigen : Wieviel Leistung mehr bringen die breiteren Register der x64-Architektur gegenüber
der x86 Architektur?
Die Compiler dürften inzwischen doch optimiert und ausgereift sein.
Merkt man inzwischen etwas, von dem mehr an Registern?
Zum Vergleich nehmen wir eine x64 CPU und lassen sie im 32 Bit als auch 64 Bit Modus laufen.
Als OS nehmen wir eines, daß auch auf die 64 Bit Plattform inzwischen optimiert ist, z.B. Linux.
Und als Benchmark irgendein aufwendiges Rechenprogramm daß in C++ geschrieben ist, aber auch die Vorteile der x64 Architektur zu nutzen weiß.
Wie sieht es also mit dieser Architektur aus, merkt man die breiteren Register in Sachen Leistung?
Außerdem gibt es im 64 Bit Modus keine Speichersegmentierung mehr.
Und die Aufrufkonvention für Programmprozeduren hat sich auch geändert,
anstatt über den Programmstack läuft diese nun über Register.
Außerdem gibt es im 64 Bit Modus keine Speichersegmentierung mehr.
Die wird eh praktisch von keinem OS verwendet im 32-Bit-Modus.
Die wird eh praktisch von keinem OS verwendet im 32-Bit-Modus. ?
Ich glaube der andere Gast meinte etwas anderes. Segmentierung des virtuellen Speichers im 32-Bit Adressraum und die Allokation von sehr großen Objekten (> 1GB).
6. Absatz:
http://de.wikipedia.org/wiki/AMD64#Architektonisches
Exxtreme
2007-11-24, 21:16:48
Direkten Speed wird man von den 64 Bit kaum spüren. Ausser bei Programmen, die mit der 32-Bit-Grenze zu knabbern haben. Also Datenbanken, Verschlüsselungsprogramme, aufwändige Spiele etc. Aus dem Grund weil man keine Krücken basteln muss um die 32-Bit-Grenze umgehen zu müssen.
Direkten Speed wird man von den 64 Bit kaum spüren. Ausser bei Programmen, die mit der 32-Bit-Grenze zu knabbern haben. Also Datenbanken, Verschlüsselungsprogramme, aufwändige Spiele etc. Aus dem Grund weil man keine Krücken basteln muss um die 32-Bit-Grenze umgehen zu müssen.
Aber die 64 Bit Architektur hat mehr Register und wenn man das Programm oder den Compiler so schreibt, daß diese besser ausgenutzt werden, dann kann man sich den Zugriff auf den Stack oder noch schlimmer Arbeitsspeicher in vielen Fällen sparen.
Das Problem ist, dass die Pointer aber größer werden und somit mehr Data-Cache und Speicherbandbreite benötigen.
Exxtreme
2007-11-24, 23:38:29
Aber die 64 Bit Architektur hat mehr Register und wenn man das Programm oder den Compiler so schreibt, daß diese besser ausgenutzt werden, dann kann man sich den Zugriff auf den Stack oder noch schlimmer Arbeitsspeicher in vielen Fällen sparen.
Tja, dann ist das ein Krücke und die neue 64-Bit-Architektur behebt diese teilweise. Von 64-Bit wird man in den Bereichen viel spüren wo die 32-Bit einfach limitieren. Z.B. wenn du mit mehr als 4 GB Daten rumhantierst. Da musst du schlicht tricksen bis zum Gehtnichtmehr und evtl. eine eigene Speicherverwaltung implementieren, die damit umzugehen weiss. Denn mehr als 4 GB kannst du mit 32-Bit direkt nicht ansprechen. Gibt zwar paar "Hacks" ala PAE (http://de.wikipedia.org/wiki/Physical_Address_Extension) aber das kostet viele viele Takte bei der Verwaltung. Zudem ist es auf die Unterstützung des Betriebssystems angewiesen. Mit 64 Bit entfällt dieses Problem erstmal für lange Zeit. Schlimm wird's zum Beispiel bei Datenbanken, die bei den IDs breitere Zahlen als 32 Bit verwenden. Da muss bei jedem Zugriff getrickst werden und das kostet massiv Performance.
Bei Programmen, die nicht mit den 32 Bit zu kämpfen haben, wird man IMHO kaum was spüren. Ist aber auch kein Wunder. Diese Programme sind meist nicht sehr aufwändig. Und da sind die aktuellen 32-Bit-CPUs wirklich schnell genug.
Mstrmnd
2007-11-24, 23:42:00
Man kann das nicht pauschalisieren. Bei einem ganz konkreten passenden Beispiel kann die Geschwindigkeit um das doppelte steigen. Aber solche Berechnungen hat man normalerweise nicht am laufenden Band im Programm. Es kommt also sehr auf die Anwendung an.
Hier (http://www.forumdeluxx.de/forum/showthread.php?t=225503)ein Performance vergleich von XP32 vs 64 an dem vorallem der 7zip Wert als Reale Applikation interresannt ist.
Der Leistungsgewinn bewegt also so im Bereich um 10%.
Tigerchen
2007-11-25, 07:43:17
Wirklich fette Spiele die selbst schon viel Speicher verschlingen zusammen mit den Entwicklertools im 32 Bit Adressraum zu halten muß doch mittlerweile unangenehm sein für die Entwickler oder Coda?
Wirklich fette Spiele die selbst schon viel Speicher verschlingen zusammen mit den Entwicklertools im 32 Bit Adressraum zu halten muß doch mittlerweile unangenehm sein für die Entwickler oder Coda?
Naja, noch hat jeder Durchschnitts PC nur 2 GB RAM.
Bis jeder Rechner auch der bei Aldi wirklich 4 GB hat, dauert es noch bis mindestens Ende 2008.
Recht hast du aber bei Spielen die sich momentan noch in der Entwicklung befinden und wohl erst 2009 erscheinen werden, aber das dürften dann auch reine 64 Bit Spiele werden.
Wer heute noch eine 32 Bit Version von Vista kauft ist IMO selber schuld.
In 2 Jahren wird er noch einmal einkaufen gehen müssen.
nomadhunter
2007-11-25, 13:46:06
Wer heute noch eine 32 Bit Version von Vista kauft ist IMO selber schuld.
In 2 Jahren wird er noch einmal einkaufen gehen müssen.
Unsinn. Die Spieleentwickler müssen sich danach richten, welches Betriebssystem Otto-Normal-Benutzer installiert hat, und solange das zu 90% ein 32bit-Betriebssystem ist, wird das Spiel in erster Linie auf das 32bit-OS zugeschnitten sein.
Wer heute noch eine 32 Bit Version von Vista kauft ist IMO selber schuld.
In 2 Jahren wird er noch einmal einkaufen gehen müssen.
einkaufen nicht, die lizenz ist für 32 und 64bit gültig, aber zumindest den zeitaufwand einer OS-neuinstallation wird einem nicht erspart bleiben.
Unsinn. Die Spieleentwickler müssen sich danach richten, welches Betriebssystem Otto-Normal-Benutzer installiert hat, und solange das zu 90% ein 32bit-Betriebssystem ist, wird das Spiel in erster Linie auf das 32bit-OS zugeschnitten sein.
Dann haben wir aber auch eine Stagnation was den für ein Spiel notwendigen Speicher betrifft.
Stagnation gab es aber beim PC noch nie, das ist für den PC ein Fremdwort,
daher werden die Entwickler ihre Spiele auch nicht abspecken nur
damit sie noch in ca. 3 GB RAM passen.
Die Spiele platzen heute schon aus allten Nähten und der Schritt zu > 4 GB
ist nicht mehr weit und dann braucht man aber auch ein 64 Bit Betriebssystem.
Kurz gesagt, ich habe Recht, die Leute werden sich ein 64 Bit Betriebssystem kaufen müssen um die neusten Spiele spielen zu können, auch wenn dir das nicht gefällt.
einkaufen nicht, die lizenz ist für 32 und 64bit gültig, aber zumindest den zeitaufwand einer OS-neuinstallation wird einem nicht erspart bleiben.
Leider nicht.
Nur die Windows Vista Ultimate Version enthält beide CDs für beide Versionen (also 32 und 64 Bit).
Bei den anderen muß man sie explizit extra kaufen, da pro Packung nur eine Version dabei ist, entweder 32 Bit oder nur 64 Bit.
Ein Wählen ist da nicht möglich.
Nur die Windows Vista Ultimate Version enthält beide CDs für beide Versionen (also 32 und 64 Bit).
Bei den anderen muß man sie explizit extra kaufen, da pro Packung nur eine Version dabei ist, entweder 32 Bit oder nur 64 Bit.
und? ich schrieb die lizenz ist gültig und an einen datenträger der jeweils andere version zu kommen sollte doch wirklich kein problem sein und wenn man wirklich niemanden mit einer entsprechenden DVD kennen sollte kann man diese immer noch für unter 5€ bei MS bestellen.
nomadhunter
2007-11-27, 14:27:21
Die Spiele platzen heute schon aus allten Nähten und der Schritt zu > 4 GB
ist nicht mehr weit und dann braucht man aber auch ein 64 Bit Betriebssystem.
Kurz gesagt, ich habe Recht, die Leute werden sich ein 64 Bit Betriebssystem kaufen müssen um die neusten Spiele spielen zu können, auch wenn dir das nicht gefällt.
1,5-2 GB reichen heute noch leicht für jedes moderne Spiel, und 3GB sind mit einem 32bit-OS auch noch kein Problem. Bis PCs mit 4 GB RAM einen nennenswerten Marktanteil haben, wird noch viel Zeit vergehen. Bis dahin ist wahrscheinlich schon Vienna draußen, bei dem ich davon ausgehe, dass die 64bit-Version aktiv vermarktet werden und auf den meisten OEM-PCs zum Einsatz kommen wird.
Das hat im Übrigen nichts damit zu tun, was mir gefällt oder nicht, sondern ist reine Marktwirtschaft. >95% aller PCs haben ein 32bit-OS => kein Spieleentwickler wird ein 64bit-only-Spiel rausbringen. Daran wird sich solange nichts ändern, bis nicht die großen OEMs auf 64bit umsteigen und MS seine 64bit-Versionen aktiv vermarktet (Vienna halte ich für einen guten Termin), und auch dann wird es noch einige Zeit dauern, bis die Nutzerbasis breit genug für ein 64bit-Spiel ist.
BlackBirdSR
2007-11-27, 14:50:54
1,5-2 GB reichen heute noch leicht für jedes moderne Spiel, und 3GB sind mit einem 32bit-OS auch noch kein Problem. Bis PCs mit 4 GB RAM einen nennenswerten Marktanteil haben, wird noch viel Zeit vergehen. Bis dahin ist wahrscheinlich schon Vienna draußen, bei dem ich davon ausgehe, dass die 64bit-Version aktiv vermarktet werden und auf den meisten OEM-PCs zum Einsatz kommen wird.
Natürlich.. schließlich braucht Crysis ja auch nicht viel mehr als 1.3GB physikalischen Speicher.
Achtung Ironie:Warum dann aber Supreme-Commander, Gothic3, Hellgate London und einige Andere ständig mit Fehlermeldungen (Out of Memory) abstürzen ist schon verwunderlich. Das kann ich mir wirklich nicht erklären. Besonders nicht warum diese Symptome auf X64-Systemen mit LAA-Bit dann verschwinden.
Auch kann ich mir nicht im Geringsten erklären, warum nahezu jedes neue Spiel gleich mit LAA kommt.:confused: Ironie-Ende
Klartext: Natürlich reichen die 2GB Speicher noch aus. Aber darum geht es ja bekanntlich nicht. Und natürlich kann der Entwickler das Problem umgehen. Crysis und World in Conflict stürzen ja auch nicht deswegen ab. Aber wieviele Programmierer können das? Anscheinend gibt es genug (SP, London, G3) die keinen so richtig guten Plan haben.
x64 ist nicht zwingend nötig um Spiele zu entwickeln. Aber es würde die Sache so viel einfacher und unkomplizierter machen.
Mstrmnd
2007-11-27, 14:57:37
Warum hast Du kein Verständnis dafür? Wieso bist Du so sicher, dass es an der Unfähigkeit der Programmierer liegt, dass ein Spiel nicht mit 2 GiB auskommt? Ich meine, nur weil einige moderne Spiele sich da reinquetschen, kann man das ja nicht unbedingt auf alle Spiele übertragen. Vielleicht haben manche davon einfach deutlich mehr Bedarf an RAM.
Und natürlich könnte man da sogar mit Streaming gegensteuern. Aber das geht dann auch wieder auf die Performance. Kann also viellecht eine Designentscheidung sein.
:confused:
Wer heute noch ein 32 Bit Betriebssystem NEU kauft ist selber schuld.
Das alte weiterbenutzen ist ok, aber wenn man es NEU kauft dann sollte man doch besser zur 64 Bit Version greifen.
Es wurde ja schon gesagt, es sind immer mehr Spiele die Probleme bei zu wenig RAM machen und diese Spiele werden nicht weniger sondern eher mehr.
ID Software hat z.b. ein Spiel in Planung mit mehren GB an Texturen, wenn man die
irgendwie schnell verfügbar haben will, dann müssen die in den Arbeitsspeicher geladen werden und <4 GB sind da für so ein Spiel dann schon sehr knapp.
Die Zukunft ist 64 Bit, momentan sind wir in einer Übergangszeit, ich gebe dem ganzen noch maximal 3 Jahre, dann haben wir nur noch 64 Bit Spiele.
Meine Geforce 4 war übrigens auch gerademal 2-3 Jahre als, als EA bei Battlefield 2 die Unterstützung von Geforce 4 Karten einstellte.
Auch ist das Betriebssystem kaum ein Problem, die Basis über den OEM Markt ist da, denn jeder neue Rechner hat heutzutage eine 64 Bit CPU.
Die Nachzügler müßten also nur ein 64 Bit Betriebssystem installieren,
daher ist das Argument, daß die Spieleentwickler auf den OEM Markt so dringend achten müssten kein Problem, denn 64 Bit Rechner sind dort schon Standard.
1,5-2 GB reichen heute noch leicht für jedes moderne Spiel, und 3GB sind mit einem 32bit-OS auch noch kein Problem. Bis PCs mit 4 GB RAM einen nennenswerten Marktanteil haben, wird noch viel Zeit vergehen. Bis dahin ist wahrscheinlich schon Vienna draußen, bei dem ich davon ausgehe, dass die 64bit-Version aktiv vermarktet werden und auf den meisten OEM-PCs zum Einsatz kommen wird.
wie oft denn noch, das problem ist nicht (nur) der verfügbare RAM sondern in erster linie der limitierte adressraum. dadurch kann der applikation real deutlich weniger als 2GB zur verfügung stehen. abgesehen davon ist bei den heutigen RAM-preisen 2GB standard in OEM-rechnern und 4GB wird für spielerechner auch bald keine seltenheit mehr.
abgesehen davon kommen auch schon heute spiele nicht immer mit 1,5-2GB locker aus. hellgate-london belegt in der 64bit-version beispielsweise nach einiger zeit durchaus über 8GB an adressraum (und dabei immer noch 3GB an physikalischem RAM). der adressraum fragmentiert bei diesem spiel offenbar sehr stark, da öfters große speicherblöcke angefordert werden.
beispielsweise auch google-earth stürzt standardmäßig sehr oft ab, weil es keinen speicher mehr bekommt. mit dem large-adress-flag ist es schon deutlich besser (3,5GB an adressraum wird da auch sehr schnell belegt).
Das hat im Übrigen nichts damit zu tun, was mir gefällt oder nicht, sondern ist reine Marktwirtschaft. >95% aller PCs haben ein 32bit-OS => kein Spieleentwickler wird ein 64bit-only-Spiel rausbringen. Daran wird sich solange nichts ändern, bis nicht die großen OEMs auf 64bit umsteigen und MS seine 64bit-Versionen aktiv vermarktet (Vienna halte ich für einen guten Termin), und auch dann wird es noch einige Zeit dauern, bis die Nutzerbasis breit genug für ein 64bit-Spiel ist.
das ist natürlich ein problem, leider ein hausgemachtes an dem vor allem MS schuld ist. mit außnahme von ein paar notebook-cpus sind alle seit jahren 64bit fähig. es gibt eigentlich nicht wirklich einen grund diese noch immer brach liegen zu lassen. klar wird es noch sehr lange dauern bis es spiele ohne 32bit-executables geben wird. mit vista ist das problem auf user-seite allerdings garnicht so groß wie es im ersten moment scheint. zwar werden praktisch alle OEM-pcs mit 32bit-versionen ausgeliefert, allerdings hat die vista-lizenz ihre gültigkeit für 32 und 64 bit. es kann sich also jeder vista32-besitzer ohne zusätliche kosten auch vista64 installieren.
Warum hast Du kein Verständnis dafür? Wieso bist Du so sicher, dass es an der Unfähigkeit der Programmierer liegt, dass ein Spiel nicht mit 2 GiB auskommt?
es geht dabei nicht unbedingt um unfähigkeit sondern um den großen aufwand der dadurch entsteht, sowohl für die programmierung selbst, als auch für die software zur laufzeit.
man könnte durch entsprechenden aufbau von datenstrukturen fast jedes problem fein genug zerlegen um locker mit unter 2GiB arbeitsspeicher auszukommen (genügend externer speicher natürlich vorausgesetzt)
nur sind die algorithmen die dann zum einsatz kommen unter umständen deutlich langsamer. es gibt oft fälle in denen man entweder viel rechenleistung und weniger speicher braucht, oder aber viel speicher und dafür weniger rechenleistung.
mit 64bit kann man sich den ganzen aufwand einfach ersparen.
BAGZZlash
2007-11-28, 14:55:19
Warum eigentlich diese ganze (180275687520ste) Diskussion um die Speicherverwaltung? Gefragt war doch nach dem Performance-Vorteil durch die breiteren Register.
Warum eigentlich diese ganze (180275687520ste) Diskussion um die Speicherverwaltung?
weil noch immer 43579565443 user behaupten alles wäre blödsinn und 32bit reicht eh noch ewig?
Sind es nicht eher 4294967296 user? *scnr*
BlackBirdSR
2007-11-28, 19:34:10
Warum eigentlich diese ganze (180275687520ste) Diskussion um die Speicherverwaltung? Gefragt war doch nach dem Performance-Vorteil durch die breiteren Register.
Der ist sehr spezifisch. Und daher ist es auch schwer eine erfüllte Diskussion darüber zu führen.
Es gibt genug theoretische Beispiele wo die breiteren Register eine verdopplung des Durchsatzes erlauben, Berechnungsschritte um ein drittel reduzieren und so Zeugs.
Man muss sich aber fragen was die breiteren Register für uns Spieler/Multimedianer bringen.
Was heißt breitere Register? Einfach statt 32 Bit nun 64 Bit?
SSE2 Register sind 128 Bit breit, FPU-Register haben 80 Bit. Was soll das denn?
Mit x64 werden die Integer und GPR Register 64 Bit breit. Das bedeutet zum einen die Möglichkeit mehr Speicher zu adressieren (virtuell physikalisch) zum anderen größere Datentypen zu benutzen. Aber wie groß müssen diese wirklich sein?
MMX wurde/wird durch SSE2/3 ersetzt. Die meisten Decoder arbeiten mit MMX/SIMD und Integer/FPU Kombinationen bei max 32 Bit breiten Datentypen.
Gleitkommaberechnungen mit hoher Genauigkeit (64Bit) sind seit langem etabliert. In Spielen findet man trotzdem meist nur 32 Bit Genauigkeit für Physik etc.
Cell hat beachtliche Leistung, aber nur bei 32 Bit Genauigkeit.
x86 bringt viele postive Aspekte auch für Spieler. Mehr Integer-Leistung durch breite Register darf man sich aber nicht erwarten. Der Rest hat schon längst 64 Bit und mehr.
x86 bringt viele postive Aspekte auch für Spieler. Mehr Integer-Leistung durch breite Register darf man sich aber nicht erwarten. Der Rest hat schon längst 64 Bit und mehr.
Es geht nicht um die breite der Register, die ist nur für die Speicheradressierung bei Spielen intererssant, sondern vor allem um die größere Anzahl an Registern.
Man kann mehr Zwischenwerte speichern und dadurch erspart man sich
die langsamen Zugriffe auf den Cache, auch können Algorithmen und Funktionen effizienter programmiert sein.
Das Beschleunigt eine Anwendung, die diese zusätzlichen Register ausnutzt je nach Algorithmus deutlich.
Das weiß BlackBirdSR ganz gut denke ich. Die Frage war aber eben nicht so gestellt wie man am Topic sieht.
Das weiß BlackBirdSR ganz gut denke ich. Die Frage war aber eben nicht so gestellt wie man am Topic sieht.
Die Überschrift ist etwas irreführend bzw. geht nur auf einen Teil der Frage ein.
Im Text steht dann nämlich auch:
Merkt man inzwischen etwas, von dem mehr an Registern?
1.) Der Performancegewinn durch die breiteren Register nicht absolut nicht vorhanden. Das ist reines Marketing.
2.) Der Performancegewinn durch die erhöhte Anzahl an Registern ist sehr wohl da, allerdings nicht immer sehr hoch. Natürlich in manchen Bereichen bringt es eine Steigerung auf das 4-fache, aber der Schnitt liegt eindeutig darunter. Das ist dasselbe, wie wenn ich den RAM verdopple. Manche Anwendungen brauchen das extrem dringend und laufen sehr viel schneller, aber die meisten davon profitieren ziemlich wenig davon in der Größenordnung von 10%.
3.) Man sollte nicht die Nachteile von 64Bit aus den Augen lassen. Jeder Pointer hat dann 64Bit, was den Speicherbedarf enorm erhöht. Das ist aber bei jedem Programm anders. Das eine Tool, das nur 1GB Cache reserviert, wird nichts spüren. Das andere, das komplexe Datenstrukturen aufbaut wie z.B. einen Baum mit kleinen Datenmengen, das wird den Unterschied sehr wohl spüren, weil dort mehr als die Hälfte das Speichers die Pointer ausmachen. Leute, die viel Java/VB.NET Programmieren, werden das vielleicht nicht so mitbekommen, weil es dort versteckt wird, aber die Pointer machen einen sehr großen Teil aus. Man kann jetzt zwar sagen: Ich habe RAM genug, aber es geht ja auch um die Bandbreite des RAMs bzw. Cache Größen und deren Bandbreiten etc. und da spielt das schon eine Rolle. Natürlich sinkt die Performance dann nicht gleich auf die Hälfte ab, aber 5-10% werden es im Schnitt schon sein, aber natürlich nur bei 64Bit Programmen unter 64Bit Betriebssystemen.
4.) Der eigentliche Grund für 64 Bit ist nicht die Anzahl der Register bzw. dessen Breite. Das ist nur ein angenehmer Nebeneffekt, weil man sowieso inkompatible Software hat. Da kann man ein paar andere, schon lange notwendige Änderungen auch gleich mit reinpacken, weil die paar Transistoren, die für die Register benötigt werden, fallen absolut nicht mehr ins Gewicht.
Der Grund, warum wir 64Bit schon sehr dringen brauchen ist der RAM-Bedarf. In Zeiten, wo 1GB RAM gerade einmal 17 Euro kostet, liegt es doch nahe, sich gleich 4GB bzw. 8GB einzufüllen. Mit 32 Bit sind aber maximal 3GB möglich. Da 3GB einzubauen aber relativ sinnlos ist, weil dann müsste man entweder 3 RAMs verwenden oder 2 verschiedene Größen und beides ist etwas, das der Performance bzw. Stabilität nicht unbedingt sehr zuträglich ist. Da sollte man eher gleich 4GB verbauen und auf 1GB verzichten, aber das ist auch keine wirkliche Lösung, einmal abgesehen davon erklär das einmal einen ALDI-PC Käufer, dass sein PC zwar 4GB hat, aber er nur 3GB nutzen kann, weil das neue 32 Bit Vista nicht mehr kann. Deshalb werden momentan durchgehend 2GB verbaut.
Wenn man bedenkt, dass hauptsächlich 32 Bit Vista verkauft wird, das selbst schon einen RAM-Bedarf von 700-800MB hat, dann ist das doch pervers. Das wäre ja so, wie wenn Win98 damals maximal 64MB RAM unterstützt hätte. Vista 64Bit ist auch noch nicht wirklich einsatzfähig für die Breite Masse, weil es eben noch an den Treibern fehlt. Für die übliche Hardware ist zwar alles da, aber wenn man etwas exotischeres haben will, dann geht es schon nicht und da es sowenig Leute einsetzen, gibt es auch keine ALDI-Käufer, die für uns die Software testen und es ist deutlich instabiler. Das trifft aber meistens gar nicht so auf Windows selbst zu, sondern auf die 64Bit Programme. Da habe ich mit XP-64 schon sehr schlechte Erfahrungen gemacht.
Grundsätzlich wäre es ja ganz einfach möglich einen flüssigen Übergang zu ermöglichen, indem man 32 Bit Treiber in einem 64 Bit System erlaubt, wie es z.B. schon bei Win95 der Fall war, aber da stellt sich ja MS quer mit der Begründung der Performance, was jedoch ein Schwachsinn ist. Die Treiber, die performancerelevant sind (z.B. Grafiktreiber etc., werden auch sehr bald in 64 Bit geschrieben werden, während es bei anderen Treibern wie z.B. einem Drucker oder Modemtreiber ziemlich egal ist.
1.) Der Performancegewinn durch die breiteren Register nicht absolut nicht vorhanden. Das ist reines Marketing.
Wenn man mit Zahlen größer 2^32 rechnen möchte sind 64-bit Register schneller, sogar bis zu 4 mal so schnell:
http://gmplib.org/32vs64.html
Für normale Software bringt es aber tatsächlich nichts.
[QUOTE=Gast;6075529]
2.) Der Performancegewinn durch die erhöhte Anzahl an Registern ist sehr wohl da, allerdings nicht immer sehr hoch. Natürlich in manchen Bereichen bringt es eine Steigerung auf das 4-fache, aber der Schnitt liegt eindeutig darunter. Das ist dasselbe, wie wenn ich den RAM verdopple. Manche Anwendungen brauchen das extrem dringend und laufen sehr viel schneller, aber die meisten davon profitieren ziemlich wenig davon in der Größenordnung von 10%.
3.) Man sollte nicht die Nachteile von 64Bit aus den Augen lassen. Jeder Pointer hat dann 64Bit, was den Speicherbedarf enorm erhöht. Das ist aber bei jedem Programm anders. Das eine Tool, das nur 1GB Cache reserviert, wird nichts spüren. Das andere, das komplexe Datenstrukturen aufbaut wie z.B. einen Baum mit kleinen Datenmengen, das wird den Unterschied sehr wohl spüren, weil dort mehr als die Hälfte das Speichers die Pointer ausmachen. Leute, die viel Java/VB.NET Programmieren, werden das vielleicht nicht so mitbekommen, weil es dort versteckt wird, aber die Pointer machen einen sehr großen Teil aus. Man kann jetzt zwar sagen: Ich habe RAM genug, aber es geht ja auch um die Bandbreite des RAMs bzw. Cache Größen und deren Bandbreiten etc. und da spielt das schon eine Rolle. Natürlich sinkt die Performance dann nicht gleich auf die Hälfte ab, aber 5-10% werden es im Schnitt schon sein, aber natürlich nur bei 64Bit Programmen unter 64Bit Betriebssystemen.
[QUOTE]
Ist das ein Nullsummenspiel, also mehr Register vs. mehr Bandbreite notwendig?
Oder überwiegt eines davon?
Ich schätze mal, wenn ich mehr Register zur Verfügung habe, dann kann ich daran auch mehr speichern, also brauche ich weniger Zugriffe auf das Ram und somit ist die Bandbreite auch nicht mehr so wichtig.
Ich schätze mal, wenn ich mehr Register zur Verfügung habe, dann kann ich daran auch mehr speichern, also brauche ich weniger Zugriffe auf das Ram und somit ist die Bandbreite auch nicht mehr so wichtig.
das hängt von der situation ab. mehr register können in erster linie was bringen wenn man auf die daten mehrfach zugreifen muss.
greift man auf ein datum bei einem programmdurchlauf eh nur 1x zu können weder cache noch eine höhere registeranzahl wirklich was bringen.
einen weiteren vorteil durch eine größere anzahl von registern kann es beispielsweise beim loop-unrolling geben, wobei der compiler das natürlich auch ausnutzen muss.
wie stark der overhead durch die größeren pointer ins gewicht fällt ist auch stark von der situation und den verwendeten datenstrukturen abhängig. wenn man mehr pointerdaten als nutzdaten hat wird das ganze natürlich etwas ineffizient.
allerdings sieht es eher so aus als würden heutige cpus in den meisten fällen eh kaum an der bandbreite hängen, daher glaub ich dass es nicht so stark ins gewicht fällt.
der größte vorteil von 64bit ist und bleibt aber der vergrößerte adressraum, größere und mehrere register sind zwar nette goodies, die aber in der realität meistens nicht viel bringen werden (vor allem da heutige cpus intern sowieso wesentlich mehr register zur verfügung haben und den programmcode durch out-of-order-execution sehr effizient abarbeiten)
als user wird man in außnahme von speziellen situationen nie viel von 64bit merken, 64bit ist in erster linie ein vorteil für die programmierer, die sich jetzt mal für lange zeit keine gedanken um den adressraum machen müssen.
ein echter vergleich wird auch nie möglich sein, da software die den 64bit adressraum wirklich benötigt, garnicht mehr in 32bit laufen wird.
Mit 32 Bit sind aber maximal 3GB möglich. Da 3GB einzubauen aber relativ sinnlos ist, weil dann müsste man entweder 3 RAMs verwenden oder 2 verschiedene Größen und beides ist etwas, das der Performance bzw. Stabilität nicht unbedingt sehr zuträglich ist.
1. Man kann 4GB einbauen und erstmal nur 3GB bis 3.4GB solange nutzen, solange man bei 32bit bleibt.
2. Man kann 2x1GB und 2x 512MB einbauen. Wenn man denn unbedingt in Hardware 3GB haben möchte.
Beides läuft mit XP tadellos. Einen Strich durch diese Rechnung machen gelegentlich nur crappige Boards. Die sollte man aber so oder so iron maiden.
der größte vorteil von 64bit ist und bleibt aber der vergrößerte adressraumUnd unter Win64 die größeren pages. Eine 64bit Anwendung die drauf eingeschossen ist kann sich alleine dadurch von 10% bis 30% steigern.
BAGZZlash
2007-12-03, 07:44:41
Wenn man mit Zahlen größer 2^32 rechnen möchte sind 64-bit Register schneller, sogar bis zu 4 mal so schnell:
http://gmplib.org/32vs64.html
Für normale Software bringt es aber tatsächlich nichts.
Naja, da konnte man vorher aber auch schon in MMX- oder XMM-Registern rechnen lassen.
AnPapaSeiBua
2007-12-03, 08:11:26
Man darf von dem Mehr an Registern auch nicht zu viel erwarten. Die Intel-CPUs beherrschen seit dem P6 schon das sog. Register Renaming (http://en.wikipedia.org/wiki/Register_renaming). D. h. es sind mehr physikalische Register vorhanden als sichtbar sind. Bei x86-64 sind nun halt 16 statt 8 Integer-Register sichtbar.
Physikalisch dürften auch nicht mehr Register vorhanden sein, die Anzahl hängt ja sowieso vom CPU-Typ ab. Es muss ja auch für die Software transparent ablaufen.
Wieviel das jetzt bringt, dass weniger Register Renaming durchgeführt werden muss, weiß ich auch nicht. Wär mal interessant :wink:
Aus meiner Sicht haben die Compiler-Bauer den größten Vorteil aus der größeren Anzahl von Registern.
BlackBirdSR
2007-12-03, 09:54:05
Man darf von dem Mehr an Registern auch nicht zu viel erwarten. Die Intel-CPUs beherrschen seit dem P6 schon das sog. Register Renaming (http://en.wikipedia.org/wiki/Register_renaming). D. h. es sind mehr physikalische Register vorhanden als sichtbar sind. Bei x86-64 sind nun halt 16 statt 8 Integer-Register sichtbar.
Physikalisch dürften auch nicht mehr Register vorhanden sein, die Anzahl hängt ja sowieso vom CPU-Typ ab. Es muss ja auch für die Software transparent ablaufen.
Wieviel das jetzt bringt, dass weniger Register Renaming durchgeführt werden muss, weiß ich auch nicht. Wär mal interessant :wink:
Aus meiner Sicht haben die Compiler-Bauer den größten Vorteil aus der größeren Anzahl von Registern.
Nur als Anmerkung: Den AMD-CPUs ist Register Renaming natürlich auch nicht fremd.
Was die zusätzlichen Register bringen hat AMD mit genügend Folien aufgezeigt. Im Schnitt wohl 10-12%. Aber das sind natürlich isolierte Wert die man nicht direkt umsetzen kann.
Praktisch gesehen:
Windows x64 arbeitet nicht reaktionsfreudiger oder schneller auf einem x64 System.
Wenn es Vorteile bei Spielen/Programmen/Treibern geben sollte, wird das anscheinend von anderen Engpässen und WoW64 negiert.
64Bit Programme können große Vorteile ziehen, wenn das Applikationsfeld dazu passt. Vorallem Spiele scheinen bisher gar nicht in dieses Feld zu passen. Weder was die Anzahl der Register betrifft, noch die 64Bit breiten Register. Wir reden ja auch nur von Integer-Registern. FPU/SIMD ist auch im 32Bit Modus 64Bit genau falls nötig.
Wenn es Vorteile bei Spielen/Programmen/Treibern geben sollte, wird das anscheinend von anderen Engpässen und WoW64 negiert.
Auf einem 64Bit Windows System kann man keine 32Bit Treiber installieren, deswegen kann WOW64 schlecht ein hemmender Schuh sein. Das gilt natürlich auch generell für 64Bit Anwendungen unter Windows.
BlackBirdSR
2007-12-03, 11:34:24
Auf einem 64Bit Windows System kann man keine 32Bit Treiber installieren, deswegen kann WOW64 schlecht ein hemmender Schuh sein. Das gilt natürlich auch generell für 64Bit Anwendungen unter Windows.
Wer sagt etwas von 32Bit Treibern auf x64?
Wenn zusätzliche Leistung durch 64Bit Treiber entstehen sollten, vergliechen mit 32Bit Treibern auf einem x86 OS, so könnte dies gleich wieder von Kosten durch WoW64 und andere Engpässe negiert werden.
Wenn am Punkt A Leistung frei wird, muss man das nicht merken, solange die Wartezeit bei Punkt B identisch ist.
Etwas besser ausgedrückt als vorher?
Sorry
so könnte dies gleich wieder von Kosten durch WoW64 und andere Engpässe negiert werden.
Aber eben nur, wenn 32Bit Software eingesetzt wird, denn für etwas anderes ist WOW64 nicht da. Was ich damit sagen wollte: Wenn alles nur 64Bit ist, wird kein WOW64 benötigt und somit kann WOW64 kein Flaschenhals sein.
Haarmann
2007-12-03, 11:51:35
Die sogenannten Punkt Operationen im Int Bereich, also zB imul, werden bei Verwendung von 64Bit oder grösseren Zahlen 4 mal schneller. Strich Operationen oder logische Verknüpfungen verdoppeln immerhin noch.
Allerdings verändern sich bekanntlich auch die Laufzeiten von zB imul bei 64 Bit. Das muss immer mitbetrachtet werden.
Je nach Art der Software kann das daher viel ausmachen, wie die Benches auch zeigen. Es kann aber auch langsamer werden - gerade auch wegen den Laufzeiten.
Naja, da konnte man vorher aber auch schon in MMX- oder XMM-Registern rechnen lassen.
Nö. Es gibt keine 64-Bit-Integer-Arithmetik per SIMD auf x86.
Die sogenannten Punkt Operationen im Int Bereich, also zB imul, werden bei Verwendung von 64Bit oder grösseren Zahlen 4 mal schneller. Strich Operationen oder logische Verknüpfungen verdoppeln immerhin noch.
Eine 64-Bit-Multiplikation braucht zumindest auf K8 und K10 einen Takt mehr.
BlackBirdSR
2007-12-03, 19:45:15
Aber eben nur, wenn 32Bit Software eingesetzt wird, denn für etwas anderes ist WOW64 nicht da. Was ich damit sagen wollte: Wenn alles nur 64Bit ist, wird kein WOW64 benötigt und somit kann WOW64 kein Flaschenhals sein.
und nochmal. Gewonnene Leistung durch 64-Bit Treiber minus Verlust durch WoW64. Natürlich für x86-Code.
Jetzt klar?
Spiel gleich mit LAA kommt. Kann man dies auch für andere erzwingen, damit 32bit Programme unter XP64 bis zu 4GiB Speicher nutzen können?
BlackBirdSR
2007-12-04, 11:06:50
Kann man dies auch für andere erzwingen, damit 32bit Programme unter XP64 bis zu 4GiB Speicher nutzen können?
natürlich kannst du es erzwingen. Aber sie werden deswegen nicht zwangsläufig 4GB Speicher nutzen können. Dazu muss der Speichermanager entsprechend ausgelegt werden. Was in den meisten Fällen aber möglich ist, dass du durch den vergrößerten virtuellen Adressraum Vorteile bemerkst.
Windows ist bei mir nach dem Beenden von BF2 oder Taskswitch mit 2GB Speicher unter x64 erstmal mit Nachladen, Swappen und genereller Reaktionsunfreudigkeit beschäftigt.
Mit LAA ist die Sache komplett vorbei. Alt+F4 und Windows ist sofort da und wartet auf weitere Benutereingaben.
Verschiedene Spiele zeigen verschieden starke Auswirkungen. Meist aber gar keine. Hab ne große Anzahl davon durchprobiert ;)
Manche Spiele haben aber etwas dagegen, wenn der Executable-Header modifiziert wird. Ghost Recon2 ist so ein Kandidat.
Wie es geht: z.B so
http://www.keindesign.de/stefan/poser/3gb.html
Gast hitcher
2007-12-04, 12:24:00
der Windows Taschenrechner x64 rechnet Faktorielle einer grossen Zahl doppelt so schnell als der Taschenrechner mit 32 Bit.
Warum das jetzt so ist, ist fraglich. Vermutlich rechnet der aber intern mit grösseren Datentypen.
Wenn am Punkt A Leistung frei wird, muss man das nicht merken, solange die Wartezeit bei Punkt B identisch ist.Das ist jetzt aber kein Grund zum Jammern oder?
Man muß ja nicht dauernd am B hängen bleiben. B läuft wahrscheinlich auch nicht immer. A kann sich auch auf andere Systemoperationen auswirken was entweder B sehr wohl leicht beschleunigen kann, das Merkbare vom Flaschenhals B aufwiegen kann oder eben merkbar C und D beschleunigt.
Es gibt keine Gründe die Versuche am A Leistung frei zu machen als nicht lohnenswert anzusehen. Ja ich weiß, daß du das damit nicht tust.
Das Wichtigste sind 64bit Treiber und 32bit lassen sich zum Glück und aus gutem Grund unter 64bit Windows nicht installieren.
natürlich kannst du es erzwingen. Aber sie werden deswegen nicht zwangsläufig 4GB Speicher nutzen können. Dazu muss der Speichermanager entsprechend ausgelegt werden.
Die meisten Spiele/Programme verwenden wohl sowieso den des Kernels (new/malloc) und damit geht es auf jeden Fall.
Spasstiger
2007-12-04, 14:37:10
der Windows Taschenrechner x64 rechnet Faktorielle einer grossen Zahl doppelt so schnell als der Taschenrechner mit 32 Bit.
Warum das jetzt so ist, ist fraglich. Vermutlich rechnet der aber intern mit grösseren Datentypen.
Generell muss man aber sagen, dass der Windows-Taschenrechner sehr ineffizient rechnet. Es gibt Programme, die rechnen die Fakultät 20-mal so schnell wie der Windows-Taschenrechner.
Übrigens ist die x64-Version vom Win-Taschenrechner bei der Fakultät mehr als doppelt so schnell wie die x86-Version. 64 Bit heißt nicht doppelt so schnell wie 32 Bit. ;)
BlackBirdSR
2007-12-04, 15:30:52
Die meisten Spiele/Programme verwenden wohl sowieso den des Kernels (new/malloc) und damit geht es auf jeden Fall.
Stimmt, aber deswegen sind mir auch noch nicht viele Spiele untergekommen die so weit gehen würden. Dazu zählen selbst Spiele die schon mit LAA ausgeliefert werden. Vielleicht aus Rücksicht? Vielleicht brauchen sie aber auch nicht mehr physikalischen Speicher.
StefanV
2007-12-04, 17:06:59
Wenn es Vorteile bei Spielen/Programmen/Treibern geben sollte, wird das anscheinend von anderen Engpässen und WoW64 negiert.
Warum??
Was macht WoW64 denn außer diverse Registry Einträge 'umzulegen'??
Die 32-Bit-API in die 64-Bit-API übersetzen.
LordDeath
2007-12-05, 00:35:43
Ich hätte zu dem Thema auch eine Frage:
Wie sieht das ganze mit Java oder .Net Anwendungen aus? Muss der Entwickler für x64 großartig etwas am Code verändern oder reicht es schon, wenn es die Runtime als x64 Version gibt?
Hier habe ich z.B. Paint.Net und das Programm verweigert es mir, Bilder größer als 2GiB zu bearbeiten. Wäre es für die Programmierer dieses Tools jetzt schwer, eine 64bit Version raus zu bringen, oder ist sowas auf die Schnelle erledigt?
Hier habe ich z.B. Paint.Net und das Programm verweigert es mir, Bilder größer als 2GiB zu bearbeiten. Wäre es für die Programmierer dieses Tools jetzt schwer, eine 64bit Version raus zu bringen, oder ist sowas auf die Schnelle erledigt?
1. Java verwendet festgelegte Datentypen.
D.h. wenn sich das Programm weigert Dateien zu akzeptieren die größer als 2 GiB sind, dann kann es sein, daß von den Programmierern wohl nur 32 Bit große Datentypen verwendet wurden.
2. Aber es kann auch sein, daß das 2 GiB Limit aufgrund deines 32 Bit Windows OS besteht, dort darf nämlich kein Progrmam mehr Speicher benutzen als 2 GiB und das gilt auch für eine Java VM.
Die Java VM dürfte also diesen Versuch, größere Bilder zu laden nicht zulassen.
Umgehen kannst du das Problem dann in der Tat dadurch, daß du dir ein 64 Bit OS und eine 64 Bit Java VM installierst.
Am Code müßte in diesem Fall nichts verändert werden.
Es gibt also 2 Möglichkeiten.
Helmsberg
2007-12-05, 08:30:55
Kann man eigentlich auch testen ob eine Anwendung dieses LAA Ding hat oder nicht hat?
BlackBirdSR
2007-12-05, 12:09:38
Ich hätte zu dem Thema auch eine Frage:
Wie sieht das ganze mit Java oder .Net Anwendungen aus? Muss der Entwickler für x64 großartig etwas am Code verändern oder reicht es schon, wenn es die Runtime als x64 Version gibt?
Hier habe ich z.B. Paint.Net und das Programm verweigert es mir, Bilder größer als 2GiB zu bearbeiten. Wäre es für die Programmierer dieses Tools jetzt schwer, eine 64bit Version raus zu bringen, oder ist sowas auf die Schnelle erledigt?
laut Entwickler liegt paint.net in einer nativen x64 Version vor. Das kann ich auch am eigenen System bestätigen. Ob ich so große Dateien bearbeiten kann habe ich aber nicht getestet.
Schimi1983
2007-12-05, 17:00:21
es geht ohne Probleme :-)
Wenn man paint.net installiert dann wird automatisch die richtige version instaliert (was für nen satz)
Spasstiger
2007-12-05, 19:58:56
Kann man eigentlich auch testen ob eine Anwendung dieses LAA Ding hat oder nicht hat?
Falls es sich um Win32-Anwendungen handelt:
Die Binaries (Exe- und Dll-Dateien) mit dem CFF Explorer öffnen und unter "Nt Headers" -> "File Header" -> "Characteristics" nachschauen.
Wenn da ein Haken bei "App can handle >2gb adressset" ist, ist die Applikation large adress aware.
Man kann dort auch selber probehalber einen Haken setzen und die Exe speichern. Hab ich bei Google Earth und Maple 9.5 erfolgreich getestet, die Apps haben danach mehr als 2 GiB Speicher adressiert.
Allerdings ist diese Veränderung der Binaries in der Regel durch den Endbenutzerlizenzvertrag untersagt.
Zu Paint.Net:
http://www.abload.de/img/paintnetwlx.png
Sicherlich wäre auch noch mehr gegangen, aber mein Rechner war da schon schwer am Swappen (hab nur 4 GiB RAM).
Bilddateien größer als 2 GiB lassen sich aber tatsächlich nicht öffnen.
LordDeath
2007-12-05, 21:10:09
Das ist sehr merkwürdig. ProcessExplorer sagt mir, dass meine PaintDotNet.exe eine 32Bit Anwendung ist...
Meine Frage bezog sich eher darauf, ob es dank Zwischencode möglich ist, ein und das selbe Programm je nach Wunsch als 32Bit oder 64Bit Anwendung laufen zu lassen, falls die nötige 32Bit oder 64Bit Runtime installiert ist. Und dazu wollte ich wissen, wie es bei Java und .Net aussieht.
Hält sich der Aufwand in Grenzen, oder lassen sich Programme sogar direkt auf der gewünschten Plattform starten?
Hat eigentlich Photoshop CS3 dieses Flag?
SgtTynis
2007-12-06, 11:43:28
Das ist sehr merkwürdig. ProcessExplorer sagt mir, dass meine PaintDotNet.exe eine 32Bit Anwendung ist...
Das scheint der ProcessExplorer zu irren. Eine .NET Anwendung die unter Verwendung von "Any CPU" compiliert wurde, besitzt unter einem 64bit Betriebssystem einen 64bit großen IntPtr auf einem 32bit System nur einen 32bit großen. Forciert man 64bit indem man mittels x64 compiliert, ist die Anwendung unter 32bit nicht mehr lauffähig; der IntPtr ist unter 64bit erwartungsgemäß 64bit groß. Die gleiche Anwendung mittels x86 compiliert liefert nur einen 32bit großen IntPtr, sowohl auf einem 32bit als auch 64bit System. Long, Int etc. bleiben unter .NET offensichtlich unangetastet.
Bei Java entscheidet die installierte VM darüber, ob die Anwendung als 32bit oder 64bit Anwendung läuft. Welche Datentypen dort von der anderen Architektur betroffen sind, kann ich allerdings nicht sagen.
Spasstiger
2007-12-06, 11:45:28
Hat eigentlich Photoshop CS3 dieses Flag?
Schon CS2 hat es. CS3 demnach sicherlich auch.
Meine Frage bezog sich eher darauf, ob es dank Zwischencode möglich ist, ein und das selbe Programm je nach Wunsch als 32Bit oder 64Bit Anwendung laufen zu lassen, falls die nötige 32Bit oder 64Bit Runtime installiert ist. Und dazu wollte ich wissen, wie es bei Java und .Net aussieht.
bei java läuft eine 32bit kompilierte anwendung nur mit 32bit runtime und umgekehrt, wie es bei .NET ist weiß ich nicht.
Ganon
2007-12-06, 13:47:39
bei java läuft eine 32bit kompilierte anwendung nur mit 32bit runtime und umgekehrt
Hö? Das deckt sich aber nicht mit dem was ich hier mache...
Entwickle und kompiliere unter Linux/x86_64 auf einem 64bit-JDK und alles läuft auch auf einem 32bit Windows...
Entwickle und kompiliere unter Linux/x86_64 auf einem 64bit-JDK und alles läuft auch auf einem 32bit Windows...
kann sein, dass es unter linux anders ist, die 64bit JRE unter windows ist ja noch etwas rückständig ;)
unter windows kann ich jedenfalls keine 32bit-java-programme starten wenn nur ein 64bit JDK/JRE installiert ist. umgekehrt laufen logischerweise 64bit-java-programme auch nur mit einem 64bit JRE/JDK.
SgtTynis
2007-12-06, 14:38:32
unter windows kann ich jedenfalls keine 32bit-java-programme starten wenn nur ein 64bit JDK/JRE installiert ist. umgekehrt laufen logischerweise 64bit-java-programme auch nur mit einem 64bit JRE/JDK.
jEdit läuft unter Vista64 sowohl mit 32bit VM als auch 64bit VM.
jEdit läuft unter Vista64 sowohl mit 32bit VM als auch 64bit VM.
ich hab mal probiert den tvbrowser mit 64bit JRE zu starten, hat allerdings nicht funktioniert (wobei man das 32bit-JRE auch für die internet-browser braucht)
Also wenn dann ist es irgendein Bug. Der Java-Bytecode hat auf 32/64bit JRE zu laufen - unabhängig ob Windows oder Linux.
nomadhunter
2007-12-07, 13:52:18
Könnte damit zu tun haben, dass der TV-Browser ein Bisschen nativen Code verwendet.
Könnte damit zu tun haben, dass der TV-Browser ein Bisschen nativen Code verwendet.
nein, viel simpler, hab jetzt den fehler gefunden.
die installationsroutine des 64bit-JDK setzt die nötigen reg-einträge für JavaHome etc. nicht.
deshalb finden die java-anwendungen die 64bit-runtime nicht.
wenn ich manuell das verzeichnis des 64bit-JRE angebe startet beispielsweise der TV-browser einwandfrei als 64bit-prozess.
bei java läuft eine 32bit kompilierte anwendung nur mit 32bit runtime und umgekehrt, wie es bei .NET ist weiß ich nicht.
Unfug, wenn das so wäre, dann würde die Plattformunabhängigkeit von Java gar keinen Sinn machen bzw, nicht funktionieren.
Gibt es Programme, welche besonders vom manuellen LAA-Flaggen profitieren? Kommt es nur darauf an wieviel Speicher sie nutzen oder auch wie sie den Speicher nutzen?
StefanV
2007-12-11, 14:19:24
Ja, gibts, z.B. Supreme Commander, Gothic 3 und noch einige andere (wovon aber die meisten das schon gesetzt haben)
Gibt es Programme, welche besonders vom manuellen LAA-Flaggen profitieren?
google-earth beispielsweise.
Kommt es nur darauf an wieviel Speicher sie nutzen oder auch wie sie den Speicher nutzen?
weder noch, es kommt darauf an wie der adressraum genutzt wird. mit LAA kann ein programm wesentlich stabiler sein.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.