Bringt FreeBSD64 bit wirklich was?

C

cabriofahrer

Well-Known Member
Ich werde demnächst einen neuen Rechner mit Nvidia-Karte bekommen, auf dem ich möglicherweise FreeBSD aufsetzen will, vielleicht sogar die 9.1-64-bit Version.
Die Frage ist nur, bringt das wirklich was? Mit dem Rechner will ich u.a. spielen, für wine gibt es sogar schon tbx-Pakete, die angeblich die 32-bit-Umgebung und die 32-bit-Version des Nvidia-Treibers gleich mitinstallieren.

Doch was bringt 64-bit wirklich? Nennenswerte Performance-Vorteile beim Kompilieren von ports, encoding von mp3's oder Videodateien? Mehr Geschwindigkeit im Umgang von z.B. KDE4? Gibt es vergleichende Benchmarks unter FreeBSD dafür?

Wird bei der Installation die allgemeine 32-bit-Kompatibilität automatisch mitinstalliert?
 
keine ahnung ob es das ist was du meintest, aber mein uname -a sieht so aus:
Code: 
FreeBSD kaffeekanne.deep.space 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Sat Jan 12 15:00:49 CET 2013     root@kaffeekanne:/usr/obj/usr/src/sys/DETTUS  amd64

ueber die geschwindigkeit kann ich nichts sagen. aber ich habe mehr als 4gb ram.
32 bit kompatibilitaet weiss ich auch nicht, ich compilier alles aus den ports.
 
Wieso taucht immer die Größe von 4GB RAM und mehr in diesem Zusammenhang auf? Kann FreeBSD/i386 etwa 4 GB RAM nicht erkennen und macht nur 2 daraus, oder wie?
 
cabriofahrer: Weil sich mit 32 Bit nur 2 hoch 32 verschiedene Adressen ausdrücken lassen. Das ergibt bei einem Byte pro Adresse halt 4GiB. Davon müssen noch eine hundert MiB abgezogen werden für Prozesse im Userspace, weil der Kerneladressraum immer sichtbar seien muss. Somit bleiben ca. 3.5GiB RAM für einen Prozess über. Es gibt seit dem Pentium Pro eine Erweiterung des physikalischen Adressraums auf 36 Bit names PAE. Damit lassen sich immerhin 64GiB RAM adressieren. Nur hat diese den Nachteil das kein Prozess (auch nicht der Kernel) den ganzen Adressraum linear adressieren kann mit 32 Bit. Dadurch werden sog. Bounce Buffers nötig um Daten vom einen Teil des RAMs in den anderen zu kopieren. Damit können unterschiedliche Prozesse zwar mehr zusammen mehr als 4GiB RAM belegen, aber man bekommt einen ganzen Haufen Probleme gratis mit dazu. Die meisten dieser Probleme lassen sich trivial dadurch lösen von i386 auf amd64 zu wechseln.
 
cabriofahrer schrieb:
Wieso taucht immer die Größe von 4GB RAM und mehr in diesem Zusammenhang auf? Kann FreeBSD/i386 etwa 4 GB RAM nicht erkennen und macht nur 2 daraus, oder wie?
Zum Vergrößern anklicken....
Mit einem 32Bit-Bus kannst du halt max. 2^32 Speicherstellen direkt adressieren, also 4GB. Und zwischen 3 und 4 GB wird dann noch der Speicher von deinen Erweiterungskarten eingeblendet, bleiben also 3-3,5GB für's System und Anwendungen.
Mit 64Bit (Bus + OS) hast du diese Grenze nicht.
 
Danke für Eure Antworten bezüglich der 4 GB RAM. Mit anderen Worten, würde ich bei Verwendung eines 32-Bit-Systems ca. 500 MB RAM verschenken.

Wie sieht es bezüglich meiner anderen o.g. Fragen aus?
 
cabriofahrer schrieb:
Die Frage ist nur, bringt das wirklich was? Mit dem Rechner will ich u.a. spielen, für wine gibt es sogar schon tbx-Pakete, die angeblich die 32-bit-Umgebung und die 32-bit-Version des Nvidia-Treibers gleich mitinstallieren.
Zum Vergrößern anklicken....

Die meisten modernen Spiele empfehlen als Untergrenze schon 4 GB RAM. Weniger als 8 GB RAM ist nicht empfehlenswert, zumal 1 GB RAM momentan weniger als 5 EUR kostet.

cabriofahrer schrieb:
Doch was bringt 64-bit wirklich? Nennenswerte Performance-Vorteile beim Kompilieren von ports, encoding von mp3's oder Videodateien? Mehr Geschwindigkeit im Umgang von z.B. KDE4? Gibt es vergleichende Benchmarks unter FreeBSD dafür?
Zum Vergrößern anklicken....

Im Allgemeinen liegt der Unterschied im einstelligen Prozentbereich. Ein paar Anwendungen profitieren massiv von amd64 (u.a. Audio- und Videoencoding, dort halbieren sich teilweise die Zeiten).
Manche großen Anwendungen haben schon Probleme beim Kompilieren unter i386 und müssen dort teilweise Optimierungen abschalten, um überhaupt noch übersetzbar zu sein (Firefox lässt grüßen).

Es gibt heute keinen triftigen Grund mehr, in einem Desktop-Rechner nur 4 GB RAM zu verbauen. Mehr RAM heißt automatisch amd64 (wie Crest ausführlich erläutert hat).
 
Wenn du mal neue RAM Riegel reindrückst, müsstest du vermutlich ohnehin umstellen. Das Einzige was bei mir aus der Reihe fällt ist wine. Das kann ich nicht selbst mit den Ports bauen, aber dafür bauen ein paar Kollegen dankenswerteweise regelmäßig x86-Pakete!
 
Also mich würde mal interessieren welchen Grund es gäbe auf 64bit Hartware 32bit Software laufen zu lassen (ich erwarte keine Antwort die frage ist eher ironisch gemeint), sofern man nicht ein Bestehendes System auf neue Hartware umzieht und nicht alles sofort Neuinstallieren will. Mit 32 compat ist auch das ausführen von 32bit Code möglich und rein logisch sollte 64bit schneller sein. Mit der Möglichkeit größere Daten-Pakete verarbeiten zu können muss die Verarbeitung von großen Datenmengen (Compilen, Datenbank kram, Routing, Verschlüsselung) einfach schneller sein. Bei Graphic lastigen Anwendungen dürfte der unterschied allerdings Marginal sein, da Graphickarten ob nun in 32bit oder 64bit Umgebungen nach erhalt der Graphicdaten alle Berechnungen gleich durchführen. Der einzige unterschied dürfte der Datentransport hin zur Graka bzw wieder zurück von ihr sein.
Angeblich sollen Binärdaten 64bit Compiled größer sein als in 32bit geprüft habe ich das noch nie, jedoch sollte es stimmen ABER nur an stellen wo auch 64bit Befehle notwendig sind, ich gehe davon aus das heutige Compiler das relativ gut umsetzen und der unterschied gering ist.
 
Spätestens am 19.1.2038 haben FreeBSD/i386-Nutzer ein Problem. :) Nein im Ernst. Es gibt eigentlich keinen Grund nicht auf ein 64-Bit System zu setzen. Selbst wenn man weniger als 4GB RAM hat. Alle relevanten Anwendungen laufen, zur Not baut man sich ein 32-Bit Jail. Es ist zukunftssicher und die minimal größeren Binaries in Zweiten von 32 Megabyte Caches de facto irrelevant. Dinge wie ZFS kann man ohne 64-Bit sogar vergessen. Vor allem aber wird im Moment immer wieder diskutiert, wie viel Zukunft FreeBSD/i386 hat. Sicher wird auch FreeBSD 20.0 es noch unterstützen, denn es ist extrem weit verbreitet. Dennoch fragt sich, ob jede Neuerung noch für FreeBSD/i386 kommen wird. Zuletzt ging es z.B. um Verbesserungen an AES-NI. Wieso sich einen Abbrechen und es auf FreeBSD/i386 frickeln, wenn doch jede CPU mit AES-NI Unterstützung auch 64-Bit kann? Im Moment lautet die Antwort "frickeln wir doch", bald aber vielleicht "nein lass mal stecken".
 
Ich hoffe das klingt nicht gar zu arrogant. Aber die Frage heutzutage noch zu lesen hat mich ziemlich überrascht.
 
Ich Frage eigentlich immer, warum noch bei i386 bleiben?

Außer von den kleinen pfSense-Boxen (ALIX.2D3 bzw. 2D13) habe ich nur noch ein legacy Thinkpad X40 in Betrieb.
Die große Mehrheit aller Maschinen freut sich über mindestens 8 GiB RAM...
 
Crest schrieb:
Ging mir ähnlich. Ich dachte auch: "Wo hat der Threadstarter die letzten 10 Jahre verbracht?".
Zum Vergrößern anklicken....

Evtl. in der Windows Welt, da glaubt man ja im allgemeinen nur wenn ich mehr als 4GB RAM habe brauche ich ein 64 bit System, wenn man überhaupt die geringste Ahnung von "diesen PC Dingern" hat. :D

Jetzt aber mal ernst, ich glaube ich war schon sehr forsch bei meiner Antwort, aber beleidigend muss das ja nicht werden oder?
 
Hi,

das bringt uns z.B. beim Thema ZFS Raid (durch`s RAM) natürlich bärigst extrem viel. Das wäre so einer der wichtigsten Punkte aus meiner Sicht. Nachdem abär 64 Bit derzeit überall läuft wo 32 Bit auch ging gibt`s eigentlich keinen Grund mehr auf i386 zu gehen. Auch die Variante mit einer i386 Jail ist ja jederzeit möglich.

Gruß Bummibär
 
Naja, die Wahl hat man ja nur dort, wo 64Bit auch geht und das wird immer öfter der Fall sein.
Wenn ich dann wenig RAM habe, das kommt ja durchaus vor und lässt sich mitunter nicht beheben, dann ist die Frage schon zulässig, was denn 64Bit da bringt.
Aus der Anfangszeit von 64Bit erinnere ich einige Benchmark-Tests, wo die 32Bit Versionen deutlich besser abgeschnitten hatten.
Und wenn es dann vielleicht bestimmte Treiber nur für 32Bit gibt und deshalb dann auch noch gefrickelt werden müsste, dann ist das ja eine durchaus berechtigte Frage, ob es überhaupt sinnvoll ist, sich mit 64Bit anzulegen.

Für mich selbst ist eine Antwort voll einfach, denn ich spiele nie und bin da nicht dafür und würde deshalb FreeBSD ohnehin nicht dafür nehmen und auch nicht empfehlen, egal wieviele Bits.
 
Crest schrieb:
pit234a: Kennst du nen anderes System auf dem ich AssaultCube spielen kann mit einer Load über 30?
Zum Vergrößern anklicken....

mit Sicherheit nicht!
Kenne noch nicht mal den Namen dieses Spieles.
Wie gesagt und an anderer Stelle schon mal etwas deutlicher ausgedrückt: ich spiele nie und halte davon gar nichts. Meine Zeit ist mir dazu viel zu schade und ich bedauere zu erleben, wieviel Energie in diesen unnützen Programmen investiert wird.
Wenn ich also FreeBSD dafür nicht empfehlen will, hat das nichts damit zu tun, dass ich es für weniger geeignet finde. Da kann ich nicht mit sprechen.
 
In Zeiten wo so ne simple Workstation schon 64 GB Ram hat gibts eigentlich keine Gründe mehr für i386. RAM kostet zur Zeit und in Zukunft deutlich weniger als früher. RAM ist durch NICHTS zu ersetzen außer durch mehr RAM oder schnelleres RAM oder mehr und schnelleres RAM :)

Gruß Bär
 
Danke für Eure Antworten. Jetzt habe ich mittlerweile das 64-bit USB-Image heruntergeladen und auf Stick geschrieben, nur um mal zu sehen ob es klappen würde. Und schon stehe ich vor der nächsten Frage: Der installer bietet beim Partitionieren folgende Möglichkeiten an:

ada0 149 GB ATA Hard Disk <Samsung HD 160JJ>
ada1 149 GB ATA Hard Disk <Samsung HD 160JJ>
da0 950 MB Disk
raid/r0 149 GB Disk
raid/r1 149 GB Disk

da0 ist naturlich der USB-Stick, von dem aus installiert wird.
Aber wo soll ich jetzt installieren? Auf ada0 oder auf raid/r1? Wo wäre da der Unterschied?
Auf dem Rechner ist Windows 7 drauf (soll platt gemacht werden) die Festplatten erscheinen getrennt als Lokal Disk C: und D: und sind nicht im sog. Spiegelbetrieb.
 
da startest du am Besten einen neuen Thread, um bessere Antworten von erfahrenen Anwendern zu bekommen.

Bisher habe ich nur einmal ein FreeBSD auf einen Raid istalliert (also mit HW-Raid) und da war es so, dass ich den Raid-Verband vorab aus dem Bios des Kontrollers angelegt hatte und der mir dann wie eine einzige Platte erkannt wurde (wenn ich das noch recht entsinne). Welchen Raid du da nimmst, entscheidet dann auch die Konfiguration des Kontrollers (Spiegel oder einfach zusammenschalten der Platten für mehr Platz).

Wenn du das also nicht hast und nicht willst, dann kannst du eine der anderen Platten nehmen.
Du kannst später immer noch die zweite einbinden und durch Links Verzeichnisse (auch Systemverzeichnisse) dort hin legen.

Bei meiner ersten 64Bit Installation bin ich darüber gestolpert, dass ein Kernel schon etwa 500MB braucht. Wenn du mit unterschiedlichen Kerneln experimentieren willst oder auch nur mal selbst einen bauen möchtest, dann solltest du ausreichend Platz in /boot haben (und wenn das nicht eine eigene Partition wird, ist das ja ein Verzeichnis in / und entsprechend braucht dann / diesen Platz).
 
An RAID bin ich galube ich nicht interessiert, also würde ich die erste Festplatte nehmen und die zweite zum Datenabspeichern verwenden.

Was mir jedenfalls positiv beim Installer aufgefallen ist: Nachdem ich die Installation abgebrochen hatte (ich wollte ja noch nicht installieren oder partitionieren) und in den Live-Modus gewechselt habe, habe ich einfach mal ein "pkg install lynx" eingegeben, um zu sehen, was passiert. Es kam eine Meldung, daß pkg noch nicht installiert sei, ob er es machen sollte. Ich gab ein "y" ein und es kam dann die Meldung, daß http://pkgbeta.freebsd.org/freebsd:9:x86:64/latest/ nicht erreichbar sei.

Klar, das Netzwerk war nicht konfiguriert und der Server enthält die Packages auch noch nicht. Wäre schön zu wissen, wann dies endlich der Fall sein wird...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben