Zitat:
den Punkt hab ich bereits erwähnt: Geschwindigkeitsvorteil durch neue Hardware.
[?] Bei dem Test kam für 32bit und 64bit jeweils
genau dieselbe Hardware zum Einsatz. Die Leistungssteigerung kommt nicht von schnellerer Hardware sondern tatsächlich vom 64bit Betriebssystem.
Zitat:
...bewusst native 64bit Versionen ausgewählt ... andere Compliereinstellung... Also Äpfel mit Birnen...
*seufz* Eben nicht Äpfel mit Birnen, die Compilersettings haben damit nichts zu tun.
Zitat:
sei doch bitte so nett und erklär deinen Praxisbezug zu dem Thema, welches du hier aufrollst. Zwei gleiche Lösungen sind schon rein technisch nicht zu realisieren und die Erfahrung spricht Bände dagegen.
Struppi steht vor einem Betriebssystemwechsel und möchte wissen ob er die 32 oder 64bit Version nehmen soll. Beide kosten das gleiche, können das gleiche, und lassen sich gleich bedienen (Mit anderen Worten, durch einen Umstieg auf 64bit gibt es keine Nachteile). Nur ist eine Version schneller. Laut deinem Kriterium "entscheide ich mich immer für das, was am wenigsten davon macht und am meisten bringt" ist die Sache ganz klar. Beide machen das gleiche, aber eine bringt mehr.
Zitat:
Von Hörensagen weiss ich, das die DAW Foren nur so gespickt mit Fehlerdiskussionen bezüglich '64bit-Versionen' waren/sind (?).
Es geht hier um die Frage nach einem 64bit Betriebssystem, Anwendungen sind ein eigenes Thema. Mit einem 64bit System kannst du 32bit Anwendungen problemlos ausführen und hast trotzdem die angesprochenen Vorteile.
Zitat:
Das ist eben keine Nostalgie, sondern der Hinweis darauf, wie wenig Resourcen eine gut programmierte Anwendung erfordert und wie stabil sie über Jahre OHNE updates laufen kann.
Was genau hat das mit Struppis Frage nach 32 oder 64bit OS zu tun? Wieviel/wenig Ressourcen ein Anwendung braucht und wie gut sie programmiert ist hat genau nichts mit der Frage nach dem Betriebssystem zu tun und taugt deshalb auch nicht zur Entscheidungsfindung für Struppi.
Zitat:
Zitat:
...Hier geht es aber (du erinnerst dich?) um 32bit vs 64bit, und die dafür entscheidenden Teile des Betriebssystems (Kernel, Memorymanager usw) werden allesamt und ausschließlich "per Hand" programmiert.
schön, dass du dabei warst.
[?] Willst du damit andeuten bei der Kernelprogrammierung kämen Codegeneratoren im großen Stil zum Einsatz? In diesem Fall rate ich dir dich mit dem Unterschied zwischen Struktur und Algorithmus/Funktionalität zu beschäftigen. Ein Codegenerator kann nur Struktur automatisch erzeugen, basierend auf einer Modellbeschreibung in irgendeiner Form (z.b. UML). Die Funktionalität bzw. der Algorithmus muss selbstverständlich vom Programmierer selbst programmiert werden. Aus dieser
http://upload.wikimedia.org/wikipedia/en/c/c9/BankAccount.png UML Beschreibung kann ein Codegenerator z.b. die entsprechenden Klassendefinitionen und Methodenrümpfe in einer beliebigen Sprache (C++, Java, Pascal, dotnet...) erzeugen. Der erzeugte Code tut aber noch nichts, denn die Funktionalität (also das was die Methoden deposit() und withdrawl() tatsächlich tun) muss erst vom Programmierer hinzugefügt werden.
http://en.wikipedia.org/wiki/Automatic_programming#Source_code_generation
http://en.wikipedia.org/wiki/Algorithm
Im Kernel dreht sich alles um die Algorithmen und die Funktionalität -> Handarbeit. Kann von einem Codegenerator nicht erledigt werden.
Zitat:
Ich muss gelegentlich mal was im Win32 API nachsehen - das Chaos bereitet mir fast physische Schmerzen und verursacht Brechreiz.
Und bitte erzähl mir nicht, dass die Spacken mit dotNet das Rad tatsächlich runder gemacht haben.
Du scheinst das häufig zu vergessen, darum sag ichs nochmal:
Hier geht es um 32bit vs 64bit, und die dafür entscheidenden Teile des Betriebssystems (Kernel, Memorymanager usw). Darum schrub ich auch folgendes "Du kannst dir sicher sein dass
in den Kernel sehr viel Arbeit(...)" und du kommst darauf mit dem win32-API daher?
Das win32-API ist die Userspace Seite von Windows und hat mit dem Kernel wenig zu tun, ist also für die Frage 32 vs 64bit irrelevant. Es ist nur ein API
http://en.wikipedia.org/wiki/Application_programming_interface, ein Interface. Die eigentliche Funktionalität, das was wirklich wichtig ist, steckt im Kernel, nicht im API.
Der Unterschied zwischen Kernel und Userspace ist die klar?
http://en.wikipedia.org/wiki/Kernel_(computing)
http://en.wikipedia.org/wiki/User_space
Zitat:
Mit noch viel weniger Speicher und erheblich zuverlässiger als das, was du da schilderst. Alles eine Frage der Technik - aus der Zeit stammt übrigens das Gerücht von der sprichwörtlichen Zuverlässigkeit der Macs.
Ahja, das überlegen Speichermanagement der alten Macs... [ooo]
Aus
http://en.wikipedia.org/wiki/Mac_OS_memory_management:
Historically, the Mac OS used a form of memory management that has
fallen out of favour in modern systems. Criticism of this approach was one of the key areas addressed by the change to Mac OS X.
Hier meldet sich einer der Entwickler von Apple zu Wort der direkt an der Betreibssystemprogrammierung beteiligt war, vielleicht wiegt sein Wort bei dir mehr als meins:
Aus
http://www.folklore.org/StoryView.py?project=Macintosh&story=Mea_Culpa.txt:
It's worthwhile to consider, if not apologize for, the worst decisions that I was personally responsible for, as well as other major faults in the system software and product as a whole.
The worst blunder that I perpetrated had to do with the memory manager.
Zitat:
Insofern kann ich von meiner Perspektive (und Erfahrung) die Notwendigkeit eines auf 64bit erweiterten Adressraums absolut nicht nachvollziehen.
Wir reden hier schliesslich nicht von Google oder einer Produktion im Stil von Avatar...
Dann möchte ich dir (und allen anderen die es interessiert) mal die Problematik des zu kleinen Adressraums erklären:
Wie wir alle wissen brauchen Programme Speicher um zu laufen. Woher bekommen sie den Speicher? Sie gehen zum Betriebssystem und sagen "Ich hätte bitte gerne einen Speicherblock der Größe x". Um in weiterer Folge die Problematik zu erfassen ist es nötig zu wissen wie das Betriebssystem den Speicher verwaltet. Sagen wir der Einfachheit halber der Speicher im Computer besteht aus Einheiten die einfach durchnumeriert sind, z.b. s1, s2, s3 ... s100 für einen Computer der 100 "Einheiten" Speicher hat. Das Betriebssystem verwaltet diese Einheiten. Nun geschieht die Verwaltung in allen modernen Betriebssystemen nicht direkt, sondern über den sogenannten virtuellen Speicher
[URL]http://en.wikipedia.org/wiki/Virtual_memory[/url]
D.h. das Betriebssystem hat einen Satz virtuelle Speichereinheiten v1, v2, v3 ... v200 und es gibt einen speziellen Teil im Prozessor der sich um die Umrechnung von virtuellen Adressen v in reale Speicheradressen s kümmert (Die Memory Management Unit
http://en.wikipedia.org/wiki/Memory_management_unit)
Nun kommt ein interessanter Punkt: Die Größe des realen Speichers und des virtuellen Speichers kann durchaus unterschiedlich sein. Die Größe des realen Speichers hängt davon ab wieviel RAM man tatsächlich im Rechner hat, die Größe des virtuellen Speichers, und das ist das Problem, hängt von der Architektur ab: Bei 32bit ist der virtuelle Speicher immer 4GB groß (unabhängig davon wieviel realen Speicher man im Rechner hat), bei 64bit ist der virtuelle Speicher zig Milliarden Terabyte (!!) groß.
Nehmen wir für das Beispiel an der reale Speicher ist 100 groß und der virtuelle 200, das entspricht in etwa dem (nicht so unüblichen) Fall 32bit Betriebssystem mit 2GB Speicher. Am Anfang ist sowohl der reale als auch der virtuelle Speicher frei.
Was passiert nun wenn ein Programm zum Betriebssystem kommt und sagt "Ich hätte gerne einen Speicherblock der Größe 3"? Das Betriebssystem sieht in seinem virtuellen Adressraum nach und sieht das alles frei ist, kein Problem, das Programm bekommt die virtuellen Adressen v1-v3 und das Betriebssystem markiert diese Adressen als "belegt". 2 Punkte sind hier wichtig: Erstens
muss der Speicher zusammenhängend sein, d.h. wenn ein Programm einen Speicherblock der Größe 3 anfordert dann kann es die Adressen v1-v3, v5-v8, v47-v50 usw. bekommen, alles kein Problem. Was nicht geht ist dass es die Adressen v2, v5 und v27 bekommt, dieser Speicher wäre nicht zusammenhängend. Zweitens
ist es egal welche realen Speicheradressen verwendet werden. Sowohl das Betreibssystem als auch das Programm brauchen sich nicht um die Umrechnung von virtuellen in reale Adressen kümmern, das macht der Prozessor selbst. Wenn am Anfang alles frei ist dann werden die virtuellen Adressen v1-v3 auf die realen Adressen s1-s3 zeigen, es könnte aber ohne weiteres sein dass die virtuellen Adressen v1-v3 auf die realen Adressen s5-s8 zeigen, oder auf s33-s36 oder auch auf s68-s71. Es kann auch sein dass die virtuellen Adressen v1-v3 auf die realen Adressen s3, s7 und s87 zeigen, das ist wichtig! Der virtuelle Speicher muss zusammenhängend sein, der reale Speicher nicht. Das geht deshalb, weil die Einheit die sich um das umrechnen kümmert Teil der Hardware ist, und nicht Teil des Betriebssystems/der Software. Das Betriebssystem weiß nur dass vom realen Speicher 3 Einheiten belegt sind, welche das im speziellen sind ist unwichtig.
Nun arbeitet man mit dem Programm und dabei kommt es unweigerlich vor dass das Programm neuen Speicher braucht, z.b. weil man im Browser ein neues Tab öffnet oder ein neues Projekt in die DAW lädt. Das Programm geht wieder zum Betriebssystem und sagt "Ich hätte gerne einen Speicherblock der Größe 15 - es ist eine sehr aufwändige Website oder ein sehr großes Projekt. Das Betriebssystem schaut im virtuellen Adressraum nach und sieht das noch genug frei ist, vom realen Speicher weiß es dass noch 97 Einheiten frei sind. Kein Problem, das Programm bekommt die Adressen v4-v19 und das Betriebssystem markiert diese als "belegt".
Nach einer Weile entscheidet das Programm dass es den ersten Speicherblock (mit der Größe 3) nicht mehr braucht, z.b. weil der nur am Anfang zum starten des Programms verwendet wird. Es gibt diesen Block frei indem es zum Betriebssystem geht und sagt "Ich brauche den Speicherblock v1-v3 nicht mehr". Das Betriebssystem markiert diese Adressen als "frei" und registriert außerdem dass jetzt noch 85 Einheiten realer Speicher frei sind (es sind jetzt nur mehr die 15 angeforderten in Verwendung). Das geht ein Weile so dahin und es könnte sich schließlich folgendes Bild des virtuellen Adressraums ergeben:
Code:
|v1 v10 v20 v30 usw v200|
|...xxxxxxxxxxxxxxx..xxx....x.....xxx......xx...|
. bedeutet die virtuelle Adresse ist frei, x bedeutet sie ist belegt. Nun braucht das Programm wieder neuen Speicher, es geht zum Betriebssystem und sagt "Ich hätte gerne einen Speicherblock der Größe 5". Das Betriebssystem weiß dass noch (beispielsweise) 42 Einheiten realer Speicher frei sind, von daher kein Problem. Aber es kann nicht die virtuellen Adressen v1-v3 verwenden. Die sind zwar frei, aber der virtuelle Speicher
muss zusammenhängend sein. Die erste Möglichkeit dafür ist nach der einzelnen belegten Adresse zwischen v20 und v30. Diese Adressen bekommt das Programm und danach sieht der virtuelle Adressraum folgendermaßen aus:
Code:
|v1 v10 v20 v30 usw v200|
|...xxxxxxxxxxxxxxx..xxx....xoooooxxx......xx...|
Die mit 0 markierten Stellen sind die neu hinzugekommenen belegten virtuellen Adressen. Dieses Phänomen dass zwar virtuelle Adressen frei sind, das Betriebssystem diese aber nicht verwenden kann nennt man Fragmentierung und das ist der Kern des Problems.
http://blogs.msdn.com/b/david.wang/...entation-and-leaks-and-wow64.aspx?PageIndex=2
http://en.wikipedia.org/wiki/Memory_fragmentation
Was passiert z.b. wenn die Speichernutzung folgendermaßen aussieht: immer 6 Einheiten belegt, 14 frei, 6 belegt, 14 frei usw. Insgesamt sind dann 60 Einheiten belegt (10 Blöcke zu je 20 Einheiten davon sind jeweils 6 belegt und 14 frei). D.h. vom realen Speicher sind noch 40 Einheiten frei (100-60=40). Jetzt kommt ein Programm und möchte einen Speicherblock der Größe 15 haben. Das Betriebsystem weiß dass noch 40 Einheiten realer Speicher frei sind, von daher kein Problem. Im virtuellen Adressraum ist jedoch
der größte verfügbare zusammenhängende Block nur 14 groß. Obwohl noch insgesamt 40 Einheiten realer Speicher frei sind kann das Betriebssystem keinen virtuellen Speicherblock der Größe 15 finden. Weil der virtuelle Adressraum so stark fragmentiert ist. Die Anforderung des Programms kann nicht erfüllt werden und es gibt im besten Fall nur eine Fehlermeldung, im schlechtesten stürzt das Programm ab.
Was passiert wenn man in diesem Fall auf eine 64bit Architektur umsteigt? Die Menge an verfügbarem realen Speicher bleibt gleich, aber die Menge an virtuellem Speicher steigt exorbitant an. Das bedeutet dass für genau das gleiche Beispiel (10 Blöcke zu je 20 Einheiten, jeweils 6 belegt und 14 frei) der virtuelle Addressraum folgendermaßen aussieht: Von v1-v200 sind wie oben je 6 belegt und 14 frei, von v200 aufwärts (es geht dann ungefähr bis v100000000000 [
] ) ist alles frei. Wenn jetzt ein Programm kommt und sagt "Ich hätte gerne einen Speicher der Größe 15, dann weiß das Betriebssystem dass noch 40 Einheiten realer Speicher frei sind (diese Menge hat sich nicht geändert), von daher kein Problem. Dann schaut es in den virtuellen Adressraum und sieht das auch dort noch jede Menge frei ist und das Programm bekommt die Adressen v201-v216, alles in Butter. So siehts aus. [
]
Das ganze hat im übrigen nichts mit Google oder Produktionen wie Avatar zu tun, Speicherfragmentierung ist ein Problem das
immer und unweigerlich auftritt. Beim Arbeiten mit Word genauso wie beim surfen im Internet oder auch beim Rendern von Avatar. Es wird umso schlimmer je länger die Anwendung (bzw. der Rechner) läuft und je größer die Datenmengen sind mit denen das Programm umgeht. Und bei Audiobearbeitung sind die Datenmengen ja nicht gerade klein, natürlich wird man beim Briefschreiben in Word viel weniger an diese Grenze stoßen.
Außerdem kommt es umso stärker zu tragen je näher die Menge an realem Speicher an der Menge an virtuellem Speicher dranliegt. 32bit System (4GB virtueller Speicher) und 2GB RAM geht noch einigermaßen (das ist ungefähr das obige Beispiel), bei 4GB RAM wirds schon eher eng.
Hoffe damit etwas Licht ins Dunkel gebracht zu haben.
