Interessanter Thread Apple<>64Bit

Hi Anstaltsinsassen!

für alle die das Thema 64Bit-"Unterstützung" seitens
Apple interessiert - hier mal ein sehr interessanter Link >
http://www.apfeltalk.de/showthread.php?threadid=15331

Die MW-Götter mögen mir den Link auf auf den "Mitbewerber" verzeihen irat:

 

Joh. Ich dachte es wäre hinlänglich bekannt, dass 64 Bit beim Mac OS X eher eine kleine Mogelpackung sind, da keine GUI Unterstützung. Die Diskusssion dort erstaunt mich doch etwas.

Ich persönliche habe etwas Bammel, ob Apple den "Switch" mit parallelem 32 Bit und 64 Bit Interface mittelfristig halbwegs hinbekommt. Da hat MS mit seiner WOW Technik, die schon beim 32 Bit Sprung eingesetzt wurde durchaus einen technologischen Vorsprung.

 

Das hatte ich hier vor ein paar Tagen auch schon mal beklagt. Bis zum Erscheinen der 64 Bit Win Version von C4d, war mir nämlich auch nicht klar, wie sehr OSX da bisher noch limitiert ist.

 

Cool, danke für den Link

Kalle

 

Jo. Sehr schade das Apple da so gute Leute wie von Maxon und letztendlich die Anwender etwas im Regen stehen lassen.
Gerade so fähige Leute wie bei Maxon stehen nicht nur auf Mac, sondern auch zum Mac. Die würden ja gerne, wie mensch Lesen kann in einem Statement.

Ich kann nur für uns C4Dler und natürlich für alle in der Gemeinde hoffen das dieser Zustand GUI 32 Bit, Core 64 Bit, auch von Apple bald aus der Welt geschaffen sein wird. Tiger wäre da ein guter Startpunkt gewesen.
Bin aber kein Proggi… "nur" Anwender.
Mich stört dann "nur" das die Windoofler dann eine wirklich bessere Performance unter C4D haben, als wir Macianer.
Was dann trotz plattformübergreifenden Konzept von Maxon (was sehr, sehr lobenswert ist!) dazu führt das es in absehbarer Zeit doch ein Zweiklassensytem (Performance) gibt. :meckert:

 

Gute Leute wie von Maxon
Na ich weiß ja nicht...

Kalle

 

Na ja, wollte eh schon länger auf Softimage wechseln, daß kenn ich noch von früher und jetzt kann man sich das ja auch als Einzelkämpfer leisten. Da gibts neben einem ordentlichen Renderer auch ein korrektes Speichermanagement, so daß man auch ohne 64 Bit keine RAM Probleme mehr bekommt.

Nur schade das es keine Mac Version gibt.

 

Kannst du Gegenteiliges dazu berichten?

Ich bin bisher sehr, sehr zufrieden. Das sind echte Macianer,
schneller und kompetenter Support sowie ein faires Preis-/leistungsverhältnis.
Die Mac und DOSenversion wird immer gleichberechtigt programmiert.
Daten sind problemlos plattformübergreifend austauschbar.
C4D ist ein offenes Programm, was auch mit Third Party Renderern wie maxwell etc. klaglos zusammenarbeitet.

Der modulare Aufbau von C4D ist ein Hit. Ein preisgünstiges Grundpaket - mit bezahlbaren Modulen zum Aufrüsten nach Bedarf oder Gusto.
Was will ein 3dimensionaler Macianer mehr?

Die Folks von Maxon antworten schnell und freundlich auf eMails.
So z.Bleistift:
es ist für Entwickler schwierig ein Programm auf 64 Bit
umzusetzen wenn es eine GUI benötigt, aber lediglich
Comandozeilenprogramme in 64 Bit laufen können.

Erst wenn Apple das gesamte MacOS 10 in 64 Bit zu Verfügung
stellt und nicht die GUI noch in 32 Bit läuft, erst dann ist es
möglich CINEMA 4D sinnvoll darauf umzusetzen.

Und wenn das der Fall sein sollte wird CINEMA 4D nicht schneller
Arbeiten als vorher. Es wird lediglich mehr Arbeitsspeicher
ansprechen können.

Der Geschwindigkeitszuwachs für die 64 Bit Version von CINEMA 4D
unter Windows resultiert lediglich daraus, das hier keine
Kompatibilität zu älteren Pentium und AMD Prozessoren mehr
benötigt wird.

Mit freundlichen Grüßen,
Kind regards,

Jörn Gollob

 

Hier steht doch alles drin. Eine Geschwindigkeitssteigerung hätte ich ausgeschlossen, denn diese Diskussion hatten wir ja hier schon.
32Bit<-->64Bit

Die Begründung 32Bit GUI und 64Bit Core für ein Programm = schwere Umsetzung ist nicht ganz so

Wenn man die Speicherverwaltung und Berechnungen usw.(also alles was Vorteile bringt) in 64Bit schreibt und eine vernünftige Schnittstelle zur GUI, die ja nun noch 32Bit ist, programmiert funktioniert das ohne Probleme. Nur wird den Leuten der "Aufwand" zu groß sein. Hätten sie ihre Software gleich ordentlich geschrieben wärs vielleicht besser/leichter gegangen. :biggrin:

Bei 32Bit kann man "nur" 4GB Speicher verwalten
bei 64Bit kann man dann eben schon 17179869184GB verwalten

Kommt halt drauf an ob man das unbedingt morgen braucht!

 

Ganz genau das ist auch meine Meinung... Die Jungs scheuen nur den Mehraufwand. Die Tiger 64bit Lösung ist garnicht mal so dumm wie alle immer munkeln. Gerade beim GUI würde man die 64bit sowieso am wenigsten bemerken.

 

Da bin ich leider anderer Meinung, komplexe 3D Szenen muss man nicht nur final rendern, sondern vorher auch bearbeiten - und das geschieht nun mal in der GUI. Auch bei Compositing und 2D Animationssystemen würden mehr als 4GB Sinn machen, viele solche Programme nützen exzessives RAM caching, wobei bereits geladene und berechnete Elemente im Hauptspeicher gehalten werden, damit sie nicht bei jeder Veränderung neu gerechnet bzw geladen werden müssen. Wenn man bedenkt, das eine Sekunde unkomprimiertes HD Video bei 8 Bit Farbtiefe schon ca 100 MB Platz braucht, kann man sich leicht den RAM Bedarf für einen 30 sekündigen Clip mit 10 Layern (was eher wenig ist) ausrechnen.
Von 10 oder gar 16 Bit Material will ich gar nicht erst anfangen, da wirds vollkommen Uferlos.

 

Soso, echte Macianer?
Mac OS 10? 10? 10 würde ein echter Macianer nicht schreiben...
Gegenteiliges berichten?

Bis vor kurzem stand auf der Maxon HP, dass es noch keine G5 Version gibt, da man noch auf G5 Compiler wartet... IBMs VisualAge gibt es aber schon seit Januar 2004.

Kalle

 

Ich sage ja nicht das der Beantworter meiner eMail von Maxon ein echter Macianer ist

Der Hinweis auf den IBM-Compiler ist interessant.
Das sind Fragen welche sich lohnen würden… auf der MacExpo in Köln.
Sowohl an Apple wie auch an Maxon! :nicken:

 

Aber laut der C't soll der Geschwindigkeitsvoreil gegenüber GCC4 nicht mehr so groß sein, also frag auch gleich mal wegen GCC. Dann kannst Maxon auch gleich mal fragen, wie's mit AltiVec-Optimierung ausschaut *lach*

Wenn du nen Apple Entwickler triffst, dann kannste auch gleich mal fragen, wie gut der GCC autovektorisiert (automatisch AltiVec-Code erzeugt, vielleicht im Vergleich zum ICC von Intel )

Und wenn du jemanden von IBM triffst, dann frag mal wie's mit Version 7 von VisualAge aussieht und ob der Compiler dann auch autovektorisieren und autoparallelisieren kann

Gruß
Kalle

P.S. Warte auf deinen Bericht

 

Erkenne was du nicht kannst, und dann lasse besser die Finger davon…
in dem Sinne: KALLE vor, noch ein Tor!

Ich bin doch nur ein armer, kleiner C4D-Anwender… menno.
Möchtest du, das ich mich erstmal mit Wörterbuch bewaffnen
muss, um mich mit denen zu unterhalten? :biggrin:

 

*lach*
Neee, dann frag halt das was du möchtest
Hauptsache du berichtest dann davon

Kalle

 

Da bin ich leider ganz anderer Meinung. Du verwechselst GUI mit dem was auf dem Bildschirm sichtbar ist. In den Mac OS X Systemen muss man den 64-bittigen Teil des Programmes der den Speicher und Renderer "bedient" unabhängig von der Darstellung des grafischen Output und Aqua/Quartz halten, richtig, aber das bedeutet nicht, dass eine Bearbeitung nicht per GUI möglich ist.

Im Gunde sollte ein solches Programm sowieso in mehrere Teile zerfallen, die recht unabhängig voneinander sind und über bestimmte Methoden miteinander kommunizieren. Dies erlaubt z.B. den Renderer weiter zu entwickeln, ohne dass dafür viel an den anderen Programmteilen um zu stellen ist. Anscheinend ist das bei C4D nicht wirklich der Fall.
Dies ist dann natürlich auch schwer hinderlich wenn der Renderer in 64 Bit arbeiten könnte und der Rest in 32 Bit.

Dazu kommt anscheinend ein Problem mit der Cross-Platform Entwicklung.

Apple ist bisher einen Kompromiss mit den 64 BIt eingegangen, unter anderem auch deshalb, weil das GUI dann langsam und speicherfressend werden würde. M. musste bei der Entwicklung Kompromisse eingehen.
An dieser Stelle der Entwicklung kollidieren anscheinend die jeweiligen Strategien und die eingegangenen Kompromisse.

Ich meine aber, dass die prinzipielle Vorgehensweise mit 64Bit Backend und 32 Bit GUI möglich und nicht sehr aufwändig ist. Da C4D wahrscheinlich eine Architektur hat, bei der der Aufwand dann doch etwas höher ist, sollte M die Argumentation doch vielleicht eher etwas deutlicher gestalten und auf die eigenen, selbsterzeugten Schwierigkeiten hinweisen und nicht nur die "Schuld" auf Apples Architektur schieben.

 

Da kann ich mit einem Analogon mit beschränkter Belastbarkeit weiter helfen.

Nimm mal das Telefonieren. Das Telefonbuch und das Telefon sind das GUI, die Benutzerschnittstelle, da kannst du blättern, suchen, lesen, abschreiben, wählen, auflegen, hören, sprechen, umleiten, abheben usw.

Wenn du nur eine Ziffer pro Teilnehmer hast, also z.B. Familie Müller hat die Telefonnummer 8, du selber die 2 usw. hast du 9 mögliche Teilnehmer, dein Telefonbuch ist ein Witz mit einer schmalen Spalte für die Telefonnummer und einer breiten mit dem Namen, aber du brauchst immer nur eine Taste zu drücken und schon ist der Vorgang beendet.

Der andere Teil der Technik, nämlich die Verbindungstechnik kann auch nur mit dieser einen Taste umgehen, das ist das Backend, wo die Verbindung bei der Telekom aufgebaut wird. Also sozusagen der nichtsichtbare Teil der Arbeit geleistet wird.

Stell dir vor, dass du nun mehr Menschen mit Telefonen ausrüsten willst, dann reichen die 9 Ziffern schnell nicht mehr. Technisch kann man zwei Strategien wählen: Man ändert das ganze Telefonieren ab, und zwar auf z.B. zweiziffrige Telefonnummern, und das so, dass nicht nur das Backend für die Verbindung zwei gedrückte Tasten braucht, sondern auch auf dem Telefon (GUI) jetzt zwei Tastaturen sind, für jede Ziffer eine und im Telefonbuch die Spalte mit den Nummern auch zweispaltig sein muss. Also muss man ein neues Telefon haben.

Nun hast du das Äquivalent zum vollständigen 64-Bit System. GUI und Backend sind zweistellig. Nur eine Schwierigkeit bleibt, nämlich die ursprünglichen Einzifferer einzuordnen. Man hilft sich, indem man entweder für die eine neue Zusatzziffer voranstellt, oder eine anhängt. D.H. alles wird anders und die alten Nummernbesitzer müssen umgestellt werden. D.H. dies wäre ein vollständiges 64 Bit System ohne Rückwärtskompatibilität zum 32 Bit System. Damit das Beispiel unserer CPU Realität entspricht kann man das technisch so ausführen, dass ohne das Drücken einer zweiten Nummer automatisch dies die alten Telefone mit den einziffrigen Nummern anspricht. Es muss also das "Programm" für die Alten Nummern nicht geändert werden und die selber bleiben auch.

Eine zweite Möglichkeit die Nummern auszuweiten wäre aber auch das Backend auf zwei Ziffern umzustellen und das Telefon unverändert zu lassen. Nur wird die Verknüpfung und Verbindungsweise mit dem Backend jetzt nicht mehr so einfach. Das Backend muss nun verstehen, dass zwei Nummern die nacheinander auf ein und derselben Tastatur gedrückt werden eine zweistellige Nummer bedeutet, und es muss da eine Reihenfolge festgelegt werden, damit es eindeutig ist. So kann man alte Telefonnummern und neue ohne grosse Änderungen haben. Auch im Telefonbuch müssen nur die neuen, zweistelligen Teilnehmer angehängt werden und der Teil mit den Einstelligen bleibt. Das Telefon kann man unverändert behalten, auch wenn es nun etwas anders bedient werden muss.
Dies entspricht der von Apple gewählten Situation.

Bezogen auf das C4D Programm hiesse das, dass die verlangen, dass man ein Telefon mit zwei Tastaturen braucht, damit ihr Backend funktioniert, da das zwei unabhängige Ziffern zum wählen braucht und mit zwei aufeinanderfolgenden nicht klar kommt.

Das ist bitte aber nur ein Beispiel, ein Analogon, das trägt nicht sehr weit. Aber der Kern der Problematik wird vielleicht etwas klarer.