x86 = total veraltete Architektur? [Archiv]

GloomY

2005-05-10, 18:46:47

Alt ja, aber veraltet? Was genau heisst in diesem Zusammenhang alt? Register-Zahl? Adressierungsmodi? Befehls-Vielfalt? Befehls-Codierung?

Ich bin prinzipiell auch eher ein Anhänger von RISCischen Befehlssätzen, aber x86 hat gerade bei der Code-Dichte schonmal einen Vorteil. Mit x86-64 (aka AMD64 aka EM64T) ist auch der Registermangel von x86 aus der Welt geschafft.
Dazu kommt, dass x86 natürlich eine klassische CISC Architektur ist, wobei innerhalb der heutigen Prozessoren diese eh in RISC-artige µOps oder Macro-Ops aufgeteilt werden. So sehr verschieden ist die Abarbeitung dadurch auch nicht. Nur der Befehlssatz nach aussen hin hat noch die klassischen CISC-Eigenschaften.

Ich würde jetzt nicht umbedingt sagen, dass das eine oder das andere besser ist. Das ist eher eine Frage der Sympathie. Beide ISAs haben Vor- und Nachteile.

Bezüglich der Mac-Fans würde ich mal behaupten, dass diese wohl eher nach einem Grund suchen, warum der Mac besser sein soll. Lange Zeit (vor dem PowerPC970) waren die Macs leistungsmäßig hinten dran und auch die marketing-wichtigen MHz waren im Vergleich mit den x86 Prozessoren nicht konkurrenzfähig. Dann guckt man eben nach vermeintlichen Schwächen, um die eigene Entscheidung für den Mac und gegen x86 zu begründen. Das ist klassische Gewissensberuhigung im Angesicht der Rückstände im Leistungsbereich der Hardware. Das hat sich aber auch seit dem Power4-Abkömmling PowerPC970 (aka G5) geändert. Der G3 oder G4 war einfach nicht konkurrenzfähig.
btw: Es gibt imho eine Reihe von guten Gründen, warum man sich einen Mac kaufen kann. Diese liegen eben nicht im Hardware-Bereich.

Gast

2005-05-10, 18:50:12

G4 war einfach nicht konkurrenzfähig.

Also der G4 ist immer noch nicht schlecht und hatte damals auch den p4 teilweise nass gemacht.

Gast

2005-05-10, 19:05:25

"Apples Dual-G5 nimmt über 300 Watt Leistung auf und muss mit Wasser gekühlt werden"
http://www.heise.de/newsticker/meldung/59445

Wieviel W zieht denn so ein G5? Gibt es da nicht auch soetwas wie C&Q?

GloomY

2005-05-10, 19:20:53

Also der G4 ist immer noch nicht schlecht und hatte damals auch den p4 teilweise nass gemacht.Teilweise? Vielleicht in ganz speziellen Fällen. Im Allgemeinen war der G4 aber nicht wirklich konkurrenzfähig. Erst ab dem PPC970 war Apple wieder mit dabei. Das sieht man allein schon an der Architektur des G4s im Vergleich zum PPC970. Einen schönen Vergleich von P4, G4 und PPC970 gibt es bei Ars (http://arstechnica.com/articles/paedia/cpu/ppc970.ars).

btw: Paul DeMone von RWT (http://www.realworldtech.com/page.cfm?ArticleID=RWT051400000000&p=3) gibt mir zumindest mal Recht bis in die frühen Tage des G4s.

BlackBirdSR

2005-05-10, 19:25:50

Also der G4 ist immer noch nicht schlecht und hatte damals auch den p4 teilweise nass gemacht.

In Fällen wo Altivec vollends genutzt werden kann, natürlich.
Neben Altivec kann dann z.B noch die ALU bneutzt werden, und schwupps hat man in RSA irrsinnige Durchsätze.
Da kann ein x86 natürlich nicht mithalten, zumal es da oft an SIMD Optimierungen mangelt.

Abweits solcher Spezialfälle ist aber der G4 die unterlegene CPU.
Dessen Befehlssatz mag vielleicht sauberer sein, aber gerade in Sachen Architektur ist er es, der auf Veraltetes setzt.
Wie Gloomy schon zum Besten gibt:
Erst der PPC970 ändert dies.

Gast

2005-05-10, 19:39:30

Ich habe hier noch etwas gefunden:

G5 = aufgeborter G4 mit 64-Bit Erweiterung, es gibt gut recherchierte
Artikel das G4 CPU's bei gleichem FSB mindestens(!) genau so schnell
wären bei 32-Bit Berechnungen wie ein G5.

Ach ja: Ich bin Apple-Nutzer, aber ein G5 kommt mir nicht ins Haus.

Quelle: http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=7964244&forum_id=78518

Der Vergleich bezieht sich speziell auf den G4 vs. P4 und stimmt gerade da. Denn der P4 wurde auf hohe Taktzahlen getrimmt auf Kosten der Performance. Intel hat ja mittlerweile selber eingesehen, dass das ein Irrweg war und setzt mit dem Centrino auf einen effizientere Architektur mit geringeren MHz-Werten. Ähnlich, wie AMD mit den Athlon-Modellen.

Der Centrino (und der Athlon) bringt durchschnittlich bei gleicher Taktfrequenz ungefähr eine mit einem G4 vergleichbare Rechenleistung.
Jedenfalls, solange nicht viel von der altivec-Unit Gebrauch gemacht wird. Wenn exzessiv von der Altivec-Unit gebraucht gemacht wird, ist der G4 jedem Prozessor überlegen. Sogar dem G5, denn der G4 besitzt doppelt so viele altivec-Einheiten. (z.B. bei der rc5-Entschlüsselung, dort bringt ein 500MHz-G4 die gleichen Werte, wie ein aktueller P4, ein aktueller G4 wäre also mit einem 10GHz P4 vergleichbar.)
Dafür ist der G5 in Fließkomma-Operationen überlegen, sowohl dem G4, als auch dem P4, als auch einem Centrion oder Athlon.
Nur bei reinen Festkomma-Operationen ist der P4 aufgrund der hohen Taktfrequenz jedem anderen x86-Prozessor überlegen und dem G4 sowieso. Der G5 hält dabei einigermaßen mit. (SPEC-CPU-Benchmark, dort bringt ein aktueller G4 gerade mal den Wert des allerersten P4 mit 1,5GHz und ist auch nicht besser, als ein gleich getakteter G3.)

Quelle: http://www.macuser.de/forum/showpost.php?p=580377&postcount=58

alpha-centauri

2005-05-10, 19:49:10

ESAD

2005-05-10, 19:52:35

wenn wir schon bei den benches sind dann nehmen wir doch mal eine seite inderen url nicht mac vorkommt :rolleyes:

http://spl.haxial.net/apple-powermac-G5/

BlackBirdSR

2005-05-10, 20:04:32

Ich habe hier noch etwas gefunden:

G5 = aufgeborter G4 mit 64-Bit Erweiterung, es gibt gut recherchierte
Artikel das G4 CPU's bei gleichem FSB mindestens(!) genau so schnell
wären bei 32-Bit Berechnungen wie ein G5.

Ach ja: Ich bin Apple-Nutzer, aber ein G5 kommt mir nicht ins Haus.

Quelle: http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=7964244&forum_id=78518

Das LETZTE was ein PPC970 ist, ist ein aufgebohrter G4 mit 64Bit.
Da bekomm ich echt die Kriese.

Sogar dem G5, denn der G4 besitzt doppelt so viele altivec-Einheiten. (z.B. bei der rc5-Entschlüsselung, dort bringt ein 500MHz-G4 die gleichen Werte, wie ein aktueller P4, ein aktueller G4 wäre also mit einem 10GHz P4 vergleichbar.)

Da kommt mir noch mehr das ..Edit: (Kotzen ist nicht fein) da wird mir übel. (so besser, sorry)
1. der G4 mag mehr Einheiten für Altivec haben. Aber deswegen kann er nicht doppelt so viel berechnen. Der G5 muss nur länger warten bzw hat es schwerer den maximalen Durchsatz zu erreichen. Das gleicht sich aber teilweise durch die effizientere Architektur wieder aus.

2. RC ist EXTREM auf den G4 hin optimiert. Neben 4 Datenpaketen durch Altivec läuft nebenher noch ein 5. über die ALU.
Das kann keine CPU toppen, für die nicht optimiert wurde.
Beim G5/P4/K8 ist das nicht der Fall.
RC ist wohl der extreme Extremfall.

Gast

2005-05-10, 20:04:59

Davon abgesehen, sagt MAC auch: Hey, machen wir mal ein altes Os, und alle koennen ihre alte Software neu kaufen.

Beim OS finde ich den Schritt sehr gut. Soetwas sollte ma M$ machen.

Und alte OS9 Software läuft trotzdem unter OSX.

Wenn man immer den alten Krempel mitschleppt, dann wird es nie was richtiges ;)

Aber es geht ja hier um die Prozessoren!

HellHorse

2005-05-10, 20:15:46

Wenn man immer den alten Krempel mitschleppt, dann wird es nie was richtiges ;)
Ja nee is klar, und UNIX ist nicht alter Krempel :rolleyes:

INTRU

2005-05-10, 20:17:49

Wo gibt es Infos über die Leistungsaufnahme eines G5?

Ja nee is klar, und UNIX ist nicht alter Krempel :rolleyes:

Ist OT!

huha

2005-05-10, 20:28:09

Beim OS finde ich den Schritt sehr gut. Soetwas sollte ma M$ machen.

Und alte OS9 Software läuft trotzdem unter OSX.

Wenn man immer den alten Krempel mitschleppt, dann wird es nie was richtiges ;)

Aber es geht ja hier um die Prozessoren!

Oh nein, warum habe ich sowas nur kommen sehen? Apple kann das eventuell machen, weil die Teile einfach nicht weit verbreitet sind. Wenn MS jetzt aber sämtliche Rückwärtskompatibilität einfach abschaltet, dann wird's extrem lustig, weil dann ein großer Aufschrei durch die Gesellschaft geht.

-huha

Gast

2005-05-10, 20:37:00

Apple hat die Rückwertskompatibilität nicht einfach abgeschaltet. Die haben ein ganz neues Betriebsystem entwickelt, daß heute vermutlich schon besser ist als Longhorn sein wird. Man kann das alte OS9 innerhalb OS X "booten".

It gets worse. Apple's Mac OS X, recently upgrade to version 10.4 ("Tiger," see my review) is more than "good enough." In many ways, OS X is simply better than Windows, especially for experienced computer users, and Tiger rubs Microsoft's nose in the embarrassment of shipping a key Longhorn feature--instant desktop search--a full year ahead of the software giant. That's right folks. We already knew that Microsoft was facing smaller, nimbler competitors. But those competitors are now starting to outperform Microsoft in the feature department too. It's time for Redmond to stop pretending Linux and OS X don't exist.

http://www.winsupersite.com/reviews/longhorn_5048.asp

Ganon

2005-05-10, 20:40:02

Die haben ein ganz neues Betriebsystem entwickelt,...

Naja... Zur Zeit proggen sie nur das nach, was NeXTStep schon 1993 konnte. ;) Nur schöner... ;)

Gast

2005-05-10, 20:41:16

Naja... Zur Zeit proggen sie nur das nach, was NeXTStep schon 1993 konnte. ;) Nur schöner... ;)

Naja OS X ist auch Nextstep ;)

HellHorse

2005-05-10, 20:56:09

Die haben ein ganz neues Betriebsystem entwickelt,
Genau, Apple hat FreeBSD, KHTML, Apache, Samba, GCC, das GUI, die Maus, das CD-ROM und noch viele andere Sachen selbst entwickelt. Endlich sagt es mal einer! :rolleyes:

Und da behaupte noch jemand Apple User kennen der Unterschied zwischen einem Programm und einem GUI nicht oder plappern nur das Wort von Jobs nach.

Ganon

2005-05-10, 21:12:21

Genau, Apple hat FreeBSD, KHTML, Apache, Samba, GCC, das GUI, die Maus, das CD-ROM und noch viele andere Sachen selbst entwickelt. Endlich sagt es mal einer! :rolleyes:

Und hätten sie es nicht gemacht, hättest du bestimmt gemeckert, warum sie nicht die vorhandenen Projekte nutzen... :rolleyes:

;) ;) :D

Trap

2005-05-10, 21:32:43

x86-Architektur != x86-Befehlssatz

Eine CPU mit x86-Architektur gibt für PCs nichtmehr zu kaufen.

Exxtreme

2005-05-10, 21:35:10

Genau, Apple hat FreeBSD, KHTML, Apache, Samba, GCC, das GUI, die Maus, das CD-ROM und noch viele andere Sachen selbst entwickelt. Endlich sagt es mal einer! :rolleyes:

LOL, fehlt noch, daß die Apple-Fanboys behaupten, daß Apple das Internet erfunden hat. :mad: :mad:

Dabei weiss doch jeder, daß das Bill Gates war. X-D

alpha-centauri

2005-05-10, 21:38:02

Oh nein, warum habe ich sowas nur kommen sehen? Apple kann das eventuell machen, weil die Teile einfach nicht weit verbreitet sind. Wenn MS jetzt aber sämtliche Rückwärtskompatibilität einfach abschaltet, dann wird's extrem lustig, weil dann ein großer Aufschrei durch die Gesellschaft geht.

-huha

Wow. Mal ein Kommentar von dir, den ich nicht kritisieren will, aber was einfuegen moechte:

Wenn ein Marktuehrer mit 90% Martdurchdringung sgt :"Ihr koennt alle eure alte Software weggwerfen", wuerden sie viele Hauptkunden verlieren und das neue OS sicher nur wenige kaufen und der Absatz zurueckgehen.

Den Grund, warum die leute auf OS X umsteigen *muessen*, hab ich in meinem Betrieb selsbst erlebt:

Wir nutzen Apple, um die Daten von anderne Firmen zu konvertieren udn zu verarbeiten.

OS X war draus, alles bunter, alles besser. Kennen wir ja. Brauchen tuts keiner, schneller ists auch nicht. Paar DTP Studios ziehen vor, andere ziehen mit..

M$ koennt sich sowas nicht erlauben und wird es nicht.

Beim Zug auf 64 bit dachte ich schon, dass wie Intel Itanium keine 32bit software laufen wird. Aber noe: Selbst da gibt es Emulation. Siehe AMD64: Ne sehr schnelle sogar, die aber auch nciht wirklich Emulation ist.

alpha-centauri

2005-05-10, 21:39:32

LOL, fehlt noch, daß die Apple-Fanboys behaupten, daß Apple das Internet erfunden hat. :mad: :mad:

Dabei weiss doch jeder, daß das Bill Gates war. X-D

Ich dachte da waere damals was mit apranet und euronet ?

GloomY

2005-05-10, 21:46:57

Ich habe hier noch etwas gefunden:

G5 = aufgeborter G4 mit 64-Bit Erweiterung, es gibt gut recherchierte
Artikel das G4 CPU's bei gleichem FSB mindestens(!) genau so schnell
wären bei 32-Bit Berechnungen wie ein G5.T'schuldigung, aber das glaubst du doch selbst nicht. Guck' dir doch mal den Link bei Ars an, den ich im letzten (vorletzten) Posting hier losgeworden bin.

Rein aus dem Gedächnis heraus: Der G5 ist ein äußerst breiter Prozessor (viele Ausführungseinheiten) - ähnlich dem Athlon - , aber mit einer ziemlich langen Pipeline. Der G4 hingegen ist wensentlich schmaler und kürzer. Mal ganz grob zusammengefasst:CPU Parallelität Pipelinelänge
(Breite) (Anzahl Stufen)
---------------------------------------
G4 gering gering
G5 hoch hoch
K7/K8 hoch mittel
P4 gering (ultra-)hochBitte besser informieren...:|
Der Vergleich bezieht sich speziell auf den G4 vs. P4 und stimmt gerade da. Denn der P4 wurde auf hohe Taktzahlen getrimmt auf Kosten der Performance. Intel hat ja mittlerweile selber eingesehen, dass das ein Irrweg war und setzt mit dem Centrino auf einen effizientere Architektur mit geringeren MHz-Werten. Ähnlich, wie AMD mit den Athlon-Modellen.

Der Centrino (und der Athlon) bringt durchschnittlich bei gleicher Taktfrequenz ungefähr eine mit einem G4 vergleichbare Rechenleistung.Jep. Nur dass der G4 bei gleicher Strukturgröße niemals auf die Taktfrequenz eines Athlons kommen wird.
Jedenfalls, solange nicht viel von der altivec-Unit Gebrauch gemacht wird.

Wenn exzessiv von der Altivec-Unit gebraucht gemacht wird, ist der G4 jedem Prozessor überlegen. Sogar dem G5, denn der G4 besitzt doppelt so viele altivec-Einheiten. (z.B. bei der rc5-Entschlüsselung, dort bringt ein 500MHz-G4 die gleichen Werte, wie ein aktueller P4, ein aktueller G4 wäre also mit einem 10GHz P4 vergleichbar.)Und wie oft wird Altivec benutzt bzw. wie oft kann man vektorisieren, so dass sich der Einsatz von SIMD lohnt?
Was ist in den anderen Fällen, in denen skalarer Code verarbeitet werden muss? Ja, richtig. Da muss man auf die sonstigen Ausführungseinheiten zurückgreifen.

Bezüglich Vektorisierung: Diese hat üblicherweise sehr schlechte Datenlokalität, so dass hier Speicherbandbreite eines der limitierenden Faktoren ist. RC5 ist nunmal gerade so ein Spezialfall, bei dem alle Daten komplett in den L1 Cache hineinpasst. Das ist aber bei weitem bei den wenigsten vektorisierbaren Problemen der Fall. Dann muss man aus dem Hauptspeicher streamen, wobei gerade bei der Speicherbandbreite der G4 gegenüber dem G5 keine Land sieht. Was hilft also die unglaublich starke Altivec Unit des G4s in der Praxis, wenn die Speicherbandbreite nicht reicht?
Dafür ist der G5 in Fließkomma-Operationen überlegen, sowohl dem G4, als auch dem P4, als auch einem Centrion oder Athlon.Ach ja? SPEC FP sagt aber 'was anderes.

Und nein, ich nehme nicht die Apple-Zahlen sondern die auf www.spec.org veröffentlichten.
Quelle: http://www.macuser.de/forum/showpost.php?p=580377&postcount=58Der Server ist zur Zeit ausgelastet. Bitte versuche es später wieder.:|

Darkstar

2005-05-10, 22:39:03

Hallo Freunde

Ich lese schon seit langem in div. Mac-Foren mit. Mir fällt dort ziemlich häufig auf, daß irgendwelche Mac-Anhänger immer von "veralteter Architektur", "20 Jahre alte Architektur", "kein Potential gegenüber PowerPC" usw. flamen, sobalt x86 ins Spiel kommt!

Allerdings schreibt niemand dort mal eine wirklich Begründung.

Was ist denn jetzt genau veraltet?Ich gebe mal drei Beispiele (Stand, bevor 64 Bit auch in der x86er-Welt Einzug hielt):
386-kompatibel PowerPC
Universalregister bis zu 8¹ 32
Befehlssatz 32 Bit 64² Bit
Kühlungsbedarf³ hoch niedrig
Erläuterungen:
¹ Daß die 8 Register nicht wirklich gleich (universell) benutzbar sind, dürfte ja wohl hinlänglich bekannt sein.
² Man hat beim Design des PowerPCs einfach den Befehlssatz von IBMs POWER zugrunde gelegt. Hinweis: Alle PowerPCs bis einschließlich G4 sind trotzdem reine 32 Bit Prozessoren.
³ Die PowerPCs wurden bei Apple bis vor wenigen Jahren ausschließlich passiv gekühlt (das höchste der Gefühle war der Einsatz eines Peltier-Elementes (http://de.wikipedia.org/wiki/Peltier-Element)). Bei vergleichbarer Geschwindigkeit wurde weniger Leistung benötigt (Beispiel (http://www.pegasosppc.com/processor.php)). Erst der Pentium M konnte hier den Vorsprung der PowerPCs verringern.

Darüber hinaus sind die PowerPCs billiger in der Herstellung, da man weniger Transistoren benötigt. Durch die geringeren Stückzahlen (z. B. bei Hyperion und Genesi) und den „Exklusivitätsbonus“ (bei Apple) sind die Preise allerdings in der Realität meist höher.

Ich habe den Eindruck, daß das Leute sind die Null Ahnung haben und irgendwie mal etwas gehört haben und jetzt in Mac-Foren auf dicke Hose machen.Die Leute haben (bzw. hatten) schon recht, aber Millionen Fliegen können ja nicht irren …

… und wer gibt schon gerne zu, daß er sich ein System mit „veralteter“ Technologie gekauft hat?!

Bezüglich der Mac-Fans würde ich mal behaupten, dass diese wohl eher nach einem Grund suchen, warum der Mac besser sein soll. Lange Zeit (vor dem PowerPC970) waren die Macs leistungsmäßig hinten dran und auch die marketing-wichtigen MHz waren im Vergleich mit den x86 Prozessoren nicht konkurrenzfähig. Dann guckt man eben nach vermeintlichen Schwächen, um die eigene Entscheidung für den Mac und gegen x86 zu begründen. Das ist klassische Gewissensberuhigung im Angesicht der Rückstände im Leistungsbereich der Hardware. Das hat sich aber auch seit dem Power4-Abkömmling PowerPC970 (aka G5) geändert. Der G3 oder G4 war einfach nicht konkurrenzfähig.Und vor dieser „langen Zeit“ gab es ja noch die PPC600er-Reihe, angefangen mit dem PPC601, der dem Pentium das Fürchten lehrte (z. B. auf der CeBIT 1994). Damals hat man bei Apple einfach die Fakten sprechen lassen und an diese Zeit erinnern sich viele Mac-Begeisterten immer noch gern.

huha

2005-05-10, 22:51:13

Ich gehe nicht auf alles ein, da ich mit verschiedenen Technologien nicht so bewandert bin wie andere, allerdings:

³ Die PowerPCs wurden bei Apple bis vor wenigen Jahren ausschließlich passiv gekühlt (das höchste der Gefühle war der Einsatz eines Peltier-Elementes (http://de.wikipedia.org/wiki/Peltier-Element)). Bei vergleichbarer Geschwindigkeit wurde weniger Leistung benötigt (Beispiel (http://www.pegasosppc.com/processor.php)). Erst der Pentium M konnte hier den Vorsprung der PowerPCs verringern.

DAS zeugt leider nicht gerade von großem Wissen im Bereich Kühlung.

I) Es ist absolut unproblematisch, auch einen x86-kompatiblen Prozessor passiv zu kühlen, auch mit geringeren finanziellen Mitteln. Das Problem ist einfach, daß Apple eine Kühlkonstruktion um die CPU herumbauen kann, weil das eben speziell daraufhin optimierte Rechner sind. Apple muß sich an keinen Standard für die Rechner halten;
bei PCs sieht das anders aus, da gibt's entsprechende Gehäuse- und Mainboardstandards, die eingehalten werden *müssen*. Die Kühlung ist da nicht oberste Priorität und so kamen eben die Lüfter mit kleinen Kühlkörpern auf, da sie auch wesentlich effizienter sind als selbst mittelgroße passive Kühlkörper. (Wesentlich effizienter = in diesem Fall auch wesentlich preiswerter!)

II) Ein Peltierelement ist nicht für die Kühlung gut, es ist -- stark vereinfacht -- ein Mittel zum Wärmetransport. Blöd nur, daß Peltiers auf der kalten Seite, im Gegensatz zu konventionellen Kühllösungen oder Wärmetransportlösungen (Heatpipes, passive Kühlkörper, aktive Belüftung), kälter als die Umgebung werden. Hierfür wird zusätzliche Energie benötigt. Diese Energie wird erstmal in Form von elektrischer Energie gebraucht, sprich: Das Netzteil muß sehr großzügig dimensioniert sein. Zweitens wird die Energie auf der warmen Seite auch wieder abgegeben.
Konkret heißt das, daß ein Peltierelement nicht dazu beiträgt, daß eine Sache besser kühlbar ist, ein Vielfaches der Kühlleistung wird auf der heißen Seite wieder abgegeben, was oftmals wirklich große Kühlkörper und/oder Belüftung nötig macht.
Natürlich gibt es die Möglichkeit, das Peltierelement speziell zu steuern, daß es nur immer die Leistung abführt, die auch anfällt, was aber an dem grundlegenden Problem, daß Peltiers ein Vielfaches der Wärme erzeugen, die sie abführen, nichts ändert.

Eine Peltierkühlung ist also höchstens zur Temperaturstabilisierung auf kleinstem Raum geeignet, nicht aber zur passiven Kühlung von Prozessoren, die viel Wärme erzeugen.

-huha

[edit]
Ich habe mir gerade den Beispiel-Link angeschaut und muß eigentlich nur schmunzeln. Marketingmaterial ist sowieso ungeeignet, aber hier werden einfach wild durcheinander verschiedene Konfigurationen verglichen, wie's eben am Besten paßt.
Als Marketingmaterial beeindruckend, für die technische Auseinandersetzung -- sofern es keine marketingtechnische ist, natürlich -- aber denkbar ungeeignet.

-error-

2005-05-10, 23:12:51

Naja, schaut euch die DualCore Benchmarks auf anandtech.com an, ein Dual G5 hat da nichts mehr zu melden.

Was bremst ist das OS, werden DualCores und 64-Bit erstmal richtig unterstützt, können viele Applikationen mehre hundert Prozent schneller laufen.

Und es ist doch egal wie alt eine Technik ist, was zählt ist die Performance.

Gast

2005-05-10, 23:22:21

@Desire: Wo ist da ein Vergleich mit einem Dual G5?

Der Mac hat jedenfalls gegenüber Windows den Vorteil, daß es bereits recht viel Software gibt, die von mehreren Prozessoren proifitiert. Angeblich steht der DualCore G5 auch schon vor der Tür und man munkelt von PowerMacs mit zwei Dual-Core G5 (= 4 Prozessoren).

Da ich eh nicht mehr so der Spieler bin ist mir das eigentlich eh nicht so wichtig welche Architektur wie schnell ist. Für meine typischen Aufgaben reichen i.d.R. wohl alle aktuellen CPUs aus.

Ich mach das eher am Betriebsystem fest. Daher wird der nächste Computer wohl ein Mac werden.

Der Server ist zur Zeit ausgelastet. Bitte versuche es später wieder.

Geht doch?!

Gast

2005-05-10, 23:27:59

@Darkstar:
So wie es aussieht lassen sich dei aktuellen G5 nicht so gut kühlen. Oder warum verwendet Apple im Spitzenmodell eine Wakü und es gibt bisher auch noch keine G5 Notebooks (Powerbooks, iBooks)?

Ich habe mal gehört daß das daran liegen soll, daß der G5 so klein ist - und nicht weil er so viel Strom frisst??!!!?!?!

Darkstar

2005-05-10, 23:57:48

I) Es ist absolut unproblematisch, auch einen x86-kompatiblen Prozessor passiv zu kühlen, auch mit geringeren finanziellen Mitteln.Es gibt einen kleinen aber feinen Unterschied zwischen: 1) „Unproblematisch“ und 2) „vom CPU-Hersteller offiziell freigegeben“. Abgesehen davon: Welchen x86er-Prozessor aus der Pre-Pentium-M-Ära willst Du passiv kühlen, der dann noch schneller rechnen soll, als ein ebenfalls passiv gekühlten PowerPC mit einer etwa gleichen Verlustleistung? :|Die Kühlung ist da nicht oberste Priorität und so kamen eben die Lüfter mit kleinen Kühlkörpern auf, da sie auch wesentlich effizienter sind als selbst mittelgroße passive Kühlkörper.Bevor die Lüfter auch bei Apple Einzug hielten, gab es dort weder große noch mittelgroße Kühlkörper. Und nein, auch keine abbrechenden Sockel, die das Gewicht der Kühler nicht mehr halten konnten! ;)II) Ein Peltierelement ist nicht für die Kühlung gut, es ist -- stark vereinfacht -- ein Mittel zum Wärmetransport.„Kühlung“ ungleich „Wärmetransport“? Ja, was denn dann??? :confused:

Außerdem war meine Bemerkung zu dem Peltier-Element auf den Passus „passiv“ bezogen: Dieses zieht ja bekanntlich ein wenig Strom (wie beipielsweise ein Lüfter) und macht die Kühlung damit quasi „aktiv“. Kleine Anmerkung am Rande: Der zusammen mit dem Peltier-Element in einigen PowerMacintosh verbaute Kühler verdient diesen Namen auf Grund seiner geringen Größe fast nicht.Ich habe mir gerade den Beispiel-Link angeschaut und muß eigentlich nur schmunzeln. Marketingmaterial ist sowieso ungeeignet, aber hier werden einfach wild durcheinander verschiedene Konfigurationen verglichen, wie's eben am Besten paßt.
Als Marketingmaterial beeindruckend, für die technische Auseinandersetzung -- sofern es keine marketingtechnische ist, natürlich -- aber denkbar ungeeignet.Ich gebe zu, daß ich zu faul bin, die Spezifikationen der einzelnen PowerPCs auf den Webseiten von IBM und Motorola herauszusuchen (das hier (http://www.ppcnux.de/modules.php?name=News&file=article&sid=2985) hatte ich allerdings schon einmal in einem anderen Thread gepostet; enthält Quellenangaben). Allerdings ändert das nichts am Sachverhalt: PowerPCs haben im Allgemeinen eine geringere Leistungsaufnahme als x86er bei gleicher Rechenleistung (oder bei gleicher Leistungsaufnahme eine höhere Rechenleistung).

Kleine Hausaufgabe:
Ich würde mich mit nur einer einzigen Webseite mit Marketingmaterial von mindestens der gleichen Qualität zufrieden geben (= mit meinem Geschreibsel aufhören), auf der dieser Sachverhalt andersherum dargestellt wird (darf ruhig von Intel, AMD, VIA oder Transmeta sein). Na, das ist doch ein Angebot, oder?@Darkstar:
So wie es aussieht lassen sich dei aktuellen G5 nicht so gut kühlen. Oder warum verwendet Apple im Spitzenmodell eine Wakü und es gibt bisher auch noch keine G5 Notebooks (Powerbooks, iBooks)?

Ich habe mal gehört daß das daran liegen soll, daß der G5 so klein ist - und nicht weil er so viel Strom frisst??!!!?!?!Da der G5 im Gegensatz zu seinen Vorgängern G3 und G4 direkt von seinem großen Bruder POWER4 (ein Server-Prozessor) abstammt, hat er auch einen etwas größeren Stromhunger als diese. IBM scheint bei den Optimierungen in Bezug auf die Leistungsaufnahme ein wenig auf der Stelle zu treten, während Motorola bzw. jetzt Freescale den „alten“ G4 immer sparsamer trimmen kann.

Spekulation meinerseits:
Möglicherweise wird die Wasserkühlung verwendet, um die (bei allen Prozessoren auftretenden) HotSpots effizienter kühlen zu können. Es besteht in diesem Fall durchaus ein Zusammenhang mit der Die-Größe.

Gast

2005-05-11, 00:33:10

Wow. Mal ein Kommentar von dir, den ich nicht kritisieren will, aber was einfuegen moechte:

Wenn ein Marktuehrer mit 90% Martdurchdringung sgt :"Ihr koennt alle eure alte Software weggwerfen", wuerden sie viele Hauptkunden verlieren und das neue OS sicher nur wenige kaufen und der Absatz zurueckgehen.

Den Grund, warum die leute auf OS X umsteigen *muessen*, hab ich in meinem Betrieb selsbst erlebt:

Wir nutzen Apple, um die Daten von anderne Firmen zu konvertieren udn zu verarbeiten.

OS X war draus, alles bunter, alles besser. Kennen wir ja. Brauchen tuts keiner, schneller ists auch nicht. Paar DTP Studios ziehen vor, andere ziehen mit..

M$ koennt sich sowas nicht erlauben und wird es nicht.

Beim Zug auf 64 bit dachte ich schon, dass wie Intel Itanium keine 32bit software laufen wird. Aber noe: Selbst da gibt es Emulation. Siehe AMD64: Ne sehr schnelle sogar, die aber auch nciht wirklich Emulation ist.

Wo ist das Problem

a) OS9 war nicht mehr das Wahre ;)

b) Sie haben einen sauberen Schnitt gemacht - man kann aber OS9 Software weiterhin nutzen.

Klar - Übergangszeit war so eine Sache. Aber jetzt hat man mit OS X ein top System mit einer guten Grundlage.

Soetwas ist IMHO besser anstatt ein veraltetes OS wie OS9 aufzupeppen - das wird nie so wie etwas ganz neues

Coda

2005-05-11, 00:33:51

Universalregister bis zu 8¹ 32Register Renaming ist dir ein Begriff? Und ja, sie sind seit dem 386 universell einsetzbar.

Befehlssatz 32 Bit 64² BitDas ist doch ein Vorteil für x86, weil man kompakteren Code hat. Und nein, man braucht nicht länger zum dekodieren

Kühlungsbedarf³ hoch niedrigIch sag nur Dual G5 2.5Ghz Wakü :rolleyes:

Außerdem war meine Bemerkung zu dem Peltier-Element auf den Passus „passiv“ bezogen: Dieses zieht ja bekanntlich ein wenig Strom (wie beipielsweise ein Lüfter)Da bist du auf dem Holzweg, Peltiers verbrauchen extrem viel Saft.

Gast

2005-05-11, 02:57:57

Register Renaming ist dir ein Begriff? Und ja, sie sind seit dem 386 universell einsetzbar.

Das ist doch ein Vorteil für x86, weil man kompakteren Code hat. Und nein, man braucht nicht länger zum dekodieren

Ich sag nur Dual G5 2.5Ghz Wakü :rolleyes:

Da bist du auf dem Holzweg, Peltiers verbrauchen extrem viel Saft.
Die brauchen deutlich mehr Strom als die Wärme, die abgeführt werden. Meist um Faktor 1,5.

Die meisten Vergleiche hier und dort zwischen einem x86 und Apple sind veraltet. Die berücksichtigen nicht die Neuheiten, vor allem bei der Hardware.

Wenn die Spass haben, warum nicht.

Zool

2005-05-11, 07:47:52

Naja... Zur Zeit proggen sie nur das nach, was NeXTStep schon 1993 konnte. ;) Nur schöner... ;)

Waren das damals noch schöne Zeiten. Nur leider hatte ja Steve Jobs mit seinem Apple Spin-Off Pleite gemacht und ging reuemütig zur Mutter zurück.

Ein schwarzer NeXT-Cube mit schicken MC 68040 war so was Feines und hatte schon vor iMac ein hübsches Design.

Ganon

2005-05-11, 08:09:25

Waren das damals noch schöne Zeiten. Nur leider hatte ja Steve Jobs mit seinem Apple Spin-Off Pleite gemacht und ging reuemütig zur Mutter zurück.

Naja. Wenigstens kann man ihm nicht vorwerfen, er klaue jetzt alles von NeXT. ;)

Aber wenigstens kann man sagen das NeXTStep nicht "tot" ist. OS X belebt es ja langsam in sich wieder. Bald sind alle Features portiert + neue. ;)

HOT

2005-05-11, 09:58:13

x86 mag schon sehr alt sein, jedoch sind die Prozessoren nicht langsamer und Netburst als Vergleich heranzuziehen finde ich eher unpassend, weil die Performance dieser Architektur doch sehr von der Speicherperformance, Cache und FSB abhängt, viel mehr als andere Architekturen bisher. Von daher war es damals auch kein Wunder, dass ein P4 2,0 (Willy) von nem Athon1400 geplättet wurde. Gegen den Athlon oder P3 sah der G4 kaum Land, auch in Sachen Takt nicht. Ausnahme: Extreme Altivec Optimierung. Der G5 hingegen ist ein durchaus konkurrenzfähiger Prozessor, jedoch mit Nachteilen bei der Hitzeentwicklung.

Heute scheint x86 aber tatsächlich veraltet. Das liegt aber mehr daran, dass der 32Bit Adressraum knapp wird. AMD hat diese Gelegenheit genutzt, um einige grundlegende Änderungen einzuführen, die die x86 Schwächen (die es unbestritten gibt) auszumerzen, und das wohl mit Erfolg.

Shink

2005-05-11, 10:48:46

Wegen dem oft verwendeten AltiVec-Argument: Ja, klar, diese Befehlssatzerweiterung ist um einiges sinnvoller als SSE. Aber Befehlssatzerweiterungen würd ich nicht gerade als Performancemaßstab hernehmen. Ein Via C3 - übrigens der letzte x86-Prozessor, der auch noch die x86-ARCHITEKTUR hat, verbläst bei der Verwendung seiner Padlock-Befehlserweiterung jeden anderen Prozessor bezüglich Pro-MHz-Leistung bei AES. Trotzdem würd ich ihn nicht als sehr modern bezeichnen.

Gast

2005-05-11, 10:58:05

Mich wundert dieses Unwissen in den Mac-Foren keineswegs. In den dortigen Foren gibt es erschreckend wenig Leute die Ahnung von Hardware haben. Die Masse hat schlicht von den einfachsten Dingen keinen Plan. Das merkt man wenn man mal längere Zeit in einem solchem Forum mitliest. So wird dann der Stuss nacherzählt, der dort verbreitet wird. Ganz schlimm sind dann die Leute, die für die Wissens-Kings gehalten werden es aber nicht wirklich oder nur zum Teil sind. Denen glaubt dann jeder - egal was für ein Unfug das auch sein mag.

Hier gab es ja schon zwei solcher zitierter Postings in dem Thread.

Tiamat

2005-05-11, 11:03:34

Hi ,
das kann man aber auch net sagen.
Der G4 hatte Anfangs 1MB L2 Cache und war untertrieben gesagt durchaus konkurenzfähig.Allerdings waren deshalb die Preise für den Powermac auch sehr hoch.Die nächste Version hatte nur noch 256kb l2(natürlich aus Preisgründen) Cache mehr takt weniger pro-mhz Leisung und ich kann mich noch an Audiobenchmarks erinnern wo ein G4 400(1MB) ma locker nen Quicksilver 733 (256kb) in die Tasche gesteckt hat.Zu guter letzt hat Motorola auch schwere Probleme gehabt um überhaupt die 1Ghz zu erreichen,während sich AMD und Intel schon total das Rennen geliefert haben.
Ohne IBM würde wahrscheinlich heute ein G4 1.67Ghz einem Athlon 4000+ oder P4 3.8Ghz gegenüberstehen und den Umstand hätte auch ein OS X nicht ausgleichen können.

Gast

2005-05-11, 11:50:49

ich halte es ja für einen Fehler, dass Apple sich für diese Hauptsache-billig-scheiß-auf-Qualität-x86-Technik entschieden hat

http://www.macuser.de/forum/showthread.php?p=849212#post849212

;D

Tja - so ein Pseudoexperte wieder. Ach von dem hatten wir ja bereits etwas in diesem Thread...

Ganon

2005-05-11, 12:06:34

http://www.macuser.de/forum/showthread.php?p=849212#post849212
Tja - so ein Pseudoexperte wieder. Ach von dem hatten wir ja bereits etwas in diesem Thread...

Ähm, ._ut würde ich nicht als "Pseudo-Experten" bezeichnen. Was sein Wissen über MacOS und generell Systeme angeht, hat er eine Menge drauf. Klar, Mister "Allwissend" ist er auch nicht, aber sicherlich kein 08/15-Mac-DAU.

Außerdem hat er doch mit USB Recht. Das gelbe vom Ei ist es nicht wirklich und gegen FireWire kommt es nicht an.
USB ist halt nur eine "billig-Lösung" gegenüber FireWire.

Der Vorteil von USB ist einfach der Preis. Mehr nicht...

Gast

2005-05-11, 12:10:30

Ach das war auf USB gerichtet - habe das anders verstanden...

Nunja - mag ja sein dass der Ahnung von OSX hat. Aber sonst? BlackBirdSR hat sich ja bereits schon über einen seiner Posts in diesem Thread aufgeregt, als er etwas über CPUs geschrieben hat.

Aber ich will das nicht an einem User festmachen. Unwissenheit ist im Maclager i.d.R. jedenfalls groß!

huha

2005-05-11, 12:25:06

Es gibt einen kleinen aber feinen Unterschied zwischen: 1) „Unproblematisch“ und 2) „vom CPU-Hersteller offiziell freigegeben“.

Weder Intel noch AMD haben was dagegen, wenn ihre CPUs passiv gekühlt werden. Freigabe genug?

Abgesehen davon: Welchen x86er-Prozessor aus der Pre-Pentium-M-Ära willst Du passiv kühlen, der dann noch schneller rechnen soll, als ein ebenfalls passiv gekühlten PowerPC mit einer etwa gleichen Verlustleistung? :|

PowerPC ist keine schlechte Architektur und ich will auch gar nicht anzweifeln, daß die x86-kompatiblen CPU mehr Wärme erzeugen/erzeugt haben, jedoch läßt sich absolut *jeder* x86-kompatible Prozessor passiv kühlen. Mit einem entsprechenden Gehäusedesign ist das überhaupt kein Problem und Apple hat eben das entsprechende Gehäusedesign. Beim PC wird's wieder schwieriger, weil die Sachen genormt und standardisiert ist, da kann nicht einfach ein Hersteller über die Stränge schlagen und sich einen eigenen Formfaktor für ein bestimmtes Produkt ausdenken, der es erlaubt, das Teil passiv zu kühlen.

Bevor die Lüfter auch bei Apple Einzug hielten, gab es dort weder große noch mittelgroße Kühlkörper. Und nein, auch keine abbrechenden Sockel, die das Gewicht der Kühler nicht mehr halten konnten! ;)

Kleines Problemchen: Du vermischst hier mehrere Sachen, was ich gar nicht leiden kann. Abbrechende Sockel sind kein Problem der Architektur, nur der Ausführung. Ich hab' übrigens noch nie davon gehört, daß ein Sockel nicht mutwillig zum Abbrechen gebracht wurde.

„Kühlung“ ungleich „Wärmetransport“? Ja, was denn dann??? :confused:

Kühlung ist zwar Wärmetransport, man muß hier aber differenzieren. Als Wärmetransport verstehe ich den Transport der Anfallenden Wärme von Punkt A nach Punkt B, wobei an Punkt B ein Kühlkörper sitzt, der seine Wärme an die Luft abgibt. Dies wird z.B. gemacht, wenn an Punkt A zu wenig Platz vorhanden ist, um die Wärmequelle adäquat zu kühlen oder, wenn es andere spezielle Erfordernisse erforderlich machen (z.B., wenn man unter die Raumtemperatur gelangen will, was dann aber wieder aktiver Wärmetransport wäre)

Außerdem war meine Bemerkung zu dem Peltier-Element auf den Passus „passiv“ bezogen: Dieses zieht ja bekanntlich ein wenig Strom (wie beipielsweise ein Lüfter) und macht die Kühlung damit quasi „aktiv“.

Das ist ein Argument, wobei man das passiv/aktiv eigentlich in der täglichen Auseinandersetzung mit der Kühlung eher darauf bezieht, wie der Wärmetauscher seine Wärme an die Umgebungsluft abgibt. Passiv wäre hier also ohne Lüfter.
"Ein wenig Strom" ist leicht untertrieben, die Verlustleistung der CPU muß erstmal in das Peltierelement gesteckt werden, da es ohne Stromzufuhr die Wärme isoliert und somit der Prozessor schnellstmöglich abraucht. Da es allerdings leider keine Peltierelemente des Wirkungsgrads 1 gibt (das verbietet die Thermodynamik), muß mehr Strom hereingesteckt werden als die Verlustleistung der CPU, dieses Mehr äußert sich in Form von zusätzlicher Wärme, die auf der heißen Seite, also vom Kühlkörper, abgeführt werden muß.

Kleine Anmerkung am Rande: Der zusammen mit dem Peltier-Element in einigen PowerMacintosh verbaute Kühler verdient diesen Namen auf Grund seiner geringen Größe fast nicht.

Das ist mir ein Rätsel. Leider habe ich absolut keine Ahnung, weshalb auf ein Peltierelement gesetzt wurde, da Peltierelemente nur unter einem Spezialfall einen Vorteil gegenüber jeglichen anderen Kühltechnologien haben und sonst nur nachteilbehaftet sind:
Dieser Spezialfall ist, wenn auf kleinem Raum eine Temperatur unter der Raumtemperatur entstehen soll, und zwar bei "moderaten" Verlustleistungen. Für größere Verlustleistungen sind Kompressoren weitaus effektiver, soll's nicht unter die Raumtemperatur gehen, sind andere Mittel zum Wärmetransport um ein Vielfaches geeigneter.

Ein Peltierelement für so eine Aufgabe ist also absolut vermessen, da es etwas Besseres gibt:
Heatpipes. Die brauchen nicht nur keinen Strom im Betrieb, sondern werden auch nicht über Gebühr warm. Außerdem lassen sich größere Strecken damit zurücklegen.
Ein Nachteil ist, daß die Dinger leicht lageabhängig sind, für verwinkeltere und komplexere Strecken gibt's dann Wasserkühlungen. Wasserkühlungen müssen auch verwendet werden, wenn der Temperaturbereich für eine Heatpipe zu stark schwankt, die erreichen ihre Kühlleistung nämlich nur innerhalb gewisser Grenzen.

Ich gebe zu, daß ich zu faul bin, die Spezifikationen der einzelnen PowerPCs auf den Webseiten von IBM und Motorola herauszusuchen (das hier (http://www.ppcnux.de/modules.php?name=News&file=article&sid=2985) hatte ich allerdings schon einmal in einem anderen Thread gepostet; enthält Quellenangaben). Allerdings ändert das nichts am Sachverhalt: PowerPCs haben im Allgemeinen eine geringere Leistungsaufnahme als x86er bei gleicher Rechenleistung (oder bei gleicher Leistungsaufnahme eine höhere Rechenleistung).

Ich wunderte mich eben nur, wie in dem Link bewußt die Sache dermaßen manipuliert wird, daß der PowerPC immer besser dasteht. Der PowerPC ist kein schlechter Prozessor, aber er ist auch nicht der Weisheit letzter Schluß. Wärmeabgabe ist nicht alles, Rechenleistung auch nicht; aber einen Prozessor einmal von der Rechenleistung mit einem absoluten Stromsparprozessor vergleichen und ein andermal von der Wärmeabgabe mit einem "normalen" Desktopprozessor, das halte ich für pures Marketing und das wirft IMHO kein gutes Licht auf das Produkt, das vermarktet werden soll.
Gerade bei Benchmarks sollte man auch darauf achten, daß die Teile wirklich CPU-limitiert sind, bei einigen kann ich das nämlich nicht so wirklich glauben.
Man kann Prozessoren immer auf bestimmte Zwecke hin optimieren, was ja nicht unbedingt schlecht ist. Wenn das OS auch noch mitspielt und diese Optimierungen voll auszunutzen weiß, ist das sogar noch viel besser, aber nur wegen dieser Traumkombination aus guter CPU und hochoptimiertem OS nebst Programmen den PPC weit über den x86 erheben zu wollen ist etwas weit hergeholt. Der PPC in Kombination mit dem OS ist ein großartiges Bundle, nicht zu vergessen ist allerdings, daß es wohl auch für den x86 entsprechende Kombinationen gibt, die eben weitaus weniger verbreitet sind.

Kleine Hausaufgabe:
Ich würde mich mit nur einer einzigen Webseite mit Marketingmaterial von mindestens der gleichen Qualität zufrieden geben (= mit meinem Geschreibsel aufhören), auf der dieser Sachverhalt andersherum dargestellt wird (darf ruhig von Intel, AMD, VIA oder Transmeta sein). Na, das ist doch ein Angebot, oder?

Ich such' mal, da ich aber nicht so, entschuldige, "marketinggeil" bin, kann das ggf. etwas dauern ;)

Spekulation meinerseits:
Möglicherweise wird die Wasserkühlung verwendet, um die (bei allen Prozessoren auftretenden) HotSpots effizienter kühlen zu können. Es besteht in diesem Fall durchaus ein Zusammenhang mit der Die-Größe.

Nunja, ich seh' das anders.
Die Die-Größe hat damit recht wenig zu tun, es ist ja keine Direct-Die-Wasserkühlung (hierbei wird das Kühlmittel direkt auf den Prozessorkern gespritzt, wird nicht nur von Bastlern mit Wasser eingesetzt, sondern auch von Großrechnern mit irgendwelchen anderen Kältemitteln), sondern die hat auch einen Kühlkörper dazwischen. Mit einem Alukühlkörper mit Kupferboden würde der selbe Effekt erzielt.
Vielmehr halte ich die Sache auch für ein Prestigeobjekt, um einfach mal das Mögliche aufzuzeigen. Für solche kleinen Ecken sind Wasserkühlungen meines Erachtens nach nicht wirklich gut geeignet, da einfach die Vorteile zu wenig zum Tragen kommen, nämlich große Kühlkörper mit langsamdrehenden Lüftern. Die Kühlung des G5 hätte man genausogut mit Heatpipes realisieren können.

-huha

HajottV

2005-05-11, 12:31:26

Daß die 8 Register nicht wirklich gleich (universell) benutzbar sind, dürfte ja wohl hinlänglich bekannt sein.

Es sind 7 Register universell nutzbar, nämlich EAX, EBX, ECX, EDX, ESI, EDI, EBP (wenn man die Stackverwaltung geschickt macht), ESP ist nicht nutzbar. Daß sieben Register suboptimal sind, ist klar. Daran kann auch Register-Renaming nicht viel ändern. Der "Sweet Spot" (da gibt es einige Paper zu dem Thema) liegt bei 16. Die x86 Architektur schleppt sicherlich Unmengen an Altlasten mit sich - dennoch muß man im Gegenzug sagen, daß es geradezu enttäuschend ist, wie schlecht sich die (quasi) altlastenfreie und nach modernen Prinzipien entwickelte PowerPC Architektur schlägt.

Gruß

Jörg

PS: Ich hab schon PowerPCs auf Assemblerebene programmiert...

micki

2005-05-11, 12:34:29

Außerdem hat er doch mit USB Recht. Das gelbe vom Ei ist es nicht wirklich und gegen FireWire kommt es nicht an.
USB ist halt nur eine "billig-Lösung" gegenüber FireWire.

das ist halt das rationale denken, entweder man macht das best mögliche, egal was es kostet/welcher aufwand "FIREWIRE" oder man versucht die anforderungen ein wenig zu überbieten zu möglichst niedrigen kosten/aufwand "USB".

kosten sind dabei nicht nur der preis der hardware, sondern der aufwand der entwicklung. selbst sony hat z.b. kein memory stick für firewire gemacht, sondern ne extra schnittstelle dafür erfunden, weil firewire zuviel aufwand bei der entwicklung braucht, es hat ein kompliziertes hostloses protokoll, hat hoche anforderungen an die qualität der hardware. das USB eine gute basis hat, kann man darin sehen dass es schon lange USB2 gibt, weil die hersteller gerne die neuen möglichkeiten günstiger hardware zu produzieren ausreizen und es von der leistungsfähigkeit mit firewire konkurieren kann.

btw. das ist kein flame gegen firewire. ich sage nur dass usb den anforderungen entspricht, die es erfüllen sollte, keine konkurenz für firewire, sondern ersatz für die bisherigen anschlüsse wie printerport,ps2,com,... flexibilität z.b. anschluss von digicams,usbsticks,festplatten usw. und günstig.
firewire sollte einfach nur schnell sein.

MfG
micki

Ganon

2005-05-11, 12:55:34

btw. das ist kein flame gegen firewire. ich sage nur dass usb den anforderungen entspricht, die es erfüllen sollte, keine konkurenz für firewire, sondern ersatz für die bisherigen anschlüsse wie printerport,ps2,com,... flexibilität z.b. anschluss von digicams,usbsticks,festplatten usw. und günstig.
firewire sollte einfach nur schnell sein.

Ja sicher. Aber genau das meinte ._ut, auch damals schon in seinen Posts.

Gerade der Multi-Geräte-Betrieb von USB ist nicht gerade gut gelöst und auch problembehaftet (er will in seinem verlinkten Post ja nur auf die Anforderung von Desktop und Server eingehen).

Probleme die bei FireWire schon vom Konzept her nicht auftreten.

Ich will ja auch nicht USB generell schlecht machen. Nur das Konzept ist nicht gerade das Beste. Und mehr will man eigentlich auch nicht sagen.

Ganon

2005-05-11, 13:02:05

Aber ich will das nicht an einem User festmachen. Unwissenheit ist im Maclager i.d.R. jedenfalls groß!

Das stimmt. Aber gerade mit ._ut hast du dir den falschen raus gesucht. ;)

Klar. Ich stimmt mit ihm auch nicht überall überein. Er ist z.B. Verfechter der Ein-Tasten-Maus und gibt auch gute Gründe an warum. Trotzdem benutze ich am Mac ne 8 Tasten Maus. ;)

Das ein G4 hoffnungslos veraltet ist, ist klar. Das in ihm, dank dicker Altivec-Einheiten, auch viele Reserven Stecken ist auch klar. Das kaum einer Altivec nutzt ist auch klar. Das der G4 somit verliert ist auch klar.

Der G5 ist imo auch nicht gerade ein besonders guter Prozessor. Aber ich mache meine Wertungen schon lange nicht mehr in brachialer Leistung fest.

Das IBM einen G3 verkauft der unter Vollast bei 733 Mhz nur 5 Watt Verbrauch hat finde ich viel viel "Spannender", als eine 2,7Ghz CPU mit 80 Watt Verbrauch (80 Watt sind geraten).

Coda

2005-05-11, 13:21:05

Wegen dem oft verwendeten AltiVec-Argument: Ja, klar, diese Befehlssatzerweiterung ist um einiges sinnvoller als SSE. Warum? Beides sind SIMD Erweiterungen die mit 4x32bit floats arbeiten. Ich wüsste nicht was an Altivec besser sein sollte.

Ganon

2005-05-11, 13:32:19

Warum? Beides sind SIMD Erweiterungen die mit 4x32bit floats arbeiten. Ich wüsste nicht was an Altivec besser sein sollte.

Altivec ist Leistungsfähiger, da die SIMD eigenständiger ist als SSE und, ich glaub, auch besseren Zugriff auf den Speicher hat.

Insgesamt ein besseres Konzept.

Das zeigt auch das RC-72-Projekt (lässt sich ja anscheinend gut vektorisieren). Die versuchen schon seit Jahren den Pentium4-Core mit SSE-Code zu beschleunigen (seit erscheinen des P4, glaube ich). Hat auch geklappt (von 2MKeys/s auf 5Mkeys/s). Nur bei weitem nicht so schnell wie der Altivec-Core (von 3Mkeys/s auf 13 MKeys/s).

Achja. Altivec muss nicht mit 4x32bit float arbeiten. 4x32bit int und 16x8bit char geht, u.a., auch. ;) Ich glaube aber das kann auch SSE auch, oder?

Quasar

2005-05-11, 13:34:58

Das IBM einen G3 verkauft der unter Vollast bei 733 Mhz nur 5 Watt Verbrauch hat finde ich viel viel "Spannender", als eine 2,7Ghz CPU mit 80 Watt Verbrauch (80 Watt sind geraten).
http://processorfinder.intel.com/scripts/details.asp?sSpec=SL7F4&ProcFam=942&PkgType=ALL&SysBusSpd=ALL&CorSpd=ALL
*SCNR*
Ich bin mir ziemlich sicher, daß mein Dothan bei 800 MHz (min. Speedstep) und 0,732 v auch nicht viel mehr zieht.

Aber ich stimme dir zu: Solche CPUs finde ich auch viel spannender, als bsw. das Monstrum von CELL, von dem ich gestern las, daß ein Versuchsexemplar im Labor bei ~1,4 v und 5,6 GHz Takt mal eben so 180 Watt soff.

Ganon

2005-05-11, 13:42:52

http://processorfinder.intel.com/scripts/details.asp?sSpec=SL7F4&ProcFam=942&PkgType=ALL&SysBusSpd=ALL&CorSpd=ALL
*SCNR*
Ich bin mir ziemlich sicher, daß mein Dothan bei 800 MHz (min. Speedstep) und 0,732 v auch nicht viel mehr zieht.

Das das nur ein PowerPC schaffen kann, habe ich ja gar nicht behauptet. ;)

Fragt sich nur wie real die Werte von Intel sind. 5.0W klingt schon seeeehr allgemein gesagt. Bei IBM kriegt man direkt die Werte:

PPC750FL
SleepMode: 0,4W
Nap Mode: 0,7W
RC5-Test 105°: 5,7W

Pallo

2005-05-11, 14:00:21

Das stimmt. Aber gerade mit ._ut hast du dir den falschen raus gesucht. ;)

Klar. Ich stimmt mit ihm auch nicht überall überein. Er ist z.B. Verfechter der Ein-Tasten-Maus und gibt auch gute Gründe an warum. Trotzdem benutze ich am Mac ne 8 Tasten Maus. ;)

Öhm da bin ich mir nicht so sicher. Ich kenne den auch. Klar der scheint einiges zu wissen - aber eben auch nicht alles. Wie sagtest du doch weiter oben?

"Klar, Mister "Allwissend" ist er auch nicht" - aber das kommt so rüber wenn man einige seiner Posts liest. Zudem lässte er keine Gelgenheit aus, unterschwellige Bemerkungen gegen x86-Nutzer oder Spieler zu machen - siehe allein schon wie er sich über USB ausgedrückt hat. Das kann man auch anders! Der provoziert damit doch gerade so die "Switcher".

Zu den CPUs hat er ja z.B. teilweise dicken Stuss geschrieben. Und in irgendsoeinem Mausthread wird es wirklich lächerlich ;)

Ich bin sicher da findet sich noch mehr ;)

Aber wie schon geschrieben wurde, man soll es nicht an einem User festmachen.

Der G5 ist meiner Meinung nach gut aber auch nicht ideal. War imho so eine Art Schnellschuss, wo noch Altivec draufgeknallt wurde damit man konkurrenzfähig bleibt.

Mag sein, daß ich falsch liege. Aber ich halte mich auch nicht für allwissend ;)

Grestorn

2005-05-11, 14:09:09

Außerdem hat er doch mit USB Recht. Das gelbe vom Ei ist es nicht wirklich und gegen FireWire kommt es nicht an.
USB ist halt nur eine "billig-Lösung" gegenüber FireWire.

Der Vorteil von USB ist einfach der Preis. Mehr nicht...Firewire hat einen ultimativen Nachteil: Das Bussystem.

Ich kann nicht immer am letzten Gerät anstecken (wenn es ungünstig steht z.B.). Und wenn ich ein Gerät mittendrin rausnehmen muss, muss ich die Kette kurzfristig unterbrechen.

Deswegen kommt FW bei mir nicht ins Haus. Auch wenn es vielleicht etwas schneller sein mag.

Ganon

2005-05-11, 14:10:28

@Pallo

Ich mag es irgendwie nicht über User eines anderen Forums "herzuziehen", deswegen halte ich mich hier zurück.

Wie ich sagte. Seine Kommentare konnte er bisher immer gut belegen. Aber deswegen muss man ja nicht gleich einer Meinung sein.

"Stuss" hat er eigentlich nicht geschrieben, in der CPU-Sache. Er hat halt nur die positiven Sachen raus gesucht. ;)

Das er etwas provokant schreibt und immer nur auf den Vorteilen rumgetrampelt wird, mein Gott. Das ist doch hier auch an der Tagesordnung. ;)

Gast

2005-05-11, 14:10:45

Mir sagt auch Firewire mehr zu. Wenn ich die Wahl habe, entscheide ich mich für FW.

Aber ist OT oder?

Grestorn

2005-05-11, 14:13:24

Mir sagt auch Firewire mehr zu. Wenn ich die Wahl habe, entscheide ich mich für FW.Und warum? Weil es von Apple gepusht wird? Oder gibt es einen echten Vorteil, der sich mir nur nicht erschließt?

Gast

2005-05-11, 14:14:42

Und warum? Weil es von Apple gepusht wird? Oder gibt es einen echten Vorteil, der sich mir nur nicht erschließt?
Nö - was Apple pusht ist mir schnuppe. Ist einfach meist besser in der Praxis!

ESAD

2005-05-11, 14:19:29

was verstehts du unter besser?

noch als kleine anmerkung: juhu ibm-pc welt gegen apple-pc welt konnte ich schon live miterleben und freue mich auf eine neue runde

Pallo

2005-05-11, 14:31:39

Wie ich sagte. Seine Kommentare konnte er bisher immer gut belegen. Aber deswegen muss man ja nicht gleich einer Meinung sein.

Konnte er eben nicht immer! Bsp. z.B. gewisse Aussagen über Eintastenmaus oder über Ego-Shooter (die er scheinbar selber noch nie gespielt hat aber hier natürlich weiss worauf es ankommt)

"Stuss" hat er eigentlich nicht geschrieben, in der CPU-Sache. Er hat halt nur die positiven Sachen raus gesucht. ;)

Das er etwas provokant schreibt und immer nur auf den Vorteilen rumgetrampelt wird, mein Gott. Das ist doch hier auch an der Tagesordnung. ;)
Finde ich nicht OK - und ist dort auf einem ganz anderem (schlechterem und einseitigem) Niveau als hier! Und jemanden der Kontra leistet direkt als Troll zu nennen ist ebensowenig nett!

Ich mag es irgendwie nicht über User eines anderen Forums "herzuziehen", deswegen halte ich mich hier zurück.

Das stimmt. Daher bin ich zu dem Thema jetzt still!

noch als kleine anmerkung: juhu ibm-pc welt gegen apple-pc welt konnte ich schon live miterleben und freue mich auf eine neue runde

Ähm - der G5 ist doch von IBM ;)

Und OSX läuft leider nur auf diesem - also muß ich sowieso den nehmen, wenn ich OSX möchte. Ich mache den Rechnerkauf mehr vom Betriebsystem anstatt von der CPU anhängig.

Ganon

2005-05-11, 14:33:51

Und warum? Weil es von Apple gepusht wird? Oder gibt es einen echten Vorteil, der sich mir nur nicht erschließt?

Also "meine Meinung":

- höhere Geschwindigkeit
- "stabilere Verbindung" (Durchschnittsgeschwindigkeit)

Reicht schon, imo.

Gast

2005-05-11, 14:36:39

AFAIK bricht FW beim Zugriff auf mehreren Geräten auch weniger ein. Habe das aber selber noch nicht getestet.

Naja - und mit FW800 kann man den "alten" FW400 Kram weiternutzen.

StefanV

2005-05-11, 14:47:26

Das IBM einen G3 verkauft der unter Vollast bei 733 Mhz nur 5 Watt Verbrauch hat finde ich viel viel "Spannender", als eine 2,7Ghz CPU mit 80 Watt Verbrauch (80 Watt sind geraten).
Der Athlon 64 idelt auch in dem Bereich (nein, nicht ganz, der idelt bei etwa 1GHz), ein Athlon XP mit diesen Specs dürfte ebenso möglich sein, wenn die Spannung klein genug ist...

Ganon

2005-05-11, 14:52:04

Konnte er eben nicht immer! Bsp. z.B. gewisse Aussagen über Eintastenmaus

Ein letztes mal: ;)

Doch konnte er. Samt Bild über die "Haltung" der Hand bei der Maus, das mit 2 Tasten nicht gehen würde.

Ist ja aber im Prinzip egal. ;)

Allgemein zu MacUser:
Das Problem ist, jeder der dort postet ist gleich ein "MacUser" für euch. Viele sind auch Switcher, die halt ein bisssch "rumlabern". Ist genauso wie ein "Linux-Switcher", so "Boah, geil, Windows ist so scheiße" etc. pp.

Ist dort nicht anders.

Oder halt die Trolle, die nur Ärger machen wollen. Oder DAUs halt... ;)

Bsp:
Tiger hat ja Probleme mit den alten Cisco-Treibern. Verständlich da neuer Kernel. Cisco hat anscheinend die Tiger-Preview "verpennt". Immerhin hat Tiger eines der längsten Dev-Phasen hinter sich.
Jetzt schieben unwissende MacUser und Trolle alles gleich auf Apple, sie hätten den Cisco-Treiber rausgeschmissen...

StefanV

2005-05-11, 14:53:07

Und warum? Weil es von Apple gepusht wird? Oder gibt es einen echten Vorteil, der sich mir nur nicht erschließt?
Nein, weil Firewire:

a) von Anfang an für Daten Transfer konsipiert wurde, USB nur als ANschluss für Eingabegeräte und ähnlichem
b) weils etwas vom SCSI Protokoll mitbekommen hat
c) weil man munkelt, das Feuerdraht intelligenter (=teurer) als USB ist.

Ganz ehrlich:
Das Intel (und andere) sich weigern, Feuerdraht einzusetzen ist IMO selten dämlich, da Feuerdraht USB nicht ersetzen kann, USB aber auch nicht Feuerdraht.
Am sinnigsten wäre es, wenn jeder PC sowohl IEE1394 als auch USB (im Chipsatz!!) hätte...

USB hatte damals den Sinn, IEE1289, PS/2 Ports und die Seriellen Ports zu ersetzen, siehe dieses ABIT MAX Dingensda mit KT333 Chipsatz.
IEE1394 war hingegen als Schnittstelle für Datenübertragung gedacht, sprich für externe Platten, DV Camcorder und ähnliches.

Was wirklich dämlich ist, ist zu sagen, USB wär einfach besser, IEE1394 unnötig, denn das stimmt nicht, die Wahrheit ist, das sich diese beiden Dinge eigentlich hervorragend ergänzen, in der Praxis!!

Black-Scorpion

2005-05-11, 14:54:32

Naja - und mit FW800 kann man den "alten" FW400 Kram weiternutzen.
Geht das bei USB nicht? ;)

Aber es gibt Beispiele wo sich FW einfach durchgesetzt hat.
Wer einen DigiCamcorder hat wird den Vorteil beim übersoielen auf den PC schon zu schätzen wissen.

Gast

2005-05-11, 15:01:19

mir ist klar, dass der g5 von ibm produziert wird genauso dass er eigenlich eine veränderte servercpu von ibm ist

so und nun rat mal wieso ibm hm?
richtig ibm hat mit der großserienproduktion von pc´s begonnen

und usb wurde ins leben gerufen weil man dafür keine lizenzzahlungen zu leisten (1$ pro fw buchse ist doch wirklich übertrieben meint ihr nicht)hat und sollte alles können was fw kann und noch mehr (mir ist zumindest noch nichts aufgefallen was es nicht kann was aber fw dafür kann)

del_4901

2005-05-11, 15:09:06

Mal zu meinen geliebten Pelztieren, da ich schon selber CPU und Pelztier zerfraggt habe. Also zum Wärmetransport von A nach B (wie bei einer Heatpipe) sind die Dinger völlig fehl am Platze.
Die dinger kann man dazu nehmen, um 1. unter Raumtemp zu kommen und
2. wenn die Energiedichte pro Oberfläche zu groß wird um mit Kupfer zu kühlen. (zweiteres trifft aber [noch] auf CPUs eher weniger zu)
Die Probleme die Peltiers mit sich bringen:

1. Der Energiebedarf
2. Die adequate Kühlung, der heißen Seite
3. Die effektive Wärmeverteilung auf der kalten Seite
4. Die Wärmepumpenleistung muss über der abgegebenen Leistung des zu kühlenden Objekts sein. -> 1.

zu 1. Selbst das beste Enermax NT ist zu schwach auf der Brust für die echt guten Pelztiere. (die haben meißtens 16V bei 16A+ ... betreibt man die bei 12V, so haben sie noch knapp über die hälfte der angegebenen Leistung)
zu 2. wird die heiße Seite auch nur ein bischen zu warm, sei es stellenweise oder Komplett, so bricht das Pelztier sofort ein (und man hat einen schoenen Dominoeffekt). -> Die Oberfläche muss sehr plan sein, und die Teile werden mit speziellen Wärmeleitkleber verklebt, sodaß nicht das gringste bischen Luft dazwischen kommen kann. Außerdem kann man die heiße Seite eines 120W Pelztieres nur mit Wasser oder einem Kompressor kühlen. (am besten unter 20°C)
zu 3. Wird die kalte Seite zu Warm (z.B wenn der Die einer CPU direkt aufliegt) so bricht auch hier die Leistung stark ein, und im schlimmsten Fall raucht es.
zu 4. Eine aktuelle CPU braucht mind. ein 120W Pelztier, besser eind 200W, ein entsprechendes NT ist SEHR teuer (ich hab meins selbst zusammengebaut (hat 17V regelbar und ca. 18A))

Meins ist nur gestorben, weil ich Depp beim Einstellen des NTs die Leerlaufspannung gemessen habe ... das passiert mir nicht nocheinmal glaubt mir Jungs .. das hat kurz geraucht und die CPU hat das Pelztier zerfraggt.

Als Pelztier Heatspreader eignen sich ca. 5mm dicke Kupferplatten die man auf beide Seiten aufklebt.

Hamster

2005-05-11, 15:11:04

Weder Intel noch AMD haben was dagegen, wenn ihre CPUs passiv gekühlt werden. Freigabe genug?

PowerPC ist keine schlechte Architektur und ich will auch gar nicht anzweifeln, daß die x86-kompatiblen CPU mehr Wärme erzeugen/erzeugt haben, jedoch läßt sich absolut *jeder* x86-kompatible Prozessor passiv kühlen. Mit einem entsprechenden Gehäusedesign ist das überhaupt kein Problem und Apple hat eben das entsprechende Gehäusedesign. Beim PC wird's wieder schwieriger, weil die Sachen genormt und standardisiert ist, da kann nicht einfach ein Hersteller über die Stränge schlagen und sich einen eigenen Formfaktor für ein bestimmtes Produkt ausdenken, der es erlaubt, das Teil passiv zu kühlen.

dell macht das z.b.
und im serverbereich so ziemlich alle. (aber das ist auch eine andere liga)

huha

2005-05-11, 15:19:40

dell macht das z.b.
und im serverbereich so ziemlich alle. (aber das ist auch eine andere liga)

Ja, Server und Notebooks sind eine andere Liga, da muß ja auch nicht großartig was aufgerüstet werden. Nur sind Server halt auf Ausfallsicherheit optimiert und nicht auf leise Kühlung und Notebooks müssen eben gerade noch so gekühlt werden bei möglichst kleinen Abmessungen.

-huha

Hamster

2005-05-11, 15:26:27

Ja, Server und Notebooks sind eine andere Liga, da muß ja auch nicht großartig was aufgerüstet werden. Nur sind Server halt auf Ausfallsicherheit optimiert und nicht auf leise Kühlung und Notebooks müssen eben gerade noch so gekühlt werden bei möglichst kleinen Abmessungen.

-huha

ich rede nicht von notebooks :|

und anscheinend hast du noch nie 'standard-desktop'-pcs von dell von innen gesehen, oder?

die haben einen eigenen formfaktor für boards und gehäuse. viele cpus werden durch dieses konzept passiv gekühlt (bzw vom netzteil oder vom gehäuselüfter mitgekühlt).

nur mal als beispiel, daß manche hersteller eben doch "über die Stränge schlagen"

HajottV

2005-05-11, 15:28:56

Altivec ist Leistungsfähiger, da die SIMD eigenständiger ist als SSE und, ich glaub, auch besseren Zugriff auf den Speicher hat.

Da ich Altivec nicht im Detail kenne, kann ich keine Beurteilung des Konzeptes machen - kann mir aber gut vorstellen, daß die Architektur auch da sauberer als SSE[2] ist.

"Besseren Zugriff auf den Speicher"... könntest Du da konkreter werden? Also mit SSE2 hat man einige Möglichkeiten, wie auf den Speicher zugegriffen wird (über den Cache, am Cache vorbei, aligned, unaligned)... konkret wüßte ich nicht, was man da noch besser machen könnte.

Achja. Altivec muss nicht mit 4x32bit float arbeiten. 4x32bit int und 16x8bit char geht, u.a., auch. ;) Ich glaube aber das kann auch SSE auch, oder?

Yap!

2x64 bit (double)
4x32 bit (float)
4x32 bit (signed/unsigned) int
8x16 bit (signed/unsigned) short
16x8 bit (signed/unsigned) char

Gruß

Jörg

huha

2005-05-11, 15:29:29

ich rede nicht von notebooks :|

und anscheinend hast du noch nie 'standard-desktop'-pcs von dell von innen gesehen, oder?

die haben einen eigenen formfaktor für boards und gehäuse. viele cpus werden durch dieses konzept passiv gekühlt (bzw vom netzteil oder vom gehäuselüfter mitgekühlt).

nur mal als beispiel, daß manche hersteller eben doch "über die Stränge schlagen"

Klar hab' ich solche Rechner schonmal gesehen, wollte aber nicht sooo arg darauf eingehen, weil die Dinger eben teilweise schon noch von den "Restriktionen" konventioneller Formfaktoren beeinflußt sind. Aber natürlich hast du recht, das woltle cih auch nie anzweifeln ;)

-huha

Hamster

2005-05-11, 15:38:12

Klar hab' ich solche Rechner schonmal gesehen, wollte aber nicht sooo arg darauf eingehen, weil die Dinger eben teilweise schon noch von den "Restriktionen" konventioneller Formfaktoren beeinflußt sind. Aber natürlich hast du recht, das woltle cih auch nie anzweifeln ;)

-huha

langsam wirds stark offtopic, aber diesen restriktionen muß apple auch folgen...

Gast

2005-05-11, 16:12:13

Und nein, ich nehme nicht die Apple-Zahlen sondern die auf www.spec.org veröffentlichten.
:|

Hat da Apple andere Zahlen? Das wäre ja eind Ding.

superdash

2005-05-11, 16:16:35

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

Gast

2005-05-11, 16:21:32

Öhm - klar liegt Windows bei der Auswahl an Programmen vorne.

Aber als Apple-User hat man da eigentlich normalerweise kaum Grund zur Klage. Es gibt eigentlich alles. Vieles auch kostenlos. Und sogar Office von Mircrosoft gibt es. Zudem lässt sich ziemlich viel aus der Linux-Welt an Programmen installieren.

Klar - es gibt auch Ausnahmen, z.B. gibt es für Architekten AFAIK nichts wirklich gutes (oder anerkanntes) - aber im grossen und ganzen ist die Situation schon ziemlich gut!

Ganon

2005-05-11, 17:15:12

@HajottV

http://en.wikipedia.org/wiki/AltiVec

Da steht eigentlich viel dazu. Auch ein Vergleich mit SSE2.

Ich weiß nicht mehr wo ich das andere gelesen habe, aber soweit ich das damals gelesen habe, ist die Speicheranbindung breiter und verfügt über mehrere Wege.

Kann aber auch sein, das ich jetzt irgendwas verwechsle. Deswegen nicht allzu auf die Goldwaage legen.

Das Hauptproblem bei Altivec ist, das man es schlecht mit Daten versorgen kann. Altivec ist viel zu schnell um einen ständigen Datennachschub zu liefern. Der G4 hat "nur" 166Mhz DDR-FSB und beim G5 reicht der Bus bei der Taktrate auch nicht mehr wirklich, wenn man zusätzlich noch die FPUs nutzen möchte, da die FPUs im G5 auch nicht von schlechten Eltern sind.

edit:
Apple hat auch nette BigNum-Bibliotheken für Altivec die bis zu 1024bit-Operationen erlauben.

GloomY

2005-05-11, 17:16:32

Hat da Apple andere Zahlen? Das wäre ja eind Ding.Zumindest waren bei der G5 Präsentation die von Apple zum Vergleich herangezogenen SPEC-Werte der x86 Systeme weit unter dem, was bei gleicher Hardware von anderen Herstellern an www.spec.org gemeldet wurde.

In dem angesprochenen kritischen Artikel

http://spl.haxial.net/apple-powermac-G5/

steht eben genau diese Diskrepanz. Ich habe die Werte nicht nachgeprüft, aber ich nehme mal an, dass diese stimmen. Ein kleiner Auszug
Dell Precision 650 (Pentium 4 Xeon 3.06 GHz)

Apple/Veritest SPEC.org Unterschied
SPECint_base 2000 836 1089 ~30%
SPECfp_base 2000 646 1053 ~63%Auch aus meinen Erfahrungen heraus kann ich nur sagen, dass für einen Xeon mit ~3 GHz die Apple-Ergebnisse viel zu niedrig sind. Irgendwas stimmt da nicht.

Ganon

2005-05-11, 17:20:38

@GloomY

Ich glaube die Werte von Apple kommen daher, weil mit dem GCC kompiliert wurde, und SPEC mit dem ICC.

Die Werte des G5 sind auch höher wenn man den IBM-Compiler nimmt. ;)

Ganon

2005-05-11, 17:31:29

Hier auch zwei (alte) Artikel zu dem Benchmark und dem G5. Nennen auch die Benchmark-Probleme, weil der GCC für die einzelnen Plattformen unterschiedlich weit ist.

http://www.heise.de/ct/03/15/062/
http://www.heise.de/ct/03/21/046/

BlackBirdSR

2005-05-11, 18:12:21

Auch aus meinen Erfahrungen heraus kann ich nur sagen, dass für einen Xeon mit ~3 GHz die Apple-Ergebnisse viel zu niedrig sind. Irgendwas stimmt da nicht.

Apple/Veritest used a special fast malloc library on the G5 benchmark, but did not use it on the Dell/Intel benchmark, thus giving the G5 an unfair advantage. Here is the relevant quote from the Veritest report:

"Installed a high performance, single threaded malloc library. This library implementation is geared for speed rather than memory efficiency and is single-threaded which makes it unsuitable for many uses. Special provisions are made for very small allocations (less than 4 bytes)."
(Page 5, also see Appendix E, Page 26, Veritest PDF)

Durch Tricks wie diesen.

Coda

2005-05-11, 18:45:51

Ganon

2005-05-11, 18:51:34

MMX, SSE/SSE2 und SSE3 sind zusammen deutlich flexibler als Altivec.

Außerdem bezweifel ich jetzt einfach mal dass der G5 eine extra FPU Einheit für Altivec hat.

Habe ich behauptet das es nicht so ist? Ich sagte nur Altivec sei deutlich Leistungsfähiger.

Und wo steht das der G5 ne extra FPU "für" Altivec hat. Ich verstehe den Satz jetzt nicht. Der G5 hat 2 FPUs die komplett unabhängig von Altivec sind.

Coda

2005-05-11, 18:57:38

Ich sagte nur Altivec sei deutlich Leistungsfähiger.Als SSE auf welcher CPU?

Sorry, aber du kannst das so nicht vergleichen. Ich glaube auch kaum, dass ein G5 einen höheren SIMD Throughput hat als ein Athlon 64.

Ganon

2005-05-11, 19:04:32

Wie gesagt, kann ich jetzt wieder mit RC72 kommen. Ist auch schon auf SSE optimiert.

Hast du andere "Bench-Software" für Vector-Einheiten, die nicht in einem Compiler-Qualitätstest enden?

Coda

2005-05-11, 19:08:45

BlackBirdSR

2005-05-11, 19:16:18

Von der Architektur sind SSE und Altivec beides 4x32bit Floating Point Operationen (Add, Mul, etc.). Altivec an sich ist kein Vorteil von PowerPC.

DIe Implementation macht es halt.
Im Gegensatz zum P3/K7/K8 setzt Altivec auf spezielle SIMD FUs.
Die x86 nutzen (Prescott als Fragezeichen mal ausgeschlossen) hierzu ihre FPUs.

Dazu kommen 32 128Bit Altivec Register gegenüber 8(16) bei x86
Die beiden (4) FUs können dazu insgesamt theoretisch an 2 128Bit Vektoren arbeiten, da beide fully pipelined und unabhängig sind.
ALU Operationen und Permutation/Speicheroperationen.

Die x86 brechen ihre 128Bit Vektoren in 2x64Bit auf, und können auch nur an einem 128Bit Paket arbeiten.

Theoretisch gesehen hat Altivec damit Vorteile.
Natürlich gibt es auch wieder haufenweise Engstellen, die Altivec nicht ganz so effektiv machen wie man theoretisch meinen könnte.
Großer Vorteil (eben auch für RC) ist hier, dass man Altivec FUs sowie ALU und FP unabhängig von einander gleichzeitig nutzen kann.
Richtig optimiert ergeben sich somit für spezielle Fälle sehr hohe Durchsätze.

Gast

2005-05-11, 19:16:24

Ist es nicht sinnvoller die CPUs anhand von echten Programmen auf Mac und PC zu testen anstatt über theoretische Werte zu diskutieren?

Bei solchen Vergleichen schneidet meist AFAIR der Mac schlecht(er) ab. So ist es zumindest bei mir hängen geblieben. Insbesondere habe ich da DVD-Shrink-ähnliche Anwendungen in Erinnerung, wo ein vergleichbarer Mac einem PC deutlich hinterherhinkt.

Nur dann kommt immer der typische Satz: Ist nicht für G5 optimiert!

Selbst wenn - OSX gibt es wie lange schon? 5 Jahre? Wenn man dann keine Optimierung hinbekommt... dem Anwender nützt es ja nichts, wenn man sagen kann, daß Programm X viel schneller laufen könnte aber es nicht so ist.

Photoshop sah damals AFAIR in einem c't Test glaube ich auch eher schlecht für den Mac aus - trotz angeblicher Optimierung (habe das so in Erinnerung).

Allgemein werden da dann häufig 2 CPU Systeme (Macs) gegen 1 CPU System getestet (PC) - und trotzdem liegt der PC häufig vorne.

Und nein ich meine nicht den Workflow von OSX - der vielleicht wirklich besser sein mag als von Windows - das ist was anderes.

Coda

2005-05-11, 19:19:46

DIe Implementation macht es halt.Ja natürlich, darauf wollte ich eigentlich auch hinaus. Bei so Sätzen wie "Altivec ist leistungsfähiger als SSE" stehen mir die Nackenhaare zu Berge.

Großer Vorteil (eben auch für RC) ist hier, dass man Altivec FUs sowie ALU und FP unabhängig von einander gleichzeitig nutzen kann.
Richtig optimiert ergeben sich somit für spezielle Fälle sehr hohe Durchsätze.Da wünsch ich dem Compiler auf jeden Fall mal viel Spaß dabei ;)

Ganon

2005-05-11, 19:20:39

Weil RC72 schneller ist heißt dass noch lange nicht, dass der G5 überall schneller ist. Man könnte wohl genauso andere Fälle erzeugen wo genau das Gegenteil gilt.

Von der Architektur sind SSE und Altivec beides 4x32bit Floating Point Operationen (Add, Mul, etc.). Altivec an sich ist kein Vorteil von PowerPC.

Ich bin auch nicht auf meine Meinung eingeschossen. Wenn du mir ein Programm/Benchmark zeigst, welche das Gegenteil zeigt, will ich es glauben. Bloß der Unterschied bei RC72 ist schon extrem. Daher mein Standpunkt.
Das Problem ist, einen anderen Benchmark zu finden, wo nicht der Compiler, bzw. die Portierungsqualität entscheidet.

Bei RC72 ist es allgemein bekannt das man viel Arbeit in die SSE-Optimierung gesetzt hat. Es brachte auch über das doppelte an Performance.

Sagte ich auch nicht das Altivec ein PowerPC-Vorteil ist. Es war sogar mal bei AMD im Gespräch, statt SSE (oder 3DNow? weiß grad nicht) einfach Altivec zu nehmen. Man hat sich dann aber für SSE (bzw. 3DNow) entschieden.

Coda

2005-05-11, 19:21:53

Altivec im x86 macht überhaupt keinen Sinn. Das ist PowerPC spezifisch, schon allein vom Befehlsformat.

Außerdem verstehst du immer noch nicht auf was ich hinaus will. Altivec ist vielleicht schneller weil der G5 extra SIMD Einheiten hat, aber nicht wegen Altivec an sich.

Im Gegenteil, SSE/SSE2 ist der flexiblere Befehlssatz (bis auf die Registerzahl)

Ganon

2005-05-11, 19:27:48

Ja natürlich, darauf wollte ich eigentlich auch hinaus. Bei so Sätzen wie "Altivec ist leistungsfähiger als SSE" stehen mir die Nackenhaare zu Berge.

Reden wir von Papier-Konzepten, oder von echt vorhandenen SIMD-Einheiten?

@Gast

Gerade im MPEG2 en/decoding gibt es viele verschiedene Programme die allesamt unterschiedlich schnell sind.

Hab mal durchgetestet, mit den selben Einstellungen.

Programm A macht 3fps/s und Programm B mit 30fps/s.

Problem ist nur, wenn man halt nur Programm A benutzt und mit einem "B"-Programm des anderen Systems testet...

Gast

2005-05-11, 19:31:16

Also ich habe da sowas in Erinnerung mit einem Programm ähnlich DVD-Shrink (ist also kein MPEG2 encoding). Ich glaube DVD2One nennt sich das (oder so ähnlich). Gibt es sowohl für PC als auch Mac. Und da war der Unterschied abartig.

Allgemein habe ich in Erinnerung, daß der Mac meist schlechter Aussieht (trotz zweier CPUs), wenn ich Vergleiche sehe. Abgesehen von denen auf Apple.de

Kann aber sein, daß ich das nur falsch in Erinnerung habe.

Was aussagekräftiges wäre jedenfalls nicht schlecht -> seriöser Link

Ganon

2005-05-11, 19:39:33

Allgemein habe ich in Erinnerung, daß der Mac meist schlechter Aussieht (trotz zweier CPUs), wenn ich Vergleiche sehe. Abgesehen von denen auf Apple.de

Wie gesagt. Muss man das Programm kennen.

Denn folgendes müsste geklärt werden:
- nutzt es überhaupt 2 CPUs?
- nutzt es SIMD? Wenn ja, wo?
- weitere Umgebungswerte

Denn man kann ja z.B. leicht sagen: "Auf PC besiegt ein Penitum4 gleich 2 G5". Ist denn nur blöde, wenn das Programm sowieso nur eine CPU nutzt.

Klar findest du überall Sachen, wo der Mac langsamer ist. Aber wie gesagt reden wir hier nur über CPUs. Linux und NetBSD laufen auch auf einem G5. ;)

Warum z.B. Doom3 auf einem Mac langsamer läuft wurde auch von den Entwicklern genannt. Schlechterer Compiler und weniger SIMD-Code. Also an der CPU liegt es nicht unbedingt.

Gast

2005-05-11, 19:55:59

Nur ich bin einfach mal davon ausgegangen: Auf den meisten x86 läuft Win - und auf den meisten Macs OSX.

Und dann einfach mal von den Programmen asgehen, die der Anwender nützt. Dem Anwender kann ja letztendlich egal sein, ob ein Programm von mehreren CPUs gebrauch macht, ob es optimiert ist usw.

Für ihn zählt ja nur das was ist - und nicht das was sein könnte, wenn... dies und jenes wäre. Das nützt ihm nichts.

Klar du hast recht. Es geht um CPUs. War halt nur eine andere Betrachtungsweise.

Ganon

2005-05-11, 20:15:11

Klar du hast recht. Es geht um CPUs. War halt nur eine andere Betrachtungsweise.

Sicher. Hast ja auch Recht.

Nur beim Mac ist das was wieder was anderes. Einen Mac kauft man sich meist wegen OS X und nicht wegen der Prozessor-Performance. Oder warum meinst du ist der MacMini und der iMac so erfolgreich? ;) Beides keine Prozessorgranaten.

@Coda

Dann hättest du das früher sagen sollen. Da ich oben ja schon zu Altivec sagte: "eigenständiger" und "bessere Speicheranbindung", meinte ich halt Altivec in den bisherigen CPUs. Denn beide Punkte haben auch nichts mit Altivec, wie du es meinst, zu tun.
Du hast ja anscheinend nur von der Registernansammlung gesprochen (;)).

Übrigends gibt es Altivec genau genommen nur im G4. Der G5 hat nur eine kompatible Einheit namens VMX (darum sagt Apple auch nur "Velocity Engine", da IBM keine Rechte an "Altivec" hat, soweit ich weiß). IBM sagte mal das VMX2 bereits fertig ist aber erst mit der 65nm-Technologie (oder kleiner) verbaut werden kann. Soll mit 256bit-Registern daher kommen.

Mal sehen was daraus wird.

Coda

2005-05-11, 20:18:36

Dann sag auch "der G5 hat eine bessere SIMD Leistung" und nicht "Altivec ist besser". Das ist ein großer Unterschied.

Wobei ich das wohl auch nur in Ausnahmefällen so ist.

Ganon

2005-05-11, 20:38:27

Wobei ich das wohl auch nur in Ausnahmefällen so ist.

Ja. Immer da wo der bessere Compiler/Programmierer am Werk war.

Das PowerPCs nur mit IBM-Compilern und x86 nur mit Intel-Compilern wirklich gut sind, ist ja bekannt.

Problem ist nur, das unter OS X/Linux/BSD der GCC verwendet wird, damit die Kompatibilität zu OpenSource-Programmen bleibt. Und GCC und PowerPC sind zur Zeit nicht wirklich gut. Und der IBM-Compiler kommt nicht sehr oft zum Einsatz. Eigentlich fast nur bei IBMs eigener Software. Intels Compiler wird da schon häufiger eingesetzt.

Coda

2005-05-11, 22:16:28

Ganon

2005-05-11, 22:26:18

GCC 4.0 produziert hervorragenden Code, nur bei der Autovektorisierung hapert's noch ein wenig.

Bei normalen Applikationen ohne Floating Point denke ich nicht dass Intel C++ oder der IBM Compiler noch besser sind.

Mag sein. Nur ist der GCC 4 erst seit ein paar Tagen raus. ;) AutoVec kommt "offiziell" auch erst in GCC 4.1. In GCC 4.0 ist halt schon mal das Grundgerüst da mit ein paar Funktionen.

Sicher, bei normalen Applikationen nicht. Diese rechnen auch meist nicht wirklich viel.

Aber in Spielen und anderen Mathe-Sachen, denke ich schon. Im Fall Doom3@OSX, wurde einigen % der 20% weniger Leistung dem GCC 3 in die Schuhe geschoben.

Mal sehen was GCC 4 bringt.

Coda

2005-05-11, 22:27:45

Also D3 wurde wahrscheinlich mit Visual Studio .NET 2003 kompiliert und der generiert schlimmeren Code als GCC.

Ich bin mir da aber nicht ganz sicher. Zumindest die alten Quakes waren immer MS Kompilate.

Also ich hab mal nachgeschaut, in der Executable gibt's zumindest Referenzen zur MS Runtime Library.

stav0815

2005-05-12, 07:27:29

Shink

2005-05-12, 08:37:06

Wenn ich mich richtig erinnere, dann gibt es doch in Altivec im Vergleich zu SSE ein paar Vorteile in Bezug auf beliebigen Zugriff auf gepackte Werte, was zumindest die Arbeit von AutoVec erleichtern SOLLTE, oder?

Ganon

2005-05-12, 09:27:47

Hmm. Ich müsste mir wirklich mal SSE programmiertechnisch angucken. ;)

Wie gesagt, nur ein Beispiel für Altivec. Ich kenne es bisher nur so. So der Altivec-Programmiercrack bin ich auch nicht. ;)

int main()
{
union nVec
{
float f[4];
vector float v;
}

nVec fVec;
fVec = (vector float){1.0,2.0,3.0,4.0};

...
// f[0] == 1.0
// f[3] == 4.0

}

Eine andere Möglichkeit auf die Werte zuzugreifen kenne ich nicht. Wie das bei SSE ist weiß ich, wie gesagt, nicht. Oder ob ich dich jetzt falsch verstanden habe, weiß ich auch nicht. ;) SSE-Leute sind jetzt gefragt. *gg*

Shink

2005-05-12, 09:50:58

Und wie bekomm ich z.B. einen Wert wieder raus?
Bei SSE (zumindest SSE 1) kann man sich z.B. nur den Wert an der ersten Stelle des Vektors auspacken; ansonsten muss man eben den Vector so mischen, dass man den gewünschten Wert an der ersten Stelle hat.
Fürs mischen hat man aber nur ein paar mehr oder weniger fix verdrahtete Permutationen zur Verfügung, sodass man in manchen Fällen sehr viel mischen muss. Das selbe tritt natürlich auch bei anderen Vektorberechnungen auf.
Klar: Die Mischoperationen dauern nicht allzu lange und meist kümmert sich vermutlich der Compiler darum. Trotzdem könnte das zu einem Vorteil für Altivec führen.

Exxtreme

2005-05-12, 09:59:48

Nein, weil Firewire:

a) von Anfang an für Daten Transfer konsipiert wurde, USB nur als ANschluss für Eingabegeräte und ähnlichem
b) weils etwas vom SCSI Protokoll mitbekommen hat
c) weil man munkelt, das Feuerdraht intelligenter (=teurer) als USB ist.

Intel und MS haben USB nur deshalb rausgebracht weil Apple für Firewire Lizenzgebühren verlangt.

Und ich persönlich bin von USB sehr enttäuscht. Mich interessiert nicht was in der Theorie möglich ist sondern das, was in der Praxis abläuft. Schon mal USB-Geräte an USB-Hubs betrieben? Viel Spass. Entweder werden die nicht erkannt oder nur unter Windows etc. Ich habe mich immer gewundert warum die Chipsätze immer mehrere unabhängige USB-Channels haben obwohl theoretisch einer ausreichen würde, den man dann teilen könnte. Es liegt wohl an den Endgeräten, die mit USB-Hubs nicht zurechtkommen.

Hamster

2005-05-12, 10:05:55

Gast

2005-05-12, 10:07:49

Wieso? FW400 hat auf dem Blatt Papier weniger Bandbreite als USB 2.0 -> in der Praxis ist es aber eher umgekehrt.

Und FW800 geht richtig ab, wa aber AFAIK bisher nur die PowerMacs haben.

Für optische Lauferrke ist IMHO die Zukunft externe Sata-II Stecker.

Exxtreme

2005-05-12, 10:08:20

schonmal an den vorteil der bandbreite gedacht?
Was brauchen Maus und Tastatur für Bandbreite?

Ausserdem bietet spätestens USB2 erstmal genug Bandbreite für Endgeräte.

Hamster

2005-05-12, 10:16:46

Was brauchen Maus und Tastatur für Bandbreite?

Ausserdem bietet spätestens USB2 erstmal genug Bandbreite für Endgeräte.

nein, laß ich nicht gelten. es gibt noch weit mehr endgeräte als ne maus und tastatur (für die es sicherlich reichen würde).

achja? genug bandbreite? es mag vielleicht nicht am laufenden band vorkommen, aber man möchte zb. schonmal ganz gerne den externen dvd brenner anschmeissen, und während man auf die cd/dvd wartet mal schnell was einscannen/drucken/daten sichern auf externe platte/ usbstick/ etc...

bandbreite kann man nie genug haben, und im falle von usb 2.0 kann man mittlerweile durchaus schonmal von einer limitierung sprechen. moderne externe festplatten kann man zb. schon gar nicht mehr ausreizen.

ganz zu schweigen davon, daß von den theoretischen 480mbit/s gut und gerne nur 280mbit/s über bleiben. und dann willst du diese bandbreite mit allen geräten teilen? ernsthaft?

Exxtreme

2005-05-12, 10:23:40

nein, laß ich nicht gelten. es gibt noch weit mehr endgeräte als ne maus und tastatur (für die es sicherlich reichen würde).

achja? genug bandbreite? es mag vielleicht nicht am laufenden band vorkommen, aber man möchte zb. schonmal ganz gerne den externen dvd brenner anschmeissen, und während man auf die cd/dvd wartet mal schnell was einscannen/drucken/daten sichern auf externe platte/ usbstick/ etc...

bandbreite kann man nie genug haben, und im falle von usb 2.0 kann man mittlerweile durchaus schonmal von einer limitierung sprechen. moderne externe festplatten kann man zb. schon gar nicht mehr ausreizen.

ganz zu schweigen davon, daß von den theoretischen 480mbit/s gut und gerne nur 280mbit/s über bleiben. und dann willst du diese bandbreite mit allen geräten teilen? ernsthaft?
Dann müssten 2 USB-Channels reichen, nicht? Ein Channel für Massenmedien, der andere für Eingabegeräte. Aber die heutigen Chipsätze haben um die 6 Channels. Und das sicherlich nicht weil 2 Channels zu wenig Bandbreite bieten.

Hamster

2005-05-12, 10:30:01

Dann müssten 2 USB-Channels reichen, nicht? Ein Channel für Massenmedien, der andere für Eingabegeräte. Aber die heutigen Chipsätze haben um die 6 Channels. Und das sicherlich nicht weil 2 Channels zu wenig Bandbreite bieten.

stümmt, 2 würden wohl reichen, aber ob ich weitere channels oder 'verteiler' realisiere spielt bei usb preislich eigentlich keine rolle. und dann doch lieber die 1. variante, oder?

und 12 usb anschlüsse klingt nach viel, ist es aber imo nicht. mein hauptpc mit 8 usb anschlüssen ist voll belegt. und hier stehen bestimmt nochmal weitere 5 usb geräte rum, die ich anschliessen könnte...

€dit: allerdings bin ich wie paynie auch dafür firewire mit in den chipsatz zu integrieren. ieee1394 rock0rt ;)

No.3

2005-05-12, 10:40:05

Dann müssten 2 USB-Channels reichen, nicht? Ein Channel für Massenmedien, der andere für Eingabegeräte. Aber die heutigen Chipsätze haben um die 6 Channels. Und das sicherlich nicht weil 2 Channels zu wenig Bandbreite bieten.

und trotzdem habe ich auf meinem Asus Board A7N8X Probleme wenn ich mehrere USB-Geräte in Verschiedenen USB-Channeln drin hab. Es macht sogar einen Unterschied ob bei den "zusammengehörenden" USB-Ports den "Oberen" oder den "unteren" nehme ! :eek: :confused:

Rainer

Exxtreme

2005-05-12, 10:45:37

und trotzdem habe ich auf meinem Asus Board A7N8X Probleme wenn ich mehrere USB-Geräte in Verschiedenen USB-Channeln drin hab. Es macht sogar einen Unterschied ob bei den "zusammengehörenden" USB-Ports den "Oberen" oder den "unteren" nehme ! :eek: :confused:

Rainer
Das meine ich. Die Endgeräte halten sich nicht oft an die USB-Standards weil man ein Paar Cent in der Herstellung sparen wollte. Versucht mal mit einer USB-Tastatur mal ins BIOS zu kommen wenn diese an einem USB-Hub hängt. ;)

HajottV

2005-05-12, 10:50:26

Ganon@work

2005-05-12, 10:51:31

Und wie bekomm ich z.B. einen Wert wieder raus?

Das meine ich ja.

fVec.f[0] hat den Wert vom ersten Vector-Element.

fVec.f[1] hat den Wert vom zweiten Vector-Element.

fVec.f[2] hat den Wert vom dritten Vector-Element.

fVec.f[3] hat den Wert vom vierten Vector-Element.

Schreiben über fVec.f[x] geht auch.

No.3

2005-05-12, 10:54:07

Das meine ich. Die Endgeräte halten sich nicht oft an die USB-Standards weil man ein Paar Cent in der Herstellung sparen wollte. Versucht mal mit einer USB-Tastatur mal ins BIOS zu kommen wenn diese an einem USB-Hub hängt. ;)

jo, das ist echt lustig, wenn ich vorne am Rechner mein Memory-Stick einstecke und dann hinten mein USB-WLan-Adapter "rausfliegt" d.h. den Betrieb einstellt :eek: :confused:

Rainer

Shink

2005-05-12, 11:04:07

q@w

2005-05-12, 11:14:08

Ich habe mich immer gewundert warum die Chipsätze immer mehrere unabhängige USB-Channels haben obwohl theoretisch einer ausreichen würde, den man dann teilen könnte. Es liegt wohl an den Endgeräten, die mit USB-Hubs nicht zurechtkommen.
Oder daran, daß ein USB1.1-Gerät den gesamten Bus, an dem er hängt, auf 1.1 ausbremst. Und da diese Geräte recht verbreitet sind und nicht jeder mehrere Hubs auf dem Schreibtisch mag, nimmt man wohl wohl oder übel in Kauf, mehrere Hubs direkt zu integrieren.

Weiters mag auch das Wettrüsten eine Rolle spielen. Wenn Boards sich leistungsmäßig kaum noch unterscheiden, nehme ich evtl. eher das, was mir möglichst viele weitere Kosten erspart, wie bsw. externe USB-Hubs. (auch wenn das logisch gesehen, zu kurz gedacht ist)

HajottV

2005-05-12, 11:20:32

Die x86 brechen ihre 128Bit Vektoren in 2x64Bit auf, und können auch nur an einem 128Bit Paket arbeiten.

Das ist genau der Punkt mit SSE/SSE2 - zumindest beim P4. (Ich muß das mal auf meinem AMD64 testen, wie sich das da verhält.)

Intel ist nämlich beim P4 auf die glorreiche Idee gekommen, die MMX-Einheit komplett zu verkrüppeln - nachdem sie MMX vorher extrem gehypt haben. Beim P4 existiert nur noch eine MMX-Einheit, die darüberhinaus ein 2/2 Verhalten (in Bezug auf Latenz/Durchsatz) hat. Damit kann man MMX auf dem P4 quasi vergessen. Die ALUs sind ja double-pumped und können 2 µ-Ops pro Takt durchführen. D.h. selbst, wenn man auf 4 16 Bit-Werten parallel rechnet, erzielt man keinen Geschwindigkeitsgewinn. Bei 2 32-Bit Werten verliert man um den Faktor 2 (!!!) gegenüber den ALUs. Lediglich bei der parallelen Berechnung von acht 8-Bit Werten bringt das noch was.

Bei SSE[2] wurden die Register verdoppelt, leider wurde das 2/2 Verhalten beibehalten, so daß sich die meisten Integer-Berechnungen in den SSE-Registern nicht lohnen. Bleiben also lediglich die Float/Double-Berechnungen, wo SSE[2] Sinn macht. Die sind allerdings sehr schnell.

Ich hab vor Kurzem mal aus Spaß XTEA (ein Kryptographie-Verfahren) in SSE2 programmiert... hat gegenüber der unparallelisierten Version gerade mal 5% Gewinn gebracht. Und das liegt ganz sicher nicht daran, daß ich das schusselig (*) implementiert habe, sondern einfach daran, daß man mit den extrem optimierten 2µ-ops/Takt-ALUs konkurrieren muß. Bei XTEA und SSE2 konnte ich in jedem Schritt zwar 4 Blöcke parallel bearbeiten... die ALU läuft aber effektiv 4x so schnell wie die SSE2-Einheit (wenn es um Integer-Berechnungen geht), damit verpuffte der Gewinn durch die Parallelität.

Gruß

Jörg

(*) Das ist ein XTEA Halbschritt bei mir. Schneller geht's nicht.

movdqa xmm3, xmm2 // z
movdqa xmm4, xmm2 // z

pslld xmm3, 4 // z << 4
psrld xmm4, 5 // z >> 5

pxor xmm3, xmm4 // (z << 4 ^ z >> 5)
paddd xmm3, xmm2 // (z << 4 ^ z >> 5) + z

pxor xmm3, [ebx] // ^ (sum + k[___])
paddd xmm0, xmm3 // y += ...

HajottV

2005-05-12, 11:30:57

@HajottV: Ja, quasi schon. Aber nicht mit einem einzigen shufps. Angenommen ich hab 3 gepackte Vektoren s1, s2, s3. Wie bekomme ich z.B. "g1 = {s1[1], s2[3], s2[1], s3[3]}"? Dafür muss ich zusätzliche SSE-Register beladen und herumshuffeln. Wenn es für Ganons Aussage tatsächlich AltiVec-Befehle gibt (könnte ja theoretisch der Compiler machen), dann wär das schon ein Vorteil für AltiVec?

Hi,

das ist richtig, wenn man so 'rumshuffelt' (*), muß man bei SSE ein bisschen Arbeit investieren. Allerdings muß ich sagen, daß ich bis jetzt noch nie einen Fall hatte, wo das Shuffle wirklich das Problem war. Bisher war es immer so, daß ich durch (z.T. allerdings viel) Nachdenken die Berechnung so organisieren konnte, daß die Umorganisation mit einem Befehl ging. Das eigentliche SSE2-Problem habe ich in einem anderen Posting beschrieben.

Gruß

Jörg

(*) Bäh, wat'ne Wortkreation!

Shink

2005-05-12, 11:54:44

Für mich sind Shuffles fast das einzige, was ich mit SSE-Programmierung in Verbindung bringe. Ich hab mal mitgearbeitet an einer Vektorisierung eines biorthogonalen Filters für JPEG2000. Ungefähr 70% meines Codes sind shufps. Aber der Speedup ist natürlich brauchbar, da es eben Float-Berechnungen sind.

BlackBirdSR

2005-05-12, 12:24:32

Die ALUs sind ja double-pumped und können 2 µ-Ops pro Takt durchführen.
Ich hab vor Kurzem mal aus Spaß XTEA (ein Kryptographie-Verfahren) in SSE2 programmiert... hat gegenüber der unparallelisierten Version gerade mal 5% Gewinn gebracht. Und das liegt ganz sicher nicht daran, daß ich das schusselig (*) implementiert habe, sondern einfach daran, daß man mit den extrem optimierten 2µ-ops/Takt-ALUs konkurrieren muß. Bei XTEA und SSE2 konnte ich in jedem Schritt zwar 4 Blöcke parallel bearbeiten... die ALU läuft aber effektiv 4x so schnell wie die SSE2-Einheit (wenn es um Integer-Berechnungen geht), damit verpuffte der Gewinn durch die Parallelität.

[/CODE]

Die beiden FAST-ALUs des Willy/NW können nur ganz spezielle ALU Befehle in einem halben Takt berechnen. Von 2Ops/Takt sind hier durchaus Utopie.
Bei Prescott gibt es Anzeichen, dass die Latenz einer Fast-ALU Operation sogar auf 1 Takt angehoben wurde.

So genial schnell ist die ALU Konstruktion also nicht.
Technisch sicherlich sehr interessant und modern. Praaktisch aber nicht so überlegen wie man meinen könnte.

Gast

2005-05-12, 13:27:52

Die beiden FAST-ALUs des Willy/NW können nur ganz spezielle ALU Befehle in einem halben Takt berechnen. Von 2Ops/Takt sind hier durchaus Utopie.
Bei Prescott gibt es Anzeichen, dass die Latenz einer Fast-ALU Operation sogar auf 1 Takt angehoben wurde.

So genial schnell ist die ALU Konstruktion also nicht.
Technisch sicherlich sehr interessant und modern. Praaktisch aber nicht so überlegen wie man meinen könnte.

Hi,

2µ-Ops/Takt gilt für folgende Befehle:

ADD
OR
XOR
CMP
TEST
DEC
INC
MOV
NEG
Jcc

Das sind die mit Abstand wichtigsten Befehle; sie machen vielleicht 80% (hab ich jetzt mal so geschätzt, aber wenn es unbedingt nötig sein sollte, kann ich das ja mal überprüfen) des Codes aus.

Ich bin wirklich kein P4-Fan, aber die ALUs sind rattenschnell beim P4. Leider ist das Konzept insgesamt dennoch ziemlich verkorkst.

Um die Frage "überlegen oder nicht" ging es mir nicht... ich wollte nur klarmachen, daß Integer-SSE bzw. MMX auf dem P4 fast keinen Sinn mehr macht.

Gruß

Jörg

HajottV

2005-05-12, 13:28:33

Das letzte Posting war von mir.

Gruß

Jörg

Grestorn

2005-05-12, 14:34:45

Das meine ich. Die Endgeräte halten sich nicht oft an die USB-Standards weil man ein Paar Cent in der Herstellung sparen wollte. Versucht mal mit einer USB-Tastatur mal ins BIOS zu kommen wenn diese an einem USB-Hub hängt. ;)Kein Problem...

Das einzige Problem, das ich hin und wieder habe, ist dass einige Geräte zu viel Spannung ziehen.

Derzeit an meinem Rechner über USB:

USB 1.1 Hub (Tastatur, Maus (Logitech Bluetooth), HBCI Kartenlesen & Tastatur, Drucker), Gamepad, MDA II Docking Station, Phatnoise Docking Station

All dies ohne größere Probleme... Nur die MDAII Docking Station zieht ab und an etwas zu viel Strom (lädt das MDA II über USB).

BlackBirdSR

2005-05-12, 16:43:19

Hi,

2µ-Ops/Takt gilt für folgende Befehle:

ADD
OR
XOR
CMP
TEST
DEC
INC
MOV
NEG
Jcc

Das sind die mit Abstand wichtigsten Befehle; sie machen vielleicht 80% (hab ich jetzt mal so geschätzt, aber wenn es unbedingt nötig sein sollte, kann ich das ja mal überprüfen) des Codes aus.

Ich bin wirklich kein P4-Fan, aber die ALUs sind rattenschnell beim P4. Leider ist das Konzept insgesamt dennoch ziemlich verkorkst.

Um die Frage "überlegen oder nicht" ging es mir nicht... ich wollte nur klarmachen, daß Integer-SSE bzw. MMX auf dem P4 fast keinen Sinn mehr macht.

Gruß

Jörg

Beisst sich mit den 0.45 Ops/Cycle die ein P4 in SpecInt erreicht ;)
Soweit ich weiss, können die FAST_ALUs hauptsächliche bestimmte Befehlsfolgen schnell durchführen, nicht die Befehle an sich.

Müsste man mal genauer untersuchen.
Aber 2Ops/Takt Durchsatz bekommst du nur in Ausnahmefällen hin, und dann auch nicht durchgehend. Mehr als 3Ops/Takt sind sowieso über dem Limit der CPU

Ganon

2005-05-12, 17:11:46

Hi.

Habs jetzt noch mal ausprobiert und mal ein bisschen erweitert.

#include <iostream>

union nVec
{
float f[4];
vector float v;
};

void zeigeVec(nVec &Vec)
{
std::cout << Vec.f[0] << " "
<< Vec.f[1] << " "
<< Vec.f[2] << " "
<< Vec.f[3] << " "
<< std::endl;
}

int main()
{
nVec fVec,xVec;

fVec.v = (vector float)(1.0,2.0,3.0,4.0);
xVec.v = (vector float)(5.0,6.0,7.0,8.0);

zeigeVec(fVec);

xVec.v = vec_add(fVec.v,xVec.v);

zeigeVec(xVec);

xVec.f[0] += 1.5;
xVec.f[1] += 1.5;
xVec.f[2] += 1.5;
xVec.f[3] += 1.5;

zeigeVec(xVec);

xVec.v = vec_sub(xVec.v,fVec.v);

zeigeVec(xVec);

}

Ausgabe:

1 2 3 4
6 8 10 12
7.5 9.5 11.5 13.5
6.5 7.5 8.5 9.5

"printf" ist auch in der Lage die Vectoren so anzuzeigen. Ich habe es nur mit cout gemacht, weil ich halt das Auslesen der Werte zeigen wollte.

Shink

2005-05-13, 09:14:02

@Ganon: Wie gesagt könnte das jetzt aber auch theoretisch der Compiler in etwas ganz anderes übersetzt haben. So könnte es sein, das zwischen float f[] und vector float v immer übersetzt wird, wenn man auf f[] zugreift, was natürlich auch mit SSE möglich ist.
Meine Frage wär, ob es AltiVec-Assemblerbefehle für so etwas wie "float x = read(2,v)" oder "store(3, v, x)" gibt. Jetzt siehts ja eher aus wie "float f[] = readAll(v); x = f[2]" oder "float f[] = readAll(v); f[3] = x; v = (vector float) f".
Ich hoffe, ihr wisst, was ich meine...

HajottV

2005-05-13, 12:05:08

Beisst sich mit den 0.45 Ops/Cycle die ein P4 in SpecInt erreicht ;)
Soweit ich weiss, können die FAST_ALUs hauptsächliche bestimmte Befehlsfolgen schnell durchführen, nicht die Befehle an sich.

Müsste man mal genauer untersuchen.
Aber 2Ops/Takt Durchsatz bekommst du nur in Ausnahmefällen hin, und dann auch nicht durchgehend. Mehr als 3Ops/Takt sind sowieso über dem Limit der CPU

Nein, beißt sich nicht unbedingt. Der P4 hat eine extrem tiefe Pipeline. Wenn die Pipeline gefüllt werden muß, dann dauert das Ewigkeiten. So was wirkt sich natürlich dann auf die resultierenden Ops/Takt aus.

Du hast aber recht: Es gibt Umstände, unter denen es zu Stalls kommt... und dann ist nix mit 2 µ-Ops/Takt. Doch ist es in der Regel schon so, daß die oben genannten Befehle in 0.5/0.5 ausgeführt werden.

Gruß

Jörg

BlackBirdSR

2005-05-13, 12:33:35

Du hast aber recht: Es gibt Umstände, unter denen es zu Stalls kommt... und dann ist nix mit 2 µ-Ops/Takt. Doch ist es in der Regel schon so, daß die oben genannten Befehle in 0.5/0.5 ausgeführt werden.

Gruß

Jörg

Für deie Spezialanwendungen vielleicht schon.
Aber für den Normalfall bei standard applikationen und Berechnungen wie sie wohl in 85% der Fälle vorkommen, sakt die Perfomance eben weit unter das Maximum.

Sieht man wie gesagt z.B an SpecInt.

Vasco

2005-05-14, 20:30:11

Muh,

mal ein paar Infos:

x86-Architektur (bis i586 (P55C aka Pentium MMX)):

8x 32bit GPRs
- EAX, EBX, ECX, EDX, ESI, EDI für Arithmetische Berechungen, Variablen etc.
- EBP, ESP, EIP für Pointer
5x 16bit Segment Register:
- CS, DS, ES, FS, GS, SS für Segmentselektoren in der GDT/LDT

8x 80bit FP-Register
- ST0..ST7 für 32bit (FLOAT), 64bit (DOUBLE) und 80bit (EXTENDED) Berechunungen

plus diverse Flag-Register (EFLAGS) und Model-Specific Registers (MSRs ab Pentium)

Ab dem Pentium-Pro/PII (i686) werden diese wenigen Register auf ein wesentlich grösseres Shadow-Registerfile abgebildet (damit Out-Of-Order Execution auch funktioniert). Der Programmierer kann diese nicht direkt ansprechen.

Nun zu den SIMD-Erweiterungen:

MMX (ab P55C) aliased 8x 64bit Register MM0..MM7 auf den 80bittigen FPU-Registern und ermöglicht es 8x 8bit BYTEs, 4x 16bit WORDs oder 2x 32bit DWORDs parallel zu verarbeiten.

Es ist entweder FP ODER (Integer) MMX möglich - aber nicht beides gleichzeitig.

3DNow! (ab K6) ermöglicht auf diesen MM-Registern zusätzlich 2x 32bit FLOATs (nach IEEE754).

SSE (ab P3/Athlon XP) enthält 8x 128bittige Register XMM0..XMM7 in einer neuen Funktionseinheit.
Dort sind 4x 32bit FLOATs pro Register unterbringbar für SIMD-Berechnungen. Alternativ kann man durch skalare Operationen nur das unterste Element benutzen. Dies ist primär dafür gedacht die total bekloppte stackbasierte (Stack in einem Registerfile!!) x87-FPU zu ersetzen.
Skalarer SSE Code is wesentlich fixer als herkömmlicher (skalarer) FP-Code.

SIMD-Berechnungen sind _nur_ effektiv wenn die Daten schnell in die Register geladen werden können. Dazu gibt es alignte Speicherzugriffsroutinen (MOVAPS) gegenüber unalignten (MOVUPS). Diese Befehle benötigen ein Ausrichtung Daten im Speicher auf eine 128bit Grenze (16 Bytes).

Großer Nachteil von SSE: Keine 64bit DOUBLEs in den XMM-Registern, ebenfalls keine Integer-Operationen.

SSE2 (ab P4/Athlon64) ermöglicht es nun auch in den 8x 128bittigen XMM-Registern zwei 64bit DOUBLEs unterzubringen. Ebenfalls kann (wie bei SSE) nur das unterste Element verwendet werden für skalare Berechnungen. Ausserdem ermöglicht SSE2 es mit 16x 8bit BYTEs, 8x 16bit WORDs, 4x 32bit DWORDs oder 2x 64bit QWORDs (oder 1x 128bit DQWORD) in den Registern zu arbeiten. SSE2 ist also eine Zusammenfassung von MMX+SSE plus Unterstützung von 64bit DOUBLEs.

SSE3 (ab P4-Prescott/Athlon64-Venice) erweitert SSE2 nur um lausige 10 Befehle, davon 2 für Barriers, 1 Integer, 4 Speicherzugriffsbefehle und 3 für SIMD-Berechnungen (HADDPS/PD) mit der man endlich (oh endlich nach fünf Jahren) das Skalarprodukt einfach berechnen kann.

Fassen wir zusammen:
- MMX+3DNow!: 8x 64bit MM-Register (mit denen der x87 FPU überlagert)
- SSE+SSE: 8x 128bit XMM-Register (eigene Funktionseinheit).

Mit dem Opteron und nun auch mit dem Athlon64 bzw. dem P4 mit E32MT wird
das ganze noch einmal erweitert. Es werden 16 neue 64bit breite Register R0..R15 eingeführt. Die unteren 8 davon enthalten in den unteren 32bit die altebekannten Register EAX, EBX, ECX, EDX, ESI, EDI, EBP und ESP - die oberen 8 werden erst aktiv wenn man in den 64bit Modus schaltet. Zusätzlich wird die Registeranzahl von SSE von 8 XMM-Register ebenfalls noch einmal verdoppelt auf insgesamt 16 (XMM0..XMM15).

Der PowerPC G3/G4 ist eine 32bit Implementation der 64bittigen PowerPC-Architektur welche IBM mit Motorola (und Apple) ins Leben rief, um die 32bittigen 68000er Prozessoren (68030/68040) des Apples (welche schon 8 Datenregister D0..D7 plus 8 Addressregister A0..A7 (A7 implizit SP)) abzulösen. Der PowerPC entstand aus der schon etwas älteren POWER-Architektur von IBM (welche z.Z. mit dem POWER5 immer noch aktuell ist). Die 32bit Implementation enhielt von Anfang an 32x 32bit Register GPR0..GPR31 plus 64x 32bit FP Register FPR0..FPR63. Wenn ich mich recht entsinne konnten je zwei 32bit FP-Register zu einem 64bittigen kombiniert werden (für DOUBLEs). Der PPC 601 bis 603 von Motorola ähnelte in der Architektur dem Pentium (superskalar), der 604 etwa dem PPro. Die e-Versionen (603e/604e) waren (kastrierte) Lower-Power Versionen für Notebooks (bei Apple heissen die Powerbooks und eigentlich nicht ohne Grund ;-). Der PPC 750 (G3) von Motorola war eine Neuentwicklung und ähnelte ebenfalls dem G3. Der G4/G4+/G4e war eine Weiterentwicklung dessen für höhere Taktraten.

Nach dem G4 bekam es Motorola nicht hin höhrere Frequenzen zu erreichen und schmiss das Mikroprozessor-Geschäft hin. Da Apple da ein bisserl dumm aus der Wäsche geguckt hat, haben sie bei Uncle Blue nachgefragt und heraus kam der G5 aka PPC970. Dieser ist ziemlich kompatibel zu den Vorgängern aber von Grund auf eine 64bit Implementation. Da der PowerPC von Anfang an für 64bit designed war musste hier nicht so gepfuscht werden wie bei x86-64 (64bit Erweiterung einer 32bit Erweiterung (i386) eines 16bit Mikroprozessors (i8086) der als Verbesserung eines 8bit Chips (i8080) entwickelte wurde, welcher von einem 4bit Taschenrechner abstammt (i4004)). Die Registerzahl bleibt bei 32 GPRs und 64 FPRs, alle nun 64bit breit.

Die Altivec SIMD-Erweiterung (seit dem G4) bringt 32 neue 128bittige Register für 8, 16 und 32bit Integers sowie 32bit Floating-Point Daten. Keine Unterstützung für 64bit Doubles. Bei der x86-Architektur gibt es nur 2 Operanden pro Befehl, etwa:

MMX: PADD MM0,MM1 (MM1 und MM0 werden addiert und in MM0 gespeichert)
SSE: ADDPS XMM0,XMM1 (XMM1 und XMM0 werden addiert und in XMM0 gespeichert)
ADDP

AltiVec dagegen kann (wie jeder Befehl beim PowerPC), drei Operanden pro Befehl ausführen:

vaddfp vr0,vr1,vr2 (addiere v0 und v1, speichere das Ergebnis in v2)

IA-64 (Itanium) von Intel dagegen ist eine von Grund auf neu designte Architektur mit 128 64bit Allzweckregistern GPR0..GPR127, 128 64bit Floating-Point Registern FR0..FR127 sowie 64 1bit Predicate-Register (für das Ergebnis von Vergleichen) und noch eine ganze Menge mehr. Die Architektur ist von Anfang an auf explizites Scheduling der Befehle durch den Compiler ausgelegt (EPIC). Hier muss der Prozessor nicht mehr Befehle dynamisch auf seine FUs verteilen sondern dies wird beim Kompilieren vom Compiler schon durchgeführt.

Über MIPS könnte ich auch noch was schreiben...

Fazit:

Ich halte von einer hohen Registeranzahl in einer ISA (Instruction Set Architecture) sehr viel. Lokale Variablen und Addressen sollten besser in den Registern zwischengespeichert werden (sofort verfügbar) statt ständig aus den Caches (L1-3) gefetcht werden zu müssen. Je 32 bis 64 GPR und FPR Register sind da denke ich wünschenswert. Register-Starvation wie bei x86 ist denke ich mal kein Geschenk für einen Compilerbauer.

x86 ist veraltet. Punkt.
Ständig wurde irgendwas angeflanscht. Improvisation par excellence. Die RISC-Architekturen (IBM's POWER/PowerPC, SGI's MIPS4, Sun's UltraSPARC, HP's PA-RISC, Digital's Alpha, Intel's IA-64) sind zwar wesentlich eleganter, aber durch eine hohe Anzahl an FUs und Out-of-Order Execution haben sich die x86-CPUs trotzdem wacker halten können (sogar ganz vorne ;-).

Um es kurz zu fassen:
"The x86 isn't all that complex - it just doesn't make a lot of sense."
Mike Johnson
Leader of 80x86 Design at AMD,
Microprocessor Report (1994)

Infos unter:
G4 vs P4: http://arstechnica.com/articles/paedia/cpu.ars (Hannibal Stokes)
x86/IA-32: The IA-32 Intel® Architecture Software Developer's Manual, Volume 1 - 3 (Intel)
x86-64/AMD64: AMD64 Architecture Programmer's Manual Volume 1 - 4 (AMD)
PPC: PowerPC Microprocessor Family - Programming Environments Manual for 64 and 32-bit Microprocessors (IBM)
IA64: Intel® Itanium® Architecture Software Developer's Manual, Volume 1 -3 (Intel)
Allgemein: Computer Architecture - A Quantitative Approach (Hennessey & Patterson) <- lesenswert!

Dieses Posting kommt zwar etwas zu spät, ich hoffe doch dass Ihr damit nicht mehr so im Dunkeln herumstochert - sorry ich konnt's einfach nicht ertragen :D

Cheers,
Vasco

Coda

2005-05-14, 20:34:18

Ich halte von einer hohen Registeranzahl in einer ISA (Instruction Set Architecture) sehr viel. Lokale Variablen und Addressen sollten besser in den Registern zwischengespeichert werden (sofort verfügbar) statt ständig aus den Caches (L1-3) gefetcht werden zu müssen. Je 32 bis 64 GPR und FPR Register sind da denke ich wünschenswert. Register-Starvation wie bei x86 ist denke ich mal kein Geschenk für einen Compilerbauer.Alle modernen x86 Prozessoren haben sehr viel mehr physikalische Register als die ISA (Athlon 64 hat 72 Integer Register) und nutzen diese auch sehr gut aus durch renaming.
AMD hat bei der x86-64 ISA auch ausgetestet inwiefern es etwas gebracht hätte 32 statt 16 GPRs einzuführen und kam zum Schluss, dass es sich nicht gelohnt hätte.

ber durch eine hohe Anzahl an FUsSoviel haben die doch gar nicht.

Bokill

2005-05-14, 21:00:04

WHOW Vasco

Zu x86-64 könnte man ergänzen, dass die ISA AMD64 ein Hauch mehr RISC spendiert bekam.

Mehr Register (weniger Speicherlastig), entrümpelte FPU (AMD forciert SSE, statt der Stackbasierten FPU), der Versuch und aktive PR zu einer eher einheitlichen Befehlslänge (es bleibt bei dem Versuch).

MIPS soll in vielen Punkten vergleichbar mit der PowerPC ISA sein (offensichtlich schaute sich das Entwicklerteam zur Power-Familie viel bei MIPS ab).

ARM (http://www.arm.com/products/CPUs/architecture.html) ging einen etwas anderen Weg, diese nahmen vergleichsweise weniger Register 16, aber war von anfang an auch mit Schattenregistern geplant.
Auch eine geschickte kompilergerechte Sprungvorhersage wurde von Anfang an eingebunden (Prediction in 4 Stufen).
Und mit Thumb (http://www.arm.com/products/CPUs/archi-thumb.html) wurde eine Kompressionstechnik eingebunden, die für Embeded heute immer noch gut genug ist (16 Bit).

Ach ja ... hier ist noch was ... 20 Jahre ARM (http://www.heise.de/ct/05/11/018/)

Bo(2005)

Vasco

2005-05-14, 21:02:55

Alle modernen x86 Prozessoren haben sehr viel mehr physikalische Register als die ISA (Athlon 64 hat 72 Integer Register) und nutzen diese auch sehr gut aus durch renaming.
AMD hat bei der x86-64 ISA auch ausgetestet inwiefern es etwas gebracht hätte 32 statt 16 GPRs einzuführen und kam zum Schluss, dass es sich nicht gelohnt hätte.

Najo für nen Compilerbauer macht's net viel Spass die Variablen eines Codeblocks in nur 8 Registern unterzubringen. Brauchst ja schon zwei für den Stack- und den Frame-Pointer. Bei nem komplexeren Stück Code (angenommen mal was rechenintensives) sind da temporäre Register für Zwischenergebnisse und bereites vorberechnete Offsets für Datenstrukturen ganz praktisch. Stell Dir halt einfach ein paar 4x4 Matrizen vor und ein paar 4D Vektoren die du in acht vierelementigen Registern unterbringen willst.

Bei einer JVM ist das glaube ich ähnlich problematisch.

Soviel haben die doch gar nicht.

http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html#1.1

3x ALU+AGUs, 3x FPU sind zumindest mehr als nen 486/586 hatte :tongue:

Cheers,
Vasco

Vasco

2005-05-14, 21:08:56

WHOW Vasco

Zu x86-64 könnte man ergänzen, dass die ISA AMD64 ein Hauch mehr RISC spendiert bekam.

auch nicht wirklich konsequent. Wieder mal nur Tofu statt Fisch oder Fleisch :biggrin:

Mehr Register (weniger Speicherlastig), entrümpelte FPU (AMD forciert SSE, statt der Stackbasierten FPU)

Das hat Intel damals mit SSE angefangen. Mittlerweile kann man's auch in eigenem Code verwenden:

<schnipp>
#include <stdio.h>

int main(void)
{
float a = 123.0f;
float b = 456.0f;

printf("%f\n",a + b * a / b - a);
}
<schnapp>

gcc -O3 -S -march=pentium3 -mfpmath=sse moo.c
gcc -O3 -S -march=pentium4 -mfpmath=sse moo.c

Der GCC verwendet dann skalare SSE-Befehle (Pentium3) bei Floats bzw. SSE2-Befehle (Pentium4/Opteron) bei Doubles.

MIPS soll in vielen Punkten vergleichbar mit der PowerPC ISA sein (offensichtlich schaute sich das Entwicklerteam zur Power-Familie viel bei MIPS ab).

Nicht nur PowerPC. Auch die SPARC- und Alpha-Entwickler haben sich daran orientiert, was auch kaum verwunderlich ist: MIPS was first (1985).

Cheers,
Vasco

Coda

2005-05-14, 21:13:07

3x ALU+AGUs, 3x FPU sind zumindest mehr als nen 486/586 hatteSchon klar. Aber ein G5 hat auch nicht weniger.

Darkstar

2005-05-15, 10:56:00

[…]

x86 ist veraltet. Punkt.

[…]

Dieses Posting kommt zwar etwas zu spät, ich hoffe doch dass Ihr damit nicht mehr so im Dunkeln herumstochert - sorry ich konnt's einfach nicht ertragen :D :up: Saubere Arbeit!

HajottV

2005-05-15, 10:58:16

Brauchst ja schon zwei für den Stack- und den Frame-Pointer.

Nein, den Frame-Pointer braucht man nicht.

Gruß

Jörg

GloomY

2005-05-15, 23:19:56

Vasco,

du zählst sehr viele Dinge / Details der Architekturen auf. Das ist alles richtig, aber mir fehlt hierbei der logische Zusammenhang, wie du zu deinem Schluss / Urteil kommst, dass x86 veraltet sein soll.
Mit den jeweiligen Erweiterungen passt man sich entsprechend der Zeit und den Bedürfnissen an.
Ich halte von einer hohen Registeranzahl in einer ISA (Instruction Set Architecture) sehr viel.Die Register müssen auch irgendwie in den Befehlen codiert werden. Je mehr das sind, desto größer wird die Codierung. Insofern muss man ein sinnvolles Maß zwischen Registeranzahl und Code-Größe beim Entwurf einer ISA wählen.
Da die RISC-Architekturen sowieso - als Merkmal selbiger - eine konstante Befehlscodierung von 32 Bit besitzen, ist es klar, dass man hier nicht umbedingt sparen muss.

RISC-Befehle sind traditionell 4 Bytes lang. In einen Befehlscache gleicher Größe bekommt man schätzungsweise 33% mehr x86-Ops als PowerPC-, MIPS-, Alpha- oder SPARC-Ops rein. Diese Zahlen basieren auf der Annahme, dass ein durchschnittlicher x86 Befehl 3 Bytes lang ist, was imho hinkommen dürfte. Gerade die lang codierten x86-Befehle (bis zu 12 Bytes) sind äußerst selten. (Im Prinzip ist das eine Art Huffman-Codierung und damit eine Kompressionstechnik)

Und die angesprochenen IA64 Befehle benötigen 128 Bit pro Dreier-Befehlsbündel, d.h. ~5,3 Byte / Befehl. Dazu kommen noch schätzungsweise 20% durch NOPs, weil man nicht jede Befehlskombination in den Dreierbündeln zusammenpacken kann. Effektiv kommt man damit im Schnitt auf etwa 6,4 Byte / Befehl für IA64.
Der Montecito hat nicht umsonst eine Hardvard-Architektur beim L2 und gigantische 1 MiB L2 Cache nur für Befehle! Eine ineffiziente Codierung schlägst sich auch auf die Hardware nieder.

Man darf hier eben nicht nur die Nachteile (wenig Register) kurzer Befehlscodierungen sehen. Mit x86-64 gibt's ja - wie erwähnt - auch wieder eine Ladung neuer Register dazu :)
Lokale Variablen und Addressen sollten besser in den Registern zwischengespeichert werden (sofort verfügbar) statt ständig aus den Caches (L1-3) gefetcht werden zu müssen.Ja. Daten, die nicht in Register passen, werden auf den Stack gepushed und später wieder gepoppt. Das sind dann effektiv Load- bzw. Store-Operationen auf dem Stack-Segment.

Wenn man öfters auf L2 oder L3 zugreifen muss, dann helfen die paar Register mehr garantiert nicht weiter. Dann geht es um sehr viel größere Datenmengen, als man jemals in einem Registerfile speichern kann. Insofern findet das Speichern und Laden von lokalen Variablen wohl hauptsächlich beim L1 D-Cache statt, von gelegentlichen L2 Zugriffen wegen Conflict-Misses des L1 mal abgesehen.
Da alle heutigen L1-Caches dual-ported sind, sehe ich für den Cache an sich nicht ein so großes Problem, wenn genügend Bandbreite (128 Bit) vorhanden ist.

Die Latenz ist wohl schon eher eine Sache. Aber oftmals kann man diese Speicher- und (vor allem) Lade-Operationen hinter der Ausführungslatenz anderer Befehle verstecken. Out-of-Order Execution bedeutet ja nicht nur die Ausführung von arithmetischen Befehlen ausserhalb der eigentlichen Programmfolge sondern eben auch der Load/Store Befehle.
Hierbei kann der Prozessor die zu ladenden Daten in Rename-Register (d.h. Register, die momentan keiner der für die ISA sichtbaren Register zugeordnet sind) laden und dann diese Zuordnung später bei den diese Daten manipulierenden entsprechenden arithmetischen Befehlen ändern und so tun, als hätte er in Blitze-Schnelle diese Load-Operation ausgeführt. In Wirklichkeit liegen diese Daten aber schon einige Takte lang in einem (früher) nicht sichtbaren Register, das nun aber einem der ISA-Register zugeordnet ist.
Je 32 bis 64 GPR und FPR Register sind da denke ich wünschenswert. Register-Starvation wie bei x86 ist denke ich mal kein Geschenk für einen Compilerbauer.Compilerbau ist ein anderes Thema. Hier geht es vor allem um die Effizienz, sprich: Geschwindigkeit.
Wenn x86 wegen Register-Knappheit öfters zu Lade- und Speicheroperationen greifen muss, dies aber mit geringerer Code-Größe - sprich: besserer Hit-Rate - ausgleichen kann, so stellt das imho keinen Nachteil für x86 an sich dar.

Im Übrigen dürfte beim Compilerbau nicht x86 sondern IA64 wohl das schlimmste sein, was man sich vorstellen kann. Die Suche nach Parallelität, Predication, Befehlsbündel, Prefetch (wichtig bei In-Order!), Register-Fenster, usw. dürfte wohl wensentlich mehr Aufwand bedeuten, als ein paar Load/Store Operationen, weil nicht genügend Register vorhanden sind.
IA-64 (Itanium) von Intel dagegen ist eine von Grund auf neu designte Architektur mit 128 64bit Allzweckregistern GPR0..GPR127, 128 64bit Floating-Point Registern FR0..FR127Imho sind bei IA64 jeweils nur 32 davon für den Programmierer / Compiler direkt sichtbar. Ansonsten kann ich auch argumentieren, dass der P4 128 GPRs hat (Anzahl an Rename Registern).

edit: Hab' noch eins vergessen:

:massa: Hennessey & Patterson's CA:AQA :massa:

Gast

2005-05-16, 01:05:08

Da der PowerPC von Anfang an für 64bit designed war musste hier nicht so gepfuscht werden wie bei x86-64 (64bit Erweiterung einer 32bit Erweiterung (i386) eines 16bit Mikroprozessors (i8086) der als Verbesserung eines 8bit Chips (i8080) entwickelte wurde, welcher von einem 4bit Taschenrechner abstammt (i4004)). Die Registerzahl bleibt bei 32 GPRs und 64 FPRs, alle nun 64bit breit.
Insgesamt eine gute Übersicht.
Vor allem beim fetten Teil musste ich schmunzeln. :D

Ich möchte keine neue Diskusion anfachen, aber man darf eines nicht außer acht lassen.
Alle 64-bitter älteren Kalibers haben/hatten einen Vorteil: Sie bedienen einen kleinen Prozentteil des Gesamtmarktes. Im Serverbereich sind es bedeutend größer, aber auch da: wenn sich eine Firma einen neuen Server zulegt, dann wird auch die komplette Software meist neu gekauft. Da können die sich erlauben, komplett neue Prozessoren inkl. angepasster/neuer Software zu entwickeln.

Bei x86 hatten unterschiedliche Faktoren eine Rolle gespielt. Angefangen vom niedrigeren Preis bis zu anderen Einsatzbereichen (Spiele-PC) usw.
Viele (nicht alle) holen sich einen PC, um zu "lernen","arbeiten" usw. Aber an erster Stelle kommt spielen, surfen (nicht arbeiten) usw. ;)
Hand aufs Herz. Warum war c64 und Amiga so erfolgreich? Weil man vieles kopieren konnte. Beim PS, PS2, PC/x86 usw. ist es genauso. Deswegen war auch GC und DC auch nicht so erfolgreich. Gute Spiele haben/hatten die ja auch. Nicht nur die Masse/Quantität entscheidet, auch die Qualität, aber andere sehen es anders. (Meine Meinung dazu)

Vasco

2005-05-17, 01:24:07

Vasco,

du zählst sehr viele Dinge / Details der Architekturen auf. Das ist alles richtig, aber mir fehlt hierbei der logische Zusammenhang, wie du zu deinem Schluss / Urteil kommst, dass x86 veraltet sein soll.

Oeh, es gibt keinen logischen Zusammenhang - das hab ich in der Eile wohl vergessen.

Eigentlich wollte ich nur kurz ein paar genauere Details über x86/PPC präsentieren. Die vorangegangene Diskussion war leider etwas auf Halbwissen basierend.

Und am Ende dachte ich mir dummerweise meine Meinung äussern zu müssen. Die war dann auch eher aus dem Bauch heraus... :rolleyes:

Cheers,
Vasco

Vasco

2005-05-17, 01:26:28

Da können die sich erlauben, komplett neue Prozessoren inkl. angepasster/neuer Software zu entwickeln.

Apple hat's auch geschafft ihr OS plus sämtliche Anwendersoftware vom 68000er zum PowerPC zu migrieren. Warum sollte das nicht auf PCs möglich sein? "Alte" Software kann ich heute auch in der Emulation ausführen. Wenn sie einigermassen geschickt ist, sogar recht schnell. Das Festhalten an x86 ist m.E. eher nur Angst vor der Konkurrenz.. ;D

Cheers,
Vasco

Vasco

2005-05-17, 01:31:48

Auch was vergessen...

Imho sind bei IA64 jeweils nur 32 davon für den Programmierer / Compiler direkt sichtbar.

"A set of 128 (64 bit) general registers provide the central resource for all integer and integer multimedia computation. They are numbered GR0 through GR127, and are all available to all programs in all privilege levels."

Aus diesem Grund wollte ich IA-64 noch ausführen (hohe Registeranzahl). Also durchgehend verfügbar sind die 128 Register für Integer+SIMD Operationen. IIRC werden all diese jedoch nicht frei vom Compiler verwendet für Variablen werden können, sondern dieser bildet in diesen die Stack-Frames von Prozeduren ab (Register Windowing, ähnlich wie beim (Ultra?-)SPARC).

Cheers,
Vasco

Coda

2005-05-17, 01:44:10

Apple hat's auch geschafft ihr OS plus sämtliche Anwendersoftware vom 68000er zum PowerPC zu migrieren. Warum sollte das nicht auf PCs möglich sein?Warum sollte man das tun? x86-64 ist eine sehr solide Platform, auch wenn du das nicht einsehen willst.

StefanV

2005-05-17, 09:59:16

Bei x86 hatten unterschiedliche Faktoren eine Rolle gespielt. Angefangen vom niedrigeren Preis bis zu anderen Einsatzbereichen (Spiele-PC) usw.
Viele (nicht alle) holen sich einen PC, um zu "lernen","arbeiten" usw. Aber an erster Stelle kommt spielen, surfen (nicht arbeiten) usw. ;)
Hand aufs Herz. Warum war c64 und Amiga so erfolgreich? Weil man vieles kopieren konnte. Beim PS, PS2, PC/x86 usw. ist es genauso. Deswegen war auch GC und DC auch nicht so erfolgreich. Gute Spiele haben/hatten die ja auch. Nicht nur die Masse/Quantität entscheidet, auch die Qualität, aber andere sehen es anders. (Meine Meinung dazu)
*hust*
DC und nicht kopieren können?!
Nicht dein ernst, oder?!

Hamster

2005-05-17, 19:29:23

*hust*
DC und nicht kopieren können?!
Nicht dein ernst, oder?!

als die dc erschienen ist, gabs kaum brenner bzw waren arschteuer....

RoKo

2005-05-17, 23:12:00

als die dc erschienen ist, gabs kaum brenner bzw waren arschteuer....
Auf keiner anderen Konsole habe ich unter Freunden überhaupt mitbekommen, dass kopiert wurde - nur auf Dreamcast hatten die Leute fast nur Kopien. Für die älteren Modelle musste man nichtmal einen Mod-Chip einbauen. Das war echt traurig mit anzusehen.

Gast

2005-05-18, 01:31:40

*hust*
DC und nicht kopieren können?!
Nicht dein ernst, oder?!
Das kam viel zu spät. Da war das Hype um PS2 viel zu groß, damit Leute objektiv denken konnten. ;)

Gast

2005-05-21, 16:18:18

http://www.esm.psu.edu/Faculty/Gray/graphics/movies/mhz_myth_320f.mov

;D

Coda

2005-05-21, 16:30:46

Das Video hat ja mit der spezifischen Architektur eines x86 Prozessors zu tun und nicht mit dem Befehlssatz an sich.

DasToem

2005-05-21, 19:08:39

Auf keiner anderen Konsole habe ich unter Freunden überhaupt mitbekommen, dass kopiert wurde - nur auf Dreamcast hatten die Leute fast nur Kopien. Für die älteren Modelle musste man nichtmal einen Mod-Chip einbauen. Das war echt traurig mit anzusehen.

Man muss(te) in kein einziges Modell einen Modchip einbauen. Die PSX ist an und für sich auch erst mit dem Aufkommen der Modchips richtig in Mode gekommen.

als die dc erschienen ist, gabs kaum brenner bzw waren arschteuer....

99/2000 waren Brenner arschteuer? Wirklich? Eher lag es am Nichtvorhandensein von Breitbandinternetverbindungen. Ein 700MB ISO ist über ein Modem eine arg langweirige Angelegenheit.

Muh-sagt-die-Kuh

2005-05-21, 22:20:24

Auch was vergessen...

"A set of 128 (64 bit) general registers provide the central resource for all integer and integer multimedia computation. They are numbered GR0 through GR127, and are all available to all programs in all privilege levels."

Aus diesem Grund wollte ich IA-64 noch ausführen (hohe Registeranzahl). Also durchgehend verfügbar sind die 128 Register für Integer+SIMD Operationen. IIRC werden all diese jedoch nicht frei vom Compiler verwendet für Variablen werden können, sondern dieser bildet in diesen die Stack-Frames von Prozeduren ab (Register Windowing, ähnlich wie beim (Ultra?-)SPARC).

Cheers,
VascoAlle 128 Register können vom Compiler direkt angesprochen werden, es gibt jedoch ein paar Besonderheiten.

Die Register sind bei IA-64 in statische Register (r0 bis r31) und dynamische Register (r32-r127) unterteilt. Die statischen Register können funktionsübergreifend verwendet werden und verweisen immer auf das gleiche physikalische CPU Register. Bei den dynamischen ist das nicht so.....r35 kann in Funktion F1 auf ein völlig anderes physikalisches Register als in F2 verweisen, sie sind als lokale Pufferspeicher innerhalb von Funktionen gedacht. Das ist im Prinzip auch Register Renaming, die Verwaltung erfolgt über die Register Stack Engine der CPU.

Wer es genauer nachlesen möchte kann das hier (http://msdn.microsoft.com/msdnmag/issues/01/06/hood/).

Muh-sagt-die-Kuh

2005-05-21, 22:32:30

Warum sollte man das tun? x86-64 ist eine sehr solide Platform, auch wenn du das nicht einsehen willst.Das sehe ich ähnlich.

Für die x86 ISA gibt es große Anzahl an hervorragend optimierten Compilern, hätte man die ISA komplett umgebaut hätte man fast bei 0 anfangen müssen. x86-64 bügelt mit der höheren Anzahl an GPRs die, meiner Meinung nach, größte x86 Schwäche aus und erlaubt trotzdem eine sehr leichte Portierung der Compiler....dazu kommt noch die wichtige Abwärtskompatibilität.

Die einzige Auswirkung der ISA auf ein CPU-Design ist, dass das Frontend durch den etwas komplizierteren Decodierungsvorgang aufgebläht wird.....dafür braucht der kompakte Befehlssatz eben weniger I-Cache (den P4 mit seinem Trace-Cache mal außen vor gelassen).

Gast

2005-05-21, 22:45:41

Hier gibt es eine "Expertendiskussion": http://www.macuser.de/forum/showthread.php?t=93495&page=3&pp=15

Interessant sind die verlinkten Artikel.

zeckensack

2005-05-24, 14:23:53

Hier gibt es eine "Expertendiskussion": http://www.macuser.de/forum/showthread.php?t=93495&page=3&pp=15

Interessant sind die verlinkten Artikel.ArsTechnica (http://arstechnica.com/) dürften vielen hier ein begriff sein. Zumindest mal den Leuten die "CPU-Guru" als Nutzertitel haben :)

Dafür ist kein Umweg über ein Mac-Forum nötig.

Bokill

2005-05-24, 16:20:21

Ars Technica hat eine geile eigene Beschreibung für die Berichte wie und warum sie so schreiben:

About Us (http://arstechnica.com/site/welcome.ars)
... Second, we don't believe in consumers. You’re a prosumer--coming to this site proves that much.
Prosumers aren’t satisfied with the status quo.
When it comes to computing, prosumers want proformance, and they want it at a price that lets ‘em sleep easy at night.
When it comes to news, opinions, and technology reviews, prosumers want content that informs, not conforms to industry hoopla or some IT Manager’s idea of proven technology. And we’re gonna give it to you. ...

In weiten Teilen kann man dieses Motto für 3DC Crew & Member auch sagen ... mit gewissen Ausnahmen ... :D

Bo(2005)

Gast

2005-05-24, 17:17:30

Die "architektonische Ueberlegenheit " des PPC ist DA, FAKT!
G4 und PentiumM nimmt sich nicht viel!

LOL, was sind denn das für Aussagen in diesem Thread:
http://www.macuser.de/forum/showthread.php?t=93870&page=12&pp=15

???

zeckensack

2005-05-24, 17:26:50

Die "architektonische Ueberlegenheit " des PPC ist DA, FAKT!
G4 und PentiumM nimmt sich nicht viel!Die Undifferenziertheit dieser Aussage ist DA, FAKT! ;(

Versuche doch mal zB auf GloomY einzugehen, der das ganze IMO sehr treffend (und wichtig: nüchtern!) gegenübergestellt hat.

Ansonsten zitiere ich mich mal selbst:
It's a well known fact that statements beginning with "It's a well known fact" are generally unfounded, uninformed conjecture coming from people who are too lazy to research or understand an issue.

Gast_x86

2005-05-24, 23:35:01

Muh-sagt-die-Kuh

2005-05-25, 21:50:00

Die x86 Architektur ist nicht mehr nur eine Architektur, sondern hat sich eher zu einer Schnittstellen-Sprache entwickelt. Eine Schnittstelle, zwischen einer "veralteten" externen x86-Welt und einem internen "modernen" non-x86 Welt.
So sollte man es eher sehen.Unter x86 versteht man allgemein den x86 Befehlssatz (englisch ISA - Instruction Set Architecture)...nicht mehr und nicht weniger. Wie dieser implementiert wird ist eine ganz andere Sache....und eben diese hat sich über die Zeit verändert. ;)

Demirug

2005-05-25, 22:35:04

Unter x86 versteht man allgemein den x86 Befehlssatz (englisch ISA - Instruction Set Architecture)...nicht mehr und nicht weniger. Wie dieser implementiert wird ist eine ganz andere Sache....und eben diese hat sich über die Zeit verändert. ;)

Ja, ich habe hier sogar eine Presentation von AMD in der man darüber spicht wie x86 über das ganze Spektrum eingesetzt wird. Dabei nutzt man zwar immer den gleichen Befehlssatz aber unterschiedliche Implementierungen.

Gast_x86

2005-05-26, 01:24:04

Genauso meine ich ja auch. Die ISA ist nichts anderes als eine Schnittstelle der "Interpreter-Sprache" x86. Ähnlich funktioniert auch Transmeta, nur softwaremäßig.

Gast

2005-06-06, 22:30:15

Das "armen" Mac-Fans sind jetzt ganz verwirrt...

;)

http://www.macuser.de/forum/showthread.php?t=96269&page=55&pp=15

Gast

2005-06-07, 09:07:37

x86 ist ja sooo veraltet, Apple setzt jetzt auch darauf, was für eine tolle Ironie.

HajottV

2005-06-07, 10:57:20

x86 ist ja sooo veraltet, Apple setzt jetzt auch darauf, was für eine tolle Ironie.

Ja... vor gerade mal 14 Tagen haben hier einige groß rumgeblökt, wie veraltet doch x86 ist. Tja, so kann man sich irren.

Gruß

Jörg

Exxtreme

2005-06-07, 11:47:13

@ Eingefleischte Apple-User
Diesen Link NICHT anklicken. X-D

Für alle anderen hier mal ein Verwendungszweck des Mac Mini:
http://www.w3sh.com/archives/2005/05/enfin_un_bon_us.html

Peppo

2005-06-07, 12:03:27

Apple übernimmt die "veraltete" x86 Architektur:

http://derstandard.at/?url=/?id=2070302
http://derstandard.at/?url=/?id=2070563

Das wird die Apple-Jünger freuen...

deekey777

2005-06-07, 12:05:25

@ Eingefleischte Apple-User
Diesen Link NICHT anklicken. X-D

Für alle anderen hier mal ein Verwendungszweck des Mac Mini:
http://www.w3sh.com/archives/2005/05/enfin_un_bon_us.html

Da das "Alt!"-Schreien nicht erwünscht ist, sage ich: "Unneu!" ;(
Ehrlich gesagt, würde es mich nicht wundern, wenn der kommende "Intel Pentium 5" auf einem Mac präsentiert wird.

Avalox@gast

2005-06-07, 15:10:36

Das ist dann der Pentium Mac, oder auch kurz Pentium M. Als ob es nicht schon heute alle gesagt haben.

Ob PowerPC mal in einem Zug mit VHS vs. Betamax etc genannt wird?

BlackBirdSR

2005-06-07, 16:01:58

Das ist dann der Pentium Mac, oder auch kurz Pentium M. Als ob es nicht schon heute alle gesagt haben.

Ob PowerPC mal in einem Zug mit VHS vs. Betamax etc genannt wird?

Glaub ich nicht.
Die Macs waren doch ein recht kleines Einsatzgebiet für PowerPC.
Gestorben ist doch damit eigentlich nur der PPC970

Coda

2005-06-07, 17:24:13

Soweit ich weiß holt PowerPC derzeit auf dem embedded Sektor auf.

avalanche

2005-06-07, 18:15:42

Hat Apple eigentlich bekanntgegeben, dass es wirklich x86er werden, oder nur, dass man nun Intel-CPUs einsetzen wird? Ich hab in bei hardtecs4u verlinkten Mitteilung nur "Intel" lesen können und nirgendwo "x86". Vielleicht hab ich's auch überlesen, aber ist es wirklich sicher, dass es ein x86er wird?

Legolas

2005-06-07, 19:07:30

Gast

2005-06-07, 19:10:07

http://static.hardwareluxx.de:591/hardware/andreas/News/Apple-Intel_P4.jpg

HellHorse

2005-06-07, 19:46:37

Das "armen" Mac-Fans sind jetzt ganz verwirrt...
Erinnert irgendwie an 1984. Wer ist doch gleich noch einmal der Feind? X-D

Gast

2005-06-07, 19:54:54

Wer ist doch gleich noch einmal der Feind? X-D

Früher IBM gehasst -> dann geliebt
Intel schon immer gehasst -> und jetzt ;)

Hehehe... Ist wirklich lustig, wenn man in Macforen wie Macuser.de rumsurft, wie die Hardcore-Jünger reagieren. Vorallem lächerlich sind diese, die von heut auf morgen Intel aufeinmal gut zu seinen scheinen finden. Oder diese, die weiterhin versuchen die Apple-Propaganda durchzudrücken.

Klar gibt es auch normalgebliebene Apple-User - Aber gegenüber den Spinnern bin ich sehr schadenfroh.

sloth9

2005-06-07, 20:41:40

Erinnert irgendwie an 1984. Wer ist doch gleich noch einmal der Feind? X-D

Jau, Steve Jobs ist schon eine lächerlicher. Wäre er bloss bei Atari geblieben...

sloth9

2005-06-07, 20:42:47

Früher IBM gehasst -> dann geliebt
Intel schon immer gehasst -> und jetzt ;)

Hehehe... Ist wirklich lustig, wenn man in Macforen wie Macuser.de rumsurft, wie die Hardcore-Jünger reagieren. Vorallem lächerlich sind diese, die von heut auf morgen Intel aufeinmal gut zu seinen scheinen finden. Oder diese, die weiterhin versuchen die Apple-Propaganda durchzudrücken.

Klar gibt es auch normalgebliebene Apple-User - Aber gegenüber den Spinnern bin ich sehr schadenfroh.

Apple ist doch die Geek-Marke! Und was bedeutet das nochmal... :D

Gast

2005-06-08, 20:22:49

http://www.macuser.de/forum/showthread.php?t=96709&page=14&pp=15

;D

Verzweifelter Versuch eines PPC-Jüngers die PPC-Plattform zu verteidigen oder als das Non-Plus-Ultra darzustellen ;D

Ghast

2005-06-09, 11:28:19

Unfassbar wie alle wieder über Dinge herziehen von denen sie keine Ahnung haben.

Es ist ein Wunder das die x86-Technik soweit entwickelt werden konnte. Ist mit der Handvoll Register und der geilen ISA einfach Steinzeit (MUL mit einem Operanden!! Geil. Es wird einfach immer mit dem EAX-Register multipliziert!)

PowerPC wäre viel moderner (technisch gesehen), speziell der G5 natürlich.

Der Umstieg Apples auf x86 ist eine reine Kosten/Zukunftsfrage: IBM kassiert mächtig für den G5, entwickelt ihn zugleich zu langsam weiter (Stichwort mobile CPUs, DualCore).

Warum habt ihr alle ein Problem damit, dass x86 veraltet ist? Ist doch wurscht, solange es gut funktioniert. Programmiere selber in Assembler für den P4.

BlackBirdSR

2005-06-09, 12:09:24

http://www.macuser.de/forum/showthread.php?t=96709&page=14&pp=15

;D

Verzweifelter Versuch eines PPC-Jüngers die PPC-Plattform zu verteidigen oder als das Non-Plus-Ultra darzustellen ;D

Ich finde es eher erschreckend, wie wenige erkennen, dass PPC nicht gleich PPC ist.

Da werden die PPCs in XBox und Cell munter zu kleinen G5 deklariert.
"Der G5 ist so gut, dass Microsoft sich entschieden hat, eine abgespeckte Version davon in der XBox360 einzusetzen" etc etc.

HajottV

2005-06-09, 12:15:37

Hi,

Unfassbar wie alle wieder über Dinge herziehen von denen sie keine Ahnung haben.

[...] MUL mit einem Operanden!! Geil. Es wird einfach immer mit dem EAX-Register multipliziert!

Oha... da hast Du Dich aber gerade voll in die Nesseln gesetzt. :P

http://www.cs.ucla.edu/~kohler/class/04f-aos/ref/i386/IMUL.htm :deal:

PowerPC wäre viel moderner (technisch gesehen), speziell der G5 natürlich.

Die Architektur ist besser, ja, keine Frage. Aber - um mal Kohl zu zitieren: "Es kommt darauf an, was hinten rauskommt." Und da sind die PowerPC zwar nicht schlecht aber auch nicht wirklich überzeugend.

Warum habt ihr alle ein Problem damit, dass x86 veraltet ist? Ist doch wurscht, solange es gut funktioniert.

Keins, ich gebe Dir voll recht, was das anbelangt... es funktioniert prima, aber nicht zwingend besser als x86.

Gruß

Jörg

Gast

2005-06-09, 12:21:05

Nö hab mich nicht in die Nesseln gesetzt.

Es gibt schon MUL-Befehle die 2 Operanden entgegennehmen, nur wird da vom Compiler folgendes drausgemacht:

PUSH(EAX)
MOV(var2,EAX)
MUL(var1)
POP(EAX)

D.h. EAX wird für den 2.Operanden einfach freigemacht.

zeckensack

2005-06-09, 12:39:01

Neomi

2005-06-09, 13:13:00

Es gibt schon MUL-Befehle die 2 Operanden entgegennehmen, nur wird da vom Compiler folgendes drausgemacht:

IMUL gehört zum Befehlssatz, nicht zu einer Hochsprache. Es ist quasi ein Mnemonic, der in einem Block Assemblercode vorkommen kann. Die werden assembliert (1:1 in Opcodes umgesetzt), ein Compiler hat an dieser Stelle gar nichts verloren.

Gast

2005-06-10, 06:24:23

Dein Compiler ist scheiße ;)
Welche Compiler sind gut? GCC? MSVC++? Borland C++?
(anderer Gast)

Coda

2005-06-10, 09:47:10

Eigentlich dürfte jeder halbwegs moderne Compiler (Sprich, GCC 3.4, MSVC++ .NET 2003 und Intel C++ 8) so nen Murks verhindern.
Borland hat aber nicht gerade einen tollen Ruf ;)

Gast

2005-06-10, 11:29:28

Eigentlich dürfte jeder halbwegs moderne Compiler (Sprich, GCC 3.4, MSVC++ .NET 2003 und Intel C++ 8) so nen Murks verhindern.
Borland hat aber nicht gerade einen tollen Ruf ;)
Borland war zu TP-Zeiten sehr gut. Heute unbekannt. So schlecht kann es auch nicht sein, da auch gute Programme mit Borland-Compilern geschrieben werden.
Wie sind die Leistungen (Geschwindigkeit, IDE-Umgebung...) unterschiedlicher Compiler in den letzten Jahren so geworden?

Gast

2005-06-10, 13:42:37

Also Delphi wurde immer langsamer, von Version 6 bis jetzt.

Wie es mit C++ aussieht weiß ich nicht.

zeckensack

2005-06-10, 14:52:43

Also Delphi wurde immer langsamer, von Version 6 bis jetzt.

Wie es mit C++ aussieht weiß ich nicht.Borland hat sich aus dem Geschäft mit C++ längst verabschiedet, und konzentriert sich auf RAD-Umgebungen für Delphi, Java und .NET.
IMO hatten die einfach nicht die Ressourcen, um neben GCC, Microsoft und Intel noch sinnvoll bestehen zu können. Die Entwicklung dort war einfach zu rasant, gerade im Bereich der Optimierungen. Egal was man sich von seinem C++-Compiler erhofft, bei einem dieser drei wird man fündig. Für Borland ist da einfach kein Platz mehr.

Demirug

2005-06-10, 14:58:04

Die Compiler von Borland waren noch nie gut was die Performance angeht. Borland hat man wegen der IDE gekauft.

Gast

2005-06-11, 13:30:31

mir fällt auf, daß doch ein powermac meist zwei cpus hat und diese dann mit pcs mit einer cpu vergleichen werden.

ist doch nicht gerade fair oder? die müssten dann doch einen vergleich gegen einen power mac mit nur einer cpu machen.

und das windows ansich vermutlich nicht so gut mit mehr cpus kalr kommt wie osx und es auch dafür weniger software gibt, die das unterstützt, dafür kann der x86 prozssor ja nichts.

powermac ppc gegen powermac intel (mit nativer osx software) wäre mal interessant :)

Demirug

2005-06-11, 13:38:42

Der Windowskern ist wesentlich Multicpu freundlicher als der Kern von OSX. Unter anderem deswegen performt OSX ja auch als Serverbetriebssystem nicht sonderlich gut.

Gast

2005-06-11, 13:43:27

Demirug

2005-06-11, 13:51:54

Ist der Kern nicht ein Unix? dann müsste doch auch ein solches schlecht sein?

Wäre es denkbar, daß der Kern von OSX mal gegen etwas anderes getausch wird (Wenn es sich lohnt) und der Endanwender davon nichts merkt?

OSX benutzt einen Mischmasch aus MACH und BSD. Es mag überraschen aber viele *nix Systeme haben tatsählich einen Kern der nicht sonderlich gut für Multicpu Systeme geeignet ist.

Gast

2005-06-28, 10:20:29

Aktuelles Bsp. für die Hardware-Kompetenz viele Apple-User:

Alle Intel-Prozessoren für Desktop und Server nun mit 64-Bit-Technologie

Mit dem in einer Pressemitteilung vorgestellten 64-Bit-Celeron-D-Prozessor besitzen nun alle Intel-Prozessoren für Desktop und Server eine 64-Bit-Speicheranbindung. Obwohl die aktuellen Prozessorlinien von Intel in den zukünftigen Macs keine Verwendung finden werden, ist es mit doch sehr wahrscheinlich, dass alle zukünftigen Desktop-Macs mit Intel-Prozessor eine 64-Bit-Speicheranbindung bieten werden
http://www.mactechnews.de/show_news_print.php?news_id=10406

Wenn schon Newsseiten solchen Mist posten, da wundert mich bei den (meist inkompetenten) Hardcore-Jüngern nichts mehr.

;D

Ganon

2005-06-28, 10:32:31

Wenn schon Newsseiten solchen Mist posten, da wundert mich bei den (meist inkompetenten) Hardcore-Jüngern nichts mehr.

Ja, MacTechNews schreibt sehr oft einen ziemlichen Durchfall. ;) Es wurde ja auch schon wieder "angepasst".

Also technische News von MTN sollte man immer mit die Kommentare mit betrachten. Da werden dann die meisten Fehler in den News mit genannt. ;)

ollix

2005-06-28, 11:20:24

Coda

2005-06-28, 12:49:23

Sondern?

Neomi

2005-06-28, 13:13:59

Hmm, jetzt haben sie es in 'Speicherverwaltung' geändert. Aber der Adressbus ist doch bei den 64bittern/AMD64 CPUs aktuell nur bei 40bit, oder? Auch ist das besondere an den '64bit' ja nun nicht in erster Linie der Adressraum.

Wenn ich mich nicht irre, sind es 48 Bit. Den deutlich größeren Adressraum halte ich für DAS absolut entscheidende Feature.

- 64 Bit Berechnungen nativ? Die ein oder andere Sache läßt sich dadurch sicherlich ein wenig beschleunigen. Eine Emulation über zusammengesetzte 32 Bit Berechnungen tut es aber auch, also ist das nicht zwingend.

- Mehr Register? Ja, die sind schon toll. Fehlen diese, nutzt der Compiler eben den Stack, also kein Beinbruch.

- Adressraum? Der ist schon längst arg knapp, hier hilft nur mehr Adressraum. Das läßt sich auch nicht durch Software alleine aushebeln.

Coda

2005-06-28, 13:37:43

AMD64: 48bit virtuelle Addressen, 40bit physikalische Addressen
EMT64: 48bit virtuelle Addressen, 36bit physikalische Addressen

ollix

2005-06-28, 13:46:12

Ja, insbesondere auch unter Windows was den virtuellen Adressraum eines Prozesses angeht (davon soll doch schon FarCry profitiert haben), aber es ist eben nicht das einzige (war falsch ausgedrückt). Im Artikel klingt es aber so, als wenn er nur einen neuen Adressbus bekommen hätte.

Gast

2005-07-02, 13:01:50

IBM: "Wir könnten Apples gesamte Produktlinie abdecken"
-> http://www.heise.de/newsticker/meldung/61335

dazu zwei gute comments:

genau IBM, deswegen gibt es ja 3 Ghz G5s und G5 Powerbooks,...
...
...
...

Die Dual G5s sind zwar wirklich schön, aber wenn die Gehäusegröße
durch die Ausmaße des Kühlsystems bestimmt wird, dann fragt man sich
auch, ob da noch alles knusper ist.

Ich bin überhaupt kein Intel-Fan, aber da kann ich Apple schon
verstehen. Freescale macht viel für Embedded und verdient damit Geld
(nicht mit Apple) und IBM macht's Geld mit Servern (auch wieder nicht
mit Apple).

Unterm Strich ist es von Apple die richtige Entscheidung gewesen und
IBM sollte es eigentlich egal sein. Solche Aussagen von IBM sind eher
peinlich.

btw.
The Xbox 360 and the PS3: late bloomers or complete failures?

The most ironic bit of it all is that according to developers, if either manufacturer had decided to use an Athlon 64 or a Pentium D in their next-gen console, they would be significantly ahead of the competition in terms of CPU performance.

http://arstechnica.com/news.ars/post/20050629-5054.html

zeckensack

2005-07-02, 18:13:38

AMD64: 48bit virtuelle Addressen, 40bit physikalische Addressen
EMT64: 48bit virtuelle Addressen, 36bit physikalische Addressen36 Bit ist doch das Limit von PAE, oder? Zufall? :|

Coda

2005-07-02, 18:14:23

Glaube ich nicht, wahrscheinlich sind die Chipsätze schon auf das ausgelegt gewesen.

Allerdings sind 36bit z.Z. auch noch ausreichend, da kann man Intel nichts ankreiden.

BlackBirdSR

2005-07-02, 18:46:24

36 Bit ist doch das Limit von PAE, oder? Zufall? :|

Man hat sich vielleicht nicht die Arbeit gemacht, wenn die Adressleitungen schon für 36Bit vorhanden waren.
Weiss nicht mehr wo das war, aber die 36Bit im EMT64 Modus haben definitiv mit PAE zu tun.

GloomY

2005-07-02, 20:32:12

Hmm, an der Stelle möchte ich doch noch mal anmerken, dass AMD64 und EM64T komplett 64 Bit (virtuell) können. Denn das sind ISAs - zu deutsch also Befehlssätze. Diese sind 64 Bit Architekturen, können also komplett mit 64 Bit arbeiten.

Etwas anderes sind hierbei die Implementationen dieser Befehlssätze in Form der Athlon64, Opteron, Pentium4, Xeons usw., die nur die angesprochenen 48/40 Bit bzw. 48/36 Bit adressieren können.
Eine neue zukünftige Prozessorgeneration, die AMD64 bzw. EM64T benutzt, könnte mehr Bit als die momentanen Architekturen unterstützen, wäre aber immer noch AMD64- bzw. EM64T-kompatibel.

Insofern ist folgendes eigentlich nicht korrekt:
AMD64: 48bit virtuelle Addressen, 40bit physikalische Addressen
EMT64: 48bit virtuelle Addressen, 36bit physikalische AddressenDas sind die momentanen Implementationen der ISAs. Die ISA selbst kann 64 Bit ohne Einschränkung.

Deswegen nervt es mich unter anderem auch, wenn ich in Hilfeforen lese, dass sich jemand einen "AMD64" kaufen will. Gemeint ist hier ein Athlon64. AMD64 ist der Befehlssatz, Athlon 64 der Prozessor. :)
Bloss können das die meisten Leute nicht auseinanderhalten und schmeissen wild mit den Begriffen um sich...

Coda

2005-07-03, 00:34:46

Das sind die momentanen Implementationen der ISAs. Die ISA selbst kann 64 Bit ohne Einschränkung.Ja. Und?

GloomY

2005-07-03, 02:38:28

Ja. Und?Noch Fragen offen? Hast du meinen Post vollständig gelesen?

Coda

2005-07-03, 10:16:12

Es kam mir so vor als würdest du mir unterstellen das nicht zu wissen wegen dem Quote.

EDIT: Ach so. Ich hätte natürlich derzeitig hinschreiben müssen X-D

Gast

2005-07-10, 13:34:32

Ist ein G4 bei gleicher Taktung nicht einem G5 überlegen?

Gast

2005-07-11, 10:57:55

http://n0cgi.distributed.net/speed/

was ist davon als benchmarkt zu halten?

BlackBirdSR

2005-07-11, 11:22:41

http://n0cgi.distributed.net/speed/

was ist davon als benchmarkt zu halten?

Integral to the mathematics of the RC5 algorithm are 32-bit rotate operations.

For whatever reason, the designers of the IA32 (32bit Intel x86) and the PowerPC architectures decided to implement the rotate function as a hardware instruction.

Many other CPUs do not have built-in hardware rotate instructions and must emulate the operation by (at the very least) two shifts and a logical OR. This handicap is why many non-32bit-Intel [1] and non-PowerPC computers run RC5 slower than one might expect based on real-world benchmarks. It is also the main reason why the RC5 client is a poor benchmark to use in determining the speed or performance of a particular CPU.

http://faq.distributed.net/cache/55.html

RC5 basiert also rein auf 32bit integer operationen. Es reicht zwar, um damit innerhalb einer Familie Vergleiche anzustellen, und sich Informationen zu extrahieren, aber ich würde damit niemals über die Familiengrenze gehen. (also x86 vs PPC)
Die G4 (und G5) haben hier Vorteile, da sie durch die Altivec Unterstützung anscheinend 4 Operationen ausführen können, während ihre Integer Einheit eine 5. beisteuert.

Tigerchen

2005-07-11, 14:16:35

Hmm, an der Stelle möchte ich doch noch mal anmerken, dass AMD64 und EM64T komplett 64 Bit (virtuell) können. Denn das sind ISAs - zu deutsch also Befehlssätze. Diese sind 64 Bit Architekturen, können also komplett mit 64 Bit arbeiten.

Etwas anderes sind hierbei die Implementationen dieser Befehlssätze in Form der Athlon64, Opteron, Pentium4, Xeons usw., die nur die angesprochenen 48/40 Bit bzw. 48/36 Bit adressieren können.
Eine neue zukünftige Prozessorgeneration, die AMD64 bzw. EM64T benutzt, könnte mehr Bit als die momentanen Architekturen unterstützen, wäre aber immer noch AMD64- bzw. EM64T-kompatibel.

Insofern ist folgendes eigentlich nicht korrekt:
Das sind die momentanen Implementationen der ISAs. Die ISA selbst kann 64 Bit ohne Einschränkung.

Deswegen nervt es mich unter anderem auch, wenn ich in Hilfeforen lese, dass sich jemand einen "AMD64" kaufen will. Gemeint ist hier ein Athlon64. AMD64 ist der Befehlssatz, Athlon 64 der Prozessor. :)
Bloss können das die meisten Leute nicht auseinanderhalten und schmeissen wild mit den Begriffen um sich...

Soviel ich weiß sind oben 8 Bit reserviert und sogar eines schon für NX verbraucht. Korrekt?

Coda

2005-07-11, 14:55:37

Soviel ich weiß sind oben 8 Bit reserviert und sogar eines schon für NX verbraucht. Korrekt?
Du meinst von den Addressen? Nein. Es müssen sogar alle nicht-verwendbaren Bits auf 0 gesetzt sein um spätere Inkompatibilitäten zu vermeiden.

zeckensack

2005-07-11, 16:04:28

Soviel ich weiß sind oben 8 Bit reserviert und sogar eines schon für NX verbraucht. Korrekt?Wenn ich mich richtig erinnere, ist das NX-Bit eine Erweiterung irgendeiner "descriptor table" (welche die Umsetzung von virtuellen auf physikalische Adressen steuern), und begrenzt den Adressraum nicht. An diese Dinger kommt man nur im Kernel-Modus ran, sonst wär's ja auch sinnlos. Zeiger, wie sie Applikationen verwenden, sind davon nicht betroffen, und dort gilt die Regel die Coda schon nannte.

GloomY

2005-07-11, 16:06:08

Ack @ Coda.
Soviel ich weiß sind oben 8 Bit reserviert und sogar eines schon für NX verbraucht. Korrekt?
Das NX Bit ist ein Bit in der Page Table, nicht in den Adressen. Neben dem NX Bit gibt es noch eine Reihe anderer Bits, die für jede Speicherseite gesetzt oder nicht gesetzt werden können: read, write, valid/mapped, referenced, modified, shared, caching-disabled, super-page oder pinned (je nach Architektur eventuell sogar noch mehr).

Das NX Bit wird bei der Umwandlung von virtuellen in physikalische Adressen getestet. Wenn der Zugriff auf die Seite vom Instruction Fetch herkommt und die Seite ist als nicht ausführbar markiert ist, dann generiert der Prozessor eine Exception, und das Betriebssystem muss sich um dessen Behandlung kümmern.

Coda

2005-07-11, 17:03:14

Wieso muss für das NX Zeug im 32bit Modus eigentlich PAE aktiviert sein? War im "normalen" Modus kein Bit mehr frei? Oder ist das ganze nur eine Windows-Einschränkung?

Gast

2005-10-21, 03:13:38

Compiler-Vergleich zwischen Intel und MS beim Lame
http://www.techreport.com/reviews/2005q2/opteron-x75/index.x?pg=9

Bei den Benchmarks kann man sehen, dass der Intel-Compiler bei Intel-CPUs besser optimiert als bei den AMD-CPUs. Oder bilde ich es mir ein?
(nicht zeilenweise vergleichen, sondern typweise)

http://www.techreport.com/reviews/2005q2/opteron-x75/lame-cbr-ms.gifhttp://www.techreport.com/reviews/2005q2/opteron-x75/lame-cbr-intel.gif

http://www.techreport.com/reviews/2005q2/opteron-x75/lame-vbr-ms.gifhttp://www.techreport.com/reviews/2005q2/opteron-x75/lame-vbr-intel.gif

Gast

2005-12-07, 00:56:22

http://www.macuser.de/forum/showthread.php?t=131103&page=6

;D

Coda

2005-12-07, 01:23:59

Oh mann. Dieser .ut ist der typische Mac-DAU.

Besonders, weil die Die-Fläache beim x86 erheblich größer ist, als bei einem modernen Prozessor.Auaaaaaaaaa.

TheGoD

2005-12-07, 03:01:35

Dann erkläre mir mal, wie du bei dem 65nm Prozess komplexe Prozessoren fertigen willst, die keine Kühlung brauchen?

Wennn der Prozessor wirklich sparsam wäre, bräuchte er keine Kühlung. Besonders, weil die Die-Fläache beim x86 erheblich größer ist, als bei einem modernen Prozessor.
Warum hast du den lustigsten Teil weggelassen. :biggrin:

Ganon

2005-12-07, 08:36:42

Oh mann. Dieser .ut ist der typische Mac-DAU.

Naja. Nicht ganz. Von OS X und PPC-Hardware weiß er schon viel, was er auch belegen kann. Nur manchmal kommt es zu solchen Ausbrüchen. ;)

Im Vergleich x86-64 und ppc64 scheint er aber Recht zu haben, was 32bit/64bit Mischbetrieb angeht. Zumindest konnte das noch keiner hier widerlegen. ;)

Ansonsten kann man ihm es nicht übel nehmen. Ist halt Buch-Autor. ;)

BlackBirdSR

2005-12-07, 09:23:20

Naja. Nicht ganz. Von OS X und PPC-Hardware weiß er schon viel, was er auch belegen kann. Nur manchmal kommt es zu solchen Ausbrüchen. ;)

Sorry, aber zum Thema x86 kann ich bei seinen Posts nur den Kopf schütteln.

Ganon

2005-12-07, 09:31:16

Sorry, aber zum Thema x86 kann ich bei seinen Posts nur den Kopf schütteln.

Ich weiß, ich weiß... ;)

BlackBirdSR

2005-12-07, 09:32:41

Im Vergleich x86-64 und ppc64 scheint er aber Recht zu haben, was 32bit/64bit Mischbetrieb angeht. Zumindest konnte das noch keiner hier widerlegen. ;)

Was genau meinst du?

Gast

2005-12-07, 09:34:39

Solche ignoranten Typen, die total falsch liegen aber davon überzeugt sind immer Recht zu haben, sind das schlimmste was es gibt. Aber davon gibt es ja leider gerade bei Mac-Usern viele.

BlackBirdSR

2005-12-07, 09:45:56

Solche ignoranten Typen, die total falsch liegen aber davon überzeugt sind immer Recht zu haben, sind das schlimmste was es gibt. Aber davon gibt es ja leider gerade bei Mac-Usern viele.

Es gibt auch sonst überall jede Menge davon.
Und ich bin mir sicher, von mir denken das auch genug Leute ;)
Hängt wohl immer davon ab, wie man zu dem Thema steht.
Also bitte nicht persönlicher oder Abwertender werden. Danke

Ganon

2005-12-07, 09:50:58

Was genau meinst du?

Ich meine Kommentare wie (irgendwo war es auch mal besser erklärt):

http://www.macuser.de/forum/showpost.php?p=1226363&postcount=113
http://www.macuser.de/forum/showpost.php?p=923910&postcount=698

Wie gesagt. Ich hatte hier schon mal irgendwo gefragt ob das stimmt und habe bisher keine, bzw. unzureichende Antwort bekommen.

BlackBirdSR

2005-12-07, 10:20:50

Ich meine Kommentare wie (irgendwo war es auch mal besser erklärt):

http://www.macuser.de/forum/showpost.php?p=1226363&postcount=113
http://www.macuser.de/forum/showpost.php?p=923910&postcount=698

Wie gesagt. Ich hatte hier schon mal irgendwo gefragt ob das stimmt und habe bisher keine, bzw. unzureichende Antwort bekommen.

PowerPC unterstützt im 64Bit Modus auch die Adressmodi der 32Bit Versionen.
PowerPC war von Anfang an auch als 64Bit angedacht, mit zu beginn nur 32Bit Vertretern.
Daher hat man da sicherlich den ein oder anderen Vorteil.

Allerdings kann auch AMD64 beliebig zwischen 32Bit und 64Bit wechseln. So ist es ja auch möglich 32Bit und 64Bit Programme gleichzeitig nebeneinander in Fenstern laufen zu lassen.
Dafür gibt es ja den 32Bit Compatibility-Modus in den die CPU nach belieben schalten kann.

Der große Nachteil ist, dass Yonah nicht wie der PPC970 schon 64it beherrschen. D.h man kann nicht einfach nach Lust und Laune 64Bit nutzen. Man muss erst auf 32Bit und dann auf 64Bit umsteigen mit den neuen Kernen.

Wäre das ein K8, würde ich da nicht so viele Probleme sehen.
Ob das den Kern jetzt trifft weiss ich nicht. Müsste man sich mal einlesen.

ShadowXX

2005-12-07, 10:55:01

Es gibt auch sonst überall jede Menge davon.
Und ich bin mir sicher, von mir denken das auch genug Leute ;)
Hängt wohl immer davon ab, wie man zu dem Thema steht.
Also bitte nicht persönlicher oder Abwertender werden. Danke

Das hat nichts mit persönlich/abwertet zu tun:

.ut ist einer, der selbst wenn er es mit eigenen Augen sehen und nachprüfen könnte, alles bezweifelt und verschwörungstheorien sieht.

Beispiel: Wenn du ihm einen imaginären Intel-Mac hinstellen würdest, der doppelt so schnell wäre wie das jetzige IBM-Mac-Flagschiff würde er immer noch behaupten, das der IBM-Mac in Wahrheit der schnellere, bessere, hübschere, etc. pp. Rechner währe und die höhere Geschwindigkeit nur daran liegt, das Apple den IBM-Mac künstlich ausbremst und Intel sowieso schuld an allem übel auf dieser Welt ist.

Dafür gibts im MacUser-Forum mehr als genug Beispiele.....

Und ehrlich gesagt hab ich auch nie in irgendeinem seiner Posts großartiges Fachwissen über die PPC-Architektur bzw. allgemein den Aufbau von Prozesoren/Architekturen lesen können (und von x86 versteht er gar nichts).

Das er sich mit den OSes der Macs gut auskennt will ich ihm allerdings nicht absprechen, denn das tut er definitiv.

Davon abgesehen finde ich ihn sehr naiv, wenn er wirklich glaubt, das Jobs nur droht.......

Frolic

2005-12-07, 12:55:13

den .ut kenne ich auch noch.
der hat viel erfahrung im OS-bereich. von hardware hat der leider keinen plan und stützt sich nur auf hören/sagen-theorien.

Gast

2005-12-07, 13:35:32

Problem ist aber, daß viele User dort dem alles blind glauben!

Ich bin mal wirklich gepspannt, wie die Intel-Macs nachher wirklich aussehen werden. Wird sicherlich sehr interessant werden.

Gast

2005-12-07, 13:39:59

Problem ist aber, daß viele User dort dem alles blind glauben!

Und? Wenn hier einer der "größeren" etwas sagt, dann glauben ihm auch ein Großteil der Nutzer.

HellHorse

2005-12-07, 17:46:37

Der große Nachteil ist, dass Yonah nicht wie der PPC970 schon 64it beherrschen. D.h man kann nicht einfach nach Lust und Laune 64Bit nutzen. Man muss erst auf 32Bit und dann auf 64Bit umsteigen mit den neuen Kernen.
Solange bloss libSystem auf 64 bit portiert ist, ist sowieso nichts los mit 64 bit auf dem Mac. Von dem her würde es auch keinen Unterschied machen, wenn Yonah 64 bit könnte.

Gast

2006-01-13, 14:43:35

wieder so ein gefrusteter mac-user ;D

also das wird richtig abenteuerlich, was dieser kai in den comments schreibt:
http://www.macguardians.de/fullstory.php?p=4060&c=1&bereich=1

Juerg

2006-01-13, 15:05:08

Wieso muss für das NX Zeug im 32bit Modus eigentlich PAE aktiviert sein? War im "normalen" Modus kein Bit mehr frei? Oder ist das ganze nur eine Windows-Einschränkung?Ja das täte mich auch mal interessieren tun :|

Ganon

2006-01-13, 15:09:06

wieder so ein gefrusteter mac-user ;D

also das wird richtig abenteuerlich, was dieser kai in den comments schreibt:
http://www.macguardians.de/fullstory.php?p=4060&c=1&bereich=1

Tja. Seine Argumente fußen leider auf vielen Fehlinformationen... und dann gibt er noch Apple die Schuld das Freescale nicht den FSB erhöht hat...

Den 7448 gibt es leider immer noch nicht, Altivec ist auch nicht 64bit und von PASemi sehen wir erst in 2 Jahren was... mit 2Ghz :/. Eigentlich sind fast alle seine Argumente falsch... naja.

Wobei in einem Punkt (ist aber nix neues was er entdeckt hat ;)) ist es trotzdem komisch.
In einigen Benchmarks von Apple ist Yonah wirklich nur "2 mal so schnell". Das bei 4fach Cache, höherem FSB und 2 Kernen. Und das gegen einen G4...

Gast

2006-01-13, 17:10:30

Wobei in einem Punkt (ist aber nix neues was er entdeckt hat ;)) ist es trotzdem komisch.
In einigen Benchmarks von Apple ist Yonah wirklich nur "2 mal so schnell". Das bei 4fach Cache, höherem FSB und 2 Kernen. Und das gegen einen G4...

Was für Benchmarks? Vermutlich welche mit Altivec ;)

Ganon

2006-01-13, 17:46:38

Was für Benchmarks? Vermutlich welche mit Altivec ;)

Guck auf die Apple-Seite. FinalCut, Pages, etc.

Bloß wenn du so argumentieren willst:

Bei hochoptimierter Software mag der G4 <gleichschnell> sein. Was passiert, wenn für Yonah erst mal optimiert ist?

Gast

2006-01-18, 00:26:58

Im Vergleich x86-64 und ppc64 scheint er aber Recht zu haben, was 32bit/64bit Mischbetrieb angeht. )

http://www.macguardians.de/index.php?p=4085&c=1#comments

"Windows XP Professional x64 Edition provides a rich platform to integrate 64-bit applications and existing 32-bit applications using the Windows on Windows 64 (WOW64) x86 emulation layer, providing customers with the ability to move to 64-bit computing without having to sacrifice their existing investment in 32-bit software and Windows expertise."

Gast

2006-01-18, 01:51:41

Salve Big Brother. Mein Gott, wie schlecht. Hier machen sich ein paar Nerds lustig über User in anderen Foren? 10 von 10 möglichen Punkten für schlechten Stil. Habt ihr das nötig? Na ja, wat soll's?

64Bitter

2006-03-18, 14:17:24

Der x86 mag schnell sein, ist aber technisch gesehen einem modernem Prozessor wir dem G5 unterlegen. Der x86 stammt von einer Taschenrechner CPU ab, die grob gesagt immer erweitert wurde. So auch mit 64Bit. Der G5 hingegen ist von Grund auf ein echter 64Bit Prozessor.
the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode

So kann gerade der G5 seine enormen Vorteile im Mischbetrieb von 32Bit und 64Bit Anwendungen ausspielen. Das Mac Betriebsystem ist teilweise schon auf 64Bit portiert (libSytem) und trotzdem bedarf es keiner extra Treiber, wie beispielsweise bei Windows 64Bit:
First, and foremost, tell your printer manufacturer that you want a 64-bit driver"
http://www.microsoft.com/windowsxp/using/64bit/russel_x64faq.mspx

Beim Mac PowerPC ist wie schon gesagt nur eine Library (libSytem) auf 64Bit portiert, aber der Rest bleibt gleich und läuft auf dem G5 ohne Probleme! Beim x86_64 unvorstellbar, da x86-64 wieder eine komplett andere Architektur als x86 ist. Kompatibiliäts-Modi hin oder her! Egal ob Windows 64Bit oder Linux 64Bit, beim erweitereten x86 mit 64Bit hängen bestimmte Bibliotheken immer doppelt im System. Ebenso müssen extra 64Bit Treiber her. Bei Mac OS Power PC ist das hingegen aufgrund der Überlegenheit des G5 nicht so! Der blendet mal eben für 32bit die obere Registerhälfte aus! ;)

Coda

2006-03-18, 15:02:29

Bitte den letzten Post komplett ignorieren. Er enthält ausschließlich geistigen Dünnschiss.

Der Kernel muss auch beim PowerPC für 64bit-Betrieb vollständig 64bit sein.

Ast

2006-03-18, 15:22:24

Na Horsti?

For most developers, 64-bit functionality in Mac OS X version 10.4 will have no impact on them. Most device drivers do not need to change (see “Device Driver Issues” for more information), and applications do not have to move to a 64-bit executable format. Most 32-bit applications will be better served by remaining 32-bit.

Because 64-bit applications will be supported using a 32-bit kernel, this 64-bit support will have no impact on most device driver or kernel extension writers. However, there are exceptions, as explained in “Device Driver Issues”.

Before we go further, it is important to dispel a few common misconceptions.

Myth #1:
Myth: My application has to be 64-bit (or run on a G5) to use 64-bit data or do 64-bit math.

Fact: 32-bit applications already have the long long data type, which is 64 bits.

Myth #2:
Myth: The kernel needs to be 64 bit in order to be fully G5-optimized.

Fact: The kernel never needs to directly address more than 4 GB of RAM at once. The kernel is able to make larger amounts of memory available to applications by simply using long long data types to keep track of mappings internally.

Myth #3:
Myth: All of the system calls have to change (or new ones have to be added) for 64-bit compatibility.

Fact: Most of the system call arguments changed to 64 bit many years ago. Functions like llseek64 are unnecessary because those functions are already 64 bit capable. The notable exceptions are those functions related to memory management, such as mmap, malloc, and so on. Those functions have changed in terms of the size of data passed (since the size of size_t changed), though this change should be largely transparent to you as a programmer.

Myth #4:
Myth: Every application needs the ability to work with more than 4 GB of RAM.

Fact: Most applications have relatively modest memory requirements (a gigabyte or less). Some applications need more. Many of these applications can do so without moving to a 64-bit address space. Generally speaking, only scientific applications have moved to 64-bit executables on other platforms. There are a few exceptions, though, such as large-scale 3D rendering applications.

Myth #5:
Myth: My application will have much faster performance if it is a “native” 64-bit application.

Fact: This is true for some other architectures because the number of registers and the width of registers changes between 32-bit and 64-bit mode. However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode. Thus, on PowerPC architectures, software does not generally become faster (and may actually slow down) when compiled as a 64-bit executable.

http://developer1.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.html