Archiv verlassen und diese Seite im Standarddesign anzeigen : x86 = total veraltete Architektur?
sloth9
2006-08-22, 22:43:30
Logic: Apple bremst Quad G5 aus
Zensur verärgerter User inklusive
1.8 mal mehr Logic-Performance als beim Quad G5 verspricht Apple beim "Mac" Pro 3GHz. Nach Veröffentlichung des Updates 7.2.2 kam auch raus, warum: Der Quad G5 nutzt weiterhin nur zwei der vier Prozessorkerne, während die Intel-Maschine aus allen vier Rohren schießt. Threads in Apples Diskussionsforen, in denen User die Thematik ansprechen und ein Statement von Apple hierzu einfordern werden kommentarlos gelöscht (Hier ist einer dank schlauem Subject den Zensoren entgangen).
Mit anderen Worten: Eine Maschine, die heute noch im Applestore für satte 3300 Euro erhältlich ist, wird jetzt schon nicht mehr richtig unterstützt. Das muss ein neuer Rekord in der Computerwelt sein, ganz besonders für Apple, wo man sich bisher sicher sein konnte, dass die Hardware mindestens 4-5 Jahre unterstützt wird. Steve Jobs Hass auf PowerPC ist offensichtlich größer als ursprünglich angenommen.
...
...
...
P.S: Verärgerte Quad G5 Logic-User sollten ihrem Ärger hier Luft machen. Wenn eine öffentliche Diskussion des Themas wegen Zensur schon nicht möglich ist, sollte man wenigstens Apple direkt davon in Kenntnis setzen, was man von solchem Geschäftsgebahren hält...
http://www.macguardians.de/index.php?p=4354&c=1#comments
Links finden sich in dem original Artikel!
Wow, zieht Apple eine Scheisse ab! Könnte Micros~1 nicht besser :biggrin:
Ganon
2006-08-22, 22:56:43
Aber so wie der Artikel geschrieben ist, merkt man das dieser Kai im Kopf noch ein kleines Kind ist. ^^ Und sowas darf News schreiben. ;)
Ja, diese Armen kleinen gekränkten PowerPC-Fanatiker. Ich lach immer noch. PPCNUX ist zur Zeit auch wieder herrlich. ^^
edit:
Zum Thema. Ich würd erst mal abwarten, bevor man solche News schreibt. Seriöse Seiten würden sich ggf. auch mal bei Apple direkt informieren... ach ja. MacGuardians und seriös. Passt nicht. :D
Ist das dieser .ut-Spack?
Thowe
2006-08-22, 23:10:40
Wow, zieht Apple eine Scheisse ab! Könnte Micros~1 nicht besser :biggrin:
Ob es Absicht ist um Benchmarks zu beschönigen bezweifel ich mal.
Thowe
2006-08-22, 23:11:47
Ist das dieser .ut-Spack?
Nein, ist er nicht. Nebenbei, ein Spack (also ut) ist er auch nicht, nur zu sehr überzeugt von seiner eigenen Wahrheit.
So wie er deshalb aber mit anderen umgeht (total hochnäsig undabwertend) ist er es sehr wohl.
Ganon
2006-08-22, 23:20:17
Kai ist so wie ut, nur mit noch weniger Ahnung. ;) Einer von der Sorte die CELL als Desktop-CPU sieht. ;)
"Arrogant in ihrer Dummheit" ist mein neuer Lieblingsspruch...
apple soll notebooks bauen.. (da sind sie die besten).. der rest ist irgendwie nicht wirklich zu gebrauchen... zumindestens nicht im pro-bereich.
die anderen apple produkte wzb.: G5 , cinema display, logic, final cut usw. usw. sind alles semi professionelle produkte... deswegen frage ich mich auch immer warum die apple fanboys von HIGH END und PROFESSIONELL reden?
sorry, aber 1.) es gibt leute die machen einen ganzen kinofilm auf einem billig MSI notebook und 2.) PROFESSIONELL heisst in meinen augen hardware zu haben um die man sich ein haus bauen koennte und diese hardware heisst aber nicht APPLE sondern eher AVID / CANOPUS.
diese apple fanboys reden von photoshop und x-press.
toll! x-press ist ur alt und läuft auf jeder kiste schnell genug. (6.5)
photoshop .. ich glaube wenn man weiss was man tut kann man damit auch auf jeder kiste einwandfrei arbeiten.
da ich selber schon öfter auf schulung war und in räumen gelernt habe wo es os x und windows xp gab kann ich nur sagen... -> beide systeme haben in softwareprogs hin und wieder macken und fehler.
was mir aber aufgefallen ist an dem 2 monatigen kurs ist jenes das es eher der G4 war der mehr macken hatte als die DELL windows kiste.
wie es heute ist weiss ich nicht, da mich apple bis auf die notebooks absolut nicht interessiert.
aber ich hoffe es ist besser als zu G4 zeiten.
es gab teacher die schwörten auf apple und welche die schwörten auf windows.
ich bin sicher nicht allwissend, aber diese apple fanboys teacher haben zu 99,9% nur schwachsinn erzählt warum ein apple besser ist und noch dazu OHNE einer einzigen begründung.
quasi -> "apple ist besser weil die software besser läuft"
aha? und dann meine frage "warum ist das so" und der apple fanboy teacher "das war schon immer so"
dann hab ich die augen verrollt und mir gesagt... "ich halt lieber die fresse in dem kurs , weil sonnst bekomm ich einen §"="§(!!"
lach
komischerweise war genau das gegenteil der fall, die software lief auf den dell kisten besser als auf den G4 kisten und noch dazu mit weniger bugs.
das ist in etwas so als wenn ich jetzt einfach mal behaupte . FIAT autos haben weniger pannen..
zwar hat mazda statistisch gesehen die wenigsten pannen .. aber WIR die (apple fanboy AG) meint .. nein nein .. FIAT hat die wenigsten pannen. als begründung natürlich apple like "weil es ein fiat ist"
also ich glaube das statistisch gesehen die meisten DAUs eher aufm apple ufer herumschwimmen.
so ists mir zumindestens bis jetzt vorgekommen.
apple soll notebooks bauen.. (da sind sie die besten)..
sagen wir, sie sind nicht schlecht!
der rest ist irgendwie nicht wirklich zu gebrauchen...
mac mini und aktueller imac sind geile computer!
zumindestens nicht im pro-bereich.
ok du relativierst die obige aussage. aber powermacs und mac pros waren schon immer tolle, sehr leistungsfähige und vielgenutzte geräte... und auch meist recht günstig im vergleich zu der konkurrenz!
die anderen apple produkte wzb.: G5 , cinema display, logic, final cut usw. usw. sind alles semi professionelle produkte... deswegen frage ich mich auch immer warum die apple fanboys von HIGH END und PROFESSIONELL reden?
ähm, jetzt wirfst du hardware mit software durcheinander.
-g5 -> war jahrelang ein extrem schneller prozessor. er ist immer noch richtig schnell. ibm nutzt nebenbei auch g5. und auf g5 basis gibt es auch mind. einen richtig schnellen cluster!
- cinema displays sind nicht schlecht und finden sich auch in vielen agenturen, wo professionell gearbeitet wird
- logic, final cut: du bist gut. das sind richtig pro-apps. z.b. schau mal was für musiker (und wieviele) logic nutzen.
sorry, aber 1.) es gibt leute die machen einen ganzen kinofilm auf einem billig MSI notebook
link? mag sein - aber mit 'nem apple geht es besser ;) sorry, aber afaik sind mehrere kino filme auf macs gerendert worden ;)
und 2.) PROFESSIONELL heisst in meinen augen hardware zu haben um die man sich ein haus bauen koennte
ja power macs
und diese hardware heisst aber nicht APPLE sondern eher AVID / CANOPUS.
die mit macs zusammenarbeiten
diese apple fanboys reden von photoshop und x-press.
nicht nur - aber in dem bereich sind z.b. macs extrem weit verbreitet!
toll! x-press ist ur alt und läuft auf jeder kiste schnell genug. (6.5)
toll - du weisst schon, dass es quark express 7 gibt und das ist nicht alt
photoshop .. ich glaube wenn man weiss was man tut kann man damit auch auf jeder kiste einwandfrei arbeiten.
aber man hat unter windows nicht den worflow wie unter mac os.
da ich selber schon öfter auf schulung war und in räumen gelernt habe wo es os x und windows xp gab kann ich nur sagen... -> beide systeme haben in softwareprogs hin und wieder macken und fehler.
ach neee
was mir aber aufgefallen ist an dem 2 monatigen kurs ist jenes das es eher der G4 war der mehr macken hatte als die DELL windows kiste.
g4 ist alt und zweitens halte ich das für ein gerücht.
wie es heute ist weiss ich nicht, da mich apple bis auf die notebooks absolut nicht interessiert.
ach interessant. und dafür den ganzen stuss von dir?
aber ich hoffe es ist besser als zu G4 zeiten.
kann ich nicht beurteilen!
fazit: Bitte erspare uns solche Posts! Danke
Legolas
2006-08-23, 10:40:11
link? mag sein - aber mit 'nem apple geht es besser ;) sorry, aber afaik sind mehrere kino filme auf macs gerendert worden ;)
Gerendert werden Animationsfilme normal auf großen Rechenclustern. Da ist es im Prinzip ziemlich egal, was da für ein OS drauf läuft, hauptsache die Renderingsoftware tuts.
Bokill
2006-08-23, 11:18:24
... komischerweise war genau das gegenteil der fall, die software lief auf den dell kisten besser als auf den G4 kisten ... Ich kürze mal dein unwissendes Kompilat ab.
Dir ist anscheinend nicht bewusst, dass "G4", "G5" allgemeine PPC Plattformnamen sind?
So hat IBM einen ganzen Zoo rund um den PPC 970/PPC 970MP, die auf Rockstable Servern/Workstations laufen.
Das kann man durchdeklinieren mit allen PPC-Lösungen. Nebenbei gesagt ist die PPC Welt in Bereichen vertreten wo sich x86 recht schwer tat. Stichwort Automotive/Set Top Boxen.
Apple war lediglich ein ganz spezieller proprietärer Desktopbereich mit dem Vorteil in sich abgeschlossener Systemumgebungen und abgestimmten Softwarepaketen.
Der Nachteil bei Apple war, dass es eben nicht nahezu beliebig grenzenlos erweiterbar war/ist.
Und was instabile Kisten angeht, so liegt das eher an dem Nutzer, da kann man nach Jahren Dauernutzung (ohne Systempflege) jedes System zerschiessen und lahm machen.
MFG Bobo(2006)
stav0815
2006-08-23, 13:14:05
Und was instabile Kisten angeht, so liegt das eher an dem Nutzer, da kann man nach Jahren Dauernutzung (ohne Systempflege) jedes System zerschiessen und lahm machen.
Dazu fällt mir nur ein: 90% aller Computer Probleme sitzen zwischen Tisch und Stuhl.
Sämtliche Gerätetreiber (außer Drucker und noch irgendwas was auch im Userspace geht) sind mit Sicherheit nicht 32 bit für Windows XP x64.
Das hängt davon ab, wie "empfindlich" der Kernel reagiert und wie nah der Treiber dem Kernel ist.
Die ersten Treiber für den frühen Alpha vom WXP64 waren ein Mischung aus 32 und 64 bit. Die alten Meldungen müsste man raussuchen.
http://www.ppcnux.de/modules.php?name=News&file=article&sid=6531
Mehrere Ursachen:
- IBM hat mit Apple einen Hauptabnehmer verloren. Nun müssen die die CPUs "verscherbeln". Besser, als auf denen sitzen zu bleiben.
- IBM hat die Produktion endlich im Griff.
...
Das hängt davon ab, wie "empfindlich" der Kernel reagiert und wie nah der Treiber dem Kernel ist.
Nein hängt es nicht. Sämtlicher Ring-0-Code muss 64-Bit sein bei einem x86-64 Betriebssystem (das diktiert AMD und nicht Microsoft).
Und da bei Windows so gut wie alle Treiber Kernelcode sind...
Why EFI went nowhere
There were two catch-22s preventing EFI adoption in the PC world. First, Microsoft would need to add EFI support to Windows before PC makers could build it into their hardware, but Microsoft sees no need to do all the work to build support for a hardware feature that no PCs are yet using.
The second catch-22: customers didn't know to ask for the functionality EFI provides, because they don't realize what crap PCs are, and the Wintel world is giving customers crap because their consumers are not asking for anything better. The PC world is not driven by innovation, but by low prices.
http://www.roughlydrafted.com/RD/Home/0E960A5B-E16E-40A6-B4FD-E4C28F77A366.html
HellHorse
2006-08-24, 18:04:37
Why EFI went nowhere.....
Vielleicht ist EFI auch nur einfach schlecht (http://kerneltrap.org/node/6884)
http://www.roughlydrafted.com/RD/Home/0E960A5B-E16E-40A6-B4FD-E4C28F77A366.html
EFI was built into the design of the Itanium 64-bit server platform, and so Microsoft's 64-bit version of Windows obviously has to support EFI. That version of Windows is very different than the legacy 32-bit Windows that PC users run however.
The standard 32-bit Windows XP has to provide support for games and vast array of legacy software titles, funky peripheral hardware, and otherwise maintain compatibility with the millions of PCs out there, which the 64-bit Windows doesn’t attempt to support.
Wow, spricht da der gut informierte Mac-User?
http://www.roughlydrafted.com/RD/Home/0E960A5B-E16E-40A6-B4FD-E4C28F77A366.html
Just as Apple pioneered USB a decade ago, they have decisively moved to EFI on their new Intel Macs.
Ach so, ja klar, hatte ich doch gleich vergessen.
Gegen Open Firmware scheint "Linus" hingegen nichts zu haben ;) Ausserdem ist das nur eine Meinung!
Nein hängt es nicht. Sämtlicher Ring-0-Code muss 64-Bit sein bei einem x86-64 Betriebssystem (das diktiert AMD und nicht Microsoft).Wo steht das? Was hindert mich daran im 64 Bit Mode mit einem operandsize override prefix nur die unteren 32 Bit der 64 Bit breiten Register zu benutzen?
http://img362.imageshack.us/img362/4781/addresssizeoi5.png
Quelle: AMD64 Architecture Programmer’s Manual Volume 1 (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf) (Seite 57)
Wo steht das? Was hindert mich daran im 64 Bit Mode mit einem operandsize override prefix nur die unteren 32 Bit der 64 Bit breiten Register zu benutzen?
Gar nichts, die Treiber laufen aber trotzdem im Long Mode, das heißt das die Dinger mindestens neu zu kompilieren sind (und ganz bestimmt keine normalen 32 Bit Binaries funktionieren).
Ganon
2006-08-24, 20:31:11
Vielleicht ist EFI auch nur einfach schlecht (http://kerneltrap.org/node/6884)
Hmm.... Kommentare von Linus... weiß nicht was ich davon halten soll... ;)
Gar nichts, die Treiber laufen aber trotzdem im Long Mode, das heißt das die Dinger mindestens neu zu kompilieren sind (und ganz bestimmt keine normalen 32 Bit Binaries funktionieren).Ja, das ist aber etwas anderes als zu sagen, dass es prinzipiell nicht gehen würde im Long Mode nur 32 Bit zu benutzen.
Davon abgesehen hat das rein gar nichts mit dem CPL0 ("Ring 0") zu tun.
stav0815
2006-08-24, 21:02:06
Hmm.... Kommentare von Linus... weiß nicht was ich davon halten soll... ;)
Fanboy? ;D
Ganon
2006-08-24, 21:04:33
Fanboy? ;D
Nunja. Er hat schon immer so diverse Kommentare abgelassen und Menschengruppen beleidigt die auch mich betreffen. Von daher halte ich den Typen schlicht für ein Arschloch. ;) Aber egal. Das tut hier nix zur Sache. ;)
Im Linuxlager hatte er auch extrem gewettert gegen Gnome!
Ist eine Meinung die man sich anhören kann - sollte man aber nicht als das NonPlusUltra sehen!
Noch zu EFI: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=4698306&postcount=71
Also wie ist euere Einschätzung?
- Werden wirklich 32Bit Treiber unter einem 64Bit Leopard mit Core 2 (Intel) laufen?
- Falls ja, wieso macht das dann MS und Linux nicht genauso?
- Ist es irgendwie möglich, in 64Bit-Anwendungen 32Bit-Plug Ins zu nutzen?
sloth9
2006-08-25, 16:23:36
"Just as Apple pioneered USB a decade ago, they have decisively moved to EFI on their new Intel Macs."
Klar, genau wie PCI, AGP und DDR-RAM. USB ist von Intel. Lügen können sie gut.
32Bit-PlugIns in 64Bit Anwendungen bei x86?
Ist es sicher, dass eine 64-Bit Applikation ein 32-Bit-Shared-Objekt laden kann? Halte ich für unwahrscheinlich, weil es unter PPC-Linux auch nicht geht.
32Bit Treiber in einem 64Bit OS bei x86?
Das geht auch auf Apfel nicht im Kernelspace. Die Treiber laufen im Userspace, da können sie auf x86-64 genauso 32-Bit sein und sind es anscheinend in Mac OS X auch.
- Werden wirklich 32Bit Treiber unter einem 64Bit Leopard mit Core 2 (Intel) laufen?
Wenn es sich so verhält wie es sehr wahrscheinlich ist: Ja.
- Falls ja, wieso macht das dann MS und Linux nicht genauso?
Kernelspace. Unter Vista könnte es sein dass es auch 32-Bit-Userspace Treiber geben wird (wenn Microsoft es vorgesehen hat). Da Vista aber sowieso ein neues Treibermodell hat und somit neue Treiber braucht und man wenn man 64-Bit im Auge hat bei deren Entwicklung eh für beide Architekturen parallel kompiliert halte ich das gar nicht für eine solche Einschränkung sich das zu sparen.
- Ist es irgendwie möglich, in 64Bit-Anwendungen 32Bit-Plug Ins zu nutzen?
Wie gesagt zweifelhaft ob das überhaupt geht. Die ganzen "64 Bit" Apps auf Mac OS X sind ja bisher ein 32-Bit-Frontend und ein 64-Bit-Backend das über Pipes angesprochen wird und nicht über direkte Codebindung, deshalb können die natürlich 32-Bit-Plugins laden (aber wohl keine 64-Bit).
USB ist von Intel. Lügen können sie gut.
Ähm, Englisch ist nicht deine Stärke, oder?
Da steht nur das Apple USB als erster benutzt und eingebaut hat. Nicht das Apple es erfunden hat...
sloth9
2006-08-26, 01:58:43
Ähm, Englisch ist nicht deine Stärke, oder?
Da steht nur das Apple USB als erster benutzt und eingebaut hat. Nicht das Apple es erfunden hat...
Und das ist eben falsch, Pappnäschen: Intels 430HX und 430VX waren vor dem iMac. Wäre auch seltsam, würde Intel eigene Entwicklungen nicht als erster verbauen.
pioneered: vorbereiten, bahnen, leiten, forschte, den Weg bereitet.
Klar. Ohne die gewaltige Marktmacht von Apple hätte sich USB nie durchgesetzt.
Und das ist eben falsch, Pappnäschen: Intels 430HX und 430VX waren vor dem iMac. Wäre auch seltsam, würde Intel eigene Entwicklungen nicht als erster verbauen.
pioneered: vorbereiten, bahnen, leiten, forschte, den Weg bereitet.
Klar. Ohne die gewaltige Marktmacht von Apple hätte sich USB nie durchgesetzt.
Sogar damalige VIA Chips hatten schon Schnittstellen für USB auf dem Board. USB war technisch am PC definitiv zerst da, konnte aber erst ab Win95B mit USB Pack genutzt werden.
Ja, das ist aber etwas anderes als zu sagen, dass es prinzipiell nicht gehen würde im Long Mode nur 32 Bit zu benutzen.
Haarspalterei. Neue Treiber braucht man so oder so, und da die Kerneldatenpointer alle 64-Bit sind wird man nicht drumrumkommen
Davon abgesehen hat das rein gar nichts mit dem CPL0 ("Ring 0") zu tun.
Natürlich tut es das. Ring-0-Code muss eben Long-Mode sein.
"in agentuern werden apples verwendet"
mag stimmen, aber auf der anderen seite arbeiten dort zum grossteil auch die meisten noobs.
wenn du dich mit der software auskennst ist es egal ob du vor linux od. apple od. windows sitzt.
die apple cinema displays haben einen verdammt schlechten kontrast... würde die eher im bereich "office" einsetzen, aber niemals für grafische sachen.
logic? was ist da so toll dran?
hatten wir zu apple G4 zeiten auch mal in verwendung.
seh da absolut nichts einzigartiges daran ausser das es ehm .. langsam ist? und nichts besser kann als andere ?
und was ist an final cut so toll?
ausser das es wiederum nichts besser kann als andere und ebenso .. langsam und träge ist?
der mac mini ist für office sicher nicht schlecht bzw. preis / leistungsmässig ganz okey.
aber diesen hässlichen imac .. igitt! den würd ich mir nicht auf den schreibtisch stellen wollen.
microsoft hat AVID gekauft vor xx jahren und AVID ist der industriestandard.
da kann apple noch so "herumtrollen" mit der kinderspielesoftware.
oder glaubst du das man 24 bit RAW film-digitalisierungs ARRI stripes in einem programm ala final cut pro bearbeitet?
das wäre viel zu schade und ausserdem gehts garnicht :) weil final cut pro eben semi-professionell ist.
http://www.avid.com/solutions/postproduction/index.asp
ich habe ja gesagt - high end -
rendern kannst du auf einer uni über billig linux cluster, dazu braucht kein mensch einen G5.
Natürlich tut es das. Ring-0-Code muss eben Long-Mode sein.Wo steht das? Belege bitte diese Behauptung.
Das Problem ist dass der Kernel nur ein Prozess ist unter Windows/Linux, deshalb kann es nicht gemischt werden.
Sorry für die Unklarheit, da waren meine Quellen undeutlich.
Das Problem ist dass der Kernel nur ein Prozess ist unter Windows/Linux, deshalb kann es nicht gemischt werden.
Sorry für die Unklarheit, da waren meine Quellen undeutlich.Ich wusste doch, dass das nicht stimmte. Im x86-64 Manual von AMD stand nämlich nichts davon.
Naja es ist aber praktisch auch nicht anders. Alle Interrupt-Handler müssen Long-Mode sein und es dürfte recht schwierig sein diesen dann von 32-Bit-Code ausführen zu lassen womit jeglicher Hardware-Treiber prinzipbedingt wieder Long-Mode sein muss.
Alles in allem ist das wie gesagt Haarspalterei.
Der Compatibility Mode gehört doch zum Long Mode?
Ja. Und? Trotzdem muss der Interrupt-Handler ein Long-Mode-Prozess sein (und nicht Compatibility Mode), d.h. der ganze Kernel inkl. Treiber ist schonmal so gut wie ausschließlich in 64-Bit zu bauen.
Es müsste doch Developer mit MacPros geben, die genau sagen können, wie es nun mit 32-64Bit bei Leopard ist! Die Dev-Version von 10.5 soll man ja sogar in Tauschbörsen finden.
Pro Desktop:
"What’s remarkable is that despite all the hubub about Apple failing to ship a Power Mac G5 with a 3GHz processor, Power Mac G5 performance has increased steadily (especially when compared to the Power Mac G4) with each new model.
The Mac Pro didn’t bring a huge performance jump over the Power Mac G5 (unlike like the jump in performance from the Power Mac G4 to the Power Mac G5)"
Scheisse, hat Apple echt damals doch glatt die "2/3x/5x faster"-Buttons vergessen, als sie den G5 vorgestellt haben! ;-) Halt, der G5 war ja deutlich SCHNELLER als der G4 als es die Intels heute im Vergleich zum G5 sind, also müsste das eher "4x/6x/10x faster" lauten, oder?
iMac:
"The most impressive switch was the switch from the PowerPC G4 to the PowerPC G5, where performace almost doubled. The switch from the PowerPC G5 to the Intel Core Duo also seems impressive, but a large part of the performace gain came not from switvching architectures, but from switching from a single-core to a dual-core CPU."
http://www.geekpatrol.ca/blog/138/
soviel zu intel super schnell und g5 lahm. die intel sind teilweise nur schneller als die g5, da 1 core vs. 2 cores!
stellt doch mal einen 2. core im intel imac ab und testet dann ;)
soviel zu intel super schnell und g5 lahm. die intel sind teilweise nur schneller als die g5, da 1 core vs. 2 cores!
Ich frage mich was es für eine Rolle spielt wie genau nun die höhere Performance erreicht wird.
Ich frage mich was es für eine Rolle spielt wie genau nun die höhere Performance erreicht wird.
die hätte man aber so auch mit g5s erreichen können. einfach einen dualcore g5 verbauen ;)
apple hat wohl mehr oder weniger bewusst eh nicht mehr aktuelle g5 in macs verbaut, damit die intel besser glänzen könne x)
Ganon
2006-09-01, 12:49:09
Einige Leute (besonders PowerPC-Fanatiker) kapieren einfach nicht das Apple nicht die CPUs vergleicht, sondern die Macs.
Apple sagt nicht das der Core-Prozessor 2x schneller ist als der G5, sondern der halt der neue iMac 2 mal schneller als der iMac davor. Und da ist es wirklich unerheblich ob da nun 2 CPU-Kerne gegen einen oder 10000 gegen 1.
Und sorry. Wie es halt auch Anwendungen gibt in dem ein G5 einen Intel Core zersägt, gibt es auch Anwendungen wo der G4 einen G5 zersägt. Und das mit teilweise nur 3/4 des Taktes... aber das wird ja gerne übersehen :rolleyes:
Nur halt in 95% der anderen Fälle ist halt die "neue" CPU schneller. Aber "Fans" der alten CPU klammern sich halt an die restlichen 5% und meinen das sei das wichtigeste auf der Welt.
Nur halt in 95% der anderen Fälle ist halt die "neue" CPU schneller. Aber "Fans" der alten CPU klammern sich halt an die restlichen 5% und meinen das sei das wichtigeste auf der Welt.
schalte beim intel einen kern ab oder verbaue eine aktuelle dual core g5 und überprüfe dann deine behauptung. dann würde es etwas anders aussehen ;)
Ganon
2006-09-01, 12:52:40
apple hat wohl mehr oder weniger bewusst eh nicht mehr aktuelle g5 in macs verbaut, damit die intel besser glänzen könne x)
Nö. Man hat einfach nur keine "aktuellen" G5s mehr bestellt, weil es hirnrissig wäre noch mal 10 Mio. G5 CPUs zu bestellen, wenn man eh zu Intel wechselt.
Ganon
2006-09-01, 12:54:57
schalte beim intel einen kern ab oder verbaue eine aktuelle dual core g5 und überprüfe dann deine behauptung. dann würde es etwas anders aussehen ;)
Eigentlich nicht. Wenn man nicht gerade QuickTime als Encoder nimmt, zersägt eine Notebook-CPU im iMac den Desktop-Chip G5 doch schon gewaltig. Und vom Core2 will ich gar nicht erst reden. Der ist ja "teilweise" (ja, so kann man es auch drehen) schon mit Rosetta schneller als der G5... :rolleyes:
Nur klammern sich halt viele PPC-Fanatiker noch an QuickTime. Das bricht dann auch weg, wenn Apple endlich mal optimiert... weiß nicht. Bisher sind viele "Pro-PPC" Argumente, die am Anfang kamen, doch schnell in den Wind geschossen...
Eigentlich nicht. Wenn man nicht gerade QuickTime als Encoder nimmt, zersägt eine Notebook-CPU im iMac den Desktop-Chip G5 doch schon gewaltig.
Eben nicht, wenn es pro Core geht!
Und jetzt überlegt man mal umgekehrt: Core Duo seit Anfang 2006 auf dem Markt und damals beste Intel CPU. G5 seit wann in mehr oder weniger ähnlicher Ausführung auf dem Markt? ;)
Also war der g5 vor 3 Jahren extrem dominierend ;)
Ganon
2006-09-01, 13:04:08
Eben nicht, wenn es pro Core geht!
Doch, schon. Ich red hier übrigens von DualCore-CPUs, nicht von Single vs. Dual.
Und jetzt überlegt man mal umgekehrt: Core Duo seit Anfang 2006 auf dem Markt und damals beste Intel CPU. G5 seit wann in mehr oder weniger ähnlicher Ausführung auf dem Markt? ;)
Der CoreDuo ist nix anderes als ein "2Kern"-Pentium M, wenn du es so willst. Ergo sind beide CPUs "in der Ausführung" etwa gleich alt. Kein zeitlicher Vorteil.
Also war der g5 vor 3 Jahren extrem dominierend ;)
Der G5 vor 3 Jahren mit über 100 Watt Verlustleistung? Nicht wirklich. ;) Denn der G5 ist nicht schneller geworden und war damals schon dem Opteron unterlegen. Klar. Schneller als der P4 war er. Aber da gibt's ja noch AMD. Und Intel ist jetzt an allen vorbei geschossen...
Doch, schon. Ich red hier übrigens von DualCore-CPUs, nicht von Single vs. Dual.
"The switch from the PowerPC G5 to the Intel Core Duo also seems impressive, but a large part of the performace gain came not from switvching architectures, but from switching from a single-core to a dual-core CPU."
Der G5 vor 3 Jahren mit über 100 Watt Verlustleistung? Nicht wirklich. ;) Denn der G5 ist nicht schneller geworden und war damals schon dem Opteron unterlegen. Klar. Schneller als der P4 war er. Aber da gibt's ja noch AMD. Und Intel ist jetzt an allen vorbei geschossen...
In Rechenleistung aber schon, wenn man bedenkt z.B. Zitat oben!
Ganon
2006-09-01, 13:20:20
"The switch from the PowerPC G5 to the Intel Core Duo also seems impressive, but a large part of the performace gain came not from switvching architectures, but from switching from a single-core to a dual-core CPU."
Öhm, wie tief willst du noch buddeln? Willst du jetzt noch mal den ersten "Switch" aushandeln, oder wie? Man kann locker die DualCore-Varianten vergleichen. Alles an Hardware da was du brauchst.
Und es ist klar das der InteliMac 2x schneller ist als der PPCiMac. Sicher weil sich die CPU-Anzahl verdoppelt hat. Aber mehr will Apple damit auch nicht sagen... (nein, Apple meint nicht die CPU-Kerne einzeln auf Takt runter gerechnet).
Trotzdem könnten PowerPC-Fanatiker endlich mal "los lassen" und mal akzeptieren das die x86er schneller sind. Denn wie gesagt, in 95% der Fälle SIND SIE ES EINFACH. Das war vor 3 Jahren schon so und das ist heute auch noch so. Das Problem ist schlicht, das man nun OS X zum benchen nimmt und nicht Linux. Das Problem an OS X ist halt das z.B. QuickTime noch recht mies auf IntelCPUs läuft. Das sieht man daran, wenn man mal wieder andere Systeme nimmt und das gleiche macht. ;)
In Rechenleistung aber schon, wenn man bedenkt z.B. Zitat oben!
Nope. Wie gesagt. Es gibt Fälle wo jede CPU mal irgendwo schneller ist als die andere wo es >wirklich< an der CPU liegt und nicht an der Software (ala QuickTime). Bloß wenn man jetzt so kleinlich anfängt, dann stell ich mich gleich hin und sage der G4 ist allen überlegen, da es ja Anwendungen gibt, wo er ProTakt weitaus schneller ist als ein G5. ;)
also so weit ich mich errinnere ging es darum ob die x86 architektur veraltet ist oder nicht und nicht über ppc vs x86 allein
also jede architektur hat ihre daseinberchtigung nur die x86 ist so wie sie ist stark angestaubt was durch die kompabilitätssache verhindert wird dass sie die architektur abstauben und neuen wind rein bringen
man könnte ja mal ein paar innovationen reinbringen aber ne immer nur rein auf simple leistungserhöhung aber ob das system auch gut durchdacht ist ist ne andere frage
ich hätte einige verbesserungen die ich besser für mich behalte denn
das wurde hier sowieso net gefragt was zu verbessern wäre ;)
BlackBirdSR
2006-09-01, 14:33:48
also jede architektur hat ihre daseinberchtigung nur die x86 ist so wie sie ist stark angestaubt was durch die kompabilitätssache verhindert wird dass sie die architektur abstauben und neuen wind rein bringen
Vorweg: Dein Satzbau und dein Schreibfluss sind sehr schwer zu lesen.
Keiner wird dir widersprechen, dass x86 angestaubt ist. Ist auch nicht verwunderlich. Das von dir kritisierte Kompatibilitätsproblem ist sicher vorhanden, zugleich aber einer der großen Pluspunkte für x86. Und einer der Gründe warum diese ISA sich großflächig durchgesetzt hat. Andere Gründe sind eben jene Innovationen, die du anscheinend nicht beachtet hast.
man könnte ja mal ein paar innovationen reinbringen aber ne immer nur rein auf simple leistungserhöhung aber ob das system auch gut durchdacht ist ist ne andere frage
Intel ist heute auch deshalb so erfolgreich, weil sie damals schon mit Innovationen um sich geworfen haben. Dazu gehören Infrastruktur genauso wie einzelne Details innerhalb der Mikroarchitektur.
Wenn ich mir x86 ansehe, dann würde mir alles einfallen, aber nicht dass sich nichts tut. Nach Außen mag es wohl statisch erscheinen. Aber überlege doch mal, was ein G5 oder G4 hat, was eine x86-64 CPU nicht auch bieten kann?
Diese bieten meiner Meinung nach sogar mehr.
Bokill
2006-09-01, 16:42:40
Ich frage mich was es für eine Rolle spielt wie genau nun die höhere Performance erreicht wird. Das ist schon auch eine Frage der Positionierung.
So wie AMD schon einen Dual-Core früh in Planung hatte, so auch IBM mit dem PPC 970.
Während aber die x86 Welt sich lautstark über die ersten Dual-Cores auf dem Heimsektor freute, ... so still pries Apple den PPC 970MP an ...
In Sachen Strombedarf ist der PPC 970MP deutlich überarbeitet worden, so dass bei niedrigen Taktraten der PPC 970MP vergleichbar sparsam ist wie ein Embedded Opteron ...
Als der PPC 970MP auf dem Markt war, hatte sich Apple aber schon längst zum Einsatz der Intel CPUs entschieden. Da hat nicht nur IBM darunter gelitten, sondern ein vielversprechendes Start-Up P.A.Semi.
P.A.Semi war so überzeugt von ihrem PPC-Design, dass sie hofften die nächsten Apple PCs mit ihren CPUs zu bestellen. Apple wollte aber keine vielversprechenden Zukunftsdesigns, sondern reale Chips in hoher Stückzahl, Qualität, Preis und begrenzten Strombedarf.
Mit der IBM G5 Variante PPC 970 versprach IBM viel, zu viel (Takt, Stückzahl) ... an der Hardware selber hat es nicht unbedingt gelegen. Es waren die Randbedingungen wie "Time to Market", Lieferbarkeit, Takt etc. die den G5 rausbrachten aus den Apple Rechnern.
MFG Bobo(2006)
Hmmmmmmmmm... schummelt Apple damit die Intel gut aussehen (können)?
"Logic Pro 7.2.2: Schummelt Apple?
Quad-Kern-Unterstützung nur für Intel-Chips"
http://www.macwelt.de/news/hardware/339806/index.html
"Universal QuarkXPress gets a speed boost, but only on Intel Macs
PowerPC performance takes a hit with version 7.01"
Universal QuarkXPress gets a speed boost, but only on Intel Macs
PowerPC performance takes a hit with version 7.01
iDVD6 VS iDVD5
Macwelt 3/2006, Seite 24
"iDVD 6 arbeitet beim Mpeg-Encoding auf Power-PCs etwa 30 Prozent langsamer als die Vorgänger-Version iDVD 5. Vergleicht man die Kodierzeiten der Intel-Macs in iDVD 6 mit denen der G5-Macs in iDVD 5, liegen die G5-Macs klar vorne"
Logic: Apple bremst Quad G5 aus
Intel-Version unterstützt im Gegensatz zur PPC-Version 4 Kerne!
http://www.lapworld.de/notebooknews/news/Logic_Apple_bremst_Quad_G5_aus.html
Link zu Quark vergessen: http://www.macworld.com/2006/09/reviews/quarkboost/index.php
http://arstechnica.com/cpu/03q1/x86-64/images/long.png
Könnte auch sein, dass das nur für den G5 gilt?
Nein, das gilt nur für den x86-64.
Beim PowerPC ist das so nicht nötig, denn:
" The PowerPC 970FX processor can execute all user-level instructions implemented by the 32-bit PowerPC processors. The PowerPC 970FX processor can also execute a number of new user-level instructions that are valid only for 64-bit PowerPC implementations.
[...]
The user-level instructions that are specific to the 64-bit PowerPC processor implementations and the instructions implemented by the 32-bit PowerPC processor can be executed in either computation mode."
http://www-128.ibm.com/developerworks/library/pa-nlaug04-introembeddev.html
(Weiter unten steht, dass bei Verwendung der ELF-ABI 32- und 64-bit-Code nicht in einem Executable gemischt werden kann. Ein Prozess muss also entweder die 32-bit- oder die 64-bit ELF-ABI verwenden.
Über Assembler-Funktionen können aber auch innerhalb eines 32-bit-Prozesses die spezifischen 64-bit-Befehle ausgeführt werden.
Mac OS X verwendet keine ELF-ABI, sondern Mach-O.)
Neuerdings wird wohl über RISC, CISC und POST-RISC gestritten:
http://www.fscklog.com/2006/11/wer_wird_der_nc.html
Aber ein sehr schönes Zitat gibt es dort:
"Invariably, the folks who protest this way are Mac users who know that the G3 has more instructions than the PII, yet they still want to insist that the G3 is a pure RISC chip (because RISC = Good) and the PII is a pure CISC chip (because CISC = Bad)."
Einfach nur noch peinlich. Als ob moderne x86 Prozessoren diese Befehle noch nativ ausführen würden. Der letzte seiner Art war bei AMD der Am5x86 (schon der K5 zerlegte die x86-Ops in kleiner Instruktionen) bzw. der Pentium MMX bei Intel.
Bokill
2006-11-24, 01:13:52
... and the PII is a pure CISC chip (because CISC = Bad)." Das ist technischer Bullshit, weil Intel mit dem PentiumPro ihre x86-CPU Welt technisch auf RISC einstellte.
AMD und Intel stellten nahezu zeitgleich ihre ersten RISC x86 CPUs vor (AMDs K5, Intels PentiumPro) ... scheint irgendwie den dortigen Mac-Jüngern irgendwie entgangen zu sein.
Ach ja, der PentiumPro, war der technische Stammvater der PentiumII Familie ... und somit auch im weitesten Sinne der Vater vom Conroe ... nicht das dümmste Stück Silizium, was Intel auf den Markt brachte ...
MFG Bobo(2006)
Bokill, sehe gerade, dass du in dem obigen Link zitierst wirst...
Adobe verzichtet in Photoshop CS 3 auf 64-Bit-Architektur
http://www.mactechnews.de/index.php?id=15371
Angeblich wegen Abwärtskompatibilität zu Tiger (mehr 32Bit als 64Bit-System). Und so eine dicke "Fat-Binary", in der sowohl 32Bit als auch 64Bit drin steckt, wäre unnötig aufgebläht.
Da fühlen sich gewisse x86-Switch-Gegner bestimmt bestätigt? :/
Ganon
2006-12-30, 15:32:30
Da fühlen sich gewisse x86-Switch-Gegner bestimmt bestätigt? :/
Wieso sollten sie? Das betrifft auch G5-Systeme...
Erst mit Leopard (OS X 10.5) ist 64bit komplett implementiert. Das hat mit ppc und x86 eigentlich gar nix zu tun.
damit war die kritik gemeint, wegen intel jetzt noch mehr architekturen unterstützen zu müssen
ppc 32bit
ppc 64bit
intel 32bit (wegen einer cpu - yonah)
intel 64bit
64 bits...when?
http://blogs.adobe.com/scottbyer/2006/12/64_bitswhen.html
Ganon
2006-12-30, 16:09:39
damit war die kritik gemeint, wegen intel jetzt noch mehr architekturen unterstützen zu müssen
Das Problem von Adobe ist nicht die CPU-Architektur. Das Problem von Adobe ist der jahrelang mitgeschleppte OS9-Code, der unter OS X noch in der emulationsschicht CarbonCFM lief. Den gibt's nun in OS X86 nicht mehr. Das hat Apple auch jahrelang angekündigt das CarbonCFM "bald" raus fliegt.
Hat Adobe nicht interessiert und jetzt haben sie den Salat.
kommt cs3 denn auf windows als 64bit version?
eine 64bit dürfte doch garnicht soviel mehraufwand sein, wenn man leopard als kleinsten nenner voraus setzt oder?
ich denke cs4 wird dann 64bit und intel only...
Das Problem von Adobe ist nicht die CPU-Architektur. Das Problem von Adobe ist der jahrelang mitgeschleppte OS9-Code, der unter OS X noch in der emulationsschicht CarbonCFM lief. Den gibt's nun in OS X86 nicht mehr. Das hat Apple auch jahrelang angekündigt das CarbonCFM "bald" raus fliegt.
Hat Adobe nicht interessiert und jetzt haben sie den Salat.
das hat aber jetzt nichts mit 64bit zu tun?
mit einem binary für 4 systeme hat man schon einen dicken klotz.
die windows-version von cs3 soll übrigens mal wieder schneller sein. unter leo soll cs3 aber besser als unter tiger laufen. stand irgendwo mal in den comments bei macnews oder macessntials
Ganon
2006-12-30, 16:15:51
das hat aber jetzt nichts mit 64bit zu tun?
OS9-Code kriegst du nicht nach 64bit portiert, da es CarbonCFM nicht als 64bit-Version gibt... ;)
Hat sehr wohl was damit zu tun.
OS9-Code kriegst du nicht nach 64bit portiert, da es CarbonCFM nicht als 64bit-Version gibt... ;)
Hat sehr wohl was damit zu tun.
carboncfm wird ja so oder so rausgeschmissen, in cs3. daher hat es doch nichts mit 64bit zu tun ;)
Ganon
2006-12-30, 16:21:42
carboncfm wird ja so oder so rausgeschmissen, in cs3. daher hat es doch nichts mit 64bit zu tun ;)
Ja eben. Adobe hatte genug zu tun ihren alten Code auszumüllen. Da bleibt nicht viel Zeit gleich noch 64bit mit zu unterstützen.
LOL
http://www.fscklog.com/2007/03/apple_tv_hacks_.html
http://www.fscklog.com/2007/03/apple_tv_entpac.html#comments
Der hört wohl nie auf
*no comment*
Daluxx
2007-03-31, 12:16:04
Davon abgesehen, sagt MAC auch: Hey, machen wir mal ein altes Os, und alle koennen ihre alte Software neu kaufen.
Davon abgesehen sagt MAC: Hey, machen wir mal nen neuen G5, und alte Hardware koennt ihr nicht mehr weiterverwenden.
x86 bedeutet fuer mich, dass ich sogar tie fighter anno win3.11 sogar auf nem P4 mit 3,6 Ghz zocken kann.
Ansonsten ist es ziemlich egal, ob es veraltet sind. Dass aktuelle Strontiums, wie AMDs boligen mit den Apples Mithalten koennen, sieht man an diversen benchmarks, so lang sie nicht besonders auf Apple optimiert sind.
Ansonsten sind die CPUs nicht wirklich von Apple.
Echt? Ich würde auch gerne wieder Tie Fighter zocken^^
Zumindest auf UNIX-Ebene kann man mit -m64 kompilieren und bekommt entsprechenden Code egal ob ein IA32/AMD64- oder ppc/ppc64-System (getestet MBP und Quad G5)
Zu dem "alten" Thema gibt es hier in der Diskussion Infos: "Schon jetzt können die "Macs" mit Core 2 x86-64-Code ausführen, obwohl der Mach-Kernel und die Kexts die arch = i386 ausweisen."
http://www.ppcnux.de/modules.php?name=News&file=comments&op=showreply&tid=10669&sid=6888&pid=10668&mode=&order=&thold=#10669
Jo, das liegt daran, dass die Kexts im Usermode arbeiten. Der Kernel an sich ist auch bei den PPCs 64-Bit.
Der Kernel an sich ist auch bei den PPCs 64-Bit.
Schau mal hier: http://macguild.org/wwdc/wwdc06.html#Kernel
und auch hier: http://macguild.org/wwdc/wwdc06.html#64-Bit
http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756/m/828002857831?r=626002957831#626002957831
Mac OS X 10.5 Leopard: the Ars Technica review
64-bithttp://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6
Öhm, echt? Wie geht das?
Der Kernel ist ein 32Bit Kernel. Hier hat jemand eine mögliche Erklärung:
In x86-64, the mode of any piece of code (32-bit compatibility mode or 64-bit long mode) is set by a bit in the cs register. The system call instructions allow a value for the cs register to be specified, which is loaded into the register when the system call is invoked. If the long mode bit is cleared in that value of 'cs', then when 64-bit code invokes a system call, the processor will switch back into 32-bit mode. When the system call returns, the processor will switch back into 64-bit mode.
In addition to the mode switch, the 64-bit libc (C library) has to cooperate to allow usage of a 32-bit kernel. For example, if it stores a 64-bit value in a register, when the mode switch occurs, the kernel will only see the lower 32-bits of that value. So the C library has to take this truncation into account.
Things aren't quite as difficult as they may seem at first. Remember that the kernel can't directly use pointers passed in from userspace anyway. It's a major security risk on any kernel , and in Darwin it's not even technically possible, because the kernel lives in a separate address space. So in the kernel there are APIs for copying data to and from userspace. These APIs work by temporarily mapping bits of the process's address space into the kernel. If these APIs are updated to account for 32-bit user processes, the kernel itself doesn't need to handle 64-bit pointers (directly).
PS) If this sounds messy, well, it is. But this is Darwin. You're already in the sticks, so you might as well enjoy the grits!
http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756/m/585002628831/p/4
apple = :uhammer:
Spaß beiseite.. Hab den Thread nur überflogen. In manchen Anwendungsbereichen ist Apple schön und gut. Es geht hier ja eigentlich wesentlich um die Leistung der Prozessoren.
Was ich allerdings tausend mal wichtiger finde, ist die Anzahl der verfügbaren Software. Das macht ein System erst WERTvoll.
Was wäre ein MS Windows mit x86 Architektur ohne anwendungen Wert: Nichts. Das gleiche gilt für Apple. Und der Vorteil liegt hier eindeutig bei MS. Hab zwar auch Linux laufen, aber in dieser Richtung bleibt ms ungeschlagen...
MfG
Superdash
Nein, der x86 PC wird nicht durch das Betriebssystem definiert, sondern
durch seine Eigenschaften.
Das Wertvollste am x86 PC ist sein hervorragendes Preis/Leistungsverhältnis, seine Aufrüstmöglichkeit und seine Abwärtskompatibilität für alte Software und alte OS.
Windows NT/2k/XP/Vista kann schon heute wegsterben und mich als PC User würde es nicht im geringsten stören, das war auch schon beim Wechsel von DOS zu Win9x so und auch von Win9x zu einem WinNT artigen OS.
Das Betriebssystem war beim x86 PC schon immer das unwichtigste, denn es wird einfach durchgereicht und das nächste kommt an den Zug.
Entscheidend sind die oben genannten Fähigkeiten der x86 bzw. jetzt x64 Architektur.
Preis Leistungsverhältnis
Aufrüstmöglichkeit
Abwärtskompatibilität
das sind die 3 großen Eckpfeiler der x86 Architektur und der Grund
warum sich der PC gegenüber allen anderen Architekturen durchgesetzt hat.
Wegen Win95+BlueScreen sind die Leute nicht zur x86 Architektur gewechselt.
Wegen DOS und seiner 8+3 Dateinamenseinschränkung auch nicht.
Und auch nicht wegen der Zwangsregistrierung von Windows XP.
Nein, der x86 PC wird nicht durch das Betriebssystem definiert, sondern
durch seine Eigenschaften.
???
Das Wertvollste am x86 PC ist sein hervorragendes Preis/Leistungsverhältnis,
???
Preis/Leistungsverhältnis ist gut, weil der x86 PC mit Abstand am weitesten verbreitet ist. Übrigens ist deine Aussage falsch. AFAIK waren PowerPC-CPUs in den Macs häufig günstiger als vergleichbare x86 CPUs, trotz deutlich geringerer Verbreitung!
seine Aufrüstmöglichkeit
Das hat nichts mit einer CPU-Architektur zu tun!
und seine Abwärtskompatibilität für alte Software und alte OS.
Wenn Abwärtskompatibitilität so Geschichten wie Kompatibilität zwischen 32 und 64 Bit mein, dann hat hier der PowerPC die Nase vorne. Die Abwärtskompatibiltitäten die du meinst sind aber eigentlich ein Fluch. Intel selber hätte am liebsten x86 abgeschossen aber da AMD64 so gut lief, ging es nicht. Auch Windows hängt in der Entwicklung wegen Abwärtskompatibilität oft zurück. Aus solchen Gründen ist bis zum Erscheinen von Vista z.B. per default ein User als Root unterwegs, damit auch alte oder schlecht programmierte Software läuft :rolleyes:
Windows NT/2k/XP/Vista kann schon heute wegsterben und mich als PC User würde es nicht im geringsten stören, das war auch schon beim Wechsel von DOS zu Win9x so und auch von Win9x zu einem WinNT artigen OS.
Da hat Apple aber viel elegantere Wechsel hingelegt ohne ihr OS aus technischer Sicht auszubremsen.
Das Betriebssystem war beim x86 PC schon immer das unwichtigste, denn es wird einfach durchgereicht und das nächste kommt an den Zug.
Falsch. Nur wegen DOS und später Windows ist x86 so verbreitet, da diese Betriebsysteme den Markt dominierten, was Verbreitung angeht. Ein 68K von Motorolla war klar besser als ein x86 damals!
das sind die 3 großen Eckpfeiler der x86 Architektur und der Grund
warum sich der PC gegenüber allen anderen Architekturen durchgesetzt hat.
Windows läft auf x86. Das ist der Grund und sonst nichts!
Preis/Leistungsverhältnis ist gut, weil der x86 PC mit Abstand am weitesten verbreitet ist. Übrigens ist deine Aussage falsch. AFAIK waren PowerPC-CPUs in den Macs häufig günstiger als vergleichbare x86 CPUs, trotz deutlich geringerer Verbreitung!
Ja, AFAIK trifft es hier richtig, leider irrst du dich.
Macs waren schon immer teurer als PCs wenn es darum ging, mindestens die gleiche Leistung zu erhalten.
Beim Mac hat man sich schon immer tot gezahlt.
Das hat nichts mit einer CPU-Architektur zu tun!
Ich spreche auch von einer Computerplattform als Ganzes.
Also PC vs. Mac vs. Amiga vs. Atari usw.
Der PC hat auf ganzer Linie gewonnen und den Sieg für sich entschieden.
Wenn Abwärtskompatibitilität so Geschichten wie Kompatibilität zwischen 32 und 64 Bit mein, dann hat hier der PowerPC die Nase vorne.
Unfug, der Mac 680x0 ist extrem inkompatibel zum PowerPC,
wenn man ihn mit der PC Plattform vergleicht.
Die Abwärtskompatibiltitäten die du meinst sind aber eigentlich ein Fluch.
Nein, ist sie nicht.
Ich muß meine Software nicht neu kaufen, ich kann sie auf meinem neusten Rechner immer noch benutzen.
Mach du das mal mit der Software deines Macs aus dem Jahr 1989 auf deinem aktuellen Intel Mac.
Aber so weit muß ich gar nicht zurückgehen, der Wechel vom PowerPC Mac zum Intel Mac reicht ja schon um zu beweisen das ich Recht habe.
Intel selber hätte am liebsten x86 abgeschossen aber da AMD64 so gut lief, ging es nicht. Auch Windows hängt in der Entwicklung wegen Abwärtskompatibilität oft zurück.
Wen interessiert hier Windows?
Windows ist eines von vielen Betriebssystemen die auf einem PC laufen.
Die Unwichtigkeit von Windows habe ich schon erwähnt.
Ich kann auf meinem PC auch Linux nutzen und mache das in der Praxis auch.
Da hat Apple aber viel elegantere Wechsel hingelegt ohne ihr OS aus technischer Sicht auszubremsen.
Das nenne ich schönen Kundensupport, wenn die ganzen Kunden ihre ganze Software neu kaufen müssen und das war jetzt nicht das erste mal, sondern kam schon 2 mal vor.
Noch schlimmer wird es, wenn man dann auch noch neue Hardware kaufen muß (Stichwort: Abschied von bewerten Schnittstellen).
An meinen PC kann ich heute noch meinen alten Canon Drucker mit Parallelport Anschluß anschließen und den nutze ich heute noch, für die 3 Seiten die ich im Jahr drucke brauche ich keinen neuen Drucker kaufen.
Falsch. Nur wegen DOS und später Windows ist x86 so verbreitet, da diese Betriebsysteme den Markt dominierten, was Verbreitung angeht.
Falsch, ganz falsch.
Die Amiga und Atari User sind zum PC gewechselt weil die Leistung besser war und man mehr fürs Geld bekam.
Das OS war eher uninteressant.
Ein 68K von Motorolla war klar besser als ein x86 damals!
Mit erscheinen des 386er konnte er einpacken, denn von da an lief die x86 Architektur der 68K Architektur davon.
Windows läft auf x86. Das ist der Grund und sonst nichts!
Siehe oben.
Zum Thema: http://arstechnica.com/news.ars/post/20071212-return-of-the-son-of-pentium-in-2008-intels-new-ultramobile-processors.html
Return of the Son of Pentium in 2008? Intel's new ultramobile processors
But in this particular low-transistor-count, sub-2W competition, the x86 ISA does put Intel at a real disadvantage.
Because a huge chunk of Silverthorne's die area is cache, the percentage of total die area that the new processor spends on x86 instruction decoding won't be as high as the original Pentium's 40 percent, but may well be in the double digits. Like the original Pentium, this relatively large number of transistors spent on x86 decode hardware will put Silverthorne at a performance and performance/watt disadvantage compared to a leaner RISC design like ARM, which can spend more die area on performance-enhancing cache. And Silverthorne's lower-cost Diamondville derivative, which will probably be underclocked and/or have less cache than its big brother, will look even worse next to a comparable ARM part.
In dem Bereich würde ich derzeit auch noch RISC den Vorzug geben. Aber die Zeit spielt auch dort für x86...
FlaschePomFrit
2007-12-13, 13:26:14
Der PC ist sowas von lächerlich. Allein der POST am Anfang dauert ewig. Die Tastatur kann nichtmal als 100Tasten-Joypad herhalten weil der lächerliche Kontroller schon bei 3 Tasten ins Röcheln kommt. Das gabs auf Amiga nicht. Und das alles mit eingebautem lärm-Netzteil (warum??, ich schleppe doch keine 10kg mit mir rum). So nun petzt wie üblich bei der Moderation wg. Bashing, ihr penetranten unwissenden Hyper-Fanboys.
Ja, AFAIK trifft es hier richtig, leider irrst du dich.
Macs waren schon immer teurer als PCs wenn es darum ging, mindestens die gleiche Leistung zu erhalten.
Beim Mac hat man sich schon immer tot gezahlt.
Ich spreche auch von einer Computerplattform als Ganzes.
Also PC vs. Mac vs. Amiga vs. Atari usw.
Der PC hat auf ganzer Linie gewonnen und den Sieg für sich entschieden.
Unfug, der Mac 680x0 ist extrem inkompatibel zum PowerPC,
wenn man ihn mit der PC Plattform vergleicht.
Nein, ist sie nicht.
Ich muß meine Software nicht neu kaufen, ich kann sie auf meinem neusten Rechner immer noch benutzen.
Mach du das mal mit der Software deines Macs aus dem Jahr 1989 auf deinem aktuellen Intel Mac.
Aber so weit muß ich gar nicht zurückgehen, der Wechel vom PowerPC Mac zum Intel Mac reicht ja schon um zu beweisen das ich Recht habe.
Wen interessiert hier Windows?
Windows ist eines von vielen Betriebssystemen die auf einem PC laufen.
Die Unwichtigkeit von Windows habe ich schon erwähnt.
Ich kann auf meinem PC auch Linux nutzen und mache das in der Praxis auch.
Das nenne ich schönen Kundensupport, wenn die ganzen Kunden ihre ganze Software neu kaufen müssen und das war jetzt nicht das erste mal, sondern kam schon 2 mal vor.
Noch schlimmer wird es, wenn man dann auch noch neue Hardware kaufen muß (Stichwort: Abschied von bewerten Schnittstellen).
An meinen PC kann ich heute noch meinen alten Canon Drucker mit Parallelport Anschluß anschließen und den nutze ich heute noch, für die 3 Seiten die ich im Jahr drucke brauche ich keinen neuen Drucker kaufen.
Falsch, ganz falsch.
Die Amiga und Atari User sind zum PC gewechselt weil die Leistung besser war und man mehr fürs Geld bekam.
Das OS war eher uninteressant.
Mit erscheinen des 386er konnte er einpacken, denn von da an lief die x86 Architektur der 68K Architektur davon.
Siehe oben.
Gast, deine Aussagen sind fast alle falsch. Rein technisch war jahrelang der Mac auch dem PC weit überlegen. OpenFirmware gibt es beim Mac schon seit Ewigkeiten. Als PCs sich noch mit ISA-Karten rumärgern durften, hatte der Mac schon weit fortgeschritteneres Bussystem. Daher auch teilweise die höheren Preise, da der PC-Kram Apple nicht gut genug war und den Ansprüchen nicht gerecht wurde. Das könnte man jetzt so weiterziehen, durch den ganzen Rechner. Erst in den letzen Jahren hat es sich angenähert bzw. ist jetzt bis auf EFI fast gleich.
Der Grund, warum der PC sich durchgesetzt hat ist wie gesagt Windows und nichts anderes. Hätte es Windows auf 68K gegeben, dann hätte sich 68K bzw. PowerPC durchgesetzt. Dann würdest du dir jetzt deinen "PowerPC-PC" genauso mit Einzelkomponenten zusammenschrauben, wie du es heute mit x86-Hardware machst.
StefanV
2007-12-13, 14:08:54
Der Grund, warum der PC sich durchgesetzt hat ist wie gesagt Windows und nichts anderes.
Das ist schlicht falsch.
Der Grund, warum sich der PC durchgesetzt hat, ist ein anderer:
Es ist eine freie, offene Architektur, zu der (früher) jeder, der bock drauf hatte, entsprechende Komponenten (CPU, Chipsätze usw) entwickeln konnte, das war bei den anderen nicht soo sehr gegeben...
Übrigens ist der MCA aufgrund der Lizensierung gescheitert, RDRAM ebenso, die Hersteller haben alle keinen Bock auf Lizenzgebühren, wenns nicht wirklich unbedingt sien muss...
Das ist schlicht falsch.
Der Grund, warum sich der PC durchgesetzt hat, ist ein anderer:
Es ist eine freie, offene Architektur, zu der (früher) jeder, der bock drauf hatte, entsprechende Komponenten (CPU, Chipsätze usw) entwickeln konnte, das war bei den anderen nicht soo sehr gegeben...
Das ist PowerPC AFAIK ebenso. AFAIK ist PowerPC sogar noch offener und jeder kann problemlos eine Lizenze zum CPU-Bauen erhalten.
Der Grund ist Windows und kein anderer ( bzw. dass das Apple-System im Gegensatz zu Windows geschlossen ist).
Wer soll PowerPC-Komponenten in großem Stil auf den Markt anbieten, wenn es keine Betriebsysteme dafür gibt? -> Windows ist der Grund!!!
Ergänzung:
Im Gegensatz zu x86 ist es im PPC-Bereich durchaus möglich Prozessoren zu kaufen, die nicht "von der Stange" sind und nach Kundenwünschen angepasst werden. IBM baut Custom-Chips (wie sie z.B. in der PlayStation 3 und der XBox 360 verwendet werden). Und auch andere PPC-Hersteller (es gibt da nicht nur einen oder zwei, sondern mehr, als eine Handvoll) machen das. Wenn man nur einen Auftrag erteilt.
Im ARM-Bereich ist das auch so. Siehe z.B. CPU im iPod.
Der PC ist sowas von lächerlich. Allein der POST am Anfang dauert ewig. Die Tastatur kann nichtmal als 100Tasten-Joypad herhalten weil der lächerliche Kontroller schon bei 3 Tasten ins Röcheln kommt. Das gabs auf Amiga nicht. Und das alles mit eingebautem lärm-Netzteil (warum??, ich schleppe doch keine 10kg mit mir rum). So nun petzt wie üblich bei der Moderation wg. Bashing, ihr penetranten unwissenden Hyper-Fanboys.
Das hat doch nichts mit x86 zu tun :)
Ganon
2007-12-13, 15:03:06
Im Gegensatz zu x86 ist es im PPC-Bereich durchaus möglich Prozessoren zu kaufen, die nicht "von der Stange" sind und nach Kundenwünschen angepasst werden.
Leg Intel oder AMD Geld auf den Tisch und sie machen es auch ;)
Leg Intel oder AMD Geld auf den Tisch und sie machen es auch ;)
Mag sein - aber sicher zu einem deutlich höherem Preis. "Custom-Chips" ist bei Intel und AMD nicht vorgesehen.
Das hat doch nichts mit x86 zu tun
Auf dem Intel-Mac scheint dank EFI in der Tat so manches besser zu sein, wie Bootvorgang. Daher sehe ich hier eher Bios als den Schuldigen und nicht x86.
Das hat doch nichts mit x86 zu tun :)
Sondern? Womit hat denn die Tastatur-Insuffizienz zu tun?
Der Tastatur-Controller? Die Architektur dieser?
Zudem glaube ich nicht, dass man auf irgend einem System eine USB-Tastatur als "100-Tasten-Gamepad" verwenden kann.
StefanV
2007-12-18, 16:07:46
Sondern? Womit hat denn die Tastatur-Insuffizienz zu tun?
An den Tastaturen selbst, da gibts anscheinend deutliche unterschiede.
Und mal ehrlich: Welchen Sinn machts, mehr als 3-4 Tasten gleichzeitig zu betätigen?! :|
Garkeinen?!
san.salvador
2007-12-18, 16:12:43
An den Tastaturen selbst, da gibts anscheinend deutliche unterschiede.
Und mal ehrlich: Welchen Sinn machts, mehr als 3-4 Tasten gleichzeitig zu betätigen?! :|
Garkeinen?!
Für Zocker schon. ;)
Und mal ehrlich: Welchen Sinn machts, mehr als 3-4 Tasten gleichzeitig zu betätigen?! :|
2 Spieler Spiele an einer Tastatur, da braucht man 6 oder besser 8.
sloth9
2007-12-20, 19:05:12
2 Spieler Spiele an einer Tastatur, da braucht man 6 oder besser 8.
Oder Joypads.
Wer spielt schon mit der Tastatur (ausser FPS u. RTS)?
Sondern? Womit hat denn die Tastatur-Insuffizienz zu tun?
Soweit mir bekannt ist, liegt das problem an der verschaltung der tastaturmatrix.
Natrurgemäß wäre es sinnfrei über hundert kabel zum rechner zu schicken, damit jede taste eine exklusive leitung hat.
Je nach hirngrips, den der verantwortliche für die matrixanordung und die schaltelektronik investiert hat ist eine tastatur mehr oder weniger für derartige ausfälle anfällig. Naturgemäß werden aber tastaturen im näheren umfeld zu einer matize zusammen geschaltet. Dann haben, vor allem spieler, den salat.
Ist also kein x86 - problem, sondern eher ein problem der kostenreduktion, indem man so minimalistisch wie möglich eine tastatur herstellen will.
Und mal ehrlich: Welchen Sinn machts, mehr als 3-4 Tasten gleichzeitig zu betätigen?! :|
Garkeinen?!
Doch, dann könnte man mit der Tastatur ein virtuelles Musik Instrument spielen.
Das geht aber nicht.
Momentan braucht man dazu ein Midi Keyboard.
Aus einem Tagebuch... der Switch zu Intel im stillen Kämmerlein
http://www.ppcnux.de/?q=node/7175
War das jemand von hier? :D
tokugawa
2008-01-04, 17:08:22
Doch, dann könnte man mit der Tastatur ein virtuelles Musik Instrument spielen.
Das geht aber nicht.
Momentan braucht man dazu ein Midi Keyboard.
Naja, für ein Instrument wär auch ideal wenn es Anschlagstärke (Velocity) erkennen könnte (eben wie ein MIDI-Keyboard).
Exxtreme
2008-01-04, 21:09:20
Wenn Abwärtskompatibitilität so Geschichten wie Kompatibilität zwischen 32 und 64 Bit mein, dann hat hier der PowerPC die Nase vorne. Die Abwärtskompatibiltitäten die du meinst sind aber eigentlich ein Fluch. Intel selber hätte am liebsten x86 abgeschossen aber da AMD64 so gut lief, ging es nicht. Auch Windows hängt in der Entwicklung wegen Abwärtskompatibilität oft zurück. Aus solchen Gründen ist bis zum Erscheinen von Vista z.B. per default ein User als Root unterwegs, damit auch alte oder schlecht programmierte Software läuft :rolleyes:
Natürlich hätte Intel x86 gerne abgeschossen. Aber nur weil Itanic voll mit Patenten ist und man so die Konkurrenz aussperren könnte. Und nicht weil EPIC so toll ist.
Schnuller4u
2008-04-22, 23:11:19
Interessant: Aus einem Tagebuch... der Switch zu Intel im stillen Kämmerlein
(http://www.ppcnux.de/?q=node/7175)
Interessant: Aus einem Tagebuch... der Switch zu Intel im stillen Kämmerlein
(http://www.ppcnux.de/?q=node/7175)
Wie cool:
Die Einführung des G5 hatte Bolsinger selbstverständlich auch miterlebt. Allerdings war wohl damals schon OS X auf einem Intel-System schneller.
Und Jobs hat auf den G5 Events immer die Vorteile des PPC Design gegenüber x86 gelobt...und alle haben im zugejubelt und ihm die Füße abgeleckt :biggrin:
Und Jobs hat auf den G5 Events immer die Vorteile des PPC Design gegenüber x86 gelobt...und alle haben im zugejubelt und ihm die Füße abgeleckt :biggrin:
Das Klappern gehört zum Geschäft. Und die Architektur (PPC) ist sicherlich nicht schlecht. Aber "Standard" ist eben x86 und deswegen fliesst da mehr Geld in Weiterentwicklung.
Das Klappern gehört zum Geschäft. Und die Architektur (PPC) ist sicherlich nicht schlecht. Aber "Standard" ist eben x86 und deswegen fliesst da mehr Geld in Weiterentwicklung.
Naja - Klappern ist leicht untertrieben ...schließlich hat man ja Benchmarks präsentiert die auf nem G5 besser waren, obwohl es auf der x86 Entwicklermaschine besser lief - ich nenn' das ne klare Verarsc.... :wink:
Naja - Klappern ist leicht untertrieben ...schließlich hat man ja Benchmarks präsentiert die auf nem G5 besser waren, obwohl es auf der x86 Entwicklermaschine besser lief - ich nenn' das ne klare Verarsc.... :wink:
Wieso? Die Benchmarks werden schon gestimmt haben, denn der G5 war in bestimmten Bereichen ja schon besser (vorallem Altivev optimierter Kram). Inwieweit das aber in der Praxis Relevanz hat, steht auf einem anderem Blatt. Interessant ist das Posting hier aus dem Link: http://www.ppcnux.de/?q=node/7175#comment-12644
Wieso? Die Benchmarks werden schon gestimmt haben, denn der G5 war in bestimmten Bereichen ja schon besser (vorallem Altivev optimierter Kram). Inwieweit das aber in der Praxis Relevanz hat, steht auf einem anderem Blatt. Interessant ist das Posting hier aus dem Link: http://www.ppcnux.de/?q=node/7175#comment-12644
Es ging mir mehr darum, dass Apple im Hintergrund ein schnelleres x86 System in der Mache hatte - aber das G5 System als ultimativ in den Himmel hob....
Simon Moon
2008-04-23, 08:29:09
Es ging mir mehr darum, dass Apple im Hintergrund ein schnelleres x86 System in der Mache hatte - aber das G5 System als ultimativ in den Himmel hob....
Naja, das Marketing würde sagen, über all die Jahre haben sich die Präferenzen der User wohl auf die Stärken der Intel Prozessoren verlagert. ;)
e.v.o
2008-04-23, 09:03:48
Es gibt für jeden Zweck den passenden Prozessor.
Wenn etwas veraltet ist dann die x86 Plattform und ihre drecks IRQ, usw.
Zu Apple gibts nur eins zu sagen:
Apple stinkt.. und zwar gewaltig. Die Firma schaffts mit den idiotischsten Argumenten und verdammt mies überteuerter Hard- und Software den Kunden das Geld aus der Tasche zu leiern wie keine andere Firma und sich dabei als die guten Helden hinzustellen.
Die Firmenpolitik und philosophie die Apple fährt sind meines erachtens nach eine Schande für jeden ITler sowie guten Ingenieur. Abgesehen von dem zeitlos geilen Design, das ja scheinbar bei der Firma Braun der 60er Jahre geklaut worden ist, sollte diese Firma vom Erdboden verschwinden.
Es gibt für jeden Zweck den passenden Prozessor.
Wenn etwas veraltet ist dann die x86 Plattform und ihre drecks IRQ, usw.
Zu Apple gibts nur eins zu sagen:
Apple stinkt.. und zwar gewaltig. Die Firma schaffts mit den idiotischsten Argumenten und verdammt mies überteuerter Hard- und Software den Kunden das Geld aus der Tasche zu leiern wie keine andere Firma und sich dabei als die guten Helden hinzustellen.
Die Firmenpolitik und philosophie die Apple fährt sind meines erachtens nach eine Schande für jeden ITler sowie guten Ingenieur. Abgesehen von dem zeitlos geilen Design, das ja scheinbar bei der Firma Braun der 60er Jahre geklaut worden ist, sollte diese Firma vom Erdboden verschwinden.
:rolleyes:
- Shake (vermutlich komplette Final Cut Studio Integration in 2009 oder killer-app Stand-Alone-Product ("Phenomenon") - hat mal 15,000 USD pro Lizenz gekostet. Apple verkauft jetzt Shake für Macs für 499$ oder "umsonst" als Teil vom SmoothCam filter in Final Cut Pro
- Logic - de facto Standard (mit Pro Tools zusammen) - was muss man sagen
- Color - eine professional pre-Apple 25000 $ App - jetzt Teil von Final Cut Studio und ist fantastisch.
Ja... aber Apple ist überteuert ;D Klar, wenn man es nur auf die Hardware beschränkt und selbst da stimmt es nur bedingt ;)
TheGamer
2008-04-23, 11:21:46
Ja... aber Apple ist überteuert ;D Klar, wenn man es nur auf die Hardware beschränkt und selbst da stimmt es nur bedingt ;)
Selbst bei der Hardware stimmt es nicht bis auf das MBA.
Anarchy-HWLUXX
2008-04-23, 11:37:18
Selbst bei der Hardware stimmt es nicht bis auf das MBA.
LoL ?
Das billigste Macbook ist immernoch massiv teurer als nen vergleichbares Windows gerät ...
TheGamer
2008-04-23, 12:12:38
LoL ?
Das billigste Macbook ist immernoch massiv teurer als nen vergleichbares Windows gerät ...
:rolleyes:
Ja dann vergleich mal mein Junge. Du kannst wiederkommen wenn du was zu vergleichen hast. Aber bitte beachte alle Aspekte die zu einem sinnvollen Vergleich fuehren. Ein reines Core2Duo 2.4 Ghz auf beiden Seiten reicht nicht aus.
Danke
Anarchy-HWLUXX
2008-04-23, 12:42:54
Auf den CPU speed schau ich garnicht, mir würde auch ein Turion oder nen 2GHz C2D reichen ... ich seh eh nicht ein wieso nen schleppi mehr power braucht als mein jetziger Tower PC.
Und die kleinste MacBook version mit 2.1GHz, 1GB RAM, 120GB und OHNE DVD Brenner kostet 1000€ ... meinen die das ernst ? Kein DVD Brenner :lol: Auf Geihzhals findet man kein annähernd aktuelles Windows Schleppi das noch ohne daherkommt ...
Sven77
2008-04-23, 12:49:58
LoL ?
Das billigste Macbook ist immernoch massiv teurer als nen vergleichbares Windows gerät ...
http://geizhals.at/?cat=nb13&sort=p
naja, so schlecht siehts fuer das Macbook wohl nicht aus? Aber man kann sich natuerlich auch ein Medion oder LG kaufen.. gibt auch Leute die sich nen Dacia Logan statt nem Auto kaufen ^^
Sven77
2008-04-23, 12:56:24
Zu Apple gibts nur eins zu sagen:
Apple stinkt.. und zwar gewaltig. Die Firma schaffts mit den idiotischsten Argumenten und verdammt mies überteuerter Hard- und Software den Kunden das Geld aus der Tasche zu leiern wie keine andere Firma und sich dabei als die guten Helden hinzustellen.
Die Firmenpolitik und philosophie die Apple fährt sind meines erachtens nach eine Schande für jeden ITler sowie guten Ingenieur. Abgesehen von dem zeitlos geilen Design, das ja scheinbar bei der Firma Braun der 60er Jahre geklaut worden ist, sollte diese Firma vom Erdboden verschwinden.
Dieses Profil passt wohl fuer jeden Global Player in der IT-Branche. Mal abgesehen von der Design-Sache
Anarchy-HWLUXX
2008-04-23, 15:25:20
http://geizhals.at/?cat=nb13&sort=p
naja, so schlecht siehts fuer das Macbook wohl nicht aus? Aber man kann sich natuerlich auch ein Medion oder LG kaufen.. gibt auch Leute die sich nen Dacia Logan statt nem Auto kaufen ^^
Mac ist ja auch für Leute die mal eben paar hundert Euro mehr zahlen wegen dem look ... wenn man sich dann noch die 15.4" Sparte anschaut schauts mal noch schlechter aus.
PS : Autovergleiche auf PCs angewendet sind zu 99% schwachfug und du bestätigst die Regel.
Ganon
2008-04-23, 15:51:09
wenn man sich dann noch die 15.4" Sparte anschaut schauts mal noch schlechter aus.
Für die Qualität der Notebooks, oder wie? :D
TheGamer
2008-04-23, 16:32:02
wenn man sich dann noch die 15.4" Sparte anschaut schauts mal noch schlechter aus.
Soso ;D
Dann vergleichen wir mal PCs mit PCs anstatt Autos mit Autos (war ja dein Wunsch an Sven)
Nehmen wir die 15.4 Zoll Sparte her.
Du sagst es sieht schlecht aus. Ich gehe davon aus das du den Preis meinst (von nichts anderem redest du ja hier).
Ich gebe dir jetzt einfach mal einen Link der dir hilft darueber nachzudenken
http://www.lenovo.com/de/de/
Ich gebe dir noch einen Tipp: Frueher lautete der Link http://www.ibm.com/de/de
Moechtest du mir auch einen Link zum denken geben? Vlt. http://www.medionshop.de
;D
Hier gehts doch nur darum zu sagen das Apple scheisse und teuer ist. Obwohl niemand eine vernuenftige Begruendung hat. Gewisse Dinge haben ihren Preis, genauso wie ein Lenovo in der Apple Preisklasse ist.
Wenn ich fuer ein Apple Notebook etwas Medionartiges bekommen wuerde waere ich deiner Meinung. So ist es aber nunmal nicht, daran kannst auch du nichts aendern. Genausowenig wie du an den Lenvopreisen was aendern kannst.
Wenn etwas veraltet ist dann die x86 Plattform und ihre drecks IRQ, usw.
IRQs gibt's bei jedem System das PCI verwendet. Das hat rein gar nichts mit x86 zu tun.
Außerdem hat x86 inzwischen einen sehr modernen APIC.
e.v.o
2008-04-23, 18:07:34
Jo Coda, da magst du sicherlich recht haben, aber ich denke hier im Thread bzw. am Anfang bei der Frage ging es wohl auch ein wenig um die Architektur heutiger PC systeme. Deshalb meine Anspielung.
Wie könnte man x86 denn verbessern? Oder was sollte anders werden?
Vielleicht eine Hybrid Architektur? In der z.B. Verschlüsselung von FPGAs übernommen wird?
Vielleicht eine Hybrid Architektur? In der z.B. Verschlüsselung von FPGAs übernommen wird?
Das ist nicht die Aufgabe einer CPU.
Anarchy-HWLUXX
2008-04-24, 02:27:04
Soso ;D
Dann vergleichen wir mal PCs mit PCs anstatt Autos mit Autos (war ja dein Wunsch an Sven)
Nehmen wir die 15.4 Zoll Sparte her.
Du sagst es sieht schlecht aus. Ich gehe davon aus das du den Preis meinst (von nichts anderem redest du ja hier).
Ich gebe dir jetzt einfach mal einen Link der dir hilft darueber nachzudenken
http://www.lenovo.com/de/de/
Ich gebe dir noch einen Tipp: Frueher lautete der Link http://www.ibm.com/de/de
Moechtest du mir auch einen Link zum denken geben? Vlt. http://www.medionshop.de
;D
Hier gehts doch nur darum zu sagen das Apple scheisse und teuer ist. Obwohl niemand eine vernuenftige Begruendung hat. Gewisse Dinge haben ihren Preis, genauso wie ein Lenovo in der Apple Preisklasse ist.
Wenn ich fuer ein Apple Notebook etwas Medionartiges bekommen wuerde waere ich deiner Meinung. So ist es aber nunmal nicht, daran kannst auch du nichts aendern. Genausowenig wie du an den Lenvopreisen was aendern kannst.
Das ist lächerlich, es gibt andere Hersteller als IBM/Lenovo und Medion... wobei Medion ja eh nur MSI Produkte vertreibt - das gebashe a la Aldi Marke ist also sinnfrei. Zwischen Low und High gibt es zum glück ja noch ein riesiges Feld das "mitte" heisst in welches Medion aka MSI auch gehört. Nach Low kommen die teile die man für gerade mal 400€ bekommt.
Schau mal die Dell Vostro 1510 an oder die HP Buisness Reihe ...
Ich hab net gesagt die Apple sind schlecht sondern das se massiv überteuert sind.
TheGamer
2008-04-24, 08:53:29
Ich hab net gesagt die Apple sind schlecht sondern das se massiv überteuert sind.
Was nicht stimmt. Du kannst an der Tatsache nichts ändern.
Das einzige was lächerlich ist sind deine Posts. Zuerst sich beschweren bezüglich unsinnigen vergleichen und sich dann aufregen wenn man richtige Vergleiche anstellt. Sag mir doch bitte wieso ich einen Apple mit HP oder MSI oder was weiß ich vergleichen soll aber nicht mit Lenovo. Consumergeraete von Apple sind nicht teurer als sonst was (man bekommt ja was dafür -> umfangreiche Hardware und Software). Thema Lenovo, bei Apple ist eben im Bereich Pro Geräte die Zielgruppe änderst -> eben wie bei Lenovo. Wieso sagst du nichts gegen Lenovo.
Wer etwas stabiles gut ausgestattetes möchte der kauft sich Lenovo (+paar andere) oder Apple. Wer nicht viel Geld ausgeben möchte der greift eben zu was anderem.
Das ist so und wird sich auch in Zukunft nicht ändern, bei keinem Hersteller.
Aber hier posten das Apple massiv überteuert sei kann nicht in Ordnung sein. Nur weil Apple da steht heißt es nicht man muss sich über alles aufregen weil es heutzutage so cool ist sich über Apples Preise zu beschweren.
Ich geh ja auch nicht her und sage Lenovo ist massiv überteuert. Denn ich weiß - durch frueheren IBM Besitz - warum Lenovo ein wenig mehr kostet. Genauso weiß ich warum ein Apple Produkt ein wenig mehr kostet. Ich erhalte bei beiden etwas das das investierte Geld Wert ist (wenn ich nichts dafür bekommen würde wäre ich deiner Meinung).
Eine Meinung über etwas zu haben das man nur vom sehen kennt reicht eben nicht aus.
Mmh, wenn man die Hardware von Apples Macbook auseinander nimmt ist Apple hoffnungslos überteuert (Consumerbereich).
Das Display ist ne billige 6Bit-Type, also unter aller Kanone.
Die Intel Grafik ist mit das lahmste was man bekommen kann.
Die Speicherausstattung ist vom Werk ab zu gering.
Gut spielen will man mit so einem Gerät sowieso nicht, aber ein vernünftiges Display soll es schon sein. Übrigens haben imho die kleinen Plastikmacbooks gerade wegen ihrem Gehäuse eine etwas billig anmutende Haptik. Ich will damit sagen, ich hab schon besseres gesehen, für weniger Geld.
Natürlich ist Apple optisch oben auf, wobei das nicht schwer ist wenn grad minimalismus im Trend ist.
Tiamat
2008-04-24, 11:18:10
Nun die Experimentierphase mit anderen Architekturen kann einen teuer zu stehen zu kommen. Siehe Intel mit IA64 und AMD die fröhlich ne Erweiterung zu X86 aufsetzten und den Itanium und dessen Preis verdammt unter Druck gesetzt haben. Wenn dann noch das Totschlargument von Microsoft kommt, kein Windows auf die neue Architektur anzupassen, war´s das dann wohl mit Experimenten.
Das wird Intel kein zweites Mal mehr machen, also woher soll denn neue Architekturen denn kommen, von AMD sicher nicht.
Zu Apple: Natürlich kann man sich für 600€,700€,800€ ein Notebook kaufen, was gleich einen DVD-Brenner und mehr als eine onBoard-Grafikkarte bietet und zudem ein größeres Display mitbringt.
Jeder hat die frei Wahl das zu kaufen, was seinen pers. Neigungen entspricht und es hält einen niemand davon ab.
Mir isses ehrlich ziemlich Schnuppe, ob z.b Dell ein Notebook in der u-1000€ Klasse im Angebot hat, was von mir aus doppelt so gut ausgestattet ist, wie das Macbook. Die 1000€ leg ich lieber ins Macbook an ;)
Mir isses ehrlich ziemlich Schnuppe, ob z.b Dell ein Notebook in der u-1000€ Klasse im Angebot hat, was von mir aus doppelt so gut ausgestattet ist, wie das Macbook. Die 1000€ leg ich lieber ins Macbook an ;)
Bei mir genauso. Nur das raffen viele nicht. Ich würde ja vermutlich selbst noch ein aus heutiger Sicht langsames iBook einem Super-Duper-Dingsbums-Laptop vorziehen.
In meinem Bekanntenkreis gibt es auch jemand, der in regelmässigen Abständen mit der Diskussion kommt und es einfach nicht versteht - verstehen will. Einen Mac kennt er natürlich nicht - bzw. nur von kurz gesehen.
TheGamer
2008-04-24, 11:28:28
Man sollte den Leuten mal wirklich einen Mac geben fuer eine Woche. Ich moechte wetten das 8 von 10 ihre Meinung drastisch geaendert haben.
Man sollte den Leuten mal wirklich einen Mac geben fuer eine Woche. Ich moechte wetten das 8 von 10 ihre Meinung drastisch geaendert haben.
Also ich nicht - auch nicht nach 4 Monaten :wink:
TheGamer
2008-04-24, 11:47:16
Also ich nicht - auch nicht nach 4 Monaten :wink:
Schonmal gemacht oder wie? :D (also ich meine die 4 Monate :D)
Schonmal gemacht oder wie? :D (also ich meine die 4 Monate :D)
Jep - für die FH haben wir in einer Projektgruppe 4 Monate auf Macs Software entwickelt..
TheGamer
2008-04-24, 11:59:31
Jep - für die FH haben wir in einer Projektgruppe 4 Monate auf Macs Software entwickelt..
Objective C? Was waren das fuer Maschinen, in welchem Jahr?
Dann bist du der 10.
Es kann noch der 9. kommen.
1-8 wird die Meinung aendern ;)
Objective C? Was waren das fuer Maschinen, in welchem Jahr?
Dann bist du der 10.
Es kann noch der 9. kommen.
1-8 wird die Meinung aendern ;)
Waren - glaube diese hier:
http://www.apple-history.com/?page=gallery&model=imac_mid_06&performa=off&sort=date&order=ASC
Ist OT aber nur da ich es gerade gefunden habe und eben in weiten Teilen wirklich so oder ähnlich ist.
http://img512.imageshack.us/img512/4934/ecca2d3550e249bd9d3d901sb1.jpg
Ist OT aber nur da ich es gerade gefunden habe und eben in weiten Teilen wirklich so oder ähnlich ist.
Ist aber kein guter Vergleich - eine Hardware, die Mac-OS von Haus aus unterstützt zu vergleichen, mit einer, die Windows nicht unterstützt...
Vergleich doch mal die beiden bei USB Stick Gebrauch...:wink:
Vergleich doch mal die beiden bei USB Stick Gebrauch...:wink:
Gerade beim USB-Stick nervt mich Windows mit der Klick- und Zielorgie von allen Betriebsystemen am meisten.
littlejam
2008-04-24, 13:04:47
Hier gehts doch nur darum zu sagen das Apple scheisse und teuer ist. Obwohl niemand eine vernuenftige Begruendung hat. Gewisse Dinge haben ihren Preis, genauso wie ein Lenovo in der Apple Preisklasse ist.
Aber hier posten das Apple massiv überteuert sei kann nicht in Ordnung sein. Nur weil Apple da steht heißt es nicht man muss sich über alles aufregen weil es heutzutage so cool ist sich über Apples Preise zu beschweren.
Dann kannst du mir auch sicherlich begründen, woher der Mehrwert für die Apple-Radeon 9600 kommt...
http://store.apple.com/Apple/WebObjects/germanstore.woa/wa/RSLID?mco=7E4EB91E&nplm=TL139
Apple ist teuer. Und die Qualität ist durchschnittlich gut.
Aber ok, soll jeder machen was er will.
Das was mich aber an den Apple-Nutzern so ärgert, ist dass die *ihren* Mac (und *ihren* Steve Jobs) so in den Klee loben und damit voll auf das Marketing reinfallen.
Solange es PPC gab, war x86 natürlich total veraltet.
Gruß
Actionhank
2008-04-24, 13:07:42
Dass Apple teuer für die gebotene Hardware ist, liegt eigentlich auf der Hand. Schliesslich bezahlt man auch für Design und damit verbunden für Lifestyle.
Wäre ja dumm von Apple, wenn sie das nicht zur Gewinnmaximierung verwenden würden.
Gerade beim USB-Stick nervt mich Windows mit der Klick- und Zielorgie von allen Betriebsystemen am meisten.
Was ist das denn für eine Klick- und Zielorgie :confused:
Was ist das denn für eine Klick- und Zielorgie :confused:
Rechtsklick unten im Tray, abmelden, aussuchen, bestätigen... Rückfragen usw.
OSX einfach in den Papierkorb oder alternativ im Finder deaktivieren fertig. Bei Gnome ist es ebenfalls angenehmer als unter Windows.
nggalai
2008-04-24, 13:10:43
Könnten wir vielleicht wieder zum Thema kommen? Und Apple vs/ den Rest der Welt stecken lassen? Das Thema hatten wir echt schon oft genug.
Danke. :)
TheGamer
2008-04-24, 13:47:36
Dann kannst du mir auch sicherlich begründen, woher der Mehrwert für die Apple-Radeon 9600 kommt...
http://store.apple.com/Apple/WebObjects/germanstore.woa/wa/RSLID?mco=7E4EB91E&nplm=TL139
Apple ist teuer. Und die Qualität ist durchschnittlich gut.
Aber ok, soll jeder machen was er will.
Das was mich aber an den Apple-Nutzern so ärgert, ist dass die *ihren* Mac (und *ihren* Steve Jobs) so in den Klee loben und damit voll auf das Marketing reinfallen.
Solange es PPC gab, war x86 natürlich total veraltet.
Gruß
Keine Argumente oder wie, es geht um hier Macs.
Das Apple bei Einzelverkauf von hardwareteilen abartig und unfair teuer ist musst du mir nicht sagen, das weiss ich selbst auch. Da ist deine Grafikkarte da noch geradezu billig wenn ich mir RAM und Festplatten anschaue ;)
Aber wir reden hier ja von Komplettpaketen in Form von Macs. Da schaut es anderst aus.
Einzelteile wurden schon immer unserioes teuer verkauft.
Solange es PPC gab, war x86 natürlich total veraltet.
So unrecht hatten sie doch gar nicht, damals hatte sich doch auf PC-Basis das schlechteste Produkt durchgesetzt, der Pentium 4.
Die Keynote dieser Käufer war ein hässliches Werbeicon, bei dem "echte 3Ghz Ausrufezeichen" draufstand und das hat schon gereicht, dass die Leute den Geldbeutel gezückt haben und wie die wahnsinnigen P4 Prozessoren und Rechner gekauft haben. Wenn du das nicht noch absurder findest, als der Hype um Apple und Steve Jobs, dann weiß ich´s auch nicht.
Der P4-PC war aber dem PPC in fast jeder verfügbaren Software überlegen.
Geschweige denn, die Athlons.
Das Komplett-Paket ein Argument was bescheuerter nicht sein kann.
Apple liefert zu ihrem OS einen Rechner der es gerade mal so laufen lassen kann. Lange Wartezeiten werden einfach mit unnötigen Animationen und Geblinke überbrückt.
Außerdem ist MacOS keineswegs ultrastabil, es ist lediglich stabiler als Win.
Das wahrscheinlich auch nur weil man eben nicht für die Kompatibilität sorgen muss. Macs sind wie Spielekonsolen und bieten selbst als solche ein für den Preis beschissene Leistung. Denn Jobs kann ja nie irren, der baut immer da beste vom besten.
Schon länger her...
Das beste war als ein repräsentant bei Giga war mit dem aktuellen Macbook und zeigen wollte wie toll alles darauf läuft. Es hat sichtlich geruckelt aber alle mussten wie mit vorgehaltener Waffe sagen, dass es wunderbar flüssig ist.
Schnell wollte auch der Moderator zum anderen Thema wechseln weil es einfach lächerlich war.
Apple liefert zu ihrem OS einen Rechner der es gerade mal so laufen lassen kann. Lange Wartezeiten werden einfach mit unnötigen Animationen und Geblinke überbrückt.
Das Disqualifiziert dich schon total und zeigt, dass du keinen blassen Schimmer hast. Und was du als unnötige Animation beschreibst, ist häufig nicht unnötig (z.B. hüpfendes Icon im Dock). Kannst du nur nicht nachvollziehen, da du nicht wissen wirst, wie die Fenster und die Oberfläche organisiert sind - nämlich anders als bei Windows, Gnome und KDE.
Jo Coda, da magst du sicherlich recht haben, aber ich denke hier im Thread bzw. am Anfang bei der Frage ging es wohl auch ein wenig um die Architektur heutiger PC systeme. Deshalb meine Anspielung.
Wie könnte man x86 denn verbessern? Oder was sollte anders werden?
Vielleicht eine Hybrid Architektur? In der z.B. Verschlüsselung von FPGAs übernommen wird?
Man wird x86 eben in die Richtung verbessern dass man den Befehlssatz immer weiter aufbohrt. Ansonsten hat man die schlimmsten Punkte schon damals mit dem 32-Bit-Protected-Mode erledigt und nun mit x86-64 noch weiter dran gefeilt (16 vollwertige Integer-Register, 16 Multimedia-Register, Missbilligung der klassischen Stack-FPU, kompletter Wegfall von Segmenten, usw.)
Es gibt z.B. mit dem nächsten SSE auch Cryptobefehle für AES.
Das ist nicht die Aufgabe einer CPU.
Das seh ich anders. Im Serverbetrieb ist das eines der Hauptaufgaben der CPU und deshalb wird es auch implementiert werden.
So unrecht hatten sie doch gar nicht, damals hatte sich doch auf PC-Basis das schlechteste Produkt durchgesetzt, der Pentium 4.
Du meinst AMD hätte Marketing ala Apple nötig gehabt? Da hast du sowas von recht ;)
Der P4-PC war aber dem PPC in fast jeder verfügbaren Software überlegen.
ROTFL - sag das mal den Leuten, die einen Rechnern zum numbercrunchen verwenden.
Naja der PPC wurde von handelsüblichen IBM-PCs die zudem deutlich günstiger waren in der damaligen Masterdisziplinen des Macs absolut runtergemacht. Von Photoshop bis Videobearbeitung konnte sich der PPC nicht absetzen.
Das gehüpfe ist definitv nur dummer blinke-scheiß das hätte man aucch anders lösen können.
Naja der PPC wurde von handelsüblichen IBM-PCs die zudem deutlich günstiger waren in der damaligen Masterdisziplinen des Macs absolut runtergemacht. Von Photoshop bis Videobearbeitung konnte sich der PPC nicht absetzen.
Das kann man eben nicht pauschalisieren. Wieso gibt es z.B. einen Supercomputer, der aus vielen Powermacs G5 zusammengeschustert ist?
Das gehüpfe ist definitv nur dummer blinke-scheiß das hätte man aucch anders lösen können.
Wie denn?
Dieter Nuhr!
Warum es so einen Supercomputer gibt, weiß ich nicht.
Es gibt bestimmt Schnelleres und Besseres was weder auf dem PPC noch auf x86 basiert.
Das einzig tolle am PPC waren die Alivec-Einheiten, die aber speziell für Grafikoperationen optimiert sind (Eine Art Grafik-SSE). Ist aber alles untergegangen und ich erinnere mich noch wie ein normale P4 3GHz in allen belangen ein PowerMac pro irgendwas mit 4 CPUs weggeputzt hat.
Und das war nicht irgendeine Decodierung oder sonst nen Spezikramm
das war Photoshop, Komprimieren und Video-Encoding. Damals hat Apple so einen dämpfer abbekommen.
"Irgendein PowerPC mit 4Ghz" zeigt sehr gut, dass du kaum Ahnung hast, denn die gibt/gab es nicht ;)
Und im Supercomputer hatte man sich damals gerade für die G5 entschieden, da die dafür gerade beim P-L-Verhältnis top waren.
http://www.heise.de/newsticker/US-Uni-entwickelt-Super-Cluster-aus-G5-Power-Macs--/meldung/40044
http://www.zdnet.de/news/business/0,39023142,39123403,00.htm
Das einzig tolle am PPC waren die Alivec-Einheiten, die aber speziell für Grafikoperationen optimiert sind (Eine Art Grafik-SSE).
Eigentlich auch nicht mehr als SSE.
Es gibt eine dynamische Shuffle-Instruction. Das fehlt SSE und vermisst man manchmal. Aber sonst ist beides nur Vec4 Float für Grafikops. Kein großer Unterschied also.
Diarrhorus
2008-04-24, 23:11:08
"Irgendein PowerPC mit 4Ghz" zeigt sehr gut, dass du kaum Ahnung hast, denn die gibt/gab es nicht ;)
Und das zeigt das du kaum lesen kannst.
Und das zeigt das du kaum lesen kannst.
OK - verlesen ;)
Trotzdem stimmt das so nicht, denn erst mit Opteron konnte in _bestimmten_ Bereichen x86 mithalten. Zumal der irgendein 4Kern-G5 damals die günstigste 4Kern-Workstation war.
Ne stimmt schon, denn abseits der Alivec-Klamotte war der G5 grottenlahm.
Wenns nicht der p4 packte dann der athlon.
Ne stimmt schon, denn abseits der Alivec-Klamotte war der G5 grottenlahm.
Wenns nicht der p4 packte dann der athlon.
Das hatte ich auch immer teilweise gedacht aber gerade durch den Switch habe ich gemerkt, dass dem häufig nicht so ist. Denn die ersten Intel-Macs lagen in etwa auf der höhe der G5s in vielen Apps und konnten sich häufig nur deutlich absetzten, da z.B. Dual-Core vs. Single Core im iMac.
So schlecht war der G5 sicher auch nicht. Das Backend usw. ist ja sehr modern. Es gibt eben nicht mehr so viele Unterschiede bei Prozessorarchitekturen, weil eh alle im Backend ähnlich sind nachdem die Instructions dekodiert wurden.
Man sieht's ja an IBMs neuem POWER6 (RISC). Es gibt davon eine CISC-Variante für die zSerie (z10) der fast exakt das gleiche Layout und Ausführungseinheiten hat.
Als Laie würde ich sagen, dass man den Unterschied heute doch fast auf die ISA reduzieren kann. Und Aussagen, dass PPC am Ende ist, halte ich für lachhaft. Dann müsste doch x86 schon x-mal am Ende sein. Es liegt schlicht daran, dass die Welt sich bei x86 abspielt und daher dort mehr Geld fliesst. Bei "Kleinprozessoren" für Handys sieht es (noch) anders aus.
Meiner Meinung nach gibt es zwei Möglichkeiten:
1. x86 breitet sich immer mehr und mehr aus bis es wirklich fast ein Monopol hat
2. Es werden irgendwann alle Userspace-Programme in platformunabhängigem Bytecode vorliegen und die Architektur ist bis auf den Kernel sowieso egal.
Letzteres gar nicht so unwahrscheinlich. Apple zielt jetzt schon in diese Richtung mit ihrem GCC der das Backend in die Ausführung verlegt und auch sonst legen sie viel Wert auf Platfromunabhängigkeit. Aber auch Microsoft hat die Basis dazu. NT lässt sich relativ gut portieren und .NET bietet die nötige platformunabhängige Infrastruktur.
Bei Linux ist es eh egal, weil da die meiste Software sowieso für alle Platformen vorliegt.
2. Es werden irgendwann alle Userspace-Programme in platformunabhängigem Bytecode vorliegen und die Architektur ist bis auf den Kernel sowieso egal.
Juhu :(, ich hoffe das passiert nie
Ganon
2008-04-25, 09:18:25
Juhu :(, ich hoffe das passiert nie
Grund?
Grund?
schonmal versucht ein DSP-Programm in Java zu schreiben?
Die Effizienz nimmt damit doch immer weiter ab, da es sich letztendlich um interpretierten Code handelt.
Würde man die bestehenden Architekturen wirklich nutzen, bräuchten wir keine 4GHz Prozessoren.
Anders wäre es natürlich wenn man platformunabhängigen Bytecode verbreitet,
und diesen auf jeder Platform selbst kompilieren kann. Das fände ich dann sogar ganz ansprechend.
Ganon
2008-04-25, 09:28:13
Was hat die Java-Virtual-Machine jetzt mit dem zu tun, was Coda oben erwähnte?
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=371666
Da. Der Byte-Code ist sogar in vielen Bereichen schneller als der direkt compilierte Code... und LLVM ist die letzten Jahre nicht langsamer geworden, eher schneller.
edit:
Außerdem sollte man Betriebssystemunabhängig und Prozessorunabhängig bei diesem Thema nicht durcheinanderwürfeln. Java-Programme sind Betriebssystem und Prozessorunabhängig. Die LLVM ist nur Prozessorunabhängig.
Toll, dann musst du ihn jedesmal Kompilieren.
Ganon
2008-04-25, 09:35:04
Toll, dann musst du ihn jedesmal Kompilieren.
Just in Time Compiling...
Was hat die Java-Virtual-Machine jetzt mit dem zu tun, was Coda oben erwähnte?
ob nun eine Virtual-Machine als JIT Compiler fungiert oder der Kernel ist doch letztendlich egal, oder hab ich jetzt irgendwas nicht verstanden?
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=371666
sind das Library-Funktionen die du gebencht hast?
Die Beispiele eignen sich auch gut für Autovektorisierung, und wie gut GCC (welche Version überhaupt) das kann, weiß ich nicht.
Nichts geht über handoptimierten Code
Ganon
2008-04-25, 09:42:38
ob nun eine Virtual-Machine als JIT Compiler fungiert oder der Kernel ist doch letztendlich egal, oder hab ich jetzt irgendwas nicht verstanden?
Java-Programme müssen auch Betriebssystemunabhängig sein. D.h. alles muss irgendwie gekapselt werden und durch Wrapper laufen. Das kostet eben Zeit. Das fällt bei LLVM weg. Es wird halt nur fix für die entsprechende CPU der Code erstellt. Ein LLVM-Programm läuft nicht unter Linux, Windows und OS X, sondern nur dort wo es erstellt wurde. Nur die CPU ist dabei egal.
sind das Library-Funktionen die du gebencht hast?
Die Beispiele eignen sich auch gut für Autovektorisierung, und wie gut GCC (welche Version überhaupt) das kann, weiß ich nicht.
LLVM nutzt GCC4, von daher liegt es nicht daran. Ich habe da einfach den SciMark ein mal mit LLVM und ein mal mit GCC4 erstellt und laufen lassen.
Nichts geht über handoptimierten Code
Den kannst du doch immer noch schreiben. Hält dich keiner davon ab. Nur das der dann nicht compiliert wird, sondern per JiTC ausgeführt wird. Das dieser locker mal 20% schneller sein kann, als der "native" Code, siehst du oben.
Nur das der dann nicht compiliert wird, sondern per JiTC ausgeführt wird. Das dieser locker mal 20% schneller sein kann, als der "native" Code, siehst du oben.
Handoptimiert heißt für mich Assembler. Und ein Natives-Kompilat ist immer schneller. Dann verwendet LLVM eben andere Optimierungsstrategien, Library-Funktionen.
Ganon
2008-04-25, 09:49:51
Handoptimiert heißt für mich Assembler.
Als wenn die Masse an Anwendungen noch Assembler-Code enthält ;) Selbst Kernel enthalten nur noch ein Minimum an Assembler. Und auch wenn du Assembler brauchst, das verbietet dir LLVM auch nicht. Nur ist dann halt CPU-Unabhänigigkeit nicht gegeben, sofern du nicht für jede CPU den Code erstellst.
Und ein Natives-Kompilat ist immer schneller.
Siehe den Benchmark oben. Ich habe halt etwas anderes heraus gefunden.
Dann verwendet LLVM eben andere Optimierungsstrategien
Ja, les den Thread. Sachen die halt nur ein JiTC kann. Darum kann es schneller als "nativ" werden.
, Library-Funktionen.
Damit meinst du?
Du kannst dir ja gerne LLVM installieren und mir einen Gegenbeweis zeigen. Würde mich auch interessieren.
Als wenn die Masse an Anwendungen noch Assembler-Code enthält ;)
ich hab oben von DSP-Programmen geredet. Audio/Video-Codecs z.B. gehen ohne ASM garnicht.
Siehe den Benchmark oben. Ich habe halt etwas anderes heraus gefunden.
das wiederspricht doch jeglicher Logik. Wie ich schon geschrieben habe,
es ist ein Optimierungsproblem. GCC bietet ab der 4.x Version auch mehr als -O3, sondern Mehrpass-Optimierung
Damit meinst du?
Ich könnte mir vorstellen, das gewisse Prozeduren schon voroptimiert sind.
Ganon
2008-04-25, 10:17:08
ich hab oben von DSP-Programmen geredet. Audio/Video-Codecs z.B. gehen ohne ASM garnicht.
Ändert ja nichts daran das es bei 90% der anderen Anwendungen eben nicht benötigt wird. Und es ist, wie gesagt, kein Problem ASM zu nutzen innerhalb von LLVM.
das wiederspricht doch jeglicher Logik.
Ändert aber nichts daran das es so ist.
Wie ich schon geschrieben habe,
es ist ein Optimierungsproblem. GCC bietet ab der 4.x Version auch mehr als -O3, sondern Mehrpass-Optimierung
Wie gesagt, kannst du auch gerne einen Benchmark damit machen. :) JiTC ist ja von Haus aus "Multipass" in dem Sinne, jedoch mit Laufzeitinformationen.
Ich könnte mir vorstellen, das gewisse Prozeduren schon voroptimiert sind.
Genau die gleichen nimmt der GCC auch...
Legolas
2008-04-25, 11:39:29
LLVM nutzt GCC4, von daher liegt es nicht daran. Ich habe da einfach den SciMark ein mal mit LLVM und ein mal mit GCC4 erstellt und laufen lassen.
LLVM nutzt vom GCC nur das Frontend für C/C++. Von den GCC Optimierungen sollten dabei nur die Sprachabhängigen zum Einsatz kommen. Ob Vektorcode da dann dazuzählt? Das Frontend generiert im Allgemeinen LLVM Code, der dann die Optimierungsinfrastruktur von LLVM nutzt. Insofern vergleichst du bei deinem Benchmark wahrscheinlich schon die Optimierungen des GCC mit denen, die LLVM durchführt.
Ganon
2008-04-25, 12:02:31
Insofern vergleichst du bei deinem Benchmark wahrscheinlich schon die Optimierungen des GCC mit denen, die LLVM durchführt.
Na das ist im Prinzip auch Sinn der Sache. Es geht ja darum das ein JiTC einen nativen Compiler "besiegt", was als "völlig unlogisch" bezeichnet wurde. Wenn, dann wird die SIMD-Optimierung eh zur Laufzeit vorgenommen.
Das ist ja auch das tolle daran. Verbesserst du die Leistung des JiTC, dann verbesserst du die Leistung von allen Anwendungen. Verbesserst du die Leistung vom GCC, dann müsste jeder erst mal neu kompilieren.
Ectoplasma
2008-04-25, 12:05:37
Ich habe da einmal eine kleine Frage bezüglich JITs und Konsorten. Diese generieren ja Code zur Laufzeit (wenn ich das richtig verstanden habe). Aber wo wird dieser Code generiert, bzw. läuft dieser Code bei X86 CPUs? Im Datensegment oder im Codesegment? Was passiert, wenn der Code im Datensegment laufen soll und das NX-Flag (No eXecution) z.B. bei AMD CPUs gesetzt ist. Läuft so ein JIT dann überhaupt oder gibt es da andere Möglichkeiten Code zur Laufzeit zu generieren und auszuführen?
Legolas
2008-04-25, 12:14:39
Na das ist im Prinzip auch Sinn der Sache. Es geht ja darum das ein JiTC einen nativen Compiler "besiegt", was als "völlig unlogisch" bezeichnet wurde. Wenn, dann wird die SIMD-Optimierung eh zur Laufzeit vorgenommen.
Das ist ja auch das tolle daran. Verbesserst du die Leistung des JiTC, dann verbesserst du die Leistung von allen Anwendungen. Verbesserst du die Leistung vom GCC, dann müsste jeder erst mal neu kompilieren.
LLVM kann ja auch statisch kompilieren. Und der Codegenerator für den JiT ist im Endeffekt derselbe, den auch die statische Version benutzt. Wenn du den LLVM JiT benutzt bekommst du halt noch Profiling Informationen, die zu einer weiteren Optimierung beitragen können.(EDIT: In wieweit das fertig implementiert ist in LLVM, da bin ich jetzt aber auch überfragt) Und bei deinem Vergleich fehlt die statisch mit LLVM kompilierte Version. Insofern vergleichst du die beiden Codegeneratoren/Optimierer.
Allerdings stimme ich dir zu, daß JiT Compilation nicht automatisch zu langsamerem Code führt.
Exxtreme
2008-04-25, 12:48:59
Problem ist halt, der erste Start einer Anwendung könnte sehr lange dauern wenn diese zur Laufzeit kompiliert werden muss. Wenn ich überlege wie lange damals das Kompilieren von Openoffice dauerte ... ;(
Nichts geht über handoptimierten Code
Genauso wie ein Computer nicht besser Schach spielen kann als ein Mensch...
Legolas
2008-04-25, 13:11:04
Problem ist halt, der erste Start einer Anwendung könnte sehr lange dauern wenn diese zur Laufzeit kompiliert werden muss. Wenn ich überlege wie lange damals das Kompilieren von Openoffice dauerte ... ;(
Man könnte ja einfach schon zum Installationszeitpunkt kompillieren.
Exxtreme
2008-04-25, 13:12:08
Man könnte ja einfach schon zum Installationszeitpunkt kompillieren.
Du willst doch nicht 7 Stunden auf das Kompilat warten oder?
Legolas
2008-04-25, 13:14:30
Du willst doch nicht 7 Stunden auf das Kompilat warten oder?
Man kompiliert ja nicht von C/C++ in ASM, sondern von einer abstrakten, möglichst effizienten Zwischensprache nach ASM. Plattformunabhängige Optimierungen können dann schon beim Hersteller gemacht werden, so dass nur noch der Codegenerator und einige plattformspezifische Optimierungen gemacht werden müssen. Dann sollte das auch schneller gehen.
Exxtreme
2008-04-25, 13:15:18
Man kompiliert ja nicht von C/C++ in ASM, sondern von einer abstrakten, möglichst effizienten Zwischensprache nach ASM. Plattformunabhängige Optimierungen können dann schon beim Hersteller gemacht werden, so dass nur noch der Codegenerator und einige plattformspezifische Optimierungen gemacht werden müssen. Dann sollte das auch schneller gehen.
Dann dauert es halt 5 Stunden ... trotzdem viel zu lange.
Dann dauert es halt 5 Stunden ... trotzdem viel zu lange.
Wenn das mal nicht ein Grund wäre, dass auch Office Rechner 4 oder 8 Kerne brauchen :wink:
Legolas
2008-04-25, 13:20:34
Dann dauert es halt 5 Stunden ... trotzdem viel zu lange.
Gut, OO ist natürlich ein extremes Beispiel, aber der GCC ist schon relativ langsam, was die Geschwindigkeit angeht. LLVM ist da schneller z.B.. Und wenns wirklich so extrem lange dauern würde, könnte das der Hersteller ja auch selbst machen, denn soviele verschiedene HW-Architekturen wird es auch in Zukunft nicht im Desktopmarkt geben. Wichtig ist doch nur, daß man ein Framework einsetzt, das sich leicht auf andere Architekturen portieren läßt, und das eine plattformunabhängige Coderepräsentation einsetzt, um einfach eine größere Unabhängigkeit von der HW zu bekommen.
Ganon
2008-04-25, 13:21:06
Und bei deinem Vergleich fehlt die statisch mit LLVM kompilierte Version.
Scrolle mal etwas runter, den hatte ich nachgereicht. Langsamer als JiTC aber schneller als GCC.
Legolas
2008-04-25, 13:23:56
Scrolle mal etwas runter, den hatte ich nachgereicht. Langsamer als JiTC aber schneller als GCC.
Ist aber komisch, weil beide, wie gesagt, denselben Codegenerator benutzten. Evtl. hat LLC aber auch andere Optimierungen bzw weniger davon benutzt.
Ganon
2008-04-25, 13:24:03
Dann dauert es halt 5 Stunden ... trotzdem viel zu lange.
Nein. Der compiliert nur das was gerade ausgeführt wird, nicht alles.
Ganon
2008-04-25, 13:24:39
Ist aber komisch, weil beide, wie gesagt, denselben Codegenerator benutzten. Evtl. hat LLC aber auch andere Optimierungen bzw weniger davon benutzt.
Es steht jedem frei sich LLVM zu laden, auszuprobieren und selbst zu benchmarken ;)
Legolas
2008-04-25, 13:27:11
Es steht jedem frei sich LLVM zu laden, auszuprobieren und selbst zu benchmarken ;)
Wenn ich in der Uni mal ein paar Minuten Zeit hab, werd ich es mal ausprobieren :).
Und ein Natives-Kompilat ist immer schneller.
Das stimmt so nicht. Interpretiert wird bei Java und .NET auch nichts, das ist alles JITC.
Problem ist halt, der erste Start einer Anwendung könnte sehr lange dauern wenn diese zur Laufzeit kompiliert werden muss. Wenn ich überlege wie lange damals das Kompilieren von Openoffice dauerte ... ;(
Könnte man einfach nen systemweiten Cache einrichten. Dann wär's nur beim ersten Mal starten langsam.
Genauso wie ein Computer nicht besser Schach spielen kann als ein Mensch...
Menschen sind soweit ich weiß immer noch besser bei der Registerzuordnung aber haben keine Chance gegen Compiler wenn es darum geht die ganzen Abhängigkeiten im Kopf zu behalten. Oder: Der Computer spielt anders Schach.
Bei Nicht-SIMD-Code sieht man gegen einen modernen optimierenden Compiler fast kein Land mehr, vor allem nicht bei FPU-Code zeigt meine Erfahrung. Das ist aber eine Legende die wohl nie sterben wird...
Das stimmt so nicht. Interpretiert wird bei Java und .NET auch nichts, das ist alles JITC.
kommt auf die Definition von Interpretation an. Wenn ich meinen Code vor dem Starten jedesmal durch den GCC jage habe ich dann auch einen JITC?
Schneller muss es dadurch nicht sein, da hast du Recht.
Bei Nicht-SIMD-Code sieht man gegen einen modernen optimierenden Compiler fast kein Land mehr, vor allem nicht bei FPU-Code zeigt meine Erfahrung. Das ist aber eine Legende die wohl nie sterben wird...
wer bei nicht SIMD-Code noch zum Assembler geift ist selbst schuld
Allerdings hat sich Intel mit dem Design ihrer FPU selbst in's Bein geschossen.
Das wurde ja erst mit dem Pentium und fxch einigermaßen erträglich.
kommt auf die Definition von Interpretation an. Wenn ich meinen Code vor dem Starten jedesmal durch den GCC jage habe ich dann auch einen JITC?
Schneller muss es dadurch nicht sein, da hast du Recht.
Es gibt durchaus Fälle in denen JITC-Code durch Runtime-Profiling und Architekturspezifische Codegeneration schneller ist. Auch ein GC kann schneller sein, weil bestimmte Optimierungen bei manueller Speicherverwaltung nicht möglich sind.
wer bei nicht SIMD-Code noch zum Assembler geift ist selbst schuld
Eigentlich durch Intrinsics auch nicht mehr nötig. Dann kann der Compiler das was du geschrieben hast noch optimieren was die Abhängigkeiten angeht. Auch das Register-Coloring des Rechners ist inzwischen nicht mehr so schlecht ;)
Das wurde ja erst mit dem Pentium und fxch einigermaßen erträglich.
Genau genommen wurde es erst mit scalar SSE2 erträglich.
Exxtreme
2008-04-25, 16:54:48
Nein. Der compiliert nur das was gerade ausgeführt wird, nicht alles.
Dann wird's aber sehr zäh was die Bedienung angeht. Klar könnte man das anschliessend cachen aber die Programme werden sich zwangläufig erstmal zäh anfühlen bis alles durchkompiliert und gecached wurde.
Edit: Und sobald du Sicherheitsfixes einspielst, geht der Kram von vorne los. :D
Die Prozessorleistung wird dafür sorgen, dass das "zäh" irgendwann auch verschwindet. Irgendwann ist das unter der Wahrnehmungsschwelle. Früher war das bei Java-Programmen wirklich der Fall, aber heute ist es schon weitgehend okay wenn man sich nicht drauf konzentriert.
Das betrifft sowieso nur die GUI. Dass z.B. das erste Frame eines Spiels länger braucht weil die ganze Engine-Logik erstmal durchkompiliert werden muss bemerkt keine Sau.
Es gibt durchaus Fälle in denen JITC-Code durch Runtime-Profiling und Architekturspezifische Codegeneration schneller ist. Auch ein GC kann schneller sein, weil bestimmte Optimierungen bei manueller Speicherverwaltung nicht möglich sind.
Runtime-Profiling bietet auch statische Kompilierung.
Architekturbedingte Optimierungen auch.
Ich sehe immernoch nicht, wo JITC bei der Geschwindigkeit Vorteile bringen soll, aber vielleicht verstehe ich davon auch zu wenig.
Eigentlich durch Intrinsics auch nicht mehr nötig. Dann kann der Compiler das was du geschrieben hast noch optimieren was die Abhängigkeiten angeht. Auch das Register-Coloring des Rechners ist inzwischen nicht mehr so schlecht ;)
Intrinsics sind aber Architekturabhängig. Meinen ASM-Code muss ich nur neu linken. Das Parameter über Register übergeben werden oder Loop-Unrolling, kann alles der Compiler, aber mit ASM-Code habe ich eben genau die Kontrolle darüber wann das passiert.
Wenn ich z.B. meinen Wavelet-Code nicht umgeschrieben hätte, hätte kein
Compiler daraus SIMD-Code machen können. Ich bezweifle auch das er es jetzt könnte, weil man oftmals Algorithmen anpassen muss, damit sie ins (perfekt) SIMD-Konzept passen.
Runtime-Profiling bietet auch statische Kompilierung.
Architekturbedingte Optimierungen auch.
Ich sehe immernoch nicht, wo JITC bei der Geschwindigkeit Vorteile bringen soll, aber vielleicht verstehe ich davon auch zu wenig.
Nun. Es gibt ganz praktische Benchmark mit denen man das zeigen kann.
Intrinsics sind aber Architekturabhängig.
Die SSE-Intrinsics sind Compilerübergreifend wenn du das mit "architekturunabhängig" meinst.
Das Parameter über Register übergeben werden oder Loop-Unrolling, kann alles der Compiler, aber mit ASM-Code habe ich eben genau die Kontrolle darüber wann das passiert.
Damit meinst du immer noch dass du besser bist als der Compiler bei sowas. Die Einstellung verliert man auf die harte Tour irgendwann, glaub mir ;)
Wenn ich z.B. meinen Wavelet-Code nicht umgeschrieben hätte, hätte kein
Compiler daraus SIMD-Code machen können. Ich bezweifle auch das er es jetzt könnte, weil man oftmals Algorithmen anpassen muss, damit sie ins (perfekt) SIMD-Konzept passen.
Und ich wette, dass das ganze mit Intrinsics mindestens gleich schnell gewesen wäre.
Damit meinst du immer noch dass du besser bist als der Compiler bei sowas. Die Einstellung verliert man auf die harte Tour irgendwann, glaub mir ;)Diese Thema wird alle 6 Monate neu aufgerollt oder? SSE muß man dem Kompiler verdaulich hinlegen. Er macht anschliessend zu 90% mehr daraus, als wenn man weiter zu fuß gehen würde. Das beschränke ich jetzt auf VC und ICC. GCC beschäftigte mich diesbezüglich noch nicht. Ich könnte mir aber vorstellen, daß es da nicht so gut aussieht. Jemand eigene Erfahrungen?
Könnte es vielleicht auch an der Größe der Routinen liegen? Oder dem Talent/Gehirn des Programmieres? Wenn ich etwas noch halbwegs überblicken kann messe ich mich immer mit dem Kompiler. Warum auch nicht. Man lernt bei solchen Übungen vor allem sich nicht zu überschätzen ;) Mehr als 30 Minuten brauche ich für diese Erkenntnis nicht. Gelegentlich gewinne ich sogar gegen Profiling :up:
Das gleiche gilt für inlineASM. Benutzt man vernünftige Werkzeuge, findet man die zeitraubendsten Routinen ohne Probleme. Wenn man es kann, kann man auch hier Hand anlegen. Wer auch ohne Zeitdruck :| keinen Spaß daran hat pro Mhz die größtmögliche Ausbeute zu erreichen, der sollte bei .niet und GUI-Programmierung bleiben. Damit wird niemand ein Problem haben.
OnT. Wie veraltet ist denn nun x86/AMD64 mit Penryn und Nehalem? ;)
vielleicht etwas offtopic:
warum kompiliert der compiler eigentlich so wie er es macht? ich habe beispielsweise vor kurzer zeit eine kleine numerische simulation in fortran geschrieben, ca. 100 zeilen code (sicherlich noch mit spielraum für optimierungen), kompiliert mit gfortran auf AMD64 linux. die simulation ist nichts wildes außer daß halt komplexe zahlen vorkommen und viele trigonometrische und e-funktionen vorkommen.
aus neugierde hab ich das binary mal durch einen disassembler gejagt... daß da natürlich sse2 code ausgespuckt wird war mir ja schon klar, allerdings kann ich eigentlich an keiner stelle sagen, was der code gerade macht - beispielsweise fängt das programm mit haufenweise ADD [RAX], AL an ohne daß ich sagen könnte wozu, vor allem weil in meinem programm keine integer vorkommen sondern nur double precision real und complex. ;)
weiterhin kommen immer mal wieder NOPs vor - wozu werden die gebraucht?
ich habe jetzt selber nur ein kleines bißchen verständnis von x86 assembler, aber würde ich das selber schreiben sähe mein programm jetzt komplett anders aus denke ich mal.
mir ist klar daß gewisse optimierungen unterschiedlich aussehen auf verschiedenen mikroarchitekturen. ich habe mal ein beispiel gesehen, wo codebeispiele optimiert für einen p4 und einen p3 (oder wars ein athlon?) verglichen wurden und der p4 code sah doch um einiges kryptischer aus als der für die "vernünftige" cpu. ;) ich habe beim kompilieren aber keinerlei optimierungen aktiviert.
kann man irgendwo mal mehr darüber lesen oder kann hier jemand ein wenig licht ins dunkel bringen (jetzt generell und nicht direkt auf mein programm bezogen)?
gruß
Bist du dir sicher, dass die ADD und NOP Befehle wirklich im laufenden Betrieb auch ausgeführt werden, also das der Programmfluss irgendwann da mal vorbeikommt?
Ich kenn gfortran nicht, aber wenn der was mit gcc zu tun hat, dann kannste mal beim kompilieren ein "-S" angeben. Dann spuckt der dir den Assemblerzwischencode aus. Ist vielleicht übersichtlicher.
(del)
2008-04-26, 23:41:08
kann man irgendwo mal mehr darüber lesen oder kann hier jemand ein wenig licht ins dunkel bringen (jetzt generell und nicht direkt auf mein programm bezogen)?Ja aber hallo ;)
http://www.agner.org/optimize/
Netkas.org hat einen 64Bit Kernel am laufen.
Screenshot:
http://www.uploadhouse.com/viewfile.php?id=2038741&showlnk=0
Dann läuft der 64Bit Kernel mit 32Bit-Treibern oder wie? :D
Ja aber hallo ;)
http://www.agner.org/optimize/
hier nochmal der gast mit der frage, hatte ganz vergessen mich für den link zu bedanken. also dankeschön! :) ist sehr interessant.
Netkas.org hat einen 64Bit Kernel am laufen.
Screenshot:
http://www.uploadhouse.com/viewfile.php?id=2038741&showlnk=0
Dann läuft der 64Bit Kernel mit 32Bit-Treibern oder wie? :D
Ja tut er. Das liegt aber daran, dass nur Teile des Mikrokernels bei Apple 64-Bit sind. Das hat nichts mit PPC oder x86 zu tun.
Ja tut er. Das liegt aber daran, dass nur Teile des Mikrokernels bei Apple 64-Bit sind. Das hat nichts mit PPC oder x86 zu tun.
Netkas hat den Kernel aber als 64Bit kompiliert bzw. einen eigenen vollständigen 64Bit-Kernel gebaut, wenn ich das nicht völlig falsch verstehen!???
It was very hard but I anyway made it.
Ladies and gentlemen, it’s first in World MacOSX snow kitty,
Running in full 64-bit mode (means 64-bit kernel) on PC
Soweit ich weiß gibt's da gar keine Sourcen dafür um das so zu kompilieren. Könnte aber auch falsch liegen.
Er hat halt einen 64-Bit-Darwin-Kernel kompiliert.
Also Sources muss es geben, da es ja auch die ganzen Kernelanpassungen für AMD-Systeme bei den Hackintoshs gibt. Darwin ist ja AFAIK auch Open Source.
Ich frage mich dann aber dennoch, wie es sein kann, dass er offenbar das ganze OSX-System booten und nutzen kann. Er wird ja wohl kaum 64Bit Treiber haben?! :ugly:
Meine Anmerkung auf Netkas.org in den Kommentare ist gelöscht worden bzw. als ich mal genauer nachgefragt habe (oder ich habe beim Abschicken irgendeinen des Kommentars einen Fehler gemacht und es nicht bemerkt).
Es ist fast sicher eben kein kompletter 64-Bit-Kernel. Schau dir mal den Beitrag vom 24C3 über XNU an.
Ich nehme an, dass er damit meint, dass er der erste ist der überhaupt einen 64-Bit fähigen Mac-Os-X-Kernel auf einem normalen PC zum laufen gebracht hat.
Späte Einsicht:
"CoreBoot bietet da einen viel bessere Ansatz. Nach bald 10 Jahren Forschung hat man bei diesem Projekt herausgefunden, wie man einen x86 zuverlässig mit wenigen Befehlen in einen Modus versetzen kann, in dem eine moderne 32-bit-Firmware geladen werden kann, ohne dass ein BIOS verwendet werden muss. (Kommentar der CoreBoot-Entwwickler dazu: Als Intels Íngenieure das in Silicon gegossen haben, müssen sie komplett betrunken gewesen sein.) Als Firmware kann dann z.B. ein angepasstes Linux-Derivat oder OpenFirmware verwendet werden. Oder es wird direkt in einen Bootloader geladen und das zu ladende Betriebssystem übernimmt die Hardware-Initialisierung."
http://www.fscklog.com/2008/08/psystar-klagt-z.html#c128004294
Nur leider ist der Kommentar Unsinn. EFI ist auf den Intel-Macs kein "Aufsatz" auf das BIOS sondern emuliert dieses nur. Das wurde sogar erst nachträglich eingeführt um Windows zu ermöglichen.
Die paar Befehle sind einfach das Protected-Mode-Setup das hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=4099597#post4099597) schon so oft erwähnt wurde (LinuxBIOS ist jetzt CoreBoot). Was ist daran jetzt neu?
roidal
2008-08-28, 09:27:43
...Wenn etwas veraltet ist dann die x86 Plattform und ihre drecks IRQ, usw...
Wie soll ein System ohne IRQ laufen?
Anarchy-HWLUXX
2008-08-28, 10:01:53
Wie soll ein System ohne IRQ laufen?
z.B. über polling, ist aber auch net besser ...
roidal
2008-08-28, 10:52:56
z.B. über polling, ist aber auch net besser ...
Da ist ja IRQ weitaus effizienter? Bei Polling müssen die Komponenten ja regelmäßig abgefragt werden?
Anarchy-HWLUXX
2008-08-28, 11:00:37
Da ist ja IRQ weitaus effizienter? Bei Polling müssen die Komponenten ja regelmäßig abgefragt werden?
Genau, auch wenn die HW nix tut und auch die nächste zeit nix tun wird muss diese abgefragt werden ... und das SEHR oft damit der user kein Lag spürt.
Hat jemand einen PowerPC- und Intel-Mac im direktem Vergleich und kann etwas dazu sagen?
Ich habe schon öfters solche Sprüche gelesen, dass die PowerPC-Macs (selbst die G4s) häufig geringere CPU-Last haben sollen und sich das System flüssiger anfühlen soll:
mir brauchst Du nichts über das Thema Benchmarks, reale Geschwindigkeit und Intel zu erzählen. Mir ist es schon mehrfach bei weißen Kunden-iMacs passiert, bei denen man ja äußerlich nicht erkennen kann, ob sie einen PowerPC oder einen Intel-Prozessor haben, dass mir eine gewisse Trägheit aufgefallen ist, die sich mit einem Blick auf "Über diesen Mac" geklärt hat: Es war ein Intel-iMac. Interessanterweise bestätigen die Kunden dann auch meist meine Verwunderung darüber, es zu der Behauptung kommt, dass die Dinger schneller seien, als ihre PowerPC-Vorgänger.
Auch habe ich schon Anwendungen auf Intel ruckeln sehen, die auf G4s mit unter 50% Prozessorlast laufen.
liegt der Fokus hier wieder auf einer einzelne Anwendung. Doch wie verhält sich das System, während der Compiler arbeitet? Es gibt viele Situationen (wie z.B. Rechte Reparieren unter Leopard) wo das System auf einem Intel-"Mac" über Minuten praktisch nicht ansprechbar ist, auf einem PowerPC aber nicht nur die Prozessorlast weit geringer ist, sondern das System weiterhin gut auf Eingaben reagiert.
Was auch klar ist, denn der x86 wurde in Hinblick auf die Bedürfnisse der 70er Jahre entwickelt, für Betriebssysteme à la DOS, die immer nur einen Task ausführten. Multitasking war damals den großen Maschinen vorbehalten, die u.a. mit den Vorläufern des PowerPC betrieben wurden.
http://www.fscklog.com/2008/10/offiziell-apple.html#comments
Aquaschaf
2008-10-11, 13:20:37
Was für ein Blödsinn wieder einmal. Als ob der Instruktionssatz irgendwas in der dort beschriebenen Weise mit Multitasking zu tun hätte.
Was für ein Blödsinn wieder einmal. Als ob der Instruktionssatz irgendwas in der dort beschriebenen Weise mit Multitasking zu tun hätte.
Ja, denke ich mir auch. Nur ist es eben nicht das erste mal, das ich soetwas lese. Und das Multitaskingverhalten auf den Intel-Macs empfinde ich auch nicht so toll, wie immer zu PowerPC-Zeiten geredet wurde. Leider habe ich keine Vergleichsmöglichkeiten, denn ich habe nur einen Mac mit C2D.
Wäre nicht verwunderlich wenn Apple sich gedacht hat, die neuen c2ds sind eh schneller also sparen wir uns die Optimierung und kommen am Ende immernoch etwas besser weg
Was für "Optimierungen"?
Multitasking ist ein Timer-Interrupt der alle n Millisekunden einen anderen Prozess auf die CPU schiebt und den State vom alten sichert. Das unterstützt x86 schon seit dem 286er vollständig.
Das OS beeinflusst die "Flüssigkeit" nur mit zwei Dingen: Einerseits die Anzahl der "Critical Sections" im Kernel, die nicht unterbrochen werden dürfen und zweitens welchen Scheduling-Algorithmus man verwendet, d.h. wie die Zeit "fair" auf die Prozesse aufgeteilt wird. Beides ist völlig architekturunabhängig.
Und die Zeit bzw. den Aufwand den die HW für einen Context-Switch betreiben muss. ;)
z.B. vollständiges flushen diverser Caches und interner Puffer, komplettes nachladen anderer Daten, nur um x millisekundne später wieder das ganze anders herum zu machen ;)
Nicht umsosnt haben Microkernel, welche eigentlich immer starke Nutzung von multithreading betrieben, einen nicht zu übersehenden Performance-Einbruch auf X86ern...
Abraxus
2008-12-21, 11:50:04
Und die Zeit bzw. den Aufwand den die HW für einen Context-Switch betreiben muss. ;)
z.B. vollständiges flushen diverser Caches und interner Puffer, komplettes nachladen anderer Daten, nur um x millisekundne später wieder das ganze anders herum zu machen ;)Task-Scheduler sind hier das Zauberwort.
Nicht umsosnt haben Microkernel, welche eigentlich immer starke Nutzung von multithreading betrieben, einen nicht zu übersehenden Performance-Einbruch auf X86ern...L4 ist gar nicht so langsam. Der Einbruch liegt unter 4% ggü einem monolithischen Linux.
Wird eigentlich der ganze alte Kram von x86 auch noch in Intels kommendem SoC drin sein? Ich mein bei einem SoC, der es vielleicht mal in ein Handy schaffen soll, gilt es keine Transistoren zu verschwenden.
Wird eigentlich der ganze alte Kram von x86 auch noch in Intels kommendem SoC drin sein? Ich mein bei einem SoC, der es vielleicht mal in ein Handy schaffen soll, gilt es keine Transistoren zu verschwenden.
Bullshit, der ganze alte Kram verbraucht prozentual eh kaum Transistoren.
Bullshit, der ganze alte Kram verbraucht prozentual eh kaum Transistoren.
Bei den Stromverbrauchsregionen, in denen sich ein ARM-CPU befindet, ist es aber kein Bullshit: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=441067
Ein kompletter ARM-Kern braucht AFAIK nur um die 2 Millionen Transistoren.
BlackBirdSR
2008-12-21, 23:53:11
Wird eigentlich der ganze alte Kram von x86 auch noch in Intels kommendem SoC drin sein? Ich mein bei einem SoC, der es vielleicht mal in ein Handy schaffen soll, gilt es keine Transistoren zu verschwenden.
Dafür hat Intel ja bereits eigene Prozessoren.
Wenn man etwas wie Atom, oder einen x86-SOC wirklich in solche Regionen drücken will, dann nur weil einem die x86-Softwarebasis von Nutzen ist. Und das ist nun mal das größte und gewichtigste aller x86-Argumente.
Und die Zeit bzw. den Aufwand den die HW für einen Context-Switch betreiben muss. ;)
z.B. vollständiges flushen diverser Caches und interner Puffer, komplettes nachladen anderer Daten, nur um x millisekundne später wieder das ganze anders herum zu machen ;)
Nicht umsosnt haben Microkernel, welche eigentlich immer starke Nutzung von multithreading betrieben, einen nicht zu übersehenden Performance-Einbruch auf X86ern...Du bist also der Meinung daß ein Penryn ohne "den alten x86-Kram" nochmals 20% schneller sein könnte? Oder 30% oder 40% schneller als jetzt?
Da muß man sich doch erst überlegen wie überladen und veraltet, also einfach nur schlecht, alle anderen Architekturen bei gleichem takt sein müßen. Ist aber auch irgendwie klar. die Deppen entwicklen ja auch ncihts neues, sondern immer nur Power 1 bis Power6 oder UltraSPARC7 mittlerweil und so ein Zeug :uup:
Die Typen können ja garnichts. Durch die Bank genauso unfähig wie Intel =)
Wars das jetzt?
Wars das jetzt?
Das sind zwei unterschiedliche Gäste bzw. zwei unterschiedliche Themen, die du nicht auseinanderhalten kannst.
Das sind zwei unterschiedliche Gäste bzw. zwei unterschiedliche Themen, die du nicht auseinanderhalten kannst.Mir scheint eher die Gäste selbst können sich nicht auseinanderhalten ;) Geschweige Texte unabhängig vom Absender analysieren. Du bist hiermit eines heldenhaften Todes gestorben. Womit wir wieder zum Topic zurückkehren könnten bitte.
Nur mal um das kalrzustellen,
das obige Zitat stammt von mir, ich bin der Gast mit dem langen Text bezüglich microkernels usw.
Fakt ist, zu früheren Zeiten sah ein X86er gegen einen PowerPC vom schlage eines G4 keine Sonne.
Und die ersten Apple mit X86er (das war noch vor dem core2, also nur Core solo und Core duo) fühlten sich sehr träge an.
Ob das nun an fehlednen compiler-Optimierungen liegen mag mit denen MacOSX für diese Maschinen kompiliert wurde, oder ein generelles Zeugnis dafür ist, dass PowerPCs flüssiger waren bzw. die vielen Threadwechsel beser vertragen haben, überlasse ich dem Leser.
Ich wollte damit eigentlich nur ausdrücken, dass die HW durchaus einfluss hat, und X86 nicht das Maß aller Dinge ist, nur weil es eben in der PC-Welt Standard geworden ist.
Es wäre nichts neues, dass sich in der Technikwelt nicht eine Technologie durchsetzt, weil sie besser ist, sondern weil sie besser vermarktet wird.
Dafür gibts genug Beispiele.
Vieles hat sich mit x86-64 Unterstützung und den Core2 - Generationen zum positiven verändert, und mittlerweile gibt es schlichtweg kein halbwegs erschwingliches nicht-x86-Basierendes Desktopsystem mehr.
Trotzdem ist der Task-scheduler nicht alles. Es ist z.b. ein fundamentaler Unterschied, ob die CPU beim Theread-wechsel den cache komplett leeren muss (und wie lang, in taktzyklen gerechnet, das dauert) oder ob sie z.b. einfach in der Lage ist, die Cachlines zu "Taggen". Das würde nämlcih bedeuten, man könnte die Inhalte mehrere Threads parallel in den caches halten (oder sogar in den registern, je nach architektur) und muss "nur" umschalten aus welchen Quellen die Rechenwerke gefüttert werden.
Eigentlich geht intels Hyperthreading schon in die Richtung. Oder auch die "Tagged TLB" - Unterstützung der Nehalems und Phenoms.
Es kann also Prozessordesigns geben denen Multihtreading eher liegt und welche bei denen das weniger der Fall ist.
Wenn L4 übrigens nur so wenig einbricht ist das klasse... dann könnte HURD ja vielleicht mal irgendwann in die Gänge kommen.
Das Fazit das ich daraus ziehe ist, dass weniger die Architektur als solche bzw. der verwendete Befehlssatz eine Rolle spielt sondern eher wie der Code gestrickt ist, den man den Prozzis füttert und einige Fundamentalere Dinge in Sachen Verwaltung.
Wenn man sich heutige Prozzessoren mit mehr oder weniger aufwändiger Branch prediction etc. mal anschaut wird durchaus einiges Getan um den Durchsatz zu erhöhen. (PowerPC hat z.B. gleich lange, alignte Befehle. Was beim decodieren Vorteile bietet)
Also ich sage keienswegs dass alle Spacken sind, im Gegenteil. Es ist halt so dass X86 definitiv Marktführer ist, allerdigns sitzen nicht nur bei Intel gute Prozessorbauer.
grüßchen
ich
Acid-Beatz
2009-02-22, 11:57:44
Dafür hat Intel ja bereits eigene Prozessoren.
Wenn man etwas wie Atom, oder einen x86-SOC wirklich in solche Regionen drücken will, dann nur weil einem die x86-Softwarebasis von Nutzen ist. Und das ist nun mal das größte und gewichtigste aller x86-Argumente.
Wie drückte es die c`t mal so schön aus: Bit für Bit und Bug für Bug ( ob es ganz richtig zitiert ist kann ich nicht genau sagen aber so in etwa hab ichs in Erinnerung, sprich aus Gründen der heiligen Kompatibilität kann man höchstens noch was hinzuschustern aber niemals was wegnehmen )
Es gab doch auch viele innovative Prozessoren die eigentlich nur daran gescheitert sind weil sie keine Softwarebasis hatten ?! Wenn mans so betrachtet eigentlich genau der Grund warum Wintel und nicht Apple den Computermarkt anführt!
Wie drückte es die c`t mal so schön aus: Bit für Bit und Bug für Bug
Dem kann man nur traurig zustimmen.
Objektiv betrachtet, hat AMD bei AMD64 einfach mist gebaut.
Dies wäre die Stelle gewesen, wo mal viele Altlasten hätte abschaffen können.
Wenn die CPU im 64 Bit Modus ist, kann sie keine 16 Bit Softare mehr ausführen, damit gibt es "sowieso" ein Bruch der Kompatibilität diesen hätten man ausbauen müssen.
Aber so wie es ist, haben wir auch heute noch das "A20-Gate" und ich befürchte auch in 20 Jahren haben wir das immer noch.
Anmerkung, das ganz "alte zeug" sollte natürlich bei so einem Bruch im 32-Bit Modus weiterhin funktionieren.
mfg
BlackBirdSR
2009-02-22, 19:36:44
Dem kann man nur traurig zustimmen.
Objektiv betrachtet, hat AMD bei AMD64 einfach mist gebaut.
Dies wäre die Stelle gewesen, wo mal viele Altlasten hätte abschaffen können.
Wenn die CPU im 64 Bit Modus ist, kann sie keine 16 Bit Softare mehr ausführen, damit gibt es "sowieso" ein Bruch der Kompatibilität diesen hätten man ausbauen müssen.
Aber so wie es ist, haben wir auch heute noch das "A20-Gate" und ich befürchte auch in 20 Jahren haben wir das immer noch.
Anmerkung, das ganz "alte zeug" sollte natürlich bei so einem Bruch im 32-Bit Modus weiterhin funktionieren.
mfg
1. Es ist eine x86 Erweiterung. Es ist nich ohne Weiteres möglich einen kompletten Bruch vorzunehmen.
2. Großer Vorteil von AMD64 ist der geringe Aufwand bestehende Software umzusetzen. Abstrakt gesehen beläuft es sich "einfach" um das Anwenden des 64-Bit Compilers anstelle der 32-Bit Version.
3. Bei einem größeren Bruch mit mehr Abstand zu x86, wäre AMD64 eventuell nicht als Standard adaptiert worden. Ein großer Verlust für uns und AMD
4. Jede AMD64-CPU kann 16Bit-Proteced-Mode Code ausführen. Wenn Windows x64 das nicht zulässt, ist das nicht AMDs Fehler.
5. Ohne Nähe von x86 und AMD64 gäbe es auch kein schnelles Umschalten zwischen 32-Bit und Longmode bzw Compatibility-Mode.
Man kann nicht Alles haben und so schlecht ist es bei weitem nicht.
Von "Mist" zu sprechen, halte ich für völlig daneben und schlecht nachgedacht.
GeneralHanno
2009-02-22, 21:49:42
hätte AMD damals den A64 als reine 64bit CPU umgesetzt, dann wäre intel heute monopolist und AMD pleite :biggrin:
hätte AMD damals den A64 als reine 64bit CPU umgesetzt, dann wäre intel heute monopolist und AMD pleite :biggrin:
AMD hätte im 64 Bit Modus, einen paar Altlasten abschaffen können (z.B. A20 Gate), der 32 Bit Modus hätte ja so bleiben können wie er ist.
mfg
1. Es ist eine x86 Erweiterung. Es ist nich ohne Weiteres möglich einen kompletten Bruch vorzunehmen.
2. Großer Vorteil von AMD64 ist der geringe Aufwand bestehende Software umzusetzen. Abstrakt gesehen beläuft es sich "einfach" um das Anwenden des 64-Bit Compilers anstelle der 32-Bit Version.
3. Bei einem größeren Bruch mit mehr Abstand zu x86, wäre AMD64 eventuell nicht als Standard adaptiert worden. Ein großer Verlust für uns und AMD
Es ist eine Erweiterung die einen Bruch bedeutet. Daher hätte man diesen Bruch unproblematisch deutlich weiter fassen können. Da eh neue Compiler geschrieben wurden mußten, hätte man vieles einfach im Compiler kaschieren können.
Aber jetzt haben wir diesen Stand und der wird sich bis zum nächsten größerem Umbruch (den ich in den nächsten 20 Jahren nicht sehe) nicht mehr ändern.
Selbst eine Emulation der alten Funktionen (16 Bit "Zeugs") wäre kein Problem, da entsprechende Anwendungen eh für viel langsamere CPUs geschrieben wurden.
Gutes Beispiel ist der Itanium, die Emulation ist zwar sehr langsam, aber es geht und für alte Software reicht die alle mal.
BlackBirdSR
2009-02-22, 23:01:56
Es ist eine Erweiterung die einen Bruch bedeutet. Daher hätte man diesen Bruch unproblematisch deutlich weiter fassen können. Da eh neue Compiler geschrieben wurden mußten, hätte man vieles einfach im Compiler kaschieren können.
Aber jetzt haben wir diesen Stand und der wird sich bis zum nächsten größerem Umbruch (den ich in den nächsten 20 Jahren nicht sehe) nicht mehr ändern.
Selbst eine Emulation der alten Funktionen (16 Bit "Zeugs") wäre kein Problem, da entsprechende Anwendungen eh für viel langsamere CPUs geschrieben wurden.
Gutes Beispiel ist der Itanium, die Emulation ist zwar sehr langsam, aber es geht und für alte Software reicht die alle mal.
Ich hab meinen Standpunkt dargelegt, darauf die gleichen Argumente wie davor abzugeben, bringt nichts. Schon recht nicht wenn sie falsch sind (siehe "16Bit zeugs")
x86-Software auf Itanium ist kein Thema mehr und ein schlechtes Beispiel. Gerade durch die langsame HW-Ausführung und dann Emulation, sind alle Ambitionen für den Desktop gestorben.
Ich hab meinen Standpunkt dargelegt, darauf die gleichen Argumente wie davor abzugeben, bringt nichts. Schon recht nicht wenn sie falsch sind (siehe "16Bit zeugs")
x86-Software auf Itanium ist kein Thema mehr und ein schlechtes Beispiel. Gerade durch die langsame HW-Ausführung und dann Emulation, sind alle Ambitionen für den Desktop gestorben.
Sorry, kein Mensch der bei klarem Verstand ist, meint(e) die Emulation wäre für moderne Software vernünftig nutzbar (nichtmal Intel).
Es sollte nur eine Möglichkeit geben, alte Software noch auszuführen, egal wie langsam und das funktioniert(e) auch, heute läuft das aber etwas schneller in Software.
Dennoch kriegt man notfalls DOS Software auf einem Itanium zu laufen, bei einem Power oder SPARC geht das nicht.
Anmerkung "16Bit zeugs" ist ein Paltzhalter für das ganze alte Zeug.
Da du aber ein Kenner bist, Fachfrage, wie kann ich die dritten 16 Bit eine 64 Bit Registers in einer AMD64 CPU ändern? (bit 32 bis 47)?
Wenn es dafür einen Befehl gibt, will ich nichts gesagt haben.
Acid-Beatz
2009-02-22, 23:59:26
Was ist denn eigentlich das genaue Problem dieses A20 Gates? Ich hab nur rausgefunden, dass es Speicherbereiche umlegt oder eben nicht, aber wo is da der Stress?
Bye
Was ist denn eigentlich das genaue Problem dieses A20 Gates? Ich hab nur rausgefunden, dass es Speicherbereiche umlegt oder eben nicht, aber wo is da der Stress?
Bye
Es ist nur ein Beispiel, aber egal es stammt aus der Zeit wo es noch 1 MB maximaleren RAM gab (20 Bit Addressbus, 8086).
Bei praktisch jeder Cache Nutzung oder RAM Addressierung, muß geprüft werden ob diese Gate gesetzt ist. Somit entsteht ein deutlich höherer Verwaltungsaufwand, auch wenn dieser durch Hardware in der CPU (z.B. TLBs und Flags) stark verringert ist, ist er dennoch da und auch eine Fehlerguelle.
Die ersten CPUs mit eigenem Cache konnten aus diesem Grund nur RAM oberhalb 1 MB Cachen, weil die Gateprüfungen im ersten MB zu aufwendig waren.
Ergo ein (unnötiges) Relikt aus alten Tagen.
Tiamat
2009-02-23, 01:51:00
Ja ich hoff ja seit Ewigkeiten, dass mal ne andere Architektur den Markt mal wieder aufwühlt, aber nachdem sogar Apple auf x86 umgesattelt ist, stehen die Zeichen wohl eher schlecht.
Ich denk zum größten Teil besteht natürlich das Windows-Problem, was natürlich für die größte x86 Abhängigkeit sorgt.
Und es gibt halt auch keinen dringenden Grund seitens Microsoft ihr OS für eine neue Architektur zu entwickeln, solch einen riesigen Markt und vorallem die Position darin würde man NIE freiwillig aufgeben, es sei denn Intel und AMD würden die Kurve kratzen.
Von daher werden wir die nächsten 20 Jahre wirklich kein Novum mehr erleben, jetzt heißt es x86 forEver ;D
Naja wer weiß, was GrafikProzessoren demnächst noch so können, zu einem Preis von 500W :biggrin:
Bei praktisch jeder Cache Nutzung oder RAM Addressierung, muß geprüft werden ob diese Gate gesetzt ist. Somit entsteht ein deutlich höherer Verwaltungsaufwand, auch wenn dieser durch Hardware in der CPU (z.B. TLBs und Flags) stark verringert ist, ist er dennoch da und auch eine Fehlerguelle.
Die ersten CPUs mit eigenem Cache konnten aus diesem Grund nur RAM oberhalb 1 MB Cachen, weil die Gateprüfungen im ersten MB zu aufwendig waren.
Ergo ein (unnötiges) Relikt aus alten Tagen.Das macht mein Penryn unter XP nicht einmal mit dem Flag. Früher konnte man noch im BIOS auf "A20-Gate fast" oder so umstellen. Bei den aktuellen Boards gibts das schon garnicht mehr.
Die Funktionalität ist zwar da, liegt aber wie eine Eintagsfliege von gestern in der Ecke rum.
Wenn ihr eine neue fortschrittlichere Architektur herbeisehnt, dann eine die erstmal pro Mhz entsprechende Leistung hat. PowerPC war mit bestem RISC-Kode, mit AltiVec und ohne einen A20-Gate real world NIE schneller als irgendein Core. Pro Mhz.
Was soll das ganze Gerede hier? Kann ein SPARC64 VII mehr pro Mhz als i7? Alle anderen CPU-Hersteller sind schon froh, wenn sie alle Jahre wieder eine CPU rausbringen können die Intel paroli bieten kann.
Draus folgt: Keine CPUs mit A20-Gate, keine sauschnellen preiswerten Systeme fürs Zuhause.
Tiamat
2009-02-23, 02:51:00
Das Problem bei solchen Vergleichen ist immer Applikationen zu finden,
die auf mehreren CPU Architekturen läuft. Und dann können diese unterschiedlich gut implementiert sein.
Hier zum Beispiel mal n Benchmark , bei dem Fujitsu´s SPARC bei 50% der Taktfrequenz Hackfleisch aus Intel´s Core i7 macht.
SAP Tier Benchmark bei Heise (http://www.heise.de/newsticker/Neue-Xeon-CPUs-mit-Nehalem-Kern-im-SAP-SD-Benchmark--/meldung/120570)
Hab jetzt keine Lust weitere Beispiele zu suchen, würde sicher schwierig werden, Software zu finden, die auf mehreren Architekturen und unterschiedlichen Betriebssystemen implementiert ist.
Das Problem bei solchen Vergleichen ist immer Applikationen zu finden,
die auf mehreren CPU Architekturen läuft. Und dann können diese unterschiedlich gut implementiert sein.Sicher. Das ändert aber nichts an den Tatsachen.
Hier zum Beispiel mal n Benchmark , bei dem Fujitsu´s SPARC bei 50% der Taktfrequenz Hackfleisch aus Intel´s Core i7 macht.Ich hab nur drauf gewartet. Dafür müßte man dem i7 aber auch das gleiche "Umfeld" bieten ;)
Ich hätte fast gesagt, nehmen wir doch eine UltraSPARC Workstation und vergleichen wird das mit einem i7 oder Penryn, aber solche Workstations bietet Sun schon seit langem nicht mehr an. Alles nur x86-64. Samt Solaris ;)
Hab jetzt keine Lust weitere Beispiele zu suchen, würde sicher schwierig werden, Software zu finden, die auf mehreren Architekturen und unterschiedlichen Betriebssystemen implementiert ist.Linux? OpenSolaris? =) http://phoronix-test-suite.com/?k=downloads
Ich finde Solaris wunderschön. Ich finde die T2 einmalig. Ich finde SPARC, seitdem der Ultra tot ist und es nur noch SPARC64 gibt, richtig stark. Ich hab hier aber leider auch keine SAP-Server am laufen. Oracle auch nicht. Ich habe hier nichtmal Apache.
Das Gesabber wegen einer unerträglich veralteten x86-Architektur ist nur ein Ergebnis dessen was passiert, wenn sich kleine Jungs mit paar Buzzwords aufspielen wollen um kurzweilig mit Leuten wie Coda oder Blackbird zu quatschen. Mehr nicht.
Es gibt eine total veraltete und miserable x86-Architektur die man sehr gut vergleichen kann. Das ist der Intel Atom gegenüber dem VIA Nano.
Ganon
2009-02-23, 08:08:28
Ich denk zum größten Teil besteht natürlich das Windows-Problem, was natürlich für die größte x86 Abhängigkeit sorgt.
Und es gibt halt auch keinen dringenden Grund seitens Microsoft ihr OS für eine neue Architektur zu entwickeln, solch einen riesigen Markt und vorallem die Position darin würde man NIE freiwillig aufgeben, es sei denn Intel und AMD würden die Kurve kratzen.
Daran liegt das, glaube ich, nicht mal. Windows gibt es ja z. B. auch für IA64. Das Problem ist eher, dass keiner dafür Software schreibt. Kein Office, keine Spiele, nix. Ebenso gab es Windows für PowerPC und Alpha. Bis auf ein paar Branchenprogramme (afaik SolidWorks, etc.) gab es da auch nichts Größeres mehr für.
Und Apple hatte mit PowerPC das gleiche Problem. Andere Architektur -> Inkompatibel zum Rest der Welt, oder wenn dann nur sehr langsam (VirtualPC).
Haarmann
2009-02-23, 08:59:50
Wieviel besser müsste wohl eine Architektur sein, damit sie x86 ablösen kann?
Und welche Voteile müsste sie bieten?
Mir fällt hier nur stromsparend ein - denn da sehe ich Potential - gleichbleibende Leistung, aber deutlich geringerer Verbrauch.
Wenn man sich so die täglichen Aufgaben ansieht, die den Durchschnittsrechner erwarten, so wird imho schnell klar, dass die Mehrzahl der x86 CPUs unterfordert werden. Hier mit Mehrleistung ködern zu wollen, wird die Mehrzahl der Menschen kaum überzeugen können.
In den wenigen Nischen, die da noch bleiben, tummeln sich doch schon lange Alternativen - seien dies SPARCs oder ARMs oder was auch immer.
BlackBirdSR
2009-02-23, 10:08:24
Es gibt eine total veraltete und miserable x86-Architektur die man sehr gut vergleichen kann. Das ist der Intel Atom gegenüber dem VIA Nano.
Leider nicht.
Weder ist Atom miserabel, noch ist das Nano.
Vergleiche werden zudem durch die starken Optimierungen der Benchmarks für Intel-Prozessoren und das schwache Umfeld des Nanos verzerrt. Dazu besitzt er kein SMT und verliert dann natürlich in vielen Benchmarks.
Ingesamt stellen die Benchmarks Nano also viel schlecher hin, als er seinen Daten zu Folge sein müsste. Atom dagegen gewinnt durch SMT sehr stark an Leistung.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.