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)

4-GiB-Grenze einzig richtige Bezeichnung

Der Begriff "4-GB-Grenze" ist hier falsch, da einerseits "GB" die offizielle Bezeichnung ausschließlich für das Gigabyte (1000³ Byte) ist, und das "GiB" für Gibibyte (2³⁰ Bytes oder 1.073.741.824 Byte) → also ist GB ≠ GiB. Gibi- ist ein Binärpräfix der IEC, Giga- ein SI-Präfix. Meint man mit "GB" das Gibibyte, ist die Abkürzung falsch. Limits in Computern beziehen sich quasi immer auf Vielfache von Zwei statt Zehn (da es Binärrechner sind). Zwar werden in der IT wie hier oftmals ähnliche Begriffe synonym verwendet (wie "GPU" und "Grafikkarte"), aber hier ist Genauigkeit wegen des Anspruchs der Wikipedia als Enzyklopädie schon wichtig. Das Limit hier liegt bei 4.294.967.296 Byte (oder 4.294.967.295 Byte), also über 4 Gigabyte, was eben ein Unterschied ist. Grüße --PantheraLeo1359531 😺 16:28, 22. Dez. 2024 (CET)

Darüber hinaus irritiert der Wechsel zwischen "GB" und "GiB" --PantheraLeo1359531 😺 16:32, 22. Dez. 2024 (CET)

Darüber hinaus kann ich soetwas wie eine 4-GB- oder 4-GiB- oder 4.294.967.296-Byte-(plus/minus 1)-Grenze gar nicht finden. Ist das WP:TF? In diversen Büchern aus den 1990er und 2000er Jahren (als diese Grenze ein Thema war) finde ich jedoch massenweise die von der 32-Bit-Architektur vorgegebenen "4 GB" -- nicht aber "4 GiB".

Beispiele?

• Die 32-Bit-Expedition: Win32, Windows 4.0 und Windows NT – Leitfaden und Referenz zur Portierung von Windows 3.x-Programmen, Thomas Lauer, Springer-Verlag, 1993, ISBN 978-3-662-11476-6
• Windows 95 – Highlights unter der Lupe, Carola Pantenburg, Gerhard Peter, Springer-Verlag, 1995, ISBN 978-3-540-60028-2
• Betriebssysteme – Grundlagen und Konzepte, Rudiger Brause, Springer-Verlag, 1998, ISBN 978-3-540-62929-0
• Das PC-Wissen für IT-Berufe: Hardware, Betriebssysteme, Netzwerktechnik, Rainer Egewardt, 2. überarbeitete und erweiterte Auflage, Springer-Vieweg, 2002 (1. Auflage 2000), ISBN 978-3-663-07857-9

Was sich in all diesen Büchern findet, ist die 640-KB-Grenze -- ja "KB" und nicht "KiB"! Auch die 1-MB-Grenze ist zu finden -- wieder, nicht "MiB" sondern "MB"! Sowie die Information, dass man auf 32-Bit-Systemen bis zu 4 GB -- wieder: "GB" und nicht "GiB" -- linear adressieren kann.

Was sagt uns das?

‣Andreas•⚖ 16:56, 22. Dez. 2024 (CET)

Nachtrag: Der Vollständigkeit halber habe mir auch noch ganz aktuelle Bücher herausgersucht und nach "4 GiB" gesucht... wurde aber nicht fündig.

• Operating Systems/Betriebssysteme (Zweisprachige Ausgabe: Englisch - Deutsch), Christian Baun, 2. Auflage, Springer-Vieweg, 2022, ISBN 978-3-658-42229-5

Auch in diesem Buch, das ja nun wirklich sehr aktuell ist, wird immer nur von "4 GB" geschrieben, natürlich mit und ohne Split (3G/1G oder 2G/2G). Das ganze ist zwar als "eine Grenze" im Betriebssystem beschrieben, aber nicht als "4-GB-Grenze" (geschweige-denn als "4-GiB-Grenze", denn, wie gesagt, "GiB" kommt im Buch gar nicht vor!). Zitate (fette Markierung von mir):

• Seite 162, Kapitel 8. Prozess Management, Abschnitt 8.3 Struktur eines Prozesses im Speicher: Bei der standardmäßigen Aufteilung des virtuellen Adressraums auf einem 32-Bit-System reserviert Linux standardmäßig 25% für den Betriebssystemkern (Kernelmodus) und 75% für die Prozesse im Benutzermodus. Auf solch einem System kann jeder laufende Prozess damit bis zu 3 GB Speicher verwenden. In Abschnitt 5.2.6 wurden bereits die Grenzen von 64-Bit-Systemen beschrieben. Die Struktur von Prozessen auf 64-Bit-Systemen unterscheidet sich nicht von 32-Bit-Systemen. Einzig der Adressraum ist größer und damit die mögliche Ausdehnung der Prozesse im Speicher.
• Seite 102, Kapitel 5. Memory Management, Abschnitt 5.2.6 Kernelspace und Userspace: Der virtuelle Adressraum (virtuelle Speicher) von 32-Bit-Prozessoren ist auf 4 GB pro Prozess beschränkt. Der Betriebssystemkern von Linux reserviert auf 32-Bit-Systemen standardmäßig 25% für den Betriebssystemkern und 75% für die Prozesse im Benutzermodus. Bei Windows auf 32-Bit-Systemen ist das Verhältnis standardmäßig 50:50. In diesem Zusammenhang spricht man auch vom sogenannten 3G/1G- oder 2G/2G-Split. Bei einem 3G/1G-Split auf der Intel IA32-Architektur (x86-32) bilden die virtuellen Speicheradressen 0x00000000 bis 0xBFFFFFFF der Userspace. Diese Adressen stehen dem laufenden Prozess im Benutzermodus zur Verfügung. Auf diesen Bereich können Prozesse im Benutzermodus, aber auch im Kernelmodus zugreifen. Die virtuellen Speicheradressen 0xC0000000 bis 0xFFFFFFFF bilden der Kernelspace. Auf diese Adressen können nur Prozesse im Kernelmodus zugreifen. 64-Bit-Prozessoren mit einem 64 Bits breiten Adressbus könnten theoretisch 16 Exabyte Speicher adressieren. Bei den gängigen 64-Bit-Prozessoren ist der Adressbus aber nur 36, 44 oder 48 Bits breit …. Ein 48 Bits breiter Adressbus bei der Architektur AMD64 (x86-64) ermöglicht es immerhin, 256 TB Speicher zu adressieren. … Wird ein 32-Bit-Prozess in einem 64-Bit-Betriebssystem ausgeführt, erhält es die ersten 4 GB des Userspace vollständig.

Wie man erkennen kann, wird hier auch "Terrabyte" mit "TB" -- und nicht mit "TiB"! -- abgekürzt.

‣Andreas•⚖ 17:21, 22. Dez. 2024 (CET)