Archiv verlassen und diese Seite im Standarddesign anzeigen : Ab Januar Apple IBook mit Yonah
http://www.hardtecs4u.com/?id=1132254682,18082,ht4u.php
Ab Januar gibt es den Intel Yonah-Prozessor auf den Apple IBook.
Nur HT4U berichtet darüber. :|
Bin mal gespannt, wie die Benches zwischen Intel und PPC ausschauen.
INTRU
2005-11-19, 00:52:20
Heise hat AFAIR auch darüber berichtet!
Im Januar werden viele Anwendungen (vorallem die Pro-Anwendungen) bestimmt noch nicht für x86 vorliegen. Daher fährt man womöglich die nächste Zeit mit PPC-Macs noch besser.
BlackBirdSR
2005-11-19, 01:00:13
Bin gespannt, wie hoch der Performanceverlust für x86 Programme ist, die sich sehr auf Altivec und dessen Spezialfunktionen verlassen haben.
Auf der anderen Seite erhält man damit endlich SIMD mit fp double precision.
mapel110
2005-11-19, 01:26:12
Bin gespannt, wie hoch der Performanceverlust für x86 Programme ist, die sich sehr auf Altivec und dessen Spezialfunktionen verlassen haben.
Auf der anderen Seite erhält man damit endlich SIMD mit fp double precision.
Hat man bei SIMD nicht ohnehin 64bit. Reicht das nicht?!
INTRU
2005-11-19, 01:26:48
Durch die Umstellung werden auch die PPC-Macs profitieren. So wie ich das mitbekommen habe, liegen selbst heute einige wichtige Programme wie M$ Office und das Adobe-Zeug nicht in Cocoa vor. Daher nutzen diese Anwendungen OS X nicht richtig aus bzw. laufen nicht optimal. M$ Office ist AFAIK noch nichtmal Carbon.
Durch den Wechsel sind nun die Hersteller gezwungen, ihre Programme in Cocoa rauszubringen.
Die, die ihre Hausaufgaben gemacht haben, müssen meist nur ein Häkchen setzen und schon ist die Universal Binary fertig (abgesehen von spezifischen Optimierungen).
Cocoa: http://de.wikipedia.org/wiki/Cocoa
Hat man bei SIMD nicht ohnehin 64bit. Reicht das nicht?!Er meinte dass man damit 2x64bit bearbeiten kann. Altivec kann nur 4x32bit, dafür aber Operationen die mit SSE nicht möglich sind, z.B. dynamisches swizzeling.
Durch den Wechsel sind nun die Hersteller gezwungen, ihre Programme in Cocoa rauszubringen. Ich verstehe nicht warum das so sein sollte. Eigentlich sollte jedes Programm, dass keine PowerPC-Assembly verwendet und keine Little-/Big-Endian-Probleme macht nach einer rekompilierung lauffähig sein.
INTRU
2005-11-19, 01:31:17
Ich verstehe nicht warum das so sein sollte.
Da das andere "Zeug" nicht auf den Intel-Macs läuft ;) -> Universal-Binary
Zumindest habe ich das so verstanden...
Das hat doch nix mit Cocoa zu tun.
Was mich am x86-Mac freut ist dass Apple jetzt auch den x86-Linux-GCC mit verbessert.
INTRU
2005-11-19, 01:39:45
Das hat doch nix mit Cocoa zu tun.
Was mich am x86-Mac freut ist dass Apple jetzt auch den x86-Linux-GCC mit verbessert.
Wieso? Carbon-Anwendungen werden AFAIK auf Intel-Macs nicht mehr laufen.
Ich hatte dazu mal irgendwo etwas gelesen. Wenn ich das finde, poste ich es.
VooDoo7mx
2005-11-19, 08:10:31
Erst Mitte nächstes Jahres. Dann war es April/mai, jetzt sollen neue Powerbooks im Januar kommen.
Ich bin gespannt.
Der Performanceverlust durch die Emulation soll etwa 30% betragen.
Ganon
2005-11-19, 15:13:36
Ich verstehe nicht warum das so sein sollte. Eigentlich sollte jedes Programm, dass keine PowerPC-Assembly verwendet und keine Little-/Big-Endian-Probleme macht nach einer rekompilierung lauffähig sein.
Nein. Viele "teure" Programme wie M$ Office und Adobe-Produkte sind noch CarbonCFM-Programme. Das heißt es sind im Kern noch MacOS8-Programme (also auch keine MACH-O-Binary) die unter OS X lauffähig sind.
Diese werden unter x86 nicht ohne Emulation laufen und sind auch nicht "mit einem Recompile" lauffähig zu machen. Diese müssen entweder auf das native Carbon oder Cocoa umgeschrieben werden.
CarbonCFM frisst ne Menge Performance. Darum ist auch M$-Office unter VirtualPC schneller als das "native" M$ Office für OS X. Denn es ist im Grunde noch ein MacOS8-Programm.
Die Hersteller haben einfach nie die Zeit genutzt, um aus den OS8-Programmen OSX-Anwendungen zu machen. CarbonCFM sollte eigentlich nie so lange existieren (Übergangslösung für OS9->OSX). Aber Apple hat sich breit schlagen lassen. Jetzt geht das nicht mehr.
Ganon
2005-11-19, 19:08:56
Bin gespannt, wie hoch der Performanceverlust für x86 Programme ist, die sich sehr auf Altivec und dessen Spezialfunktionen verlassen haben.
Apple hat ja schon ein "Altivec to SSE porting guide" oder so ähnlich raus gebracht. Dort steht beschrieben, wie man Altivec-Optimierte Anwendungen gut nach SSE portiert.
Fragt sich nur ob SSE Leistungsfähig genug ist, oder ob "nur" der Takt alles wett machen muss.
HellHorse
2005-11-19, 22:47:16
Wann denkt man eigentlich bei Apple, dass man Cocoa in 64bit am laufen hat?
Ganon
2005-11-19, 23:52:40
Wann denkt man eigentlich bei Apple, dass man Cocoa in 64bit am laufen hat?
Nunja. Das wird sich zeigen. Aber ich denke mal es wird wohl erst mal 32bit bleiben, da Intel dem neuem Prozessor ja keine 64bit-Fähigkeit gegeben hat.
Weiß auch nicht wie die das am Ende anstellen wollen. Eigentlich wäre der Wechsel zu Intel auch ideal für einen Wechsel auf 64bit gewesen, aber nun muss man dann wohl in der nächsten Zeit noch mal wechseln, oder Apple denkt sich was neues aus... ;)
Ist ja leider dann nicht mehr so das der Prozessor beliebig zwischen 32bit und 64bit hin und her schalten kann...
Tiamat
2005-11-20, 03:11:54
Wann denkt man eigentlich bei Apple, dass man Cocoa in 64bit am laufen hat?
Tja das wird das die nächste große "Verarschung" von Apple.
Erst machen die User den Intel-Wechsel mit dann wird in 2 Jahren schon wieder n neuer Mac fällig wegen MacOS 10.8 (Codename "Nasenbär" ;D )
was diesmal nur 64bit fähig ist.
Ist ja leider dann nicht mehr so das der Prozessor beliebig zwischen 32bit und 64bit hin und her schalten kann...Ein AMD64 kompatibler Prozessor kann im 64bit-Modus auch 32bit-Programme ausführen.
Ganon
2005-11-20, 08:46:54
Oder sie schaffen es irgendwie über UniversalBinary. Ich meine wenn man jetzt schon x86 und ppc Code drinnen hat, warum dann nicht auch noch x86_64-Code drinnen?
Muss halt Apple nur einen Weg finden das die CPU "ihre" Daten findet.
Ganon
2005-11-20, 08:54:34
Ein AMD64 kompatibler Prozessor kann im 64bit-Modus auch 32bit-Programme ausführen.
Ja, aber soweit ich gelesen habe, nicht so flexibel wie der G5. Weil man braucht ja für 32bit-Anwendungen bei Windows64 und Linux64 jeweils das 32bit-Zeugs noch mal auf der Platte. lib32 und lib64.
So kompliziert ist das beim G5 nicht nötig, soweit ich das jetzt gelesen habe. Kann auch sein das das falsch ist. ;)
Daher wäre auch ein fließender Übergang 32bit->64bit bei OS X möglich gewesen...
INTRU
2005-11-20, 20:31:54
Gibt es irgendwo Infos (oder gar eine Roadmap), wann mit den großen x86 Anwendung gerechnet werden darf (insb. M$ Office)?
Tiamat
2005-11-21, 11:05:46
Mac World San-Francisco Januar 2006
INTRU
2005-11-21, 11:10:14
Wenn M$ Office und Adobe-Produkte wirklich noch CarbonCFM-Programme sind, dann glaube ich kaum, daß die bis zur Mac World im Januar fertig sein werden. Die müssen doch dann praktisch komplett neugeschrieben werden oder nicht?
Ganon
2005-11-21, 11:58:12
Die müssen doch dann praktisch komplett neugeschrieben werden oder nicht?
Jups. "Komplett neu" sicherlich nicht, aber vor allem Bereiche die mit dem Betriebssystem und der CarbonCFM-API zu tun haben.
Was dann aber z.B. Office einen starken Performance-Schub geben dürfte. Auch für PowerPC-Prozessoren.
Aber dazu müssen die meisten ihre Projekte erst mal von CodeWarrior zu Xcode portieren, was trotz Import seitens Xcode nicht gerade leicht ist (Mitarbeiter "Umschulung", etc.)
Ich kann mir nicht vorstellen das M$ und Adobe schon so schnell die Programme fertig haben. Dazu haben sie einfach zu wenig gemacht in den letzten Jahren. Die auf Apple gehört haben, haben jetzt weniger ein Problem (die Mathematica Entwickler, z.B.). Die brauchen wirklich nur den Haken setzen und ein paar Compiler Makros ändern.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.