Diskussion:4-GB-Grenze

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 30 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

Falsch auch ein 32bit Windows kann mehr als 4GiB addressieren

Siehe auch Physical Address Extension. Bei den Desktop Versionen ist diese Funktion schlicht aus lizenztechnischen Gründen deaktiviert. (Und weil dann die Treiber 64bit Addressen können müssen.) Der Server Versionen von Windows können schon länger die vollen 64GiB ansprechen (was technisch schon seit 1995 geht). Linux kann schon seit längerem mehr als 4GiB im 32bit Modus ansprechen (und Mac OS X auch).

Für Hintergründe siehe auch: http://www.dansdata.com/askdan00015.htm (nicht signierter Beitrag von Pgampe (Diskussion | Beiträge) 13:59, 24. Mai 2012 (CEST))

Soviel ich weiß hat das weniger mit "lizenzrechtlichen" Gründen zu tun, als eher damit, dass man dafür spezielle Treiber braucht, die es für die meiste Consumerhardware nicht gibt. Und die CPU-Auslastung solls laut deinem Link auch erhöhen, daher wurde es wohl für die noramlen Windows x32-Versionen nie aktiviert, sondern nur für die Serverversionen, da bei Servern zu Zeiten vor der Einführung von AMD64 ~3GB teilweise knapp bemessen waren, während Desktop-PCs maximal 1-2GB hatten. Außerdem können mit PAE zwar merh als 4GB addressiert werden, pro Prozess sind aber weiterhin maximal 2GB oder 4GB verfügbar. Außerdem wird PAE eh schon im Artikel erwöhnt, das reicht auch, für alle die mehr über PAE erfahren wollen gibts ja den Wikilink zum PAE-Artikel. --MrBurns (Diskussion) 14:19, 24. Mai 2012 (CEST)

Ich finde aber auch, dass die Lizenz als Grund zumindest erwähnt werden sollte. Die Treiberprobleme klingen mMn eher nach einer Ausrede, die von MS gesucht wurde. --Kuhno133 (Diskussion) 16:20, 17. Sep. 2013 (CEST)

oma-tauglichkeit

Der Artikel ist derzeit eher eine Sammlung von technischen Details, die je nach Autor an scheinbar beliebigen Stellen einsortiert sind. So richtig oma-tauglich ist der Artikel nicht, weder in der Einleitung noch in der Übersichtlichkeit. Man kläre etwa erstmal, warum es überhaupt ein "Problem" ist! Hab selbst keine Zeit zur Überarbeitung... GuidoD 05:52, 11. Sep. 2013 (CEST)

Quellenangaben fehlen!

Quellenangaben fehlen zuhauf! Dementsprechend bitte Neutralitäts- und Beleg-Baustein setzen! --80.187.102.159 21:43, 29. Apr. 2014 (CEST)

It's a wiki. Bitte quellen selsbt hinzufügen, offensichtlich weisst du wie die Wikisyntax funktioniert. ;) Shaddim (Diskussion) 16:38, 30. Apr. 2014 (CEST) gruesse Shaddim (Diskussion) 16:38, 30. Apr. 2014 (CEST)

Welche Kernaussagen des Artikels sind denn deiner Meinung nach noch nicht über die bereits existierenden Referenzen belegt? --RokerHRO (Diskussion) 18:00, 2. Mai 2014 (CEST)

allokieren vs. allozieren

Hallo Benutzer:Widar23!

Bzgl diesem Edit von dir:

Es gibt sowohl "allozieren" als auch "allokieren", zweiteres scheint aber wohl seltener; der Artikel Allokation (Informatik) spricht von "zunehmend häufiger [Verwendung]". Wiktionary kennt beides, Duden-online nur die "z"-Variante.

Nur als Anmerkung. --arilou (Diskussion) 09:08, 24. Jun. 2014 (CEST)

PS: Ach ja, meine immerwährende Anmerkung: Es gibt kein "richtiges" oder "falsches" Deutsch... (aber sehrwohl eine Vorgabe, welche Version in WP verwendet werden soll!) --arilou (Diskussion) 09:10, 24. Jun. 2014 (CEST)

Gibt es denn eine Vorgabe zu allo[kz]ieren?

Laut Google hatte das Wort "warscheinlich" 2009 einen Verbreitungshöhepunkt, aber ich hoffe es hat trotzdem niemand dafür plädiert es in enzyklopädischen Artikeln anstelle von "wahrscheinlich" zu verwenden. -- Widar23 (Diskussion) 11:54, 24. Jun. 2014 (CEST)

Mich hat es auch gewundert, dass weder der Duden noch der Leipziger Wortschatz "allokieren" kennen. Das Wiktionary ist als Wiki selbst eigentlich keine zuverlässige Quelle.

Allerdings gibt es unzählige (übersetzte) Fachliteratur, die es mit "k" schreiben. Ich würde es hier so handhaben, als ob beide Schreibweisen zulässig wären, d.h. "allokieren" stehen zu lassen.--Plankton314 (Diskussion) 12:11, 24. Jun. 2014 (CEST)

@Widar23: Wenn genügend Leute in (ausreichend anerkannten) Veröffentlichungen "warscheinlich" verwenden, wird es in den Duden aufgenommen (und dadurch "Duden-richtig"). Auf jeden Fall ist es kein "falsches Deutsch", sondern nur "falsch bzgl. Duden", "falsch bzgl. Langenscheidt", ...

Aber zurück zum Thema: Ich habe kein Problem damit, "allozieren" und "allokieren" zu akzeptieren. Hab beides schon gehört, gelesen (und vmtl. auch schon beides selbst geschrieben/verwendet ;-) ...)

Daher ja auch kein Revert deines Edits, nur eine Anmerkung, dass die 'k'-Version wohl ebenfalls (etwas) verbreitet ist und von vielen als (auch) richtig gewertet wird.

--arilou (Diskussion) 16:35, 24. Jun. 2014 (CEST)

Satzwiederholung

Unter 32-Bit-Systemen gibt es mit PSE36 und PAE Möglichkeiten, die 4-GiB-Grenze zu überschreiten (das Limit von 2 GiB oder 4 GiB pro Prozess bleibt aber). Diese Prozessorerweiterungen vergrößern allerdings nur den physisch adressierbaren Speicher, jeder Prozess für sich kann weiterhin nur 4 GiB Daten gleichzeitig adressieren.

Ist das 2x das gleiche Argument oder versteh ich da technisch was nicht ? (nicht signierter Beitrag von ShalokShalom (Diskussion | Beiträge) 00:31, 12. Sep. 2014 (CEST))

Richtig, hier verdeutlicht ein wenig Redundanz, dass "mehr Ram" nicht zwangsweise einem Prozess zugute kommt. --arilou (Diskussion) 09:40, 12. Sep. 2014 (CEST)

Verwendung von 128 Bit Pointern

Es gibt auch Systeme, die das Problem weiter umschiffen möchten, indem sie 128 Bit Pointer verwenden oder zumindest vorsehen. Siehe: ZFS (Dateisystem). Das könnte man hier auch als Ausblick vermerken. Divof (Diskussion) 12:11, 27. Jun. 2017 (CEST)

Ob das wirklich relevant ist? Mit 64 bit lassen sich theoretisch 2^64 Bytes adressieren (= 16 EiB), das sollte für absehbare Zeit reichen. Bei der AMD64 sind zwar max. 2^48 Bytes möglich (= 256 TiB), aber das könnte man bei einem Architekturupdate leicht erhöhen. --MrBurns (Diskussion) 13:16, 28. Jun. 2017 (CEST)