MacBook 32 bit oder 64 bit

[abi]

also ich finde die diskussion hier ebenfalls sehr interessant. auch wenn ich leider nicht allzu viel verstehe

 

[MacMark]

Windows hat eh mit 64 Bit mehr Probleme: Sie haben keine Fat Binaries und sie haben kein LP64-Programming-Model sondern das LLP64. Hier steht, warum LP64 in vieler Hinsicht besser ist:
http://www.unix.org/version2/whatsnew/lp64_wp.html

 

[below]

Back to Topic: Auch zum Beispiel VMWare Fusion ist noch nicht K64 kompatibel, auch daher sollte man sich gut überlegen, ob es sinnvoll ist, auf 64 Bit umzustellen:

"However, VMware Fusion 2.0.5 is NOT compatible with the optional 64-bit kernel of Snow Leopard and Snow Leopard Server. For most users, this will not be a problem, as the 64-bit kernel of Snow Leopard only starts up by default only for Snow Leopard Server on 2008 and 2009 Xserves."
http://blogs.vmware.com/teamfusion/...-2-and-max-os-x-snow-leopard-even-better.html

@MacMark: Lügt VMWare hier? "The transition to the 64-bit kernel of Snow Leopard is a major undertaking and something that we are taking seriously as we plan future products."

Alex

 

[Jamsven]

Windows hat eh mit 64 Bit mehr Probleme: Sie haben keine Fat Binaries und sie haben kein LP64-Programming-Model sondern das LLP64. Hier steht, warum LP64 in vieler Hinsicht besser ist:
http://www.unix.org/version2/whatsnew/lp64_wp.html

Naja ich habe grade ein "64 Bit Transition Guide" von Apple gefunden. Das ist nicht ohne Grund 74 Seiten stark. Ich werde es mir heut Abend mal durchlesen.
http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/64bitPorting/64bitPorting.pdf

 

[MacMark]

-> below
Die Virtualisierung kompletter Gastbetriebssysteme ist ein extremer Fall.

--> Jamsven
Darin wirst Du einige meiner Aussagen wiederfinden (Register statt Stack beispielsweise)

 

[Jamsven]

-> below
Die Virtualisierung kompletter Gastbetriebssysteme ist ein extremer Fall.

--> Jamsven
Darin wirst Du einige meiner Aussagen wiederfinden (Register statt Stack beispielsweise)

Du meinst den Myth 5 auf S12. Jedoch sagt er auch das ein Peformancegewinn nicht per se eintritt.

Jedoch empfiehlt Apple unter S62 auch, dass man als Treiberentwickler den Code "64 Bit Clean" haben muss. Die schreiben zwar auch, dass generell die rekompilierten auf IOKit basierenden Treiber laufen sollten, aber wir kennen ja Murphys Gesetz. Deswegen sollte der Code auf die möglichen Probleme getestet werden.

Generell denke ich aber, das besonders schlecht geschriebene Projekte überarbeitet werden müssen.
Ich muss dazu sagen Treiber und IOKit Erfahrung hab ich nicht.

 

[MacMark]

Und klingt das schwierig?

 

[Jamsven]

Und klingt das schwierig?

Es wird den Herstellern Geld und Kapazitäten kosten. Da wäre ein eventueller HW Neukauf seitens der Anwender für die Hersteller günstiger.

Rastafari hat ja auch so einen Kameraden genannt:

Weil ich mit der Fa. schon ein paar Begegnungen hatte.
"Heiauweia" - "Option" - "intel WiFi Group" --> alles die gleiche Manufaktur.
Marktabdeckung gefühlte 95%, möglicherweise auch reale 100,0% ???

Die bringen Updates wirklich nur dann, wenn eine explizit zugesagte Funktion bei einem aktuell vertriebenen Modell versagt (weil das den Umsatz gefährdet). Fortgeführte Pflege für ausgelaufene Produkte -> Fehlanzeige, da verkauft man lieber das Nachfolgemodell. Und da sich die Modelle alle 2-4 Wochen abwechseln... halten sich die Kosten für Supportleistungen in Grenzen. (Milde formuliert)

 

[below]

Und klingt das schwierig?

Klingt was schwierig, Treiber Code 64 Bit clean zu bekommen, oder ihn zu testen?

Bei Treiber Code ist die grosse Frage, wann der das letzte mal angefasst wurde. Wenn zum Beispiel die vollständige Umstellung auf IODMACommand und neue Kernel Interfaces schon passiert ist, sind die Änderungen eher gering.
Wenn nicht.... dann ist einiges zu tun. Aber ganz ohne Änderungen wird es in den wenigsten Fällen gehen.

Und wie gesagt, das ist ja im Normalfall gar nicht das schlimmste, sondern die anfallende QA.

Kurzum: Es ist nicht zum Nulltarif zu haben. Schon gar nicht, wenn es sich zum Beispiel um Treiber für RAID Systeme handelt, an die die Kunden -- mit gutem Recht -- höchste Anforderungen betreffend Qualität und Sicherheit haben.
Da ist es mit "Einmal -arch Flag setzen" nicht getan

Alex

 

[nerd99]

MacBook's & MacMini's dürften normalerweise nicht im 64-bit Modus laufen....

also nicht ärgern wenns ned klappt !

 

[MacMark]

Klingt was schwierig, Treiber Code 64 Bit clean zu bekommen, oder ihn zu testen?
… Umstellung auf … neue Kernel Interfaces schon passiert ist, sind die Änderungen eher gering.
Wenn nicht.... dann ist einiges zu tun. …
Und wie gesagt, das ist ja im Normalfall gar nicht das schlimmste, sondern die anfallende QA.
…

Du hattest ja gestern nach professioneller Softwareentwicklung gefragt: Mit testgetriebener Entwicklung würde man die bestehenden Tests gegen das 64er Compilat laufen lassen, sofort sehen, ob und wo Probleme auftreten und die gezielt beheben.

Wenn man natürlich solche alte Leichen im Keller des Projektes hat, wie Du oben nennst, dann ist das Problem nicht die 64-Bit-Umstellung, sondern vernachlässigter Code.

Kurz: Wenn man professionell testgetrieben entwickelt, hat man saubereren Code, eine automatisierte Testsuite, die die Anforderungen jederzeit prüfen kann und kaum Sorgen mit der Umstellung.

Frag nicht wieder, woher ich das alles weiß

Wie bitte? Das stimmt sicherlich für Code der Marke "int x = 25;". Für mehr aber auch nicht. Mach dir mal den Spaß und ruf bei der Firma [Name aus Rücksicht gelöscht] an und frag nach warum die über 2 Jahre gebraucht haben um von 32-Bit auf 64-Bit umzustellen. …

Ich habe da eine Vermutung

Erst wenn du mir erklärst, warum mehr Register einen Code beschleunigen sollten, der sie gar nicht braucht.

Möglicherweise hast Du meine Antwort von gestern verpaßt, denn ich habe keine Antwort darauf gesehen, darum wiederhole ich meine nochmal explizit:
Mit x86_64 werden (die ersten sechs) Funktions-Argumente nicht mehr über den Stack (wie beim 32er x86 Code), sondern über die Register übergeben. Das ergibt eine erhebliche Beschleunigung. Der Kernel ist voll von solchen Funktions-Aufrufen und benutzt daher auch dafür in der 64er Version all die schönen Register.

 

[below]

Kurz: Wenn man professionell testgetrieben entwickelt, hat man saubereren Code, eine automatisierte Testsuite, die die Anforderungen jederzeit prüfen kann und kaum Sorgen mit der Umstellung.

Frag nicht wieder, woher ich das alles weiß

Muss ich nicht. Das weisst Du aus dem Märchenbuch der Softwareentwickler.

Alex

 

[abi]

eine frage habe ich noch: kann ich bei einem 32bit-os mehr als 4gb ram ansprechen oder benötige ich dafür explizit ein 64bit-os?

 

[below]

eine frage habe ich noch: kann ich bei einem 32bit-os mehr als 4gb ram ansprechen oder benötige ich dafür explizit ein 64bit-os?

Also: Auch mit dem 32 Bit Kern kann man mehr als 4 GB RAM verwalten... wie sonst hätten das die MacPros bis 10.6 gemacht?

Und selbst in diesen MacPros schaltet Apple den Kern standardmäßig auf 32 Bit.

Einen 64 Bit Kern brauchst Du erst, wenn Dein RAM in den dreistelligen Bereich kommt, da dann der Kern selbst Platzprobleme bekommt, diesen riesigen Speicher zu verwalten.

Alex

 

[Unkaputtbar]

Halte ich für ein Gerücht, aber wer es glauben mag...

Mein XServe kann dank 64-Bit nun auch Kaffe kochen...

Ironie oder wird der XServe wirklich so heiß unter SL?

Manuel

 

[abi]

Also: Auch mit dem 32 Bit Kern kann man mehr als 4 GB RAM verwalten... wie sonst hätten das die MacPros bis 10.6 gemacht?

Und selbst in diesen MacPros schaltet Apple den Kern standardmäßig auf 32 Bit.

Einen 64 Bit Kern brauchst Du erst, wenn Dein RAM in den dreistelligen Bereich kommt, da dann der Kern selbst Platzprobleme bekommt, diesen riesigen Speicher zu verwalten.

Alex

danke für die info. aber zum beispiel windows xp (nicht 64bit) kann ja nicht mehr als 4gb ram ansprechen, oder?

 

[MacMark]

… kann ich bei einem 32bit-os mehr als 4gb ram ansprechen oder benötige ich dafür explizit ein 64bit-os?

Ja, aber nicht so einfach und komfortabel. Zum Beispiel kann ein Programm mit Hilfe von mmap() und munmap() mehr als 4 GB nutzen, dann aber nicht zeitgleich mehr als 4 GB am Stück, sondern zeitversetzt.

 

[FrankR]

Du hattest ja gestern nach professioneller Softwareentwicklung gefragt: Mit testgetriebener Entwicklung würde man die bestehenden Tests gegen das 64er Compilat laufen lassen, sofort sehen, ob und wo Probleme auftreten und die gezielt beheben.

Wenn man natürlich solche alte Leichen im Keller des Projektes hat, wie Du oben nennst, dann ist das Problem nicht die 64-Bit-Umstellung, sondern vernachlässigter Code.

Kurz: Wenn man professionell testgetrieben entwickelt, hat man saubereren Code, eine automatisierte Testsuite, die die Anforderungen jederzeit prüfen kann und kaum Sorgen mit der Umstellung.

Frag nicht wieder, woher ich das alles weiß

Hmm, mich würde das aber wirklich interessieren - entwickelst Du *wirklich* professionell Software - also so richtig "von Hand" mit Editor, Compiler & Co - oder gibst Du einfach nur theoretisches Wissen von Dir?

Auch noch so schöne automatisierte Tests können nur das testen an was schon beim Design der Tests gedacht wurde, und spezifische Probleme der 32/64 Bit umstellen waren zu der Zeit ggf. überhaupt kein Thema...

Der Transition-Guide von Apple beschreibt schon ein paar Probleme, die u.U. in der realen Welt "etwas" Arbeit verursachen.

 

[MacMark]

-> FrankR

Neue Anforderungen ergeben zusätzliche Tests. Die alten Anforderungen und deren Tests bleiben aber bestehen und man sieht daran, ob man was kaputt macht. Das Softwaredesign ergibt sich teilweise aus testgetriebener Entwicklung. Ist ne Art Ping-Pong-Spiel.

 

[below]

Hmm, mich würde das aber wirklich interessieren - entwickelst Du *wirklich* professionell Software - also so richtig "von Hand" mit Editor, Compiler & Co - oder gibst Du einfach nur theoretisches Wissen von Dir?

Das ist ganz offensichtlich eine Frage, die er nicht beantworten möchte.

Ich würde die Firma, in der TDD auf die von MacMark beschriebene Art und Weise betrieben wird, wirklich gerne mal kennenlernen.

Alex