Steinbergs CuBase als Benchmark

[Haarmann]

Mein Kollege stellt Goa her (diese Ausdrucksweise ist Absicht). Wie viele seiner Artgenossen nutzt er dazu das PRG vom Titel. Er nutzte dazu bisher einen Athlon XP 1700+ auf einem AMD Chipset mit Via SB und ner Audigy2 mit KX Treibern.
Das System war ihm allerdings zu langsam, resp man musste sich behelfen, weil die Leistung nicht mehr für alles in Echtzeit reichte. Also baute er sein System um un nutzt nun statt dem AMD eine Intel P4 2.4 GHz mit nur 533 FSB und P4S8X Board. Als Benchmark nutzte er ein Stück, welches aufm AMD nur so mit Ach und Krach gerade an der Grenze durchlief. Ergebnis war ernüchtern - der P4 war nicht in der Lage das Stück abzuspielen, sondern schlicht total überlastet.

Wozu taugt diese "Breitbandarchitektur" des P4 eigentlich überhaupt ausser für Videoencoding?

[pippo]

Für nix, das isses ja :D Ohne FSB800 kannst den P4 den Hasen geben. Wenn dann noch HT dazukommt, ist er eigentlich ganz in Ordnung. Wobei ich mir ausser zu Videoencoding auch keinen P4 kaufen würde

[Gast]

Original geschrieben von pippo
Für nix, das isses ja :D Ohne FSB800 kannst den P4 den Hasen geben. Wenn dann noch HT dazukommt, ist er eigentlich ganz in Ordnung. Wobei ich mir ausser zu Videoencoding auch keinen P4 kaufen würde

So ein Quatsch, mit nur 533 "Mhz" FSB und ohne HT taugt er genauso gut, nur ist da das Preis-/ Leistungsverhältniss ein Stückchen schlechter. Ich glaube zudem nicht, das der CuBase so schlecht aufgrund der Hardware lief, vielmehr dürfte ein schlecht konfiguriertes System vorliegen.

Ich habe selbst eine Menge AMD sowie Intelrechner verbaut und vielen Leuten bei Problemen geholfen, und wie schon gesagt; meist sitzt es vor dem Monitor...

[Zool]

Cubase ist mehr ein Benchmark für die Latency von Soundkarte und deren Treiber und der PCI-Leistung der Southbridge.

Einige ViaChipsatze haben ja bekanntlich Probleme mit der PCI-Performances. Mit einem anderen Board kann das auch bei alten Athlon XP 1700+ wieder ganz anders aussehen.

[Haarmann]

Zool

Kein VIA Chipset vorhanden... Nur AMD und SIS. Die SB von VIA hängt ja bereits am PCI und daher müsste der P4 abgehen wie nur was, da auch die HD genutzt wird. Der Rest der HW ist ja identisch geblieben. Nur Board und CPU wurden gewechselt (Ok, die DEC LAN Karte flog auch noch raus....).

[Power]

Wer bei nem Intel system ein SiS Chipsatz als unterbau nimmt braucht sich der schlechten Leistung nicht wundern.

Zuerst mal nachfragen was für ein Board empfehlenswert wäre nicht irgend ein billig Müll kaufen und dann sich beschweren das die Leistung nicht passt.

Wer beste Leistung will kommt nicht an nem 865/875er Board vorbei.

[StefanV]

Original geschrieben von Power
Wer bei nem Intel system ein SiS Chipsatz als unterbau nimmt braucht sich der schlechten Leistung nicht wundern.

Zuerst mal nachfragen was für ein Board empfehlenswert wäre nicht irgend ein billig Müll kaufen und dann sich beschweren das die Leistung nicht passt.

Wer beste Leistung will kommt nicht an nem 865/875er Board vorbei.

Sorry, aber da kann ich eigentlich nicht zustimmen.

Die SIS Bretter sind auch recht ordentlich, ebenso die IO Performance jener Komponenten, wie in der c't 'abgeschätzt' wurde...

Und soo überragend sind die i865/875 Bretter IMO auch nicht, da das Speicherinterface nicht ganz unproblematisch ist...

[Haarmann]

Power

Wir nutzten das Teil testweise in meinem 865er PAT System mit selbiger CPU... meinste es war wirklich schneller? :rofl:

Der SiS ist sogar hervorragend und braucht sich hinter nem PE Chipset nicht zu verstecken.

[Power]

Original geschrieben von Haarmann
Power

Wir nutzten das Teil testweise in meinem 865er PAT System mit selbiger CPU... meinste es war wirklich schneller? :rofl:

Der SiS ist sogar hervorragend und braucht sich hinter nem PE Chipset nicht zu verstecken.

wo soll der SIS den hervoragend sein wenn er laut deiner eignen Aussage hinter einem 1700+ zurückliegt. ?

Aber du verwendest schon win XP oder win2000 ?


Ist zum Lachen wie Leute ohen jede erfahrung im zusammensetzen passender Komponenten Systeme zusammen setzen und sich dann wegen fehlender Leistung aufspielen.

@SP was für Problemme mit dem Speicherinterface ? - wenn man die passenden Speicher nimmt gibts keine.
Und wenn du jetzt wirklich behauptest das SIS genausogut wie die 865/875 Boards sind dann mal beweise mit Benchmarks nicht irgenwelche abschätzungen laut C´T du Oberspammer !

[LOCHFRASS]

Original geschrieben von Power
Wer bei nem Intel system ein SiS Chipsatz als unterbau nimmt braucht sich der schlechten Leistung nicht wundern.

Zuerst mal nachfragen was für ein Board empfehlenswert wäre nicht irgend ein billig Müll kaufen und dann sich beschweren das die Leistung nicht passt.

Wer beste Leistung will kommt nicht an nem 865/875er Board vorbei.

Heil Intel, bla, bla, bla... Bring mal richtige Argumente bzw. Quellen zu diesen Behauptungen.

[Endorphine]

Original geschrieben von Haarmann
Mein Kollege stellt Goa her (diese Ausdrucksweise ist Absicht). Wie viele seiner Artgenossen nutzt er dazu das PRG vom Titel. Er nutzte dazu bisher einen Athlon XP 1700+ auf einem AMD Chipset mit Via SB und ner Audigy2 mit KX Treibern.
Das System war ihm allerdings zu langsam, resp man musste sich behelfen, weil die Leistung nicht mehr für alles in Echtzeit reichte. Also baute er sein System um un nutzt nun statt dem AMD eine Intel P4 2.4 GHz mit nur 533 FSB und P4S8X Board. Als Benchmark nutzte er ein Stück, welches aufm AMD nur so mit Ach und Krach gerade an der Grenze durchlief. Ergebnis war ernüchtern - der P4 war nicht in der Lage das Stück abzuspielen, sondern schlicht total überlastet.

Wozu taugt diese "Breitbandarchitektur" des P4 eigentlich überhaupt ausser für Videoencoding? Der P4 will natürlich richtig konfiguriert werden, mit sämtlichen aktuellen SiS-Treibern. Ich wette, dass es sich nicht um ein Architekturproblem handelt, sondern um ein Konfigurations- und/oder Softwareproblem.

[Haarmann]

Power

SiS hat ne gesunde Bandbreite zwischen NB und SB - nicht wie Intel, die mit ihrem arschlahmen Hublink dahergondeln. An diesen 250MB/s hängen dann bescheidene 6 USB 2.0 a 40 MB/s und 2 ATA-100 mit 200MB/s und dem SATA RAID mit 300MB/s nebst ev nem FE LAN und AC97 bei vielen. Das muss wahrlich rauschen :rofl:.
Da lob ich mir SiS mit etwas mehr Bandbreite...

XP ists.

Ich glaube nicht, dass Du auch nur annähernd mal zugeben könntest, dass ein P4 lahm wäre, so er es denn ist ;). Intel produziert seit jahren nen chip, der nur Bandbreite hat und deswegen ist Q3 dort so schnell. Rechenleistung suchste bei normaler SW vergebens. Ich sollte glaubs mal nen alten Winstone 95 oder so versuchen - da hätte ich mal was zu lachen.

Endorphine

Alles drauf und noch immer gleich lahm *eg*. Er arbeitet auch in der IT seit nen paar Jahren...

[Endorphine]

Original geschrieben von Haarmann
Intel produziert seit jahren nen chip, der nur Bandbreite hat und deswegen ist Q3 dort so schnell. Rechenleistung suchste bei normaler SW vergebens. Ganz neue Erkenntnisse. Belege? Original geschrieben von Haarmann
Ich sollte glaubs mal nen alten Winstone 95 oder so versuchen - da hätte ich mal was zu lachen. Ich kann über synthetische Pseudobenchmarks wie Winstone nicht mal mehr müde lächeln. Wer kauft sich einen Rechner, um damit synthetische Benchmarks möglichst schnell ablaufen zu lassen? Original geschrieben von Haarmann
Alles drauf und noch immer gleich lahm *eg*. Er arbeitet auch in der IT seit nen paar Jahren... Er soll es mal mit einem i865/i875 Board versuchen. Ich unterstelle aber trotzdem mal, dass irgendwas mit der Konfiguration oder der Software allgemein nicht stimmt.

Hat er das System wirklich von Grund auf neu aufgesetzt nach dem Upgrade?

[GloomY]

Original geschrieben von Haarmann
Wozu taugt diese "Breitbandarchitektur" des P4 eigentlich überhaupt ausser für Videoencoding? Original geschrieben von Haarmann
Intel produziert seit jahren nen chip, der nur Bandbreite hat und deswegen ist Q3 dort so schnell. Rechenleistung suchste bei normaler SW vergebens.Haarmann,
Du übertreibst hier, auch wenn ich deine Einwände tendenziell durchaus nachvollziehen kann und an anderer Stelle auch schon mal selbst als Kritik zum P4 erwähnt habe. Aber eins dürfte wohl klar sein: Es bedarf noch ein bisschen mehr als nur eine breite Speicheranbindung, um eine CPU mit > 1200 SpecInt2000 zu designen (und SPEC ist nun wirklich größtenteils kein Streaming).

btw: Wie groß sind die Bandbreiten von SiS, Intel, Via und nVidia denn zwischen North- und Southbridge?
Original geschrieben von Endorphine
Wer kauft sich einen Rechner, um damit synthetische Benchmarks möglichst schnell ablaufen zu lassen?Tendentiell schon eher P4 User, wenn ich meine Erinnerungen hier aus dem Forum und von anderswo betrachte...

[Endorphine]

Original geschrieben von GloomY
Tendentiell schon eher P4 User, wenn ich meine Erinnerungen hier aus dem Forum und von anderswo betrachte... Aus meinen Erfahrungen her eher AMD-User. Intel-User lassen sich imho in zwei Gruppen einteilen: diejenigen, die Fertig-PCs von der Stange kaufen sowie wenige, die genau auf die Technik schauen und mit Überzeugung kaufen, dass die Komponenten für ihren Anspruch genau das richtige sind.

Benchmarkkiddies findest du eher nicht unter den Käufern von Fertigrechnern, das sind eher traditionelle emotionalisierte AMD-Käufer.

[Haarmann]

Endorphine

Ich dachte immer, Winstone 95 sind diese Word/Excel blabla Skriptbenches. Und ich bevorzuge mit Absicht eine dieser Uraltversionen, die noch mit SW vieler Hersteller sind, die wohl auch verschiedenen Compiler nutzten. Damit lässt sich imho ein besserer Vergleich ziehen. Zudem führen die Skripte Sachen durch, die man wohl auch tut. Sortieren in Excel is ja echt ned das, was ich immer tue mit 10k+ Zeilen... Dieser Bench war daher imho recht sinnvoll und sagte auch was aus. Leider schmeisst man Heute nur noch Scheisse in diese "Anwendungsbenches" rein, die wirklich Niemand je nutzten wird.

Ganz neue Erkenntnisse. Belege?

Auch wenn THG nicht Gottesquelle ist, man siehts http://www.tomshardware.com/cpu/20030923/index.html unter OpenGL Tests, mit ner uralt Q3 Version (da hats auch kein SSE2 drinnen) mit so nem Legoquake Grafik 640*640 CPU-Test. Wie Du z.B. siehst, kann man schon den Unterschied von XP 3000+ 166FSB zu 3000+ 200FSB sehen, wobei der mit weniger MHz, aber mehr FSB=Bandbreite "klar" gewinnt. Selbiges gilt dann auch für die Athlon FX und Athlon 64, nebst denn höher FSB P4. HT ist ned relevant, da r_smp 1 nicht gesetzt ist. Aber de 2.6C steckt z.B. den 2.8 locker in den Sack, wie auch der 2.8C den 3.06 schlägt. Noch extremer ists beim FX 411 fps mit 100MHz DDR RAM und 490 mit 200MHz DDR RAM. Schon Q1 war ein idealer RAM-Bench. Ein Timing verstellt und Q1 reagierte bereits mit paar FPS drauf. Alles was vor allem beim FX ändert ist die RAM Bandbreite. Alles Andere bleibt unverändert, wobei wohl die Latenzen auch noch varieren dürften aufgrund der SPD Timings der Steine. Neu ist diese Erkenntnis also nicht.
Leider ist wohl der Sound noch aktiv bei diesen Benches - der bremst das aus wie nur was. Der Effekt ist riesig ohne Sound. Meine Rekorde gehen ohne Sound weit über 600 fps mit ner 2.7 GHz P3 400 FSB resp eben etwas mehr und nem alten SiS 645 Board von ASUS.

Ich schrieb Oben schon, dass es mit meinem 865 Board nicht besser war ;). Offensichtlich wird das gerne mal überlesen.

Jein, die Festplatten sind die Gleichen und nicht neu Formattiert worden. Es gibt 2 OS drauf... eines alles neu und das andere Repaired. Da sich diese aber nicht unterscheiden in der Performance isses nicht das Problem.

Wer nen Rechner für Benches kauft? Imho Leute mit nem "Kleinen" und zuwenig Geld für nen BMW ;). Ich glaube nicht, dass ich mit meinem Dual AMD System viele Benches gewinne, aber ich mag sein Arbeitsverhalten und das ist mir mehr wert als die 200 mehr FPS im Q3, die ein P4 liefern kann.

Gloomy

SPEC Benches sind imho ziemlich *gähn* da gewisse Compiler schon fast merkwürdig draufhin optimiert werden... Auch hat Intel dabei schon mal beschissen ;). Da ich allerdings nicht wirklich die Tiefe des SPEC Benches ausgelotet habe in Punkto was diese tun, kann ichs auch nicht ausschliessen, dass die Bandbreite unwichtig ist. Jedenfalls ist der verwendete Compiler und dessen Optionen inzwischen das Wichtigste... Leider ists in der Reale Welt doch so, dass wir keinen P4 Code einsetzten und dementsprechend sind diese Resultate mir ziemlich egal.

Die Bandbreiten der anderen sind inzwischen glaubs bei allen bei nem GB/s, dem 4-fachen, angelangt, wobei ich bei NV nicht so sicher bin. Dem fehlen aber eh ein paar Sachen, die Via und SiS nebst Intel schon haben. Es wäre also weniger schlimm.

[StefanV]

Original geschrieben von GloomY
btw: Wie groß sind die Bandbreiten von SiS, Intel, Via und nVidia denn zwischen North- und Southbridge?


Intel -> 266MB/sec (AGP1x/PCI-66, IMO nicht wirklich viel), SIS AFAIK 533MB/sec, ev. auch 1,066GB/Sec, VIA bei den alten (z.B. P4X333) auch 266MB/Sec, wurde aber letztens erhöht auf 533MB/sec.

[Endorphine]

Original geschrieben von Stefan Payne
Intel -> 266MB/sec (AGP1x/PCI-66, IMO nicht wirklich viel) Der i865/875 MCH hat noch einen zweiten HubLink, genannt CSA. Dadurch ist das imho nicht so kritisch. Original geschrieben von Stefan Payne
SIS AFAIK 533MB/sec, ev. auch 1,066GB/Sec, AFAIK: 512 MiB/s bei Chipsätzen, 1 GiB/s bei all-in-one "Chipsätzen".

An der I/O Bandbreite zwischen NB und SB liegt es IMHO aber nicht. Die ist großzügig genug dimensioniert. So viele Datenströme kann man kaum gleichzeitig anstossen, als dass diese Schnittstelle den Durchsatz begrenzt. Da hakt es eher an anderen Stellen.

p.s. Mit PCI-Express hat sich das Thema sowieso wieder für eine Weile erledigt:
http://www.hardtecs4u.com/images/news/grantsdaleblock.jpg

[Tiamat]

Das ganze nennt sich Denormalisation..
Ein nicht ganz so bekanntes Problem mit dem P4.
In der Keyboards Ausgabe 8/02 gibt es einen 4 DIN-A4 Seiten Artikel darüber.
Die VST-plugins müssen erstmal repariert oder normalisiert werden.Dazu brachst du/er das Normalizer Plugin :
http://www.digitalfishphones.com/main.php?item=2&subItem=6
Viel Spaß noch mit dem P4 :)
Gruß
Tiamat

[StefanV]

Original geschrieben von Endorphine
Der i865/875 MCH hat noch einen zweiten HubLink, genannt CSA. Dadurch ist das imho nicht so kritisch. AFAIK: 512 MiB/s bei Chipsätzen, 1 GiB/s bei all-in-one "Chipsätzen".

An der I/O Bandbreite zwischen NB und SB liegt es IMHO aber nicht. Die ist großzügig genug dimensioniert. So viele Datenströme kann man kaum gleichzeitig anstossen, als dass diese Schnittstelle den Durchsatz begrenzt. Da hakt es eher an anderen Stellen.

p.s. Mit PCI-Express hat sich das Thema sowieso wieder für eine Weile erledigt:
http://www.hardtecs4u.com/images/news/grantsdaleblock.jpg

1. ja, aber der dient 'nur' zur Anbindung von GBit Ethernet...
2. hat SIS das nicht bei den aktuelleren Chipsets wieder erhöht?? :|

2. naja, S-ATA RAID, dazu noch 'ne ATA Platte, dazu 'ne High Bandwith Karte im PCI und schon wirds IMO 'etwas' eng...
Dazu noch USB2.0, wobei jedes ordentliche BOard auch IEE1394 drauf hat...

[Haarmann]

Tiamat

Das könnte eher helfen - Danke mal fürn Tip. Wird getestet.

[Haarmann]

Endorphine

Reichte das schon wegen der Bandbreitenthese?

Hier noch nen paar Linksystem Informationen...

bis 1GB/s

http://www.via.com.tw/en/southbridge/vt8237.jsp

bis 0.5GB/s

http://www.via.com.tw/en/southbridge/vt8235.jsp

0.5 - 1GB/s je nach SB

http://www.sis.com/products/chipsets/southbridge/96x.htm

800MB/s HT Interface

http://www.nvidia.com/object/LO_20010528_5511.html

Ich hab ja auch noch den PCI Bus vergessen, der sich auch noch irgendwie durch den Hublink durchwürgen muss... Mein Fehler. Nun sinds also etwa 0.25 GB/s fürs CSA GBit Ethernet (falls angeschlossen) und 0.25 GB/s für PCI Bus und den ganzen Rest. Das ist imho auch der Grund, wieso Intel schlicht keinen schnelleren PCI Bus machen wollte - er könnte gar nicht genutzt werden ohne grundlegend was zu ändern.

ftp://download.intel.com/design/chipsets/datashts/25252501.pdf

[cos]

in der letzen ct haben die p4 lowcost boards getestet, unter anderem auch die pci performance mit einem gigabit ethernet adapter.

da waren ne menge billig chipsätze vertreten, sis - ali - via - ati - auch die intel low cost.

ok kein i865 oder i875, aber die sis haben vor allem im pci benchmark hervorragend abgeschnitten wenn auf mehrere pci geräte zugegriffen wurde.

das möchte ich speziell auch noch unserem IntelJüngerExtraPurFanboyXE Power vor augen halten...

[Gast]

Original geschrieben von Haarmann
Nun sinds also etwa 0.25 GB/s fürs CSA GBit Ethernet (falls angeschlossen) und 0.25 GB/s für PCI Bus und den ganzen Rest.

Habe ich da den Kontext falsch verstanden? Wieso sollten die per CSA empfangenen und gesendeten Daten durch den Hublink?

[Muh-sagt-die-Kuh]

Original geschrieben von Haarmann
Ich dachte immer, Winstone 95 sind diese Word/Excel blabla Skriptbenches. Und ich bevorzuge mit Absicht eine dieser Uraltversionen, die noch mit SW vieler Hersteller sind, die wohl auch verschiedenen Compiler nutzten. Damit lässt sich imho ein besserer Vergleich ziehen. Zudem führen die Skripte Sachen durch, die man wohl auch tut. Sortieren in Excel is ja echt ned das, was ich immer tue mit 10k+ Zeilen... Dieser Bench war daher imho recht sinnvoll und sagte auch was aus. Leider schmeisst man Heute nur noch Scheisse in diese "Anwendungsbenches" rein, die wirklich Niemand je nutzten wird.Anwendungsbenchmarks (Office) kann man sowieso vergessen, dafür ist jede heutige CPU mehr als schnell genug.
Ganz neue Erkenntnisse. Belege?

Auch wenn THG nicht Gottesquelle ist, man siehts http://www.tomshardware.com/cpu/20030923/index.html unter OpenGL Tests, mit ner uralt Q3 Version (da hats auch kein SSE2 drinnen) mit so nem Legoquake Grafik 640*640 CPU-Test. Wie Du z.B. siehst, kann man schon den Unterschied von XP 3000+ 166FSB zu 3000+ 200FSB sehen, wobei der mit weniger MHz, aber mehr FSB=Bandbreite "klar" gewinnt. Selbiges gilt dann auch für die Athlon FX und Athlon 64, nebst denn höher FSB P4. HT ist ned relevant, da r_smp 1 nicht gesetzt ist. Aber de 2.6C steckt z.B. den 2.8 locker in den Sack, wie auch der 2.8C den 3.06 schlägt. Noch extremer ists beim FX 411 fps mit 100MHz DDR RAM und 490 mit 200MHz DDR RAM. Schon Q1 war ein idealer RAM-Bench. Ein Timing verstellt und Q1 reagierte bereits mit paar FPS drauf. Alles was vor allem beim FX ändert ist die RAM Bandbreite. Alles Andere bleibt unverändert, wobei wohl die Latenzen auch noch varieren dürften aufgrund der SPD Timings der Steine. Neu ist diese Erkenntnis also nicht.
Leider ist wohl der Sound noch aktiv bei diesen Benches - der bremst das aus wie nur was. Der Effekt ist riesig ohne Sound. Meine Rekorde gehen ohne Sound weit über 600 fps mit ner 2.7 GHz P3 400 FSB resp eben etwas mehr und nem alten SiS 645 Board von ASUS.Danke...wir wissen alle, dass Q3A sehr von Speicherleistung abhängt, wo sind aber deine Belege, dass ein P4 zu sonst nix taugt...

Wo du einen 2,7 Ghz Pentium III mit FSB 400 her hast würde mich auch interessieren ;)SPEC Benches sind imho ziemlich *gähn* da gewisse Compiler schon fast merkwürdig draufhin optimiert werden... Auch hat Intel dabei schon mal beschissen ;). Da ich allerdings nicht wirklich die Tiefe des SPEC Benches ausgelotet habe in Punkto was diese tun, kann ichs auch nicht ausschliessen, dass die Bandbreite unwichtig ist. Jedenfalls ist der verwendete Compiler und dessen Optionen inzwischen das Wichtigste... Leider ists in der Reale Welt doch so, dass wir keinen P4 Code einsetzten und dementsprechend sind diese Resultate mir ziemlich egal.

Die Bandbreiten der anderen sind inzwischen glaubs bei allen bei nem GB/s, dem 4-fachen, angelangt, wobei ich bei NV nicht so sicher bin. Dem fehlen aber eh ein paar Sachen, die Via und SiS nebst Intel schon haben. Es wäre also weniger schlimm. http://www.spec.org/cpu2000/CINT2000/ lies einfach nach...

Und wie wärs, du belegst deine Behauptung, dass in der "realen Welt" kein P4 Code eingesetzt wird....die meisten Anwendungen sind immer noch in C/C++ geschrieben, dafür gibts eben jenen Intel Compiler zu kaufen. Falls du es noch nicht weisst, auch bei AMD CPUs holt dieser Compiler mehr Leistung raus als jeder andere.

[Haarmann]

Gast

Hab ich das entsprechende Dokument von Intel nicht verlinkt?

Die NB hat einfach 2 HL und eines nennt man CSA ;).

Muh-sagt-die-Kuh

Wieso sollte ich diese vergessen? Natürlich ist Office schnell genug, aber relative Indexe kann ich damit setzen. Heterogene Benches sind imho am interessantesten. Anbeten sollte man sowas aber eh ned ...

Ich hab nicht gesagt er taugt zu nix, ich hab gefragt wozu das Ding taugt ausser Video Encoding, womit ich mindestens ein Anwendungsgebiet genannt hab. Der Gag an der Sache ist, dass viele Leute glauben der P4 wäre für CuBase gut, aber laut dem Kollegen, der das Problem hat, soll im vorletzten Keys (ich hoffe das schreibt sich echt so) genau das Gegenteil stehen. OK, er hätte das vorher lesen sollen, wie wiederum sein Kollege ;).

Ich glaube nicht, dass michs wirklich interessiert, wie ein SPEC Bench genau arbeitet... es ist einfach ein weiterer Bench, der manipulierbar ist, weil man künstlich auf dessen Ergebnisse hin optimieren kann. Was ich mich entsinne ist es ein Mix aus C und Fortran und schon das Disqualifiziert diesen Bench für CPUs, aber nicht für Compiler, wenn sie nicht optimiert drauf wären.
Ein CPU Bench darf für mich keinen fixen Code haben, sondern nur ein Problem lösen und das wenns geht auf idealem Code für die jeweilige CPU. Dies ist imho bei SPEC nicht gegeben -> nicht interessant.

[Gast]

Original geschrieben von Haarmann
Gast

Hab ich das entsprechende Dokument von Intel nicht verlinkt?


Doch schon, nur scheinbar hab ich das gestern Abend in den falschen Hals bekommen. Ich hatte es so verstanden, als behauptetest du, die 266MB aus dem CSA würden auch noch durch den Hub-Link zwischen MCH und ICH durchmüssen.

Q

[Haarmann]

Gast

Scheiss drauf - ohne unsere kleine Macken wär die Welt doch langweilig ;).

[Muh-sagt-die-Kuh]

Original geschrieben von Haarmann
Ich glaube nicht, dass michs wirklich interessiert, wie ein SPEC Bench genau arbeitet... es ist einfach ein weiterer Bench, der manipulierbar ist, weil man künstlich auf dessen Ergebnisse hin optimieren kann. Was ich mich entsinne ist es ein Mix aus C und Fortran und schon das Disqualifiziert diesen Bench für CPUs, aber nicht für Compiler, wenn sie nicht optimiert drauf wären.
Ein CPU Bench darf für mich keinen fixen Code haben, sondern nur ein Problem lösen und das wenns geht auf idealem Code für die jeweilige CPU. Dies ist imho bei SPEC nicht gegeben -> nicht interessant. SPEC CPU 2000 deckt ein ziemlich großes Spektrum an Anwendungsgebieten ab, dabei kommen Kernalgorithmen zum Einsatz die sich auch in einer ganzen Menge Anwendungssoftware wieder finden, optimiert man den Compiler auf SPEC (damit meine ich keine Compilertricks wie statische Code-Bibliotheken) können die hier gewonnenen Verbesserungen auch bei Anwendungssoftware einen positiven Effekt haben.

Ja, SPEC INT ist in C(++) geschrieben und SPEC FP in Fortran, wieso das diesen anerkannten Benchmark disqualifiziert verstehe ich nicht wirklich.

Und was meinst du mit "Ein CPU Bench darf für mich keinen fixen Code haben"....sollen etwa alle CPU Benchmarks ausschliesslich Self-Modifying Code enthalten? Die Leistung die ein Programm auf einer Architektur erzielt ist eben abhängig davon, wie Compiler und CPU miteinander harmonieren....auch in der Realität.

[GloomY]

Original geschrieben von Endorphine
Aus meinen Erfahrungen her eher AMD-User. Intel-User lassen sich imho in zwei Gruppen einteilen: diejenigen, die Fertig-PCs von der Stange kaufen sowie wenige, die genau auf die Technik schauen und mit Überzeugung kaufen, dass die Komponenten für ihren Anspruch genau das richtige sind.Es gibt viel mehr "Benchmarks", die dem P4 wundervolle Zahlen bescheinigen als den Athlons (PCMark, Sandra, Sysmark 03 usw.). Einige P4 User - um es mal übertrieben auszudrücken - geilen sich an diesen Zahlen auf.

AMD User wissen, dass sie eine ganz gute CPU haben (sonst wären diese nämlich auf Grund der viel tolleren "Benchmark"-Zahlen bei Intel gelandet), auch wenn die Werte in ihren Tests oftmals nicht so toll aussehen. Daher werden diese tollen Zahlen tendenziell von diesen eher links liegen gelassen.
Original geschrieben von Endorphine
Benchmarkkiddies findest du eher nicht unter den Käufern von Fertigrechnern, das sind eher traditionelle emotionalisierte AMD-Käufer.Das würde ich nicht umbedingt auf AMD beschränken. Emotionalisierte Intel-Käufer gibt's (mindestens) genau so häufig.

Es sind Leute mit solidem Halb-Wissen, die so einen "Benchmark" verwenden, um mal eben ihr System durchzutesten, aber eigentlich nicht wirklich verstehen, was der Test macht oder warum ihr System so oder so reagiert.
Original geschrieben von Haarmann
Gloomy

SPEC Benches sind imho ziemlich *gähn* da gewisse Compiler schon fast merkwürdig draufhin optimiert werden...Du kannst Compiler auch nur in einem gewissen Maße optimieren. Gerade der breite Mix an verschiedenen Benches macht dies bei SPEC besonders schwer.

Ich hatte SPEC eigentlich nur angeführt, weil ich diesen für relativ zuverlässig bezüglich der Performance-Aussage halte. Klar kann man immer optimieren (und SPEC sieht das ja auch ausdrücklich bei den Peak Werten vor), aber man kann nicht so optimieren, dass man die Performance unrealistisch hoch steigern kann.

Der P4 ist also - um nochmal auf meine Grundaussage zurückzukommen - nicht (nur) wegen seiner hohen Bandbreite so schnell.
Original geschrieben von Haarmann
Auch hat Intel dabei schon mal beschissen ;). Da ich allerdings nicht wirklich die Tiefe des SPEC Benches ausgelotet habe in Punkto was diese tun, kann ichs auch nicht ausschliessen, dass die Bandbreite unwichtig ist. Jedenfalls ist der verwendete Compiler und dessen Optionen inzwischen das Wichtigste... Leider ists in der Reale Welt doch so, dass wir keinen P4 Code einsetzten und dementsprechend sind diese Resultate mir ziemlich egal."Keinen P4 Code" würde ich auch nicht unterschreiben. Das war vielleicht bei der Einführung des P4s so. Aber mittlerweile ist einige Zeit vergangen und die Compiler haben sich auch auf den P4 eingestellt.

[FZR]

Original geschrieben von GloomY
Es gibt viel mehr "Benchmarks", die dem P4 wundervolle Zahlen bescheinigen als den Athlons (PCMark, Sandra, Sysmark 03 usw.). Einige P4 User - um es mal übertrieben auszudrücken - geilen sich an diesen Zahlen auf.

AMD User wissen, dass sie eine ganz gute CPU haben (sonst wären diese nämlich auf Grund der viel tolleren "Benchmark"-Zahlen bei Intel gelandet), auch wenn die Werte in ihren Tests oftmals nicht so toll aussehen. Daher werden diese tollen Zahlen tendenziell von diesen eher links liegen gelassen.


Bei den meisten Usern die sich ein AMD System aufbauen spielt die Geldbörse aber den größeren Aspekt, als das sie sich nicht von "tollen zahlen" beeindrucken lassen ;)

Aufgeilen tut wir uns doch alle an Zahlen, ob AMD oder Intel System. Alle lästern immer wie unausgeglichen Benchmarks sind, aber trotzdem lassen se sie alle laufen und posten ihre scores.... ;)

so far...

[Haarmann]

Muh-sagt-die-Kuh

Ich werd mal wieder die Mottenkiste bemühen...
Wer früher ne 2er Potenz als Multiplikator hatte, der bevorzugte im Assembler nen Bitshift statt nem Mul Command, weil dies schlicht schneller war - das gilt aber glaube ich nicht für alle CPUs. Oftmals gibts für Probleme also mehrere Lösungen, die absolut unterschiedlich sind und kein Compiler sucht gezielt z.B. nach Multiplikationen mit 2er Potenzen und ersetzt diese bei Bedarf durch Shifts. Dementsprechend bin ich für problemorientierte Formulierungen, wo man so murksen kann, wie man will.

Und gerade weil etwas anerkannt ist, ists gefährdet. Siehe Q3 oder 3DM - da lohnt sich das optimieren ja wenigstens, denn es zahlt sich in barer Münze aus, besonders, wenn CPU und Compiler aus gleichem Hause kommen. Ich denke hier weniger an x86 und Pentium4, sondern mehr an den Itanium... Beschissen hat Intel bekanntlich schonmal bei SPEC.

Gloomy

Schwer heisst aber nicht unmöglich...

Man liest sehr Vielerorts, dass Intel Compiler ähnlich NVs Treibern bei 3DM den Code vom Spec erkennen können... Ich kann nicht beurteilen, ob dem so ist, aber auszuschliessen ist es nicht.

Kleiner Hinweis am Rande, als Intel den 120er Pentium testete, wurde das auf nem System gemacht, welches man schlicht nie kaufen konnte und auch nicht nachbaubar war, weil es keinen Chipset zu kaufen gab, der mit der Cachemenge umgehen konnte damals. Das Alleine ist imho schon Cheat.

Auch ists interessant zu wissen, dass ein Intel Pentium/Xeon 4 mit HT aktiviert langsamer ist bei SPEC 2000 denn ohne HT. (Das gilt ev allerding nur für Linux, wo Intel ja auch seine Benches absolvieren will, weil schlicht schneller) Das deutet schon ziemlich auf Handoptimierten Code hin, denn genau damit verliert HT fast jegliche Daseinsberechtigung. Volle Funktionseinheiten sind des HTs Tod.

[Muh-sagt-die-Kuh]

Original geschrieben von Haarmann
Muh-sagt-die-Kuh

Ich werd mal wieder die Mottenkiste bemühen...
Wer früher ne 2er Potenz als Multiplikator hatte, der bevorzugte im Assembler nen Bitshift statt nem Mul Command, weil dies schlicht schneller war - das gilt aber glaube ich nicht für alle CPUs. Oftmals gibts für Probleme also mehrere Lösungen, die absolut unterschiedlich sind und kein Compiler sucht gezielt z.B. nach Multiplikationen mit 2er Potenzen und ersetzt diese bei Bedarf durch Shifts. Dementsprechend bin ich für problemorientierte Formulierungen, wo man so murksen kann, wie man will. Deine Mottenkiste ist für die heutige Zeit nicht relevant. Selbstverständlich kann ein Compiler nicht jegliche grottenschlechte Implementation in die schnellste mögliche überführen, da ist aber auch nicht seine Aufgabe. Dass Compiler Multiplikationen mit 2er Potenzen erkennen und entsprechend Shifts verwenden ist durchaus möglich. Und erklär doch bitte mal, was du unter einer "problemorientierten Formulierung" verstehst.Und gerade weil etwas anerkannt ist, ists gefährdet. Siehe Q3 oder 3DM - da lohnt sich das optimieren ja wenigstens, denn es zahlt sich in barer Münze aus, besonders, wenn CPU und Compiler aus gleichem Hause kommen. Ich denke hier weniger an x86 und Pentium4, sondern mehr an den Itanium... Beschissen hat Intel bekanntlich schonmal bei SPEC.Schonmal die Möglichkeit in Betracht gezogen, dass der Itanium II einfach eine sehr starke FPU hat...und schau dir doch bitte mal an, aus was SPEC besteht bevor du große Sprüche klopfst.Schwer heisst aber nicht unmöglich...

Man liest sehr Vielerorts, dass Intel Compiler ähnlich NVs Treibern bei 3DM den Code vom Spec erkennen können... Ich kann nicht beurteilen, ob dem so ist, aber auszuschliessen ist es nicht.Das lässt sich herausfinden, wer so etwas behauptet, es aber nicht beweist ist in meinen Augen nicht sehr vertrauenswürdig.
Kleiner Hinweis am Rande, als Intel den 120er Pentium testete, wurde das auf nem System gemacht, welches man schlicht nie kaufen konnte und auch nicht nachbaubar war, weil es keinen Chipset zu kaufen gab, der mit der Cachemenge umgehen konnte damals. Das Alleine ist imho schon Cheat.Hat SPEC Regeln ist so etwas heute nicht erlaubt.Auch ists interessant zu wissen, dass ein Intel Pentium/Xeon 4 mit HT aktiviert langsamer ist bei SPEC 2000 denn ohne HT. (Das gilt ev allerding nur für Linux, wo Intel ja auch seine Benches absolvieren will, weil schlicht schneller) Das deutet schon ziemlich auf Handoptimierten Code hin, denn genau damit verliert HT fast jegliche Daseinsberechtigung. Volle Funktionseinheiten sind des HTs Tod. Schon mal daran gedacht, dass die SPEC Tests single-threaded sein könnten....

[Haarmann]

Muh-sagt-die-Kuh

Meine Mottenkiste sollte etwas Veranschaulichen. Sie ist jedenfalls sehr einfach zu begreiffen und das war der Sinn der Übung. Ich sehe nicht ein, warum man immer komplizierte Beispiele nehmen muss, damit man den Anderen verwirren kann. Das ist imho nicht der sinn der Sache - ich folge hier halt dem KISS Prinzip.
Um mal Auswirkungen von sowas zu Zeigen empfehle ich Dir Windows95 auf Deinen Rechner zu installieren ohne den "IDE Patch". Danach geht Dir ein Licht auf, dass gewisse x86 CPUs total unterschiedliche Eigenschaften haben, die sich z.B. in der Art der Schleife äussern können.
Zusätzlich kommt dann auch noch der Cache etc in Betracht. Obschon ein P4 den gleichen Core hat wie ein Celeron, ist Celeron optimierter Code nicht identisch mit P4 optimiertem Code. Gleiches gilt analog auch Für Northwood und Willamette usw. Besonders SPEC FP reagiert aber sehr auf Bandbreite und Cachesize. Man könnte also einer CPU auch gerade soviel Cache mit aufn Weg geben, dass sie bei SPEC gut abschneidet, aber bei anderen Anwendungen heisst das sicher nicht, dass dies ebenso der Fall wäre. Auf SPEC zu optimieren hat allerdings nen Vorteil, der in der echten Welt nicht vorhanden ist - es ist ein einziger Task wirklich aktiv und man profilet beim Intel Compiler einfach so lange, bis man aus allen Möglichkeiten die Beste gefunden hat und muss nicht berücksichtigen, ob diese sich mit der Restlichen Umgebung, die eben nicht da ist, verträgt und ob dieses "Beste" sich nicht durch Vorbedingungen verändern könnte. Die Vorbedingungen sind nämlich fix.
Und nun komm ich zu nem ganz interessanten Punkt beim SPEC. Ich "behaupte" mal, dass der Intel Compiler für nen System mit P4 ohne HT auf nem 875er System mit schnellen RAMs etc nicht den gleichen Code verwendet, wie für die gleiche P4 CPU auf nem SiS Board mit langsamem SDRAM. Das liegt genau an dem Profilingverfahren, das ich vorher erwähnt hab. 2 mal die gleiche CPU und nicht den gleichen Code ist für mich untragbar bei nem CPU Bench. So ein Compiler hat in dem Modus auch keine Praxistauglichkeit mehr und das ist doch ne Bedingung bei SPEC?

Was heisst nun Problemorientiert? Man stellt einfach nen Problem hin - z.B. Primfaktorenzerlegung. Der Code, den man einsetzt ist natürlich Opensource, dan darf ihn aber selbst schreiben. Für solche Probleme gibts oft verschiedene Varianten und nicht jede CPU muss beim Verfahren A langsamer sein als beim Verfahren B. Habe ich aber nen fixen Code, dann wird einem ne Variante aufgezwungen, was keineswegs optimal ist.

Ich werde sicher nicht den ganzen Code der Benches durchlesen und die zugrunde liegenden Probleme analysieren, aber genau das müsste ich dann tun, wenn ichs wirklich bewerten können will. Dazu ist mir meine Zeit aber zu schade und weniger als das zu tun bringt imho gar nix.

[Muh-sagt-die-Kuh]

Original geschrieben von Haarmann
Muh-sagt-die-Kuh

Meine Mottenkiste sollte etwas Veranschaulichen. Sie ist jedenfalls sehr einfach zu begreiffen und das war der Sinn der Übung. Ich sehe nicht ein, warum man immer komplizierte Beispiele nehmen muss, damit man den Anderen verwirren kann. Das ist imho nicht der sinn der Sache - ich folge hier halt dem KISS Prinzip.
Um mal Auswirkungen von sowas zu Zeigen empfehle ich Dir Windows95 auf Deinen Rechner zu installieren ohne den "IDE Patch". Danach geht Dir ein Licht auf, dass gewisse x86 CPUs total unterschiedliche Eigenschaften haben, die sich z.B. in der Art der Schleife äussern können.Was ist das KISS Prinzip und was hat das Win95 LOOP-Problem (ein Befehl den kein aktueller Compiler mehr erzeugt) mit Benchmarks zu tun.Zusätzlich kommt dann auch noch der Cache etc in Betracht. Obschon ein P4 den gleichen Core hat wie ein Celeron, ist Celeron optimierter Code nicht identisch mit P4 optimiertem Code. Gleiches gilt analog auch Für Northwood und Willamette usw. Besonders SPEC FP reagiert aber sehr auf Bandbreite und Cachesize. Man könnte also einer CPU auch gerade soviel Cache mit aufn Weg geben, dass sie bei SPEC gut abschneidet, aber bei anderen Anwendungen heisst das sicher nicht, dass dies ebenso der Fall wäre.Der Code ist bei modernen CPUs meist nicht das Problem sondern die Daten. Greift ein Programm eben häufig auf den Speicher zu und der Cache ist einfach zu klein kann der Compiler nichts machen. Auf SPEC zu optimieren hat allerdings nen Vorteil, der in der echten Welt nicht vorhanden ist - es ist ein einziger Task wirklich aktiv und man profilet beim Intel Compiler einfach so lange, bis man aus allen Möglichkeiten die Beste gefunden hat und muss nicht berücksichtigen, ob diese sich mit der Restlichen Umgebung, die eben nicht da ist, verträgt und ob dieses "Beste" sich nicht durch Vorbedingungen verändern könnte. Die Vorbedingungen sind nämlich fix.Auch bei SPEC läuft ein OS...mal nebenbei gefragt, kennst du den Unterschied zwischen den "base" und "peak" werten?
Auch verstehe ich nicht, wie du das mit der restlichen Umgebung meinst....auf der CPU ist immer nur ein Thread (bei HT 2) aktiv, Wechselwirkungen gibt es keine.Und nun komm ich zu nem ganz interessanten Punkt beim SPEC. Ich "behaupte" mal, dass der Intel Compiler für nen System mit P4 ohne HT auf nem 875er System mit schnellen RAMs etc nicht den gleichen Code verwendet, wie für die gleiche P4 CPU auf nem SiS Board mit langsamem SDRAM. Das liegt genau an dem Profilingverfahren, das ich vorher erwähnt hab. 2 mal die gleiche CPU und nicht den gleichen Code ist für mich untragbar bei nem CPU Bench. So ein Compiler hat in dem Modus auch keine Praxistauglichkeit mehr und das ist doch ne Bedingung bei SPEC?Eine Binary nach Chipsatzdetection Sektionen zu durchsuchen ist nicht schwer, zudem würde das die Binary aufblasen bis zum geht nicht mehr. Die Behauptung ist, meiner Meinung nach, absolut nicht tragbar.
Was heisst nun Problemorientiert? Man stellt einfach nen Problem hin - z.B. Primfaktorenzerlegung. Der Code, den man einsetzt ist natürlich Opensource, dan darf ihn aber selbst schreiben. Für solche Probleme gibts oft verschiedene Varianten und nicht jede CPU muss beim Verfahren A langsamer sein als beim Verfahren B. Habe ich aber nen fixen Code, dann wird einem ne Variante aufgezwungen, was keineswegs optimal ist.Verfahren A und B unterscheiden sich normalerweise in ihrer Komplexitätsklasse....lässt man einen Merge-Sort auf einem P-100 gegen einen Selection-Sort auf einem P4-3,0 antreten gewinnt der P-100 ab einer bestimmten Problemgröße immer...wo ist der Sinn bei solch einer Aktion? Vergleichbarkeit ist nur bei gleichen Bedingungen für alle gegeben.Ich werde sicher nicht den ganzen Code der Benches durchlesen und die zugrunde liegenden Probleme analysieren, aber genau das müsste ich dann tun, wenn ichs wirklich bewerten können will. Dazu ist mir meine Zeit aber zu schade und weniger als das zu tun bringt imho gar nix. Das sollst du auch nicht, die Beschreibungen wären aber mal ein Anfang....

[Haarmann]

Muh-sagt-die-Kuh

"Was ist das KISS Prinzip und was hat das Win95 LOOP-Problem (ein Befehl den kein aktueller Compiler mehr erzeugt) mit Benchmarks zu tun."

Ich dachte ich bezog das KISS auf meinen Vergleich mitem Shift, aber offenbar dachte nur ich so. Das mitem AMD soll zeigen, wie unterschiedlich CPUs diverse Befehle behandeln. Der Intel Compiler nutzt schlichtes Porfiling für seine "Optimierung" - Optimierung ist imho aber was ganz Anderes denn Profiling, auch wenns ähnliche Folgen haben kann.

Chachegrösse sagt alleine nichts - es ist die Segmentierung, die auch was mitzuhusten hat. Intels 8 Segmente sind imho AMDs 16 Segmente im Normalfall weit unterlegen. Die längeren Lines sind z.B. auf deutlich mehr Bandbreite angewiesen, denn das Warten der CPU ist bei nem Linefill schlicht davon abhängig, weswegen ein P4 mit SDRAM auch so lahm wird, kaum isses nimmer im Cache, wogegen der AMD da weniger Probleme hat Aufgrund kürzerer Lines.

Soweit ich mich entsinne sinds nur Unterschiede in was erlaubt ist und was nicht für den Compiler. Loops flach "abrollen" ist z.B. ab und an "sinnvoll" aber bei base wohl nicht erlaubt und bei peak erlaubt.

Ich sags mal so. Laut bösen Unkenrufen halbiert sich unter Umständen bei unterschiedlichen Umgebungen die Performance, wenn man den Intel Compiler optimieren lässt. In der Praxis lässt sich damit also keinen Blumentopf gewinnen, wenn man nicht identische Geräte hat.

"Verfahren A und B unterscheiden sich normalerweise in ihrer Komplexitätsklasse....lässt man einen Merge-Sort auf einem P-100 gegen einen Selection-Sort auf einem P4-3,0 antreten gewinnt der P-100 ab einer bestimmten Problemgröße immer...wo ist der Sinn bei solch einer Aktion? "

Tja das Verfahren darf ja frei gewählt werden von beiden Seiten... Ist also fair.

"Vergleichbarkeit ist nur bei gleichen Bedingungen für alle gegeben.Das sollst du auch nicht, die Beschreibungen wären aber mal ein Anfang..."

Nein, diese Beschreibungen sind eben genau das, was mich nicht interessiert. Das ist imho nur Halbwissen, welches oft zu Trugschlüssen führt. Ich bin jedenfalls noch immer der Meinung, dass Optimierung "wissenschaftlich" ist und und Optimierung durch Profiling nur ein durchtesten von Möglichkeiten darstellt, was imho keine Optimierung mehr ist.

Dell stellte bei einzelnen Test bei angeschaltetem HT nen Leistungsverlust von satten 37% fest - schon happig.

Ich halte die SPEC Suite für nen guten Systemtest und ohne Profiling sogar für nen brauchbaren CPU/Compilertest, aber CPUs kann man damit nicht vergleichen und Profilingcompiler gehörten geächtet.

[Muh-sagt-die-Kuh]

Original geschrieben von Haarmann
Muh-sagt-die-Kuh

"Was ist das KISS Prinzip und was hat das Win95 LOOP-Problem (ein Befehl den kein aktueller Compiler mehr erzeugt) mit Benchmarks zu tun."

Ich dachte ich bezog das KISS auf meinen Vergleich mitem Shift, aber offenbar dachte nur ich so. Das mitem AMD soll zeigen, wie unterschiedlich CPUs diverse Befehle behandeln. Der Intel Compiler nutzt schlichtes Porfiling für seine "Optimierung" - Optimierung ist imho aber was ganz Anderes denn Profiling, auch wenns ähnliche Folgen haben kann.Ich glaube nicht, dass du intel Compiler genau genug kennst um über seine Optimierungsstrategien urteilen zu können....würde er nur Profiling betreiben wäre er nicht in fast allen Bereichen der schnellste x86 Compiler.Chachegrösse sagt alleine nichts - es ist die Segmentierung, die auch was mitzuhusten hat. Intels 8 Segmente sind imho AMDs 16 Segmente im Normalfall weit unterlegen. Die längeren Lines sind z.B. auf deutlich mehr Bandbreite angewiesen, denn das Warten der CPU ist bei nem Linefill schlicht davon abhängig, weswegen ein P4 mit SDRAM auch so lahm wird, kaum isses nimmer im Cache, wogegen der AMD da weniger Probleme hat Aufgrund kürzerer Lines.Ja, die längeren Lines brauchen mehr Bandbreite, 16er Sets bringen gegenüber 8er Sets aber keinen wirklichen Vorteil.Soweit ich mich entsinne sinds nur Unterschiede in was erlaubt ist und was nicht für den Compiler. Loops flach "abrollen" ist z.B. ab und an "sinnvoll" aber bei base wohl nicht erlaubt und bei peak erlaubt.Nein, bei peak darf man die Compiler-Flags für jeden Einzeltest beliebig setzen, bei base müssen sie für alle Tests gleich sein.
Ich sags mal so. Laut bösen Unkenrufen halbiert sich unter Umständen bei unterschiedlichen Umgebungen die Performance, wenn man den Intel Compiler optimieren lässt. In der Praxis lässt sich damit also keinen Blumentopf gewinnen, wenn man nicht identische Geräte hat.Dieser Absatz ist zusammenhangsloses gerede, bitte konkrete Fakten und keine "bösen Unkenrufe"."Verfahren A und B unterscheiden sich normalerweise in ihrer Komplexitätsklasse....lässt man einen Merge-Sort auf einem P-100 gegen einen Selection-Sort auf einem P4-3,0 antreten gewinnt der P-100 ab einer bestimmten Problemgröße immer...wo ist der Sinn bei solch einer Aktion? "

Tja das Verfahren darf ja frei gewählt werden von beiden Seiten... Ist also fair.Das läuft im Endeffekt auf den effektivsten Algorithmus raus, wobei wir wieder bei gleichen Bedingungen wären.
"Vergleichbarkeit ist nur bei gleichen Bedingungen für alle gegeben.Das sollst du auch nicht, die Beschreibungen wären aber mal ein Anfang..."

Nein, diese Beschreibungen sind eben genau das, was mich nicht interessiert. Das ist imho nur Halbwissen, welches oft zu Trugschlüssen führt. Ich bin jedenfalls noch immer der Meinung, dass Optimierung "wissenschaftlich" ist und und Optimierung durch Profiling nur ein durchtesten von Möglichkeiten darstellt, was imho keine Optimierung mehr ist.Du hast keine Ahnung, wie der Compiler intern arbeitet, mit solchen Kommentaren wäre ich vorsichtig...Dell stellte bei einzelnen Test bei angeschaltetem HT nen Leistungsverlust von satten 37% fest - schon happig.Quelle? B-Step oder C-Step P4?Ich halte die SPEC Suite für nen guten Systemtest und ohne Profiling sogar für nen brauchbaren CPU/Compilertest, aber CPUs kann man damit nicht vergleichen und Profilingcompiler gehörten geächtet. Drücken wir es mal so aus: Du hast ziemlich komische Vorstellungen...

[Haarmann]

Muh-sagt-die-Kuh

"Ich glaube nicht, dass du intel Compiler genau genug kennst um über seine Optimierungsstrategien urteilen zu können....würde er nur Profiling betreiben wäre er nicht in fast allen Bereichen der schnellste x86 Compiler."

Genau mitem Profilen wirste ja so schnell. Ein "normaler" Compiler würde für den P4 NW immer gleich optimieren egal welches Board drin ist - ist ja immer die gleiche CPU. Beim Profiling wirste aber feststellen, dass aufgrund unterschiedlicher RAM Bandbreiten z.B. das System gewisse "Optimierungen", gerade das "Flachrollen" von Schleifen, nicht mehr so gut laufen, wie die laufen könnten (SDR Ahoi) und rollst nimmer flach. Das ist nur logisch, aber im Prinzip nicht Praxistauglich. Du kannst ja nicht für jedes eingesetzte System neu optimieren.

Lustige Tests um dies Verhalten, die Praxisuntauglichkeit, mal zu Zeigen ist, dass man mal nen Willy und nen NW nimmst auf nem SDR und nen 875 Board und danach lässt SPEC bauen per Intel und GNU Compiler (ich lernte also im peak mode) und am Ende tauschste mal dann die fertigen Programme aus und lässt se also auf dem anderen System laufen. Wetten der GNU Compiler wird gewinnen?
Und weil dem eben so ist, wird der GNU Compiler oder auch M$ Compiler bevorzugt, wenn man ein Program für allerlei Systeme schreiben und optimieren will.

"Nein, bei peak darf man die Compiler-Flags für jeden Einzeltest beliebig setzen, bei base müssen sie für alle Tests gleich sein."

Wie Du siehst, hab ich diese Erkenntnis schon eingebaut. Danke dafür.

"Dieser Absatz ist zusammenhangsloses gerede, bitte konkrete Fakten und keine "bösen Unkenrufe"."

Steht oben als Exempel. Ich nenne solche Sachen gerne böse Unkenrufe, denn als das werdens die Befürworter bezeichnen, ohne je nen Gegnetest gemacht zu haben.

"Das läuft im Endeffekt auf den effektivsten Algorithmus raus, wobei wir wieder bei gleichen Bedingungen wären."

Richtig, aber den kannste immer verschieden in Code fassen und das ist imho sehr interessant, denn nicht jeder Prozessor ist bei allem gleich schnell. Da kanns Unterschiede geben und diese möchte ich auch berücksichtigen. Ich kenne sowas drum aus eigener Erfahrung, als ich ab und an mal PRGs anderer Leute umgeschrieben hab (Schule und Pascal), um ihnen zu zeigen, dass man mit anderen Befehlen etc sehr viel Power rausholen kann.

"Du hast keine Ahnung, wie der Compiler intern arbeitet, mit solchen Kommentaren wäre ich vorsichtig..."

Muss man nicht - das ist bekannt. Deswegen wird er auch nur selten genutzt. Kannst für Dich selbst mal ausprobieren, wie lahm ein Intel Compiler "SPEC" optimiertes PRG für P4 auf nem Banias ist - sofern Beide Systeme hast.

"Quelle? B-Step oder C-Step P4?"

Quelle ist/war Dell selber - kam im Zusammenhang mit dieser G5 Story zum tragen, wo man absichtlich ja nur GNU Compiler eingesetzt hatte für die Benches. Da es sich um 3.06GHz Xeons handelte, muss ich von C-Step ausgehen, auch wenn das nicht explizit angeschrieben war.

"Drücken wir es mal so aus: Du hast ziemlich komische Vorstellungen..."

Ich lass mich nur nicht gerne verarschen - wenn Du den P4 Besitzer mal hören könntest, der sagt schon, dass Windows träge wie nur was ist, seit er auf Intel gewechselt hat usw (siehe Titel). Wahrscheindlich fällt einem das nur dann auf, wenn man Klickibunti immer abgestellt hat. Da ich ebenfalls meine P4s verkauft habe, weil sie mir zu langsam waren im Alltagsbetrieb und statt dem P4 mit ca 3GHz lieber wieder nen Dual AMD 1600+ nahm (inzwischen Dual 2400+), kannste Dir etwa ausrechnen, wie langsam sich das anfühlen musste.

P.S. Ev hat ja Demirug oder Zeckensack nen "Minibench", den er mal mit mehreren Compilern auf sein System abstimmen kann und wir dann auf unseren P4s und Athlons "testen" könnten. Wär das ne Idee?

[mrdigital]

Haarman, wieso verbeisst du dich machmal auf ne Position, die eigentlich nicht wirklich zu halten ist? Die SPEC ist meiner Meinung nach der einzige plattformübergreifende Benchmark, der einigermassen ein Vergleichskriterium liefert (zwischen verschiedenen Plattformen aber auch innerhalb einer Plattform). Der einzige Kritikpunkt ist der, dass auf den verschieden Plattformen nicht der selbe Compiler verfügbar ist. Gleichzeitig ist die SPEC doch für jeden Entwicker eine gute Sache, man kann sehen welche (Compiler)Optimierungen auf welcher Plattform einen Vorteil bringt (oft ist es ja auch so das ein Vorteil für den P4 nicht zu einem Nachteil für den Athlon wird) und auf diese Weise kann man die Compilerflags finden, die mir auf allen Zielplattforen gute Leistung bringen, ohne dass ich eine Plattform benachteilige (auch wenn ich dabei nicht das absolute Maxiumum für eine Plattform rausgeholt habe). Das geht mit der SPEC aber nur deshalb, weil sie ein sehr breites Anforderungsprofil hat, dass so breit ist, dass eben nicht einzelne Plattformen bevorzugt werden.
Das der GNU oder MS Compiler bevorzugt werden, ist glaube ich auch ne Preisfrage (den GNU gibts für lau, der MS ist in meiner IDE mit drinn und den Intel muss ich für komerzielle Anwendungen noch mal extra kaufen, und für das gro der Anwendungen sind diese hochoptimierten Compiler Kanonen auf Spatzen, wieso soll man sich dann also damit noch "belasten")

[Haarmann]

mrdigital

Seltsamerweise lese ich aus dem Anfang von Deinem Post exakt meinen Standpunkt heraus. Danach widerum löst Du Dich von der "Plattform" und schliesst auf ne CPU - wieso eigentlich. Da liegt ja gerade der Pferdefuss. Die SPEC Suite reagiert nicht nur auf die CPU, sondern auch aufs Drumherum, was imho die Plattform ausmacht. Dementsprechend kann man nur Plattformen vergleichen und keineswegs CPUs. Ein P4 mit SDR is nunmal nicht gleich schnell im SPEC "Test" wie der gleiche P4 mit nem Dual Channel DDR Board.

"oft ist es ja auch so das ein Vorteil für den P4 nicht zu einem Nachteil für den Athlon wird"

Ein Vorteil fürn P4 ist z.B. SSE2, denn mit x86 FPU ist das Teil so lahm, dass es einem die Schuhe auszieht, mit der Einbusse von nur 64 Bit vs 80 Bit FPU Genauigkeit. Wo da der Athlon nen Vorteil herbekommen soll ist mir z.B. ein Rätsel. Die SPEC rechnet bekanntlich nicht mit 80 Bit FPU Formaten, sondern mit 64 Bit und somit muss man da gar nicht irgendwas vergleichen wollen. Sowas geht immer in die Binsen. 80 Bit FPU Power von x86 lässt sich einfach nicht mit 64 Bit Power vergleichen. Genau das wird dort z.B. aber getan. Gleiches gilt nicht für alle nur 64 Bit tauglichen FPUs.
Der Vorteil der grösseren Genauigkeit wussten viele Berufsgruppen zu schätzen und genau deswegen stiegen sie auf Intel um, obschon diese damals eigentlich "langsamer" waren.

Und für mich gilt nach wie vor, dass die Holzhammervariante bei Intels "Optimierung" keine Optimierung dem Sinne nach darstellt, sondern ein Ausprobieren verschiedener Lösungen. Das ist aber ne "Glaubensfrage".

[Lefty de Vito]

@Haarmann:

Konntest Du den Tip von Tiamat schon ausprobieren?

out--Lefty

[Muh-sagt-die-Kuh]

Original geschrieben von Haarmann
Muh-sagt-die-Kuh
Genau mitem Profilen wirste ja so schnell. Ein "normaler" Compiler würde für den P4 NW immer gleich optimieren egal welches Board drin ist - ist ja immer die gleiche CPU. Beim Profiling wirste aber feststellen, dass aufgrund unterschiedlicher RAM Bandbreiten z.B. das System gewisse "Optimierungen", gerade das "Flachrollen" von Schleifen, nicht mehr so gut laufen, wie die laufen könnten (SDR Ahoi) und rollst nimmer flach. Das ist nur logisch, aber im Prinzip nicht Praxistauglich. Du kannst ja nicht für jedes eingesetzte System neu optimieren.

Lustige Tests um dies Verhalten, die Praxisuntauglichkeit, mal zu Zeigen ist, dass man mal nen Willy und nen NW nimmst auf nem SDR und nen 875 Board und danach lässt SPEC bauen per Intel und GNU Compiler (ich lernte also im peak mode) und am Ende tauschste mal dann die fertigen Programme aus und lässt se also auf dem anderen System laufen. Wetten der GNU Compiler wird gewinnen?Profiling ist dann sinnvoll, wenn das Programm auf einer speziellen Architektur laufen soll, compiliert man ein kommerzielles Programm benutzt man diese Option nicht, der Compiler ist trotzdem noch schneller als der Rest.Und weil dem eben so ist, wird der GNU Compiler oder auch M$ Compiler bevorzugt, wenn man ein Program für allerlei Systeme schreiben und optimieren will.Meinen Erfahrungen nach ist selbst vom Intel Compiler mit P3 Optimierung erzeugter Code auf einem P4 schneller als das was der MS Compiler oder GNU ausspuckt."Du hast keine Ahnung, wie der Compiler intern arbeitet, mit solchen Kommentaren wäre ich vorsichtig..."

Muss man nicht - das ist bekannt. Deswegen wird er auch nur selten genutzt. Kannst für Dich selbst mal ausprobieren, wie lahm ein Intel Compiler "SPEC" optimiertes PRG für P4 auf nem Banias ist - sofern Beide Systeme hast.Wenn es "bekannt" ist hast du doch sicher eine Quelle. Wie ich oben schon schrieb, man muss nicht mit Profiling arbeiten und bekommt trotzdem erstklassige Geschwindigkeit."Quelle? B-Step oder C-Step P4?"

Quelle ist/war Dell selber - kam im Zusammenhang mit dieser G5 Story zum tragen, wo man absichtlich ja nur GNU Compiler eingesetzt hatte für die Benches. Da es sich um 3.06GHz Xeons handelte, muss ich von C-Step ausgehen, auch wenn das nicht explizit angeschrieben war.Wenn ich nach einer Quelle frage erwartet ich einen Link auf ein Dokument oder eine Website."Drücken wir es mal so aus: Du hast ziemlich komische Vorstellungen..."

Ich lass mich nur nicht gerne verarschen - wenn Du den P4 Besitzer mal hören könntest, der sagt schon, dass Windows träge wie nur was ist, seit er auf Intel gewechselt hat usw (siehe Titel). Wahrscheindlich fällt einem das nur dann auf, wenn man Klickibunti immer abgestellt hat. Da ich ebenfalls meine P4s verkauft habe, weil sie mir zu langsam waren im Alltagsbetrieb und statt dem P4 mit ca 3GHz lieber wieder nen Dual AMD 1600+ nahm (inzwischen Dual 2400+), kannste Dir etwa ausrechnen, wie langsam sich das anfühlen musste.

P.S. Ev hat ja Demirug oder Zeckensack nen "Minibench", den er mal mit mehreren Compilern auf sein System abstimmen kann und wir dann auf unseren P4s und Athlons "testen" könnten. Wär das ne Idee? P4 mit 3 Ghz zu langsam im Alltagsbetrieb? Aha....das ist so ziemlich die abgehobenste Aussage die ich seit langer Zeit gehört habe...

[Haarmann]

Lefty de Vito

Half leider nix in dem Falle... Aber schaden kann sein Tip ja nicht.

Muh-sagt-die-Kuh

"Profiling ist dann sinnvoll, wenn das Programm auf einer speziellen Architektur laufen soll, compiliert man ein kommerzielles Programm benutzt man diese Option nicht, der Compiler ist trotzdem noch schneller als der Rest."

Den Beweis musst Du mir erst liefern - Bedingungen hab ich bereits gegeben. Ich glaub nicht dran, weil ichs anders gehört hab, aber selbst den test nicht durchführen kann.

"Meinen Erfahrungen nach ist selbst vom Intel Compiler mit P3 Optimierung erzeugter Code auf einem P4 schneller als das was der MS Compiler oder GNU ausspuckt."

Und er wird auf nem Pentium M nochmals schneller sein... Was soll das aussagen? Ist er denn auch schneller auf nem Via C3?

"Wenn es "bekannt" ist hast du doch sicher eine Quelle. Wie ich oben schon schrieb, man muss nicht mit Profiling arbeiten und bekommt trotzdem erstklassige Geschwindigkeit."

Was erstklassige Geschwindigkeit ist, das muss man wohl jeden selbst definieren lassen. Aber kannst Dich wie gesagt mit nem P4 mit SDR gegen nen P4 mit 875 zum reversen SPECen melden. Danach kannste das auch belegen - vorher nur behaupten, denn mir ist kein solcher Test public bekannt.

"Wenn ich nach einer Quelle frage erwartet ich einen Link auf ein Dokument oder eine Website."

Ich find sicher paar Links zu dem beanstandeten Test G5 vs Xeon usw. Nur bis darunter mal was Schlaues ist, kanns dauern. Nicht alles, was ich vor 20 Tagen gelesen hab, ist Heute noch verfügbar - leider.

"P4 mit 3 Ghz zu langsam im Alltagsbetrieb? Aha....das ist so ziemlich die abgehobenste Aussage die ich seit langer Zeit gehört habe..."

Es gibt immer andere Ansichten zum gleichen Thema. Mir wars eben zu langsam in gewissen Fällen und dementsprechend hatte ich dies Gefühl. Mein Kollege z.B. hat mir Heute erzählt, dass ihm der AMD Athlon 64 auch schneller vorkam, denn andere Geräte. Da er EDV Händler ist, kannste Dir ausrechnen, dass er durchaus ab und an was "teures" zusammensetzt. Dass hier ein AMD Athlon 64 positiv herausragt, das ist eben sein empfinden. Das muss ich nicht nachvollziehen können, um ihm das zu glauben.