Nutzt ihr 64-Bit Anwendungen?

Ich nutze ausschließlich 64 bit OS auf allen neueren Rechnern. Sowohl Windows als auch Arch.

Das bei mir XP noch als 32-Bit rennt, ist ja auf einem Netbook klar. So oder so unterstützt Atom kein 64-Bit.
Auf meinem Hauptrechner läuft 64-Bit und bisher hatte ich nur Probleme mit älteren Anwendungen. Da half VirtualBox aus, dort rennt ein XP 32-Bit. Machen Programme laufen hier zwar im 64-Bit, aber auch nur die Speicherhungrigen.

Zitat von niwax

Kann man sich eig auch denken, wenn dass Programm genug Addressraum kreigt, dass beide Dateien (original & komprimiert) reinpassen, ist das natürlich schneller als mit Auslagern auf die Festplatte.

Der Adressraum war aber nur bis 1.5GB als RAM verfügbar. Und da haben 32Bit Systeme auch keine Schwierigkeiten voll darauf zuzugreifen.

Zitat von Ebbi

Welchen Vorteil hätte ich von 64-Bit Anwendungen, außer dass pro Prozess mehr als 2GB RAM allokiert werden können?

es gibt doppelt so viele general purpose- und SSE-Register, außerdem wird SSE standardmäßig für FP-Berechnungen verwendet und es gibt keine Speichersegmentierung mehr

die größere Menge addressierbaren Speichers bringt natürlich auch nur etwas, wenn man überhaupt auch so viel RAM hat

Zitat von husan

Das bei mir XP noch als 32-Bit rennt, ist ja auf einem Netbook klar. So oder so unterstützt Atom kein 64-Bit.
Auf meinem Hauptrechner läuft 64-Bit und bisher hatte ich nur Probleme mit älteren Anwendungen. Da half VirtualBox aus, dort rennt ein XP 32-Bit. Machen Programme laufen hier zwar im 64-Bit, aber auch nur die Speicherhungrigen.

Echt? ich dacht die Atom 400-500 Serie kann es weil:
MMX, SSE, SSE2, SSE3, SSSE3, Intel 64, XD-Bit, Hyper-Threading, EIST (nur Nxxx)

Qulle: Wikipedia

Und CPU-z spuckt das selbe bei unseren N450 aus. Naja aber ob 64 Bit auf einem Netbook was nützt ist eine andere Sache, weil so oder so sind meistens nur 2GB RAM möglich.

Unter Windows: nö, ich hab so viel alte sachen, auch 16bit, das wär nix. Vom Scannertreiber mal ganz zu schweigen, der is eigl maximal für XP, die Installation unter 7 x86 war schon schlimm genug
Linux: hmm, eventuell bald mal. In 3 Tagen kommt das neue openSUSE raus, da muss ich sowiese fast 5 GiB runterladen, könnt ich auch grad 64bit nehmen, muss ich halt noch knapp 300MiB VMware 64 bit runterladn, sonst nutz ich da eh nur SuperTux (unstable, d.h. ich muss es sowieso kompilieren) und VBox (gibts für 64) und VMware (auch) und QEMU (kompilieren, ergo auch)
Zurzeit ist meiun Slack aber noch 32-bittig.

Zitat von oreissig

es gibt doppelt so viele general purpose- und SSE-Register, außerdem wird SSE standardmäßig für FP-Berechnungen verwendet und es gibt keine Speichersegmentierung mehr

Und was bringt mir das?

der rechner gibt mehr gas beim arbeiten?

Zitat von Ebbi

Und was bringt mir das?

primär bringt das dem compiler was, was sich für dich u.U. in schnellerem code äußert
aber wer will das schon?

Ich find die Fortschrittsverweigerer toll, wenns nach den geht, wären wir noch auf den Stand von ~1998

Selbst ich installiere 64 Bit auf nur 1GB Maschinen.. In vielen Programmen wie Winrar oder Audio Konvertierung, merkste den Unterschied von 32 auf 64 Bit gut deutlich..

Zitat von Blue

Ich find die Fortschrittsverweigerer toll, wenns nach den geht, wären wir noch auf den Stand von ~1998

Naja, ich bin ja auch so jemand, dem locker noch Technik von vor 7 Jahren ausreicht Aber 1998 finde ich nun doch etwas früh... Lieber 2000: Da gabs schon Windows 2000 und Office 2000, mehr brauche ich fast nicht

Und weswegen "Fortschrittsverweigerer"? Ich meine, wenn du mit dem was du hast, gut zurecht kommst und die Technik für deine Aufgaben vollkommen genug ist, warum solltest du dann umsteigen? Klar, wenn du die Leistung eines modernen Rechners absolut brauchst (für welche Anwendung auch immer), dann sehe ich keinen Grund dafür sich dem Fortschritt zu verweigern. Schließlich isses beim Rechner ähnlich wie beim Automobil. Nur weil es da ein neues Modell gibt (oder weil ein Elektro-Auto gerade "in" ist), haust du dein Auto, was vielleicht 5 Jahre auf dem Buckel und gerade mal 70000 auf der Uhr hat, doch auch nicht gleich auf den Schrott, oder? ;D

Ich glaube Blue meint vielmehr die Leute, die sich weigern, auf neue Versionen umsteigen wollen, weil sie ihnen nicht in den Kram passen, und sich damit immer mehr den Zugang zu neuen System versperren, weil sich die Formate, Benutzeroberflächen und Workflows zu weit weg entwickelt haben.

Es gibt nen Unterschied zwischen: "Ich update nicht, das neue ist zwar gut, aber das alte reicht mir noch" und "Ich update nicht, das neue ist doof, drum bleib ich beim alten".

Letztere übersehen schlichtwegs, dass es längerfristig keine Lösung ist und sie sich den späten Umstieg nur noch schwerer machen. Beispiel: Die Ribbon-Oberfläche aus MS Office 2007: Die wird die nächsten 10 Jahre einfach da sein. Und in den nächsten 10 Jahre wird sich .docx auch durchsetzen. Der Aufwand, auf jetzt auf Ribbons umzusteigen ist ein Vielfaches geringer als in 10 Jahren dann auf eine Office umzusteigen zu müssen, was nicht nur Ribbons, sondern eine komplett andere Oberfläche und andere Dateiformate hat.

Zitat von gandro

Es gibt nen Unterschied zwischen: "Ich update nicht, das neue ist zwar gut, aber das alte reicht mir noch" und "Ich update nicht, das neue ist doof, drum bleib ich beim alten".

naja letztere argumentieren doch aber auch mit ersterem, es ist nur nen unterschied ob man heute noch mit nem Core 2 zufrieden ist und nich gleich auf Core i umstellt, oder ob man heute ernsthaft noch mit Office 2000 Textverarbeitung machen will und 1. die meisten aktuellen Dokumente netmehr problemlos öffnen kann und 2. alle Leute um einen rum mit Dokumenten bestraft, die die nicht mehr richtig öffnen können

Zitat von xCtrl

der rechner gibt mehr gas beim arbeiten?

Du scheinst dir deiner Aussage selbst nicht sicher zu sein, da du das als Frage formulierst.

Zitat von oreissig

primär bringt das dem compiler was, was sich für dich u.U. in schnellerem code äußert
aber wer will das schon?

64-Bit-Anwendungen sind nicht grundsätzlich schneller als ihre 32-Bit-Gegenstücke. Das 64-Bit-Programm belegt mehr Speicher, da Zeiger darin immer 64 Bit groß sind. Dadurch kann der Prozessor weniger Daten und Instruktionen im schnellen Cache halten und muss häufiger auf den langsameren Hauptspeicher zugreifen, was Leistung kostet.

Quelle: Umsteigen auf 64 Bit | c't

Zitat von Blue

Ich find die Fortschrittsverweigerer toll, wenns nach den geht, wären wir noch auf den Stand von ~1998

Mit vollen Hosen ist gut stinken, gell?
Viele Jahre lang war Microsoft der Fortschrittsverweigerer, guck mal hier wie lange es schon andere 64-Bit Plattformen gibt: 64-Bit-Architektur – Wikipedia

Zitat von Ebbi

64-Bit-Anwendungen sind nicht grundsätzlich schneller als ihre 32-Bit-Gegenstücke. Das 64-Bit-Programm belegt mehr Speicher, da Zeiger darin immer 64 Bit groß sind. Dadurch kann der Prozessor weniger Daten und Instruktionen im schnellen Cache halten und muss häufiger auf den langsameren Hauptspeicher zugreifen, was Leistung kostet.

Quelle: Umsteigen auf 64 Bit | c't

Da erzählst du mir nichts neues, aber du hast ja nicht gefragt, ob 64bit schneller ist, sondern was die doppelte Anzahl an Registern usw bringt
Es kommt halt auf den Anwendungsfall drauf an, ob die Sache eher speicherbandbreiten- oder registerlimitiert ist. Das Mehr an Registern erspart außerdem so manchen Speicherzugriff.

Seit 1961 gibt es 64-bit schon o_O

Im überigen sind Pointer bei 64bit nicht zwingend immer 64bit gross, AMD hat bei AMD64 programm-counter-relative Adressen eingeführt, so dass man relative "Pointer" verwenden kann, die nicht die vollen 64bit ausfüllen müssen.

Gerade standardmässiges SSE bringt dem Compiler einiges bei nicht-optimierten Standard-Anwendungen, und da läuft 64Bit dann auch im Einzelfall signifikant schneller.