News Beeindruckender Weltrekord in Super PI

[stummerwinter]

Zunächst mal Glückwunsch nach Italien!

Hier die wohl vollständigste Übersicht, Team Japan ist zB nicht im hwbot vetreten: http://ripping.org/benchmarks.php?act=scores&superpi=1M&cpuid=INTEL

Aber an der Stelle muss ich mal Kritik äußern: No_Name hat es Anfang des Jahres geschaft, den 1M-WR nach D zu holen (und nicht nur den, diverse andere auch), das war CB KEINE News Wert, sehr schade, dass solche Ergebnisse von deutschen OCen keine Beachtung finden...

 

[alice]

@ Kritik an SuperPi

Ich weiß nicht, ob SuperPi für Intel irgendwie optimiert ist - der Punkt ist einfach, dass dieser Benchmark irrelevant ist, weil er ausschließlich die Leistung der X87-FPU testet. Man darf in dem Zusammenhang ruhig mal daran denken, dass Adobe Flashplayer, eine Anwendung die vermutlich jeder mal benutzt, SSE vorraussetzt (läuft nicht mehr auf Pentium II oder K6) und viele gebräuchliche Anwendungen SSE, zumindest SSE1, benutzen. Wer bei Gleitkommaoperationen also SSE ausschließt vergleicht etwas, das in der Praxis schon lange keine Rolle mehr spielt. Mit irgendwelchen SuperPi-Leistungsdaten die Leistung heutiger Prozessoren zu vergleichen ist, wie die Leistung heutiger Grafikkarten mit 3Dmark99 zu beurteilen.

Bringt doch nichts. Super Pi ist Single Threaded, nutzt also auch nur einen Kern.

Im planet3dnow Forum stand mal etwas interessantes dazu. AMD kann pro Takt 3 x87 FP Instruktionen verarbeiten. Der Maschinencode von Super Pi ist dafür aber nicht ausgelegt, weil er eben für die damaligen uneingeschränkt vorherrschenden Intel CPUs erstellt wurde. Man sollte nicht vergessen, Super Pi stammt aus dem Jahre 1995.
Ich kann dir nicht sagen, ob diese Analyse zutrifft, ist aber durchaus plausibel. Würde man den Super Pi Quellcode durch einen aktuellen Compiler jagen, der für AMD optimiert, wären auch hier bessere Zeiten zu erwarten. Trotzdem denke ich nicht, dass Core2 CPUs, zumindest was IPC betrifft, bei diser Anwendung übertroffen werden könnten.
Man sollte Super Pi daher nicht mehr für Leistungsvergleiche verwenden, schon gar nicht zwischen unterschiedlichen Herstellern. Selbst für ein und den selben Hersteller ist Super Pi nur noch begrenzt brauchbar, da eben nur obsolete x87 Instruktionen für FP genutzt werden. Aktuell ist jedoch SSE.

hi,

dem ist nichts hinzuzufügen, ausser noch:

das superpi den windows eigenen timer (=zeitmesser) nutzt.
dieser hat eine mittlere genauigkeit von ca.+/-15ms,
was das bedeutet ist wohl jedem klar.

alternative, MaxxPI, hier momentan als Techdemo :

http://forum.effizienzgurus.de/f47/stelle-vor-maxxpi-preview-cpu-benchmark-auf-pi-basis-t4980.html

zitat:

####################################

features:

mmx / sse support

hardwarenahe zeitmessung, ca. 1-2ms genau

max. rechentiefe: 128m

max. ram verbrauch ca. 1.2gb ram (bei 128m)

multithread (nicht multicore)

mit einem 4ghz intel (+sse2), 6mb cache:
128m = ca. 14min
.
32m = ca. 3min
.
1m = ca. 2,4sec.


score:

k/sec.
ist dazu da, die erreichten ergebnisse einfacher zu vergleichen,
also anstatt 2min 32sec 343ms sagen zu müssen gibt es
nun einen wert, mit hilfe derer man die erg. vergleichen kann.

es ist nichts anderes als:
die anzahl der errechneten nachkommastellen pro sec. in k (also 1024)

z.b.: im 1m fall wurden 356.2(k/sec.) x 1024 also 364748.8 nachkommastellen pro sec. errechnet.

####################################

kleine faq:

f:
unter welchen betriebssystemen läuft das ganze?
a:
winxp, vista, win2003/2008 server, win2000

f:
auch unter 64bit?
a:
maxxpi² ist eine 32bit applikation die auch
unter x64 problemlos läuft

f:
haben dual/quad(tripple) cpu's einen vorteil?
a:
ja, einen kleinen

f:
welchen einfluss hat das ram bei diesem benchmark?
a:
je höher die zu berechnende anzahl der nachkommastellen
umsomehr spielt die memory-performance eine rolle.
maxxpi profitiert stark von dingen wie: fsb, timings

f:
warum *preview*?
a:
weil diese *preview* teil eines grösseren
projektes ist.

f:
wird man später, mit dem release der *vollversion
die jetzt erreichten erg. vergleichen können?
a:
ja

f:
was wird alles bei dem ONLINE submit übertragen?
a:
NUR ein unveränderter screenshot
der aktuell laufenden MaxxPi² anwendung

####################################

 

[masterchorch]

Die News ist teilweise irreführend bzw. falsch,
der Satz über die magische 7 Sekunden-Marke suggestiert für einige Leute, dass dies der erste Score unter 7.0 Sekunden ist, was ja nicht korrekt ist!

Auch Handelt es sich bei +650mv CPU VID Special nicht um einen Vmod,
sondern ledigleich um eine im DFI BIOS frei verfügbare Spannung.

 

[gruffi]

Hallo Alice,

ist der Quellcode von MaxxPI verfügbar?

 

[alice]

Hallo Alice,

ist der Quellcode von MaxxPI verfügbar?

hi,

nein, er ist nicht öffentlich.

hier ein ausblick was kommen wird:

http://www.MaxxPI.net

cu

alice

 

[MountWalker]

Solange für MaxxPI gilt: "MaxxPI² is an 32bit application, ...)." und AMD-Prozessoren im x64-Modus mehr Register haben, als im 32b-Kompatibilitätsmodus, demzufolge dort also schneller sind, ist auch MaxxPI wegen technischer Veralterung unbrauchbar.

 

[alice]

Solange für MaxxPI gilt: "MaxxPI² is an 32bit application, ...)." und AMD-Prozessoren im x64-Modus mehr Register haben, als im 32b-Kompatibilitätsmodus, demzufolge dort also schneller sind, ist auch MaxxPI wegen technischer Veralterung unbrauchbar.

...techn. veralterung... = no comment

das würde 99.9% aller benchs in frage stellen.

unter einem 32bit os ist das nicht anders realisierbar,
alle prog. durchlaufen hier den selben weg zum microcode der cpu
nur nutzen die meinsten die akt. erweiterungen nicht (mmx,sse usw.)

und unter einem x64 os-system stimmt diese aussage hingegen nicht,
hiervon profitiert MaxxPI sehr wohl, was sich auch in den erg. niederschlägt
(bei all denen die memory intensiv sind), allerdings trägt hier zu einem grossen
teil MS selber dazu bei, jedoch einen teil muss der entwickler selber hinzusteuern.

es ist immer wieder intressant, wie der wissensstand ist, hierbei

cu

 

[MountWalker]

In der MaxxPI-FAQ steht eindeutig drin, was ich oben geschrieben habe - 32b Anwendung, egal ob diese 32b Anwendung nun laut Entwicklermeinung von einem 64b OS "profitiert" - solange sie selbst eine 32b Anwendung ist, ist sie eine 32b Anwendung.

Dass die zusätzlichen Register der AMD-Prozessoren im 64b Modus vollkommen unabhängig von der RAM-Größe einen starken, sehr wohl messbaren Unterschied in der reinen Rechenleistung haben, kann jeder mit Cinebench x86-32 vs Cinebench x86-64 auf nem PC mit einer AMD-CPU und kleiner gleich 2 GiB RAM prüfen. Wozu ein Benchmarksystem für neue x86-Prozessoren, die sowieso alle 64b sind, auf ein 32b OS setzen sollte, kann ich nicht verstehen.

P.S.
Ich verstehe auch nicht, warum der Urheber, obwohl er sowieso keine Gebühren verlangen will, den Quelltext nicht veröffentlicht - wenn er den offenlegen würde, gäbs ziemlich schnell 64b-Kompilate davon.

 

[alice]

hi,

In der MaxxPI-FAQ steht eindeutig drin, was ich oben geschrieben habe - 32b Anwendung, egal ob diese 32b Anwendung nun laut Entwicklermeinung von einem 64b OS "profitiert" - solange sie selbst eine 32b Anwendung ist, ist sie eine 32b Anwendung.
Dass die zusätzlichen Register der AMD-Prozessoren im 64b Modus vollkommen unabhängig von der RAM-Größe einen starken, sehr wohl messbaren Unterschied in der reinen Rechenleistung haben, kann jeder mit Cinebench x86-32 vs Cinebench x86-64 auf nem PC mit einer AMD-CPU und kleiner gleich 2 GiB RAM prüfen. Wozu ein Benchmarksystem für neue x86-Prozessoren, die sowieso alle 64b sind, auf ein 32b OS setzen sollte, kann ich nicht verstehen.
P.S.
Ich verstehe auch nicht, warum der Urheber, obwohl er sowieso keine Gebühren verlangen will, den Quelltext nicht veröffentlicht - wenn er den offenlegen würde, gäbs ziemlich schnell 64b-Kompilate davon.

man muss nicht alles verstehen...

maxxpi ist ein benchmark der genaueren art, nicht mehr nicht weniger.
mit einem Win OS sind *echte*, also genaue benchmarks, egal ob nun 32/64b prinzipell so einfach nicht mögl.
das gillt auch für dein o.g. Cinebench,
denn im grunde müsste man dazu wirklich in den kernel-modus um per CLI/STI auch irq's unterdrücken zu können.
ein alleiniges zuweisen (isolieren) der rechenlasst per AffinityMask und/oder setzten der SetPriorityClass genügt bei *weitem nicht.

alles andere ist humbug.

man kann nur versuchen das annähernd genau zu erstellen, was maxxpi sehr gut gelingt wie ich meine.
wer jedoch anderer meinung ist, kann gerne mit programmen seiner wahl, die leistung einer maschine vergleichen.
es steht jedem frei, auch dir MountWalker.

ich würde es begrüssen, wenn *du* einen benchmark auf die beide stellen würdest, an mit all deinen genannten
features, natürlich Osource. damit wir, auch was davon haben,
anstatt hier eine (meine) leistung, unwissend, zu diskreditieren.

MaxxPI wird, zu gegebener zeit, auch in x64 erscheinen, warum auch nicht.

cu

 

[gruffi]

Solange für MaxxPI gilt: "MaxxPI² is an 32bit application, ...)." und AMD-Prozessoren im x64-Modus mehr Register haben, als im 32b-Kompatibilitätsmodus, demzufolge dort also schneller sind, ist auch MaxxPI wegen technischer Veralterung unbrauchbar.

Nun ja, die zusätzlichen Register stehen Intel Prozessoren unter x86-64 ja auch zur Verfügung. Es ist einfach so, dass die Core Architektur, zumindest bis Nehalem, noch einige gravierende Schwächen unter 64 Bit hatte, zB das nicht funktionierende Macro-Op Fusion, was bei AMD nicht der Fall ist. IdR können AMD Prozessoren unter 64 Bit also mehr zulegen. Von "technischer Veralterung" kann man da nicht wirklich sprechen.

Nein, das Problem sehe ich an ganz anderer Stelle. MaxxPI wurde vermutlich mit dem Microsoft Compiler erstellt (oder eventuell auch Intel Compiler). Und das ist generell keine Basis fürs Benchmarken von AMD Prozessoren. MaxxPI ist also maximal ein Benchmark Tool für Intel Prozessoren.
Wer wirklich allgemeine Benchmark Anwendungen schreiben möchte, und nicht gerade jede menge Kohle für lizenzpflichtige Compiler ausgeben möchte, für den gibt es momentan imo nur eine Option, GCC (Dwarf-2).

 

[alice]

hi,

Von "technischer Veralterung" kann man da nicht wirklich sprechen.

wollt schon sagen , wer oder was hier *veraltet ist,
( https://www.computerbase.de/forum/t...rekord-in-super-pi.466800/page-4#post-5559256 )
oder wie weit es hier mit den kenntnissen der materie bestellt ist, ist offenkundig

die zusätzlichen Register stehen Intel Prozessoren unter x86-64 ja auch zur Verfügung. Es ist einfach so, dass die Core Architektur, zumindest bis Nehalem, noch einige gravierende Schwächen unter 64 Bit hatte, zB das nicht funktionierende Macro-Op Fusion, was bei AMD nicht der Fall ist. IdR können AMD Prozessoren unter 64 Bit also mehr zulegen

nunja, das könnte man jetzt ellenlang weiterführen:
z.b. sind gravierenden performanceunterschiede zum AMD nur durch die Anwendung der Opcodes BTS/BTC
in einem Bitarray[] funktionen vorhanden. AMD prozessoren (auch die aktuellen) sind bei diesen operationen
signifikant langsamer als Intel CPU's, für AMD's müsste man diesen opcodes durch indizierte array[]
zugriffe + AND/OR bitmasken per SHL/SHR ersetzen.

nur: macht das sinn? insbesondere bei einem benchmark?!?
natürlich nicht, es ist kein benchmark mehr wenn für alle mögl. cpu's verschiedener angepasster code verwendet wird.
der grundgedanke eines jeden benchs ist es, alles mit einem maß zu messen und genau
so wird in maxxpi verfahren.

Nein, das Problem sehe ich an ganz anderer Stelle. MaxxPI wurde vermutlich mit dem Microsoft Compiler erstellt (oder eventuell auch Intel Compiler). Und das ist generell keine Basis fürs Benchmarken von AMD Prozessoren. MaxxPI ist also maximal ein Benchmark Tool für Intel Prozessoren. Wer wirklich allgemeine Benchmark Anwendungen schreiben möchte, und nicht gerade jede menge Kohle für lizenzpflichtige Compiler ausgeben möchte, für den gibt es momentan imo nur eine Option, GCC (Dwarf-2).

grundsätzlich stimme ich zu, wie ich weiter oben schon gesagt hatte,
ist das generelles problem mit win32/64 derivaten da diese nun mal multitasking OS-systeme sind. richtig *genau*
messen (benchen) geht das nur mit echtzeitsystemen, meines erachtens.

zu GCC und co.: irrelevant, da nicht verbreitet/massentauglich
ein bench macht nur sinn, in diesem umfeld hier,
wenn er mit eigener HW, SW vergleichbar ist.

zum compilier:
PI-part, MS-Visual studio, C++, Inline ASM
cache,latency,Memory(benchs)-part, watcom, ASM
Prime,AES,BZip, watcom, C++, ASM, Inline ASM
Gui-part, Embarcadero, OOP

mehr oder weniger alle zeitkritischen routinen sind via ASM mögl. direkt.
das ist meiner meinung nach der einzige akzeptabele weg um äussere einflüsse
auf ein erträgl. maß zu reduzieren. ganz elimieren kann man das nicht, nicht unter windows.

wie ich schon sagte, ist mir das meiner meinung nach sehr gut gelungen. es ist klar das so ein benchmark nicht von heute
auf morgen entstehen kann. viele jahre sind ins land gegangen, was die resultate wiederspiegeln

gruffi:
schaue dir die ergebnisse (maxxpi .net) an und wenn du nur ansatzweise verstehst was ich hier schreibe und
die intel/amd memorysubsysteme + core architekturen kennst (tiefergreifend),
wirst du schnell sehen das alle erg. für ein win-basierenden bench, sehr exact sind.
kleiner tip fur dich: cache, mips, memory sind die augenscheinlichtsten bezügl.intel/amd

oder glaubst du auch: das zb. auf einem x58 es keinen unterschied, macht ob
dual oder tripple channel genutzt wird , was uns ja im moment
die alle (>99%) benchs zeigen.
falls du das glaubst, dann bleibe besser bei superpi, everest, wprime... und co.

//edit:
tripple: http://www.maxxpi.net/results/show.php?ID=x5x8l4f0w4b7

dual : http://www.maxxpi.net/results/show.php?ID=b9p5r1p0c7m5

@all:

man könnte diese diskussion endlos weiterführen, jedoch macht es für mich keinen sinn.
CB ist nicht das richtige forum für so etwas. hier ist mainstream angesagt, was ja auch nicht weiter schlimm ist,
jedoch ist dieser verlauf der diskussion für <1% der leser verständlich denke ich wenn überhaupt.

cu

 

[gruffi]

nunja, das könnte man jetzt ellenlang weiterführen:
z.b. sind gravierenden performanceunterschiede zum AMD nur durch die Anwendung der Opcodes BTS/BTC
in einem Bitarray[] funktionen vorhanden. AMD prozessoren (auch die aktuellen) sind bei diesen operationen
signifikant langsamer als Intel CPU's, für AMD's müsste man diesen opcodes durch indizierte array[]
zugriffe + AND/OR bitmasken per SHL/SHR ersetzen.

Du hast überhaupt nicht verstanden, was ich in dem Abschnitt geschrieben habe. Es geht hierbei konkret um die Unterschiede zwischen x86-32 und x86-64. Und nicht um allgemeine Unterschiede. Ausserdem müsstest du gar nichts ersetzen. Logische Operatoren wie and/or/xor sind die primären und präferierten Instruktionen um Bits auf Bytemaschinen zu verarbeiten, da sie praktisch überall verfügbar und sehr effizient sind. Und ob bts/btc/btr auf AMD Prozessoren wie von dir behauptet wirklich so langsam sein sollen, da wäre ich mir gar nicht mal so sicher. Könnte genauso gut an deinem Mikrocode liegen.

nur: macht das sinn? insbesondere bei einem benchmark?!?
natürlich nicht, es ist kein benchmark mehr wenn für alle mögl. cpu's verschiedener angepasster code verwendet wird.

Genau das aber passiert schon durch den Compiler, was du gar nicht bewusst mitbekommst. Handgeschriebene Assembler Routinen kommen noch erschwerend hinzu.

zu GCC und co.: irrelevant, da nicht verbreitet/massentauglich

GCC ist sehr wohl weit verbreitet. Ich würde dir einfach mal empfehlen, deinen Blick auch auf Nicht-Windows Systeme schweifen zu lassen. Und vor allem auch mal auf professionelle Bereiche. Da werden teils noch ganz andere Sachen eingesetzt. GCC war lediglich eine Empfehlung für alle Hobbyisten, die einen kostenfreien, standardkonformen und universellen Compiler suchen. Dazu ist er mittlerweile auch wesentlich performanter als zB der Microsoft Compiler. Sry, falls das jetzt hart für dich klingt. Aber jeder, der für explizite Benchmark Tools noch auf den Microsoft Compiler setzt, ist auf einem Entwicklungsstand irgendwo von vor 5 bis 10 Jahren stehen geblieben. Für alle, die wirklich die HARDWARE benchmarken wollen, ist der GCC eine wesentlich bessere Alternative.

wenn er mit eigener HW, SW vergleichbar ist.

Den Punkt verstehe ich zB auch nicht. Was soll daran denn nicht vergleichbar sein? Die Binary ist fix und damit ist die Vergleichbarkeit von System zu System problemlos gegeben.

 

[alice]

hi,

grumel...

Du hast überhaupt nicht verstanden, was ich in dem Abschnitt geschrieben habe

naja... das ist deine meinung.

Genau das aber passiert schon durch den Compiler, was du gar nicht bewusst mitbekommst. Handgeschriebene Assembler Routinen kommen noch erschwerend hinzu.

naja... auch das ist deine meinung, ich lasse sie dir.

GCC ist sehr wohl weit verbreitet. Ich würde dir einfach mal empfehlen, deinen Blick auch auf Nicht-Windows Systeme schweifen zu lassen.

warum sollte ich das tun, wir sind hier auf dem CB, vergessen?, nicht auf einem GCC / GNU / linux supportforum o.ä.

wenn GCC so gut ,ist dann wünsche ich mir einen benchmark,
der unter 1500kb gross ist auf allen plattformen (XP-w7) einwandfrei läuft ohne installation,
ohne zus. ext. library's, überall eine genauigkeit von ca. +/-1% liefert (auf das end-ergebniss)
dazu noch auf allen cpu's eine gleichbleibende/vergleichbare nettolast erzeugt (PMU),
das ganze überall mit einer einzigen gleichbleibenden excutable,
ja dann, reden wir weiter.

Sry, falls das jetzt hart für dich klingt. Aber jeder, der für explizite Benchmark Tools noch auf den Microsoft Compiler setzt, ist auf einem Entwicklungsstand irgendwo von vor 5 bis 10 Jahren stehen geblieben.

uhh, vorsicht!
da sieht meine karriere aber doch *leicht anderst aus... die letzten 5-10 jahre, lol

wenn das zutreffend sein sollte, dann sind hier 5mio. posts, 400tausend mitglieder, xxxReviews
zitat: "auf einem Entwicklungsstand irgendwo von vor 5 bis 10 Jahren stehen geblieben"
das lasse ich jetzt mal so stehen und du bist uns allen vorraus, mit gnu...

Den Punkt verstehe ich zB auch nicht. Was soll daran denn nicht vergleichbar sein? Die Binary ist fix und damit ist die Vergleichbarkeit von System zu System problemlos gegeben.

bitte reise die texte von mir nicht ausseinander,
du kennst watcom und dessen fähigkeiten nicht ansatzweise.

ursp. war die PI routine, mit GNU/GCC erstellt, erschreckend... das ganze.
schaue dir kompilate von watcom/ms im vergl. zu gnu an (Uops Retired /Retired Ops) dann kannst du genau sehen
wer was fabriziert. vom speichermanagment will erst gar nicht anfangen (>1gb).

es geht hier um ein win-basierndes system.
wenn GCC (o.ä.) so weit verbreitet ist, dann würde ich auch einen blick darauf werfen,
warum nicht, ist es aber nicht, in der ms welt.
unter linux mag das ganze anderst aussehen, jedoch nutzt kein mensch linux von
den 400t usern hier, oder doch...

wir leben nun mal in einer MS welt, nicht einer GCC/GNU/Linux welt.

Aber warum streiten, du nimmst GNU/Linux und wir nehmen MS/watcom, ok?!
Oder noch besser Java/Linux, was ja irgendwan-einmal *das* mass aller dinge
sein wird, wurde zum. vor 5-10 jahren gesagt ,oder nicht?

Sry, falls das jetzt hart für dich klingt

ich beende meinerseits diesbezügl. die diskussion, hier ( jetzt wirklich ) und überlasse dich alleine
der MS welt hier.

falls jemand weitere infos bezügl. MaxxPI² und dessen techniken benötigt,
dann kann er gerne via http://www.maxxpi.net/pages/contact.php eine anfrage erstellen.

mfg

alice

 

[gruffi]

naja... das ist deine meinung.



naja... auch das ist deine meinung, ich lasse sie dir.

Das ist nicht meine Meinung, sondern erschliesst sich aus dem Kontext bzw entspricht nun mal der Sachlage. Irgendwie habe ich das Gefühl, du willst dich weder mit Kritik noch mit der angesprochenen Thematik befassen. Ist zwar dein gutes Recht. Nur wird dich Ignoranz auf Dauer nicht weiterbringen.

warum sollte ich das tun, wir sind hier auf dem CB, vergessen?, nicht auf einem GCC / GNU / linux supportforum o.ä.

Warum solltest du das tun? Frage dich lieber, warum du es nicht tun solltest. CB hat zudem weder etwas mit Windows, Linux, GNU oder sonst irgendwas explizit in diese Richtung zu tun. Deine Gedankengänge ergeben absolut Null Sinn.

wenn GCC so gut ,ist dann wünsche ich mir einen benchmark,
der unter 1500kb gross ist auf allen plattformen (XP-w7) einwandfrei läuft ohne installation,
ohne zus. ext. library's, überall eine genauigkeit von ca. +/-1% liefert (auf das end-ergebniss)
dazu noch auf allen cpu's eine gleichbleibende/vergleichbare nettolast erzeugt (PMU),
das ganze überall mit einer einzigen gleichbleibenden excutable,
ja dann, reden wir weiter.

Solche Aussagen ergeben noch viel weniger Sinn. GCC ist immer noch ein Compiler. GCC ist nicht dafür verantwortlich, was die Anwendung tun soll. Und Benchmarks gibt es theoretisch genug. Solange der Quellcode standardkonform ist, kannst du ihn idR auch durch den GCC jagen und entsprechende Executables erzeugen. Als Hausaufgabe kann ich dir zB Lame empfehlen.

du kennst watcom und dessen fähigkeiten nicht ansatzweise.

Dann kläre uns doch mal auf, was für tolle Fähigkeiten Watcom haben soll. Und nein, seit den 90ern habe ich die Entwicklung von Watcom nicht mehr mitverfolgt. Mir ist auch nicht bekannt, dass Watcom heutzutage für irgendwas besonderes hervorzuheben wäre.

ursp. war die PI routine, mit GNU/GCC erstellt, erschreckend... das ganze.
schaue dir kompilate von watcom/ms im vergl. zu gnu an (Uops Retired /Retired Ops) dann kannst du genau sehen
wer was fabriziert. vom speichermanagment will erst gar nicht anfangen (>1gb).

Toll. Von welchem GCC sprichst du? 2.95?

es geht hier um ein win-basierndes system.
wenn GCC (o.ä.) so weit verbreitet ist, dann würde ich auch einen blick darauf werfen,
warum nicht, ist es aber nicht, in der ms welt.

Was völlig irrelevant ist. Entweder du willst es nicht verstehen oder suchst nur nach Ausreden. Wenn du Hardware testen willst, dann sollte die Software bzw das Betriebssystem keinen Einfluss haben. Es spielt also keine Rolle, ob Windows nun das verbreitetste Betriebssystem ist oder nicht. Genauso wenig, ob GCC in der Windows Welt genutzt wird oder nicht. Du willst ermitteln, zu was die Hardware fähig ist. Das kannst du aber nun mal nicht mit Compilern wie dem Microsoft Compiler, die seit mehreren Dekaden ausschliesslich auf Intel Mikrocode optimiert sind. Das macht einen Benchmark einfach wertlos. Es ist die alte Generationenfrage. Will man voranschreiten und sich und seine Umwelt weiterentwickeln? Oder verharrt man stur bei alten Strukturen mit der Gewissheit auf Stagnation? Du machst leider letzteres.

Aber warum streiten, du nimmst GNU/Linux und wir nehmen MS/watcom, ok?!
Oder noch besser Java/Linux, was ja irgendwan-einmal *das* mass aller dinge
sein wird, wurde zum. vor 5-10 jahren gesagt ,oder nicht?

Sry, falls das jetzt hart für dich klingt

Du erzählst ganz schön viel Müll. Ich habe weder Linux noch Java jemals ins Spiel gebracht. Ich denke, du bist weder im Stande eine konstruktive Diskussion zu führen, noch dazu in der Lage zu erkennen, dass ich überhaupt nichts gegen einen Benchmark für Windows gesagt habe. Vielleicht sagt dir ja MinGW Port etwas.

 

[frankpr]

Ich dachte immer, in dem Thread geht es um den eindrucksvollen SuperPi Rekord. Stattdessen wieder einmal Besserwisserei, Korinthenkackerei und was nicht noch alles, das absolut nichts mit dem Threadthema zu tun hat.
Der Kritik von stummerwinter kann ich mich anschließen. Es wäre durchaus gerechtfertigt, auch mal die Leistungen einheimischer Extrem-Overclocker zu würdigen.

Edit: und die nächsten beiden Weltrekorde wurden nach Deutschland, genauer gesagt, nach Cottbus in Südbrandenburg, geholt, 3dmark 05 und 06. http://www.benchbrothers.de/forum/thread.php?sid=&postid=1021#post1021

 

[MountWalker]

Worum soll es denn deiner Meinung in einer lesenswerten Diskussion eher gehen: Um tausend Beiträge die den selben Inhalt, nämlich "finde ich beeindruckend", rezitieren, oder um eine tatsächliche Diskussion über die dem Ergebnis zu Grunde liegende Technik und die Sinnhaftigkeit des Ergebnisses? Diese Diskussion ist imho nicht OT gewesen.