OS X @ x86 - hat es schon jemand probiert? - Seite 2

Seite 2 von 2 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/os_x_x86_hat_es_schon_jemand_probiert_152129/page_2 - zur Vollversion wechseln!

whitegrey schrieb am 13.11.2005 um 16:08

Zitat von deagle
Gibt es signifikante Änderungen zwischen 10.4.1 und 10.4.3?

wie xdfk schon erwähnt hat - es sollte nicht mehr auf "normalen" PC's laufen :fresserettich:

Changelog PPC-Version: http://docs.info.apple.com/article.html?artnum=301984
nichts "signifikantes" für mich - etwas schneller, Support neuerer Endgeräte usw.
das übliche halt

xdfk schrieb am 13.11.2005 um 16:23

Zitat von whitegrey
wie xdfk schon erwähnt hat - es sollte nicht mehr auf "normalen" PC's laufen

Changelog gibts hier: http://docs.info.apple.com/article.html?artnum=301984
nichts "signifikantes" für mich - etwas schneller, Support neuerer Endgeräte usw.
das übliche halt

sicher dass das nicht das changelog nur fuer die ppc version ist?

soweit ich das mitbekommen hab ist 10.4.3 intel jetzt ca auf dem stand von 10.4.3 ppc.
wobei ich keine ahnung habe wie es bei version 10.4.2 ausgesehen hat.

deagle schrieb am 13.11.2005 um 16:24

Das 10.4.3 nur mit den von Apple zu den Dev-Kits ausgelieferten (TCP-bestückten) Mobos ist mir schon klar, aber bei 10.4.1 hab ich das auch relativ leicht aushebeln können (weil ich zu faul zum Umbauen war - ich habs ja nur jetzt gebraucht, sonst ists in der Firma eh kaum in Verwendung).

Jetzt hab ich mich eh wieder trennen müssen, ich find OS X auf jeden Fall super, da mir momentan allerdings die Mittel für ein Powerbook/ibook/Powermac fehlen und ich mir mit Sicherheit keinen x86-Mac zulegen werde (TCP...) wirds wohl nie einen Platz auf meiner Workstation finden.

SYSMATRIX schrieb am 13.11.2005 um 17:08

@xdfk:

gerade boost sollte doch np sein, warum ists nicht gegangen?

xdfk schrieb am 13.11.2005 um 17:35

Zitat von SYSMATRIX
@xdfk:

gerade boost sollte doch np sein, warum ists nicht gegangen?

bjam ist ein biest.

einfach mal fuer i386 auf dem devel kit compilen war ja kein problem
doch wie bringt man dem teil bei das compilerflag -arch ppc zu setzen?

das hab ich dann durch ein wenig herumgreppen, und jamfiles editieren geschafft.

komischerweise waren aber alle dynamischen libraries leer bis auf irgendwelche stubs(x86 assembler) die der linker erzeugt.

die object files wurden noch korrekt mit ppc code erzeugt.
danach fuehrte bjam folgende befehle aus

Zitat
ld -dynamic -m -r -d -o "bin/boost/libs/date_time/build/libboost_date_time.dylib/darwin/debug/shared-linkable-true/libboost_date_time-d-1_33.lo" "bin/boost/libs/date_time/build/libboost_date_time.dylib/darwin/debug/shared-linkable-true/greg_month.o" "bin/boost/libs/date_time/build/libboost_date_time.dylib/darwin/debug/shared-linkable-true/greg_weekday.o" "bin/boost/libs/date_time/build/libboost_date_time.dylib/darwin/debug/shared-linkable-true/date_generators.o"

soweit eigentlich fast klar, fasst die object files zusammen. darin war noch ppc assembler

Zitat
c++ -g -o "bin/boost/libs/date_time/build/libboost_date_time.dylib/darwin/debug/shared-linkable-true/libboost_date_time-d-1_33.dylib" "bin/boost/libs/date_time/build/libboost_date_time.dylib/darwin/debug/shared-linkable-true/libboost_date_time-d-1_33.lo"
-dynamiclib -install_name "libboost_date_time-d-1_33.dylib"

wtf? wieso willst du x86 code erzeugen obwohl du nur ppc object files bekommst?(hier musste nochmal ein -arch ppc rein)
ld war wenigstens intelligent genug den unterschied zwischen ppc und i386 zu erkennen, steht auch in der manpage. dass der c++ das nicht schafft hat mich etwas verwundert.

naja es hat eben mal etwas zeit gekostet dem bjam lesbare debug infos zu entlocken. (bjam -d 2 oder 3 glaub ich)

um dann eine fat library zu erzeugen nochmal intel und ppc version mit lipo gemerged und man hat das teil fuer alle architekturen

SYSMATRIX schrieb am 14.11.2005 um 21:38

naja also ein bjam problem, ich check die */jams auch überhaupt nicht. wo ist der sinn das zu verwenden? ist ja kein volles autofoo replacement. und die ganzen derivate jam sind auch alle ein graus. aber ein gscheites buildsystem ist anscheinend ein dinger unmöglichkeit. atm spiele ich mich mit bksys/miniscons.

eigentlich ein graus, manche versionen wollen KDE, andere können die XML files wieder nicht usw. ...

alles ein graus.

aber witzig zu hören daß boost/bjam nicht so einfach auf den ppc zu kriegen ist, wobei es an der codebase ja nicht scheitern hätte sollen. war ja schon fast klar daß das build system hier vollkommen versagt.

LTD schrieb am 14.11.2005 um 21:43

ahm gibts eig. schon ne möglichkeit macos auf meinem dual xeon oder so laufen zu lassen?

xdfk schrieb am 14.11.2005 um 21:50

Zitat von SYSMATRIX
naja also ein bjam problem, ich check die */jams auch überhaupt nicht. wo ist der sinn das zu verwenden? ist ja kein volles autofoo replacement. und die ganzen derivate jam sind auch alle ein graus. aber ein gscheites buildsystem ist anscheinend ein dinger unmöglichkeit. atm spiele ich mich mit bksys/miniscons.

eigentlich ein graus, manche versionen wollen KDE, andere können die XML files wieder nicht usw. ...

alles ein graus.

aber witzig zu hören daß boost/bjam nicht so einfach auf den ppc zu kriegen ist, wobei es an der codebase ja nicht scheitern hätte sollen. war ja schon fast klar daß das build system hier vollkommen versagt.

naja boost fuer ppc ist kein problem solang man es auf einem ppc compiled.

das build system ist wie du schon sagtest absoluter mist.
aber die welt kann froh sein dass es noch ein 101. buildsystem gibt.

osx x86 auf einem dual xeon system geht maximal mit der version 1.4.1 und selbst da bin ich mir nicht sicher, unterstuetzen die xeons SSE2/3 ?

SYSMATRIX schrieb am 14.11.2005 um 22:11

je nach xeon, könne sie SSE2 oder SSE2+SSE3.
(alle prescott basierenden xeons)

deagle schrieb am 14.11.2005 um 22:41

Allerdings dürfte OS X auch mit SSE3 bei nicht portierten Anwendungen relativ langsam sein (mit SSE3-fähigem Prozessor ist Rosetta zwar schneller, aber trotzdem noch merkbar langsamer als bei nativen Anwendungen), zudem ist kein Soundtreiber integriert, was es den produktiven Einsatz (zum. für mich) unmöglich macht.

xdfk schrieb am 15.11.2005 um 08:21

Zitat von deagle
Allerdings dürfte OS X auch mit SSE3 bei nicht portierten Anwendungen relativ langsam sein (mit SSE3-fähigem Prozessor ist Rosetta zwar schneller, aber trotzdem noch merkbar langsamer als bei nativen Anwendungen), zudem ist kein Soundtreiber integriert, was es den produktiven Einsatz (zum. für mich) unmöglich macht.

du nennst eine warez developer beta version in einen satz mit produktivbetrieb? gehts noch?

COLOSSUS schrieb am 15.11.2005 um 11:14

Um ehrlich zu sein kann ich nicht glauben, dass die 6 neuen Instructions, die durch SSE3 zum Befehlssatz der CPU dazukommen, die PPC-Emulation um Welten beschleunigt wird.

Oder kann hier jemand etwas Gegensaetzliches belegen?

deagle schrieb am 15.11.2005 um 13:54

@xfdk: 1. Oben genannte Firma ist ein Softwareentwickler, der u.a. ein relativ bekanntes und weit verbreitetes Buchhaltungsprogramm entwickelt.

2. War das die originale Developer-DVD von Apple, da das Mainboard von Apple in der HW- und Reperaturabteilung verschollen war (und ich am Sonntag als einziger in der Firma war - eben nur zu Testzwecken) habe ich die Kernel Extension die den TCP-Chip sucht aus dem Extensions-Folder gelöscht - fertig.

3. War die Aussage die den Produktivbetrieb betrifft nicht nur auf den momentanen Stand der x86-Version von Mac OS X bezogen, sondern vor allem auf die unzähligen (freien) Softwareprojekte für OS X, die sicher noch einige Zeit brauchen bis sie auf x86 portiert werden.

@colo: In diversen Foren wird doch von einem erheblichen Geschwindigkeitsunterschied gesprochen, iirc sinds doch 13 zusätzliche Instructions?

SYSMATRIX schrieb am 15.11.2005 um 14:53

es könnte sein daß rosetta viele skalare dinge über SSE schiebt und dann hier einiges mit SSE3 machen möchte. follte das der fall sein frage ich mich warum sie nicht anstatt dessen liber einen eigenen optimizing compiler oä bauen.

es sind 12(13), aber was nicht MPEG CODECs und nicht graphiksw damit zu tun hat kann ich auch nicht verstehen, obwohl ich selbst SSE3 verwende. aber eben nur für letzteres.