ARCHIV 1999-2006

ARCHIV :: # 2414

Neue AfterFX-Tests

G5 weiterhin ganz vorne mit dabei

Autor: kai - Datum: 01.10.2003

Es gab Leute, die waren mit Nightflight als AfterFX-Test unzufrieden weil sie die Macs bevorteilt sahen und deshalb wurde ein neuer Test namens "Burning Man" ins Leben gerufen. Wie uns Leser Markus Klöck informiert ist dieser jetzt fertig und die ersten Ergebnisse sind da. Dieser Test ist in 2 Teile aufgeteilt: Teil 1 hat den Fokus auf roher CPU-Power und berechnet die Frames, die dann in Teil 2 von Disk geladen werden um verrechnet zu werden. Ergebnis: In Test 1 ist der Dual G5 mit nettem Abstand ganz vorne und in Test 2 hinter einem Dual Xeon 3GHz und ein paar 3GHz P4s. Da leider bei den ansonsten sehr umfangreichen Angaben zum System der verwendete Massenspeicher (SCSI, IDE, Software-RAID oder Hardware-RAID, wenn RAID: über wieviele Disks? Oder wurde gar eine RAM-disk verwendet?) komplett fehlt ist die Aussagekraft von Test 2 allerdings sehr zweifelhaft. Wenn Diskzugriff die ausschlaggebende Komponente ist (woran ja per se nichts auszusetzen ist) sagt Test 2 wohl eher in zweiter Linie etwas über die Leistungsfähigkeit aus. Aber: ohne das verwendete Disksystem zu kennen ist er eigentlich nutzlos. Was allein schon die Unterschiede zwischen den laut Tabelle völlig identisch ausgestatteten 2 3GHZ P4s auf Platz 2 und 4 sehr schön illustrieren. Ich verstehe nicht ganz, wie man einen Test machen kann, dessen erklärtes Ziel es ist, Disk-I/O mit in den Test einzubeziehen (weil das praxisnaher ist, was ja stimmt!), der dann aber das verwendete Disk-System völlig aussen vor lässt.. Das ist ungefähr so sinnvoll wie ein Quake-Test ohne Angabe der Grafikkarte! ;-)

Auch die Tatsache, dass die Single-CPU-Modelle in diesem Test so weit nach vorne kommen (auch bei Test 1 folgt ein Single-P4 direkt dem Dual Xeon) sagt wieder mal alles über die Dual-Eignung von AfterFX.. Auch wenn Brian und andere PC-User den Nightflight-Test nicht mochten: Er nutzte wenigstens die Filter, die von Dual-CPU profitieren, und das sogar sehr gut (Faktor 1.9, auf Mac und PC!).

Kommentare

OT

Von: comical ali | Datum: 01.10.2003 | #1
wer hat einen qtopia (von trolltech) basierenden handheld?
der freut sich sicher uber:
[Link] iaDesktop-1.7.0-macosx.tar.gz
;)

hab mal kurz reingeguckt: so schoen ich es finde dass es das gibt, es zeigt aber mal wieder was man alles an den schoenen iapps hat, auch wenn die einem bei diesen pdas wohl nicht weiterhelfen...

zu den benchmarks

Von: comical ali | Datum: 01.10.2003 | #2
ein toller benchmark waere ja auch wenn man auf verschiedenen platformen ein cpu- und hd-intensives opensource projekt compiliert (meinetwegen auch mit verschiedenen compilern).
wie waers denn mit einem dvd-shrink tool. die benchmarks gibt es in jeder videothek auszuleihen.(nicht vergessen: danach wieder loeschen, waere ja sonst illegal!!!) ist auch nicht vom grafikkartentreiber abhaengig!!!
an dieser stelle wie immer der link zur anleitung:
[Link]

OT naechster versuch

Von: comical ali | Datum: 01.10.2003 | #3
ich weiss jetzt nicht ob der link diesmal ankommt:
[Link]

ansonsten einfach zusammenbaseln...

comical ali:

Von: Kraftbuch | Datum: 01.10.2003 | #4
pass auf, dass man dich nicht bald "compiler ali" nennt ;-))

mattin:

Von: Kai (MacGuardians) | Datum: 01.10.2003 | #5
Ja, das war für mich auch der Aufreger des Tages!... Checkt Macromedia eigentlich überhaupt noch irgendwas??

liebes kraftbuch

Von: comical ali | Datum: 01.10.2003 | #6
ich bins nicht der hier rumtoent, dass alles nur an den compilern liegt. gleichwohl gibt es solche leute. selbige veroeffentlichen hier auch alle 4.5 stunden neue g5 benchmarks. gehen aber auf vorschlaege zu selbstgenerierten realworld-benchmarks komischerweise nicht ein.

die chance ist einmalig! es gibt leicht zu handhabenden code. es handelt sich um eine anwendung die weit verbreitet ist. sie sollte performanceintensiv genug sein. das benchmarkmaterial kann man so auswaehlen, dass die ergebnisse nicht durch messstreuungen verfaelscht werden. es gibt fuer unser aller lieblingsplattform (noch!) zwei kostenlose compiler, womit man deren optimierungspotential abschaetzen koennte. was will man mehr? es gibt sicher auch leute, die das compilat sehr erfreuen wuerde <ggg>

also auf gehts ...

Comicali:

Von: Kai (MacGuardians) | Datum: 01.10.2003 | #7
Ich entschuldige mich vielmals, aber leider habe ich weder einen XLC, noch weiss ich, wie man diesen einbindet & richtig bedient, noch habe ich einen G5 oder auch nur einen G4, der auch nur ansatzweise das Prädikat "aktuell" verdient!

Wenn dir das so am Herzen liegt dann kompilier's doch selbst aber nerv mich nicht damit!

Das Ding existiert übrigens schon in einer G4-Version. Es heisst "DVD Remaster" und es ist doppelt so schnell wie DVD2one, also was willst du eigentlich?

@kai

Von: comical ali | Datum: 01.10.2003 | #8
nu sei doch nicht gleich sauer ;)
der neueste mac der hier rumsteht hat auch schon 2.5 jahre aufm buckel :(

zu xlc gibts doch bestimmt ein tutorial. und einbinden muss mans ja nicht. ausserdem kann man auch auf aelteren macs sehen, welches potential der compiler in sich buergt ...

und dieses dvd remaster kann man kaufen. das wusste ich auch. mir gings ja gar nicht um die funktionalitaet dieses tools. es ging um benchmarking. selbst generiert und besser nachvollziehbar als alles andere. und es ging um vergleich gcc xlc. sprich um die frage: was bringt neukompilieren!

und natuerlich gings darum wie schnell du antwortest <ggg> koennte man auch einen benchmark drausmachen...

nichts fuer ungut, aber da haette man mal einen echt guten vergleich gehabt.

zu den Benchmarks

Von: xl | Datum: 01.10.2003 | #9
Wenn man bedenkt, wie riesig der Performance Unterschied zu PC´s noch vor kurzem war, kann man doch ganz zufrieden sein. Der G5 rendert ca dreimal so schnell wie mein alter QS 867 da lohnt sich die Neuanschaffung auf jeden Fall.

Was die, wieder mal von Euch bemängelte MP Performance angeht, so solltet Ihr bedenken, daß bei Compositions mit viel eingebundenem Footage, ein Großteil der Renderzeit aus Festplatten- bzw Netzwerkzugriffen besteht - da helfen auch 4 oder mehr Prozessoren nichts. Daher entspricht auch der zweite Test viel eher dem Arbeitsalltag mit AE (auch wenn natürlich Filter von Drittherstellern, bestimmt wieder ein ganz anderes Bild zeigen würden, die sind nämlich leider oft nicht MP fähig).

Ich gehe davon aus, daß die schnellsten der hier getesteten PC´s (insbesondere die Xeon Workstation), mit SCSI Raids on Board ausgestattet sind. Da hat der G5 natürlich Pech, weil man da immer auf externe Raid Lösungen setzen müsste (im Übrigen einer meiner Hauptkritipunkte am G5: die für profesionelle Videoanwendungen ungenügende Erweiterbarkeit, da ist man wieder auf Krücken wie PCI-Extender angewiesen, die leider immer potentielle Fehlerquellen sind.).

Ich jedenfalls werde nicht, wie eigentlich geplant, auf PC umsteigen - sondern dem G5 eine Chance geben.

@cyrus bzgl Benchmarking

Von: Rüdiger Goetz | Datum: 01.10.2003 | #10
Hallo,

> es ging um benchmarking. selbst generiert und besser
nachvollziehbar als alles andere

Yepp, deshalb hab ich schon vor Jahren eine eigene Suite zusammengestellt (zugegebnerweise ausgerichtet auf Sachen, bei denen es _mir_ auf Performance ankommt).

Nur leider ist der neuste Mac, an den ich rankomme ein iceBook mit 500MHz G3. Und dem Vernehmen nach bringt der xlc beim G3 noch nicht so viel.

Aber es steht jedem frei es mal auszuprobieren. Wobei ich zugegebn muss lange keine Ergebnisse nachgetragen zu haben. Ich hab noch einige x86er Rumzuliegen.

Bis dann

R"udiger

[OT] Ali und sein Benchmark

Von: Leo | Datum: 01.10.2003 | #11
Also kompileren tut der Requantizer schon mal mit xlc. (Nur eine geringfügige Änderung im Code ist nötig: in der Quelldatei main.c in Zeile 143 die drei Punkte (...) entfernen).

So und jetzt, was möchten wir damit machen? Ich habe leider keinen G5 und dummerweise *hhnnnnaargh* habe ich kein DVD-Laufwerk in meinem G4... :-(

Aber ich kann ja die Binaries vom Programm verschicken...?

@R"udiger,@Leo

Von: comical ali | Datum: 01.10.2003 | #12
@R"udiger:
ich habe versucht deine unixsourcen zu compilieren (welche compilerflags gibts eigentlich fuer den 7450?) leider gabs ne fehlermeldung und ich hab leider nicht die zeit mich darum zu kuemmern (bin auch nicht _der_ hacker ... :( )
--------
g++ -DUNIX auswertung.cc -o Auswertung -lm
auswertung.cc:19: `main' must return `int'
make: *** [Auswertung] Error 1
--------
vielleicht haste ja ne idee?
@Leo:
doofe frage: hast du die demoflags entfernt? <ggg>
also wenns dir nichts ausmacht wuerde ich folgendes vorschlagen:
du compilierst - ich teste. habe auch testmaterial da! muesste nur mal die platte aufraeumen und platz schaffen ;)
wuerde auch mehrere versionen testen (also mit gcc compiliert, mit xlc compiliert, tolle optimierung weniger tolle etc. ) kann aber dauern, da ich im stress bin (muss immer bei mg dusselige kommentare schreiben)
hab nen G4 733 mit L3 cache falls das interessiert.

[OT] Requantisierer-Binaries

Von: Leo | Datum: 01.10.2003 | #13
In meinem iDisk-Public (im Ordner „Ali”) liegen jetzt die Kompilate für den Requantizer aus gcc und xlc. Ich kann sie wie gesagt leider nicht ausprobieren.

[Link]

Außerdem versuche ich gerade mal R"udigers Benchmark mit xlc zu kompilieren.

@leo

Von: comical ali | Datum: 01.10.2003 | #14
das ist nicht OT das ist endlich mal was genaues <ggg>

*kurz mal zum link geschielt*

wow-> da hat sich jemand echt mehe gegeben! danke ...

nochmal die fuer die benchmarks unwichtige frage: hast du den code der den film ungeniessbar macht rausgenommen?

@ali: ungenießbar

Von: Leo | Datum: 01.10.2003 | #15
Och, ist das nicht illegal? Also ich bin mir nicht mehr sicher, also...
Probier's mal aus *g*

(OT stand in diesem Fall auch für "on topic", hehe)

@comical ali

Von: me@r-goetz.de | Datum: 01.10.2003 | #16
Hallo,

Ja hab. Ich hab immer noch vergessen, die gcc3.x-Variante hochzu laden. Der gcc3.x ist an einigen Stellen wesentlich mäkliger als der gcc 2.9.x. Ich hab jetzt eine angepasste Version hochgeladen. Diese sollte - soweit der gcc die selbstständig tut - auch Altivec benutzen. Dazu musst du aber im Makefile die entsprechenden G4-Zeilen einkommentieren.

GGfs Schick mir ne Mail.

Bis dann

R"udiger

@ali: Festplatte

Von: Leo | Datum: 01.10.2003 | #17
Ich denke, die Wahl der Festplatte ist nicht so wichtig. Wenn (wie der Onkel sagt) die Konvertierungszeit ca. 30 Minuten beträgt, sind das etwa 3 MByte/s, die der Algorithmus verarbeitet. Das sollte sogar deine FW-Platte hinbekommen (wenn man davon ausgeht, dass der Algorithmus die Daten in schönen großen Blöcken in den Speicher zieht, was er sicher tut). Nimm also die, die dir jetzt am wenigsten Stress bereitet.

@leo und @r"udiger

Von: comical ali | Datum: 01.10.2003 | #18
ihr beiden bench-knuffelbacken ;)

super team! ihr solltet mal was sinnvolles machen ;) <hihi> gar nicht auszumalen, was dabei heraus kommen wuerde. oder noch besser: fangt bei macromedia an, und wenn ihr da fertig seid, zieht ihr von einer softwarebude zur naechsten <ggg>

die ergebnisse die leo postete sprechen ja wohl eine eindeutige sprache. kai hatte recht: optimierende compiler sind wichtig.
sehr wichtig!!! haette er ja auch selber verfizieren koennen <ggg>

ich werde meinen teil demnaechst mal in angriff nehmen (also requantisieren ...)
sehe ich das jetzt richtig: je hoeher der requantisierungsfaktor desto mehr hat der rechner zu rechnen?

"kai hatte recht: optimierende compiler sind wichtig."

Von: Leo | Datum: 01.10.2003 | #19
Hmmm... Ich denke da an eine Diskussion zwischen Kai und mir bei MacGuardians im Juni, wo ich Apple die Verwendung von gcc für die SPECbenchs angekreidet hatte und für die Wichtigkeit hochoptimierender Compiler eintrat *g*:

[Link]


Allerdings sind optimierende Compiler wichtig! Seit es IBMs xlc-beta für den Mac gibt, interessiert man sich für die gcc-Werte bei Performancemessungen eher zum Schmunzeln. Bei x86 ist das nur schon länger so.

@Kai: Bitte schlag mich nicht ;-)

@leo

Von: comical ali | Datum: 01.10.2003 | #20
ich wollte jetzt keinen besonders hervorheben ;)
das groesste lob gebuehrt natuerlich den beiden benchisten (s.o.)

@Leo

Von: Rüdiger Goetz | Datum: 02.10.2003 | #21
Hallo,

RGBench 1.5.1 ist in der Tat ohne Vorschläge für AltiVec-Optionen beim gcc. Ich hab wegen fehlern mit gcc3.x eine Verison 1.5.2 heute hochgeladen.
Dort sollte beim gcc auch AltiVec eingeschaltet sein. Allerdinmgs gibt es keine speziellen AltiVec-Optimierungen im Programm-Code.

Das würde bei einem Crossplattform-Benchmark auch nur dann Sinn machen, wenn man für alle Plattformen, per Hand qualitativ gleichwertige Optimierungen einbauen würde, was aber kaum machbar ist. AltiVec/ISSE/etc.-Optimierung sollte Sache des Compilers sein.

BTW Leo, Du hast deine Läufe unter OS X 10.?.? mit gcc?.?.? gemacht ? (ggc 3 bringt im Vergleich zum gcc 3 einiges, vor allem im int-Bereich und bei Ausnutzung von AltiVec)

Hier noch ein Parr RGBench Ergebnisse, die bisher auf meiner Seite fehlen (zum Vergleichen):

PIII 1000 MHz , gcc 2.9.5
float Average 1050 %
int Average 931 %
total Average 1001 %

PIII 1000 MHz, gcc 3.2.3
float Average 1235 %
int Average 975 %
total Average 1131 %

PIII 800 MHz, intel-Compiler (beta-Version von 2001)
float Average 1367 %
int Average 1285 %
total Average 1333 %

PIII 800 MHz, gcc 2.9.5 (siehe auch meine HP)
float Average 905 %
int Average 802 %
total Average 864 %

Ergo, der Intel-Compiler bringt gut 50 % im Vergleich zum gcc2.9.5. Der gcc3.2 auf x86 bringt ca 10-15 % .

P4 2.4 GHz FSB800, gcc 3.3
float Average 2326 %
int Average 1714 %
total Average 2081 %

Mit Intel-Compiler dürfte da noch mal ca 40 % mehr drin sein. Das wäre wohl die Messlatte für einen G5 1.6 GHz.

Und noch wat altes:
PowerMac G3 350 Mhz, gcc.2.9.5
float Average 499 %
int Average 416 %
total Average 466 %

PowerMac G3 350 Mhz, gcc.3.2.1
float Average 495 %
int Average 465 %
total Average 483 %

Fazit: Auf einem G3 bringt der gcc 3.2 im FP-Bereich nix (der Unterschied 499 zu 495 liegt im Messrauschen), aber ca 10 % im int-Bereich.

Eines zeigt sich hier aber deutlich. Bei einem Crossplattformbench muss immer die Combo aus Hardware und Compiler betrachtet werden.
Wobei man sich Fragen kann, ob man die jeweils höchstoptimierenden oder die gebräuchlichsten Compiler vergleicht. Beides hat seinen Berechtigung. Das eine zeigt das Potential der Hardware am besten an, dass andere eher, dass was für den Anwender aktuell zu erwarten ist.

Und jeder Bench sagt eigentlich nur etwas über die Performance bei den betrachteten Anwenungen aus. Für die eigene Entscheidung sollte man daher möglichst viele Benchs vergleichen und nach dem eigenen Anwendungsprofile wichten. Nur so bekommt man ein stimmige Bild. Auf wissenschaftliche Anwendungen orientierte Benchs, wie SPEC oder eben mein RGBench, sagen etwas über die pure Rechenlsitung eines Systems aus und versuchen Einflussfaktoren wie Grafik und Festplatte so klein wie möglich zu halten (weil die eh langsam sind und die Programme unnötig ausbremsen). Andere Benchmarks beziehen mehr/andere Systemkomponenten ein. Erst die "Summe" gibt dann ein stimmiges Bild.

Bis dann und gute Nacht

R"udiger

Leo:

Von: Kai (MacGuardians) | Datum: 02.10.2003 | #22
Hey, ich war der, der schon zu G4-Zeiten ständig auf die Notwendigkeit für hochoptimierende Compiler aufm Mac hingewiesen hat! ;-)

Und daran hat sich nichts geändert! Ist mir schon klar, dass der XLC mehr bringt, ich habe den dessen Release für OS X ja auch aus eben diesem Grunde herbeigefiebert! ;-)

Doch ich bleibe weiterhin dabei: Wenn Apple GCC auf x86 gegen GCC auf G5 antreten lässt, dann ist das nicht 'unfair'! Wenn Schumacher und Coulthard statt in Formel1-Autos in Strassenwagen oder Go-Carts zum Rennen antreten ist das auch nicht "unfair", sondern einfach andere, selbst gesteckte Ausgangsbedingungen, die auf keinen Fall eine Partei bevorteilen, sondern einfach nur anders gesteckt sind!
Es gab zu dem Zeitpunkt eben noch keinen XLC, sonst hätte Apple diesen verwendet! Unfair wäre es gewesen, einen hochoptimierenden Compiler wie den ICC gegen den GCC zu testen!

Und dass der GCC besseren x86-Code ausspuckt als PPC-code ist auch weiterhin ein Faktum!

@Leo & @Kai

Von: Rüdiger Goetz | Datum: 02.10.2003 | #23
Hallo,

Da ich enen fairen Benchmark machen wollte, hätte ich auf allen Plattformen (und das schloss ursprünglich IRIX, HPUX ... ein) jeweils gleich guten handoptimierten Code schreiben müssen. Sorrz, aber das überfordert mich (BTW: HPUX hatte damals Fortran/C-Funktionen mit denen man handoptimierten Vektorcode in normale Progarmme einbinden konnte.,z.B. Vektor e = Vektor a + vektor b * skalar c, hat ca. einen Faktor 2 gebracht, damals auf Kisten mit HPPA 7100-CPU ).

AltiVec-CVoden wollteb ich schon lange, nur macht es auf meinen Macs keinen Sinn (Yosi & iceBook). Mal sehen wann ich mir einen neuen Mac leisten kann.

@Kai:
> Doch ich bleibe weiterhin dabei: Wenn Apple
>GCC auf x86 gegen GCC auf G5 antreten
>lässt,

ACK, dass meinte ich mit:
> Wobei man sich Fragen kann, ob man die
> jeweils höchstoptimierenden oder die
> gebräuchlichsten Compiler vergleicht. Beides
> hat seinen Berechtigung.

Und getestet wurde der PC ja unter Linux und dort ist der gcc mit Sicherheit der gebräuchlichste Compiler, so wie er es auch unter MacOS X ist (im Moment jedenfalls noch).

Das der PPC-Code des gcc vergleichsweise schlecht ist, hört man zwar immer wieder. Ich frage mich nur wie man das feststellen will? Den vergleichen kann man immer nur die Compiler/Hardware-Combo. Und keiner kann sagen ob z.B. der Intel-Compiler das Potenzial des P4 zu 90% ausschöpft (das dürfte das beim gcc3-x86 ca 60 % sein) der xlc das Potenzial des G5 aber nur zu 75% (_dann_ würde der gcc3-ppc das Potenzial zu 45 % ausnuzten, als Potenzial hab ich mal die maximal erreichbar Performance mit dem ultimativen Compiler, der immer optimalen Code erzeugt, definiert). Man hat hier ein Henne/Ei Problem. Man müsste es also an der Code-Struktur festmachen. Und da hab ich wenig genaues gelesen, dass belegen würde das der gcc-x86-Code näher am Optimum wäre als beim ppc.

Bis dann

R"udiger

*riesentusch* meine benchmarkergebnisse

Von: comical ali | Datum: 02.10.2003 | #24
mein system:
G4 @733 MHz, 1 MB L3Cache
1GB RAM, 10.2.8

mein test:
getestet habe ich mit den von leo compilierten requantisierer (die links findet ihr itgendwo ;))
cat quelle.m2v | /<pfad>/requant<version> 2 > /<pfad>/ziel.m2v
so hab ichs gestartet. die quelldatei war ein 3.27GB grosser video-mpeg2stream. die zieldatei war halb so gross(1.64).

meine ergebnisse:

requantGCC : 46:12 min
requantGCC_O3 : 16:07 min
requantXLC_O5 : 28:28 min

hat mich irgendwie vom sockel gehauen!!! man kann sicher auch kleinere dateien nehmen! habe jetzt aber keine zeit mehr :(
vielleicht kann das ja mal einer ueberpruefen? wenigstens die letzten beiden werte!!!

@ comical ali

Von: Rüdiger Goetz | Datum: 02.10.2003 | #25
Hallo,

Bist du sicher das du für eine G4+ übersetzt hast?
Sonst könnte es sein, das der Compiler u.U. stark auf eine andere CPU (G5,G3) optimiert und der Code für den G4 suboptimal ist, (z.B. falsche Annahmen über die Branchprediction und dadurch viele Pipe-Stalls)

Wobei moch schon etwas wundert, dass der xlc so schlecht läuft.

Bis dann

R"udiger

@r"udiger

Von: comical ali | Datum: 02.10.2003 | #26
ich habe gar nichts uebersetzt ... das war leo. der ist schuld :)

ich lass nur laufen ...

Performance-Regression

Von: Leo | Datum: 02.10.2003 | #27
"Wobei moch schon etwas wundert, dass der xlc so schlecht läuft."

In der Tat, mich auch. Ist das erste mal, meiner Erfahrung nach. Übrigens schedult xlc defaultmäßig für G4, wenn man nichts anderes angibt. (Da sieht man mal, wie instabil Optimierungen sind. So etwas wie einen "allgemein nur ein bisschen optimierenden Compiler" gibt es nicht. Es ist völlig verschieden, wo welcher Compiler/Optimierung gut aussieht. Deswegen finde ich ja das Argument, dass gcc-PPC vs. gcc-x86 interessant sei, weil beide Compiler "nur ein bisschen optimieren und zwar ähnlich schlecht", so albern. Die haben u.A. völlig andere Optimierer eingebaut, die bei völlig verschiedenen Codes mal einen „Glückstreffer” landen.)

*Andererseits*: Es gibt bei xlc -zig verschiedene Optimizerflags und die Anzahl sinnvoller Kombinationen dürfte in die Hunderte gehen. Ich habe eben einfach nur -O<Zahl> probiert, aber da kann man an unglaublich vielen Schräubchen drehen, die alle fein dokumentiert sind.
xlc kann sogar so perverse Sachen wie Profiling-gesteuerte Auto-Optimierungen, d.h. er probiert bestimmte Optimierungen, dann lässt man das Programm kontrolliert laufen, er schaut, was an der Optimierung gut war und was nicht, und dann das ganze von vorne etc. Im Übrigen ist xlc ja noch Beta, ich habe auch Bugs finden/reporten können. (Vielleicht schenken sie mir ja irgendwann die Finalversion *g*).
Ich bin mir sicher, dass man die 967 s von gcc schlagen kann mit xlc, es ist eine Frage des Aufwands. Ich vielleicht gleich auch mal eine Requantisierung.

@ali: Wenn du wirklich Lust hast da einzusteigen, installier dir doch den IBM-Compiler! Das ist keine große Sache und die Doku kann sich sehen lassen (mit schickem "Getting Started" und so).
Da lernt man ne Menge über Optimierung und du siehst ja selbst, wie groß die Unterschiede sein können.
Solltest du Probleme bekommen, schreib mir eine Mail (leofinkATmacPUNKTcom).

Der gute alte CodeWarrior

Von: Leo | Datum: 02.10.2003 | #28
Den hatten wir vergessen! CW ist fast immer schneller als gcc...
Ich hab's mal zu den anderen Binaries gelegt (requantCW). Bin gespannt.

Fairer Vergleich und Glückgriffe

Von: Rüdiger Goetz | Datum: 02.10.2003 | #29
Hallo,

> Deswegen finde ich ja das Argument, dass
> gcc-PPC vs. gcc-x86 interessant sei, weil beide
> Compiler "nur ein bisschen optimieren und zwar
> ähnlich schlecht", so albern.

Das Argument macht nicht viel Sinn, der vergleich ist trotzdem relevant. Der gcc ist Apples Standardcompailer und er ist der Standardcompiler unter Linux/x86. Und Apple hat mit Linux/86 verglichen. Somit war es ein Vergleich Standard-Compiler gegen Standardcompiler (wobei unter Mac OS man einwenden könnte, das wäre der CW).

Zum Thema Glücksgriff. Als ich RGBench geschrieben habe, hatte ich ein Programm noch dabei, das ganz empfinlich davon abhing, ob der Compiler ein aggressives Loop-unroling macht oder nicht. Leider steckte 95 % der CPU-Zeit in einem kurzen Programmteil das ohne unrolling langsam und mit sher schnell war. Da dieser Unterschied zu drastisch war und dieser eine Vorteilhaft Situation das ganze Bench-Ergbenis dominiert hätte, hab ich es dann weggelassen.

U.U. haben wir hier was ähnliches. Aber dazu müsste man wohl mit den Optimier-flags spielen.

Bis dann

R"udiger

Danke Jungs!

Von: Thyrfing | Datum: 02.10.2003 | #30
Ich habe zwar nix verstanden, aber man kann eure Diskussion recht spannend lesen und erahnen um was es geht, was ihr tut und welche Ergebnisse ihr bekommen habt. Danke! Endlich wieder eine Diskussion!

Thyr

intelstandart

Von: mattin | Datum: 02.10.2003 | #31
Dies bietet Ihnen unsere BX Serie: [Link] und da den farbkabel lt. intelstadart zur einfachen installation [Link] flash teaser angucken

upss tschuldigung

Von: mattin | Datum: 02.10.2003 | #32
wollte nicht stören, das sollte hier [Link] hin. bin verrutscht :)

xlC holt die Krone zurück

Von: Leo | Datum: 03.10.2003 | #33
Ha, ich habe den Fehler gefunden. Der Code ist eigentlich C++, deswegen muss man das File in main.cpp umbenennen und xlC nehmen (statt xlc), da sonst das "inline"-Schlüsselwort ignoriert wurde.

Bei mir ist es nochmal gut 20% schneller als gcc, hehe...

Ich habe das Binary zu den anderen hinzugefügt (requantXLC_CPP). Probier mal mit deiner Videodatei.