Mehrdimensionale dynamische Arrays in C++

newer
Intel Compiler kompatibel zu gcc...

Bernhard Walle

16 Nov 2002 16 Nov '02

10:35

Hallo, ich möchte in C++ mehrdimensionale Arrays dynamisch erzeugen (nach der Erzeugung bleibt die Größe unverändert) und zwar kein rechteckiges Array sondern mehr dreieckig. Außerdem möchte ich nicht C-Geschichten wie malloc() etc. verwenden sondern den new-Operator. In Java geht es wunderbar mit int[][] array = new int [2][]; for (int i = 0; i < array.length; i++) array[i] = new int[i]; System.out.println(array[1][0]); // ergibt den Defaultwert 0 Sowas hätte ich jetzt auch gerne in C++. Wie macht man sowas? Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ Die, die ihre Kinder nicht säugen, weil das für die Mutter Tierquälerei wäre. -- Wau Holland

Show replies by date

Sebastian Huber

16 Nov 16 Nov

13:40

Hi, nimm doch einfach Vektoren von Vektoren von ..., z.B. typedef std::vector Vector2D; Eine Alternative waeren evtl. valarrays mit slices. Ciao PS: Man sollte den new-Operator in C++ besser nicht so wie in Java verwenden. On Saturday 16 November 2002 11:35, Bernhard Walle wrote:

...

Hallo,

ich möchte in C++ mehrdimensionale Arrays dynamisch erzeugen (nach der Erzeugung bleibt die Größe unverändert) und zwar kein rechteckiges Array sondern mehr dreieckig. Außerdem möchte ich nicht C-Geschichten wie malloc() etc. verwenden sondern den new-Operator.

In Java geht es wunderbar mit

int[][] array = new int [2][];

for (int i = 0; i < array.length; i++) array[i] = new int[i];

System.out.println(array[1][0]); // ergibt den Defaultwert 0

Sowas hätte ich jetzt auch gerne in C++. Wie macht man sowas?

Gruß, Bernhard

Martin Oehler

14:31

Hi! Am Sam, 2002-11-16 um 11.35 schrieb Bernhard Walle:

...

ich möchte in C++ mehrdimensionale Arrays dynamisch erzeugen (nach der Erzeugung bleibt die Größe unverändert) und zwar kein rechteckiges Array sondern mehr dreieckig.

Meinst Du, Dein Array soll etwa so aussehen (in 2D): usw. xxxx xxx xx x

...

int[][] array = new int [2][]; for (int i = 0; i < array.length; i++) array[i] = new int[i];

System.out.println(array[1][0]); // ergibt den Defaultwert 0

Sowas hätte ich jetzt auch gerne in C++. Wie macht man sowas?

Versuche mal folgendes: (dimY wäre nach Deinem Beispiel gleich 2, gibt in meinem kleinen Bild oben die Höhe an) int dimY = ... int** data; // Erzeugung von dimY Zeigern auf integer-Werte data = new( int* )[dimY]; for( int y = 0; y < dimY; y++ ) { // hier erzeugt man das Dreieck // dies ist effektiv ein 1-dim Array von integer-Werten int* temp = new( int )[y+1]; // hier könnte eine Schleife stehen, die temp mit Werten // belegt // Anhängen des Hilfszeigers data[y] = temp; } Mit dimY = 2 sollte das dann so aussehen: xx x Im Allgemeinen (wenn das ganze laufzeitunkritisch ist) hat Sebastian jedoch recht und das ganze löst sich einfacher mit geschachtelten STL-Vektoren. CU Martin

Sebastian Huber

17:10

On Saturday 16 November 2002 15:31, Martin Oehler wrote: [...]

...

Im Allgemeinen (wenn das ganze laufzeitunkritisch ist) hat Sebastian jedoch recht und das ganze löst sich einfacher mit geschachtelten STL-Vektoren.

Hallo, warum sollen STL Vektoren weniger effizient als C-Felder sein? Intern arbeiten die Vektoren ja auch mit Feldern und der Indexoperator ist eine inline-Funktion. Ich denke, dass es da keine Effizienzunterschiede gibt. Ciao

Martin Oehler

19:12

Hi! Am Sam, 2002-11-16 um 18.10 schrieb Sebastian Huber:

...

warum sollen STL Vektoren weniger effizient als C-Felder sein? Intern arbeiten die Vektoren ja auch mit Feldern und der Indexoperator ist eine inline-Funktion. Ich denke, dass es da keine Effizienzunterschiede gibt.

Mach doch mal 10^9 Zugriffe auf ein C-Array und auf einen STL-Vektor.¹ Solange ich den Kram nicht optimiert übersetze (und damit eine nummerische Genauigkeit jenseits von gut und böse in Kauf nehme), ist mein nicht-STL Array um einiges schneller. Mit Optimierung sind beide etwa gleich schnell (gcc3.2). In Bernhards Fall ist das nicht interessant, da er ja schließlich integer in seine Struktur pflanzt. CU, Martin ¹) z.B. ganz billig mit Schleife und Zeitmessung um die Schleife herum

Sebastian Huber

20:52

On Saturday 16 November 2002 20:12, Martin Oehler wrote:

...

Hi!

Am Sam, 2002-11-16 um 18.10 schrieb Sebastian Huber:

...
warum sollen STL Vektoren weniger effizient als C-Felder sein? Intern arbeiten die Vektoren ja auch mit Feldern und der Indexoperator ist eine inline-Funktion. Ich denke, dass es da keine Effizienzunterschiede gibt.

Mach doch mal 10^9 Zugriffe auf ein C-Array und auf einen STL-Vektor.¹ Solange ich den Kram nicht optimiert übersetze (und damit eine nummerische Genauigkeit jenseits von gut und böse in Kauf nehme), ist mein nicht-STL Array um einiges schneller. Mit Optimierung sind beide etwa gleich schnell (gcc3.2).

Das ist klar, da ohne Optimierung keine Funktion (also auch der Indexoperator) inline generiert wird. Warum bekommst du ohne Optimierung numerische Ungenauigkeiten?

...

In Bernhards Fall ist das nicht interessant, da er ja schließlich integer in seine Struktur pflanzt.

CU, Martin

¹) z.B. ganz billig mit Schleife und Zeitmessung um die Schleife herum

Martin Oehler

17 Nov 17 Nov

08:26

Hi! Am Sam, 2002-11-16 um 21.52 schrieb Sebastian Huber:

...

Das ist klar, da ohne Optimierung keine Funktion (also auch der Indexoperator) inline generiert wird. Warum bekommst du ohne Optimierung numerische Ungenauigkeiten?

Äh, sorry, ich habe die Logik in dem Satz verhunzt. Nummerische Ungenauigkeiten kriege nur mit Optimierung. :) CU Martin

Sebastian Huber

09:50

On Sunday 17 November 2002 09:26, Martin Oehler wrote:

...

Hi!

Am Sam, 2002-11-16 um 21.52 schrieb Sebastian Huber:

...
Das ist klar, da ohne Optimierung keine Funktion (also auch der Indexoperator) inline generiert wird. Warum bekommst du ohne Optimierung numerische Ungenauigkeiten?

Äh, sorry, ich habe die Logik in dem Satz verhunzt. Nummerische Ungenauigkeiten kriege nur mit Optimierung. :)

Servus, also mir ist das immer noch nicht klar, wie numerische Ungenauigkeiten und Optimierung zusammenhaengen.

Ralf Corsepius

18 Nov 18 Nov

01:50

Am Son, 2002-11-17 um 10.50 schrieb Sebastian Huber:

...

On Sunday 17 November 2002 09:26, Martin Oehler wrote:

...
Hi!

Am Sam, 2002-11-16 um 21.52 schrieb Sebastian Huber:

...
Das ist klar, da ohne Optimierung keine Funktion (also auch der Indexoperator) inline generiert wird. Warum bekommst du ohne Optimierung numerische Ungenauigkeiten?

Äh, sorry, ich habe die Logik in dem Satz verhunzt. Nummerische Ungenauigkeiten kriege nur mit Optimierung. :)

Servus, also mir ist das immer noch nicht klar, wie numerische Ungenauigkeiten und Optimierung zusammenhaengen. Garnicht.

Ralf

Martin Oehler

11:38

Hi! Am Mon, 2002-11-18 um 02.50 schrieb Ralf Corsepius:

...

Am Son, 2002-11-17 um 10.50 schrieb Sebastian Huber:

...
also mir ist das immer noch nicht klar, wie numerische Ungenauigkeiten und Optimierung zusammenhaengen.

Garnicht.

Na ja. http://gcc.gnu.org/fom_serv/cache/49.html #include <iostream> int main() { double min = 0.0; double max = 0.5; double width = 0.01; std::cout << static_cast<int>(((max - min) / width) - 1) << std::endl; return 0; } ~> g++ -o testprog test.cc ~> ./testprog 48 ~> g++ -O -o testprog test.cc ~> ./testprog 49 ~> g++ -ffloat-store -O -o testprog test.cc ~> ./testprog 48 Strange... CU, Martin

Sebastian Huber

17:59

New subject: Genauigkeit und Optimierung (Mehrdimensionale dynamische Arrays in C++)

On Monday 18 November 2002 12:38, Martin Oehler wrote:

...

Hi!

Am Mon, 2002-11-18 um 02.50 schrieb Ralf Corsepius:

...
Am Son, 2002-11-17 um 10.50 schrieb Sebastian Huber:

...
also mir ist das immer noch nicht klar, wie numerische Ungenauigkeiten und Optimierung zusammenhaengen.

Garnicht.

Na ja. http://gcc.gnu.org/fom_serv/cache/49.html

#include <iostream>

int main() { double min = 0.0; double max = 0.5; double width = 0.01; std::cout << static_cast<int>(((max - min) / width) - 1) << std::endl; return 0; }

~> g++ -o testprog test.cc ~> ./testprog 48

~> g++ -O -o testprog test.cc ~> ./testprog 49

~> g++ -ffloat-store -O -o testprog test.cc ~> ./testprog 48

Strange...

Hallo, das ist alles andere als Strange. Das ist (unter umstaenden) ein Programmierfehler. Ein Cast ist zwar auch eine Rundung, jedoch nicht immer die gewuenschte. Das sollte immer das gleiche Resulat bringen: rint((max - min) / width) - 1 Ciao

Michael Matz

19:03

New subject: Genauigkeit und Optimierung (Mehrdimensionale dynamische Arrays in C++)

Hi, On Mon, 18 Nov 2002, Sebastian Huber wrote:

...

das ist alles andere als Strange.

Leider, ja.

...

Das ist (unter umstaenden) ein Programmierfehler.

Jein.

...

Ein Cast ist zwar auch eine Rundung, jedoch nicht immer die gewuenschte. Das sollte immer das gleiche Resulat bringen: rint((max - min) / width) - 1

Nein. Es hat genau die gleichen Probleme wie ein direkter (int) cast. Aber abhaengig vom rounding mode sind es jeweils verschiedene Werte die "falsch" gerundet werden. "x.5 +- EPS" oder eben "x +- EPS" (x ne ganze Zahl und alles in Dezimalschreibweise). In _diesem_ Fall wuerde rint tatsache helfen, aber nicht generell (ich gebe zu, das rint() dann besser ist, wenn man ehh schon "fast" Ganzzahlen erwartet, wie eben hier, um solche non-IEEE Rundungen zu minimieren). Das auf x87 nicht mal "-mieee-fp -ffloat-store" helfen, um 49 auszugeben ist allerdings aergerlich, und koennte man als Bug bezeichnen (der naemlich ist, das das divisionsergebnis direkt weiterverwendet (gerundet) wird, anstatt es vorher auf den Stack zu schreiben und neu zu laden). D.h. uebrigens auch, das hierbei das _optimierte_ Programm korrektes IEEE implementiert, die nicht optimierte Variante aber nicht. Dies ist natuerlich nicht generalisierbar, und im allgemeinen hat man mit x87 Hardware verloren, wenn man Performance, und strikte IEEE Konformitaet haben muss (letzteres ist allerdings nur relativ selten wirklich erforderlich, und Leute die es nicht genau wissen, brauchen es ueblicherweise nicht). Der beste Weg da raus, ist ne moderne x86 Implementierung, die SSE 2 unterstuetzt. Da hat man dann endlich IEEE Konformitaet. Ciao, Micha.

Sebastian Huber

19:59

New subject: Genauigkeit und Optimierung (Mehrdimensionale dynamische Arrays in C++)

On Monday 18 November 2002 20:03, you wrote:

...

Hi,

On Mon, 18 Nov 2002, Sebastian Huber wrote:

...
das ist alles andere als Strange.

Leider, ja.

...
Das ist (unter umstaenden) ein Programmierfehler.

Jein.

...
Ein Cast ist zwar auch eine Rundung, jedoch nicht immer die gewuenschte. Das sollte immer das gleiche Resulat bringen: rint((max - min) / width) - 1

Nein. Es hat genau die gleichen Probleme wie ein direkter (int) cast.

Soweit ich weiss, fuehrt ein Cast von Gleitkomma zu Ganzzahl dazu, dass der Kommaanteil wegfaellt 4.2 -> 4 und -3.4 -> -3. Bei Werten, die fast eine Ganzzahl sind, ist ein rint, wie du ja auch sagst, auf jeden Fall zu empfehlen.

...

Aber abhaengig vom rounding mode sind es jeweils verschiedene Werte die "falsch" gerundet werden. "x.5 +- EPS" oder eben "x +- EPS" (x ne ganze Zahl und alles in Dezimalschreibweise).

Tja das laesst sich halt nicht vermeiden, irgendwo ist eine Grenze. Wenn man mit Gleitkommakonstanten arbeitet, muss man daran denken (oder auch nicht, je nach Qualitaetsanspruch).

...

In _diesem_ Fall wuerde rint tatsache helfen, aber nicht generell (ich gebe zu, das rint() dann besser ist, wenn man ehh schon "fast" Ganzzahlen erwartet, wie eben hier, um solche non-IEEE Rundungen zu minimieren). Das auf x87 nicht mal "-mieee-fp -ffloat-store" helfen, um 49 auszugeben ist allerdings aergerlich, und koennte man als Bug bezeichnen (der naemlich ist, das das divisionsergebnis direkt weiterverwendet (gerundet) wird, anstatt es vorher auf den Stack zu schreiben und neu zu laden). D.h. uebrigens auch, das hierbei das _optimierte_ Programm korrektes IEEE implementiert, die nicht optimierte Variante aber nicht. Dies ist natuerlich nicht generalisierbar, und im allgemeinen hat man mit x87 Hardware verloren, wenn man Performance, und strikte IEEE Konformitaet haben muss (letzteres ist allerdings nur relativ selten wirklich erforderlich, und Leute die es nicht genau wissen, brauchen es ueblicherweise nicht).

Der beste Weg da raus, ist ne moderne x86 Implementierung, die SSE 2 unterstuetzt. Da hat man dann endlich IEEE Konformitaet.

Ciao, Micha.

Martin Oehler

19 Nov 19 Nov

06:20

New subject: Genauigkeit und Optimierung (Mehrdimensionale dynamische Arrays in C++)

Hi! Am Mon, 2002-11-18 um 20.03 schrieb Michael Matz:

...

Dies ist natuerlich nicht generalisierbar, und im allgemeinen hat man mit x87 Hardware verloren,

Auf einer sparc habe ich keine Probleme, d.h. ich kriege mit/ohne Optimierung stabil die 49. Dafür ist die Kiste sehr lahm, man kann eben nicht alles haben... :) CU Martin

Philipp Thomas

00:04

Martin Oehler [17 Nov 2002 09:26:01 +0100]:

...

Äh, sorry, ich habe die Logik in dem Satz verhunzt. Nummerische Ungenauigkeiten kriege nur mit Optimierung. :) ^ich :)

Dann solltest du dich evtl. mal mit der Option -ffloat-store befassen. ia32 arbeitet bei Fliesskommazahlen nun einmal intern mit (AFAIR) 80 Bits, während im Speicher nur 64 gehalten werden. Wann immer also der Compiler meint, einen Wert im Hauptspeicher zwischenlagern zu müssen (Registerüberlauf = spilling), verliert dieser an Genauigkeit. Mit -ffloat-store werden Fliesskommawerte grundsätzlich nur im Hauptspeicher gehalten, was zu einheitlicher Genauigkeit führt, aber auch deutlich Performance kostet. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de

Martin Oehler

05:52

Hi, Philipp! Am Die, 2002-11-19 um 01.04 schrieb Philipp Thomas:

...

Martin Oehler [17 Nov 2002 09:26:01 +0100]:

...
Äh, sorry, ich habe die Logik in dem Satz verhunzt. Nummerische Ungenauigkeiten kriege nur mit Optimierung. :) ^ich :)

Oh je, ich sollte mal wieder die Kaffee-Marke wechseln...

...

Dann solltest du dich evtl. mal mit der Option -ffloat-store befassen.

Eigentlich hatte ich das getan (siehe meine mail mit dem kleinen Programmbeispiel, 3.Compilierung).

...

Mit -ffloat-store werden Fliesskommawerte grundsätzlich nur im Hauptspeicher gehalten, was zu einheitlicher Genauigkeit führt, aber auch deutlich Performance kostet.

Ja. Ich denke das ganze Problem ist gar nicht so furchtbar wild, sofern man das Rundungs-Verhalten seines Compilers kennt. Was bezüglich der Fehlerfortpflanzung gute und schlechte Operationen sind, ist ja bekannt. Ist der von Michael erwähnte SSE2-Standard im gcc sauber implementiert (seine Anmerkung diesbezüglich klang nicht so)? Leider habe ich keinen Pentium 4, um das zu testen. Es gibt ja auch noch den Intel-Compiler für Linux. Würde mich mal interessieren, ob der das gleiche Verhalten zeigt. Könnte man die non-commercial version nicht mit auf die distri packen? CU Martin

Michael Matz

10:56

Hi, On 19 Nov 2002, Martin Oehler wrote:

...

Ist der von Michael erwähnte SSE2-Standard im gcc sauber implementiert (seine Anmerkung diesbezüglich klang nicht so)?

Ja. Der SuSE gcc 3.2 hat alles notwendige.

...

Es gibt ja auch noch den Intel-Compiler für Linux. Würde mich mal interessieren, ob der das gleiche Verhalten zeigt.

Yep. Ohne Optimierung (und ohne Optionen fuer SSE2) wird das gleiche non-IEEE Ergebnis erzeugt.

...

Könnte man die non-commercial version nicht mit auf die distri packen?

Nein. Lizenzprobleme. Ciao, Micha.

Bernhard Walle

16:02

On Tue, 19 Nov 2002 at 11:56 (+0100), Michael Matz wrote:

...

On 19 Nov 2002, Martin Oehler wrote:

...
Könnte man die non-commercial version nicht mit auf die distri packen?

Nein. Lizenzprobleme.

Eigentlich schade. Was mich mal interessieren würde: Merkt man einen deutlichen Geschwindigkeitsunterschied? Ich meine jetzt keine Programme, die eh zu 99 % der Zeit auf Benutzereingaben warten, sondern sowas wie mathematische Berechnungen etc. Und wie gut unterstützen die Intel-Compiler ANSI C/C++? Gruß, Bernhard -- Ich habe überhaupt keine Hoffnung mehr in die Zukunft unseres Landes, wenn einmal unsere Jugend die Männer von morgen stellt. Unsere Jugend ist unerträglich, unverantwortlich und entsetzlich anzusehen. -- Aristoteles (384 - 322 v. Chr.)

Michael Matz

17:10

Hi, On Tue, 19 Nov 2002, Bernhard Walle wrote:

...

...
Nein. Lizenzprobleme.

Eigentlich schade. Was mich mal interessieren würde: Merkt man einen deutlichen Geschwindigkeitsunterschied? Ich meine jetzt keine Programme, die eh zu 99 % der Zeit auf Benutzereingaben warten, sondern sowas wie mathematische Berechnungen etc.

Kommt drauf an ;-) Wenn der Benchmark von Autoparallelisierung profitiert, dann kann ICC nochmal Performance rausholen. Von whole-program analysis auch (beides kann GCC nicht). Allerdings ist es wirklich von Fall zu Fall verschieden. Es gibt auch Benchmarks, die mit GCC besser abschneiden (besonders auf nicht-Intel Hardware).

...

Und wie gut unterstützen die Intel-Compiler ANSI C/C++?

Komplett. ICC benutzt das EDG Frontend, was so ziemlich das beste ist, was es auf dem Markt gibt. Ciao, Micha.

Manfred Tremmel

18:35

Am Dienstag, 19. November 2002 18:10 schrieb Michael Matz:

...

Es gibt auch Benchmarks, die mit GCC besser abschneiden (besonders auf nicht-Intel Hardware).

Dem kann ich nur zustimmen, auf meinem Powerbook laufen mit gcc compilierte Programme deutlich besser als die mit dem Intel-Compiler ;-) -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de

Christoph Maurer

18:40

Am Die, 19 Nov 2002 schrieb Manfred Tremmel:

...

Am Dienstag, 19. November 2002 18:10 schrieb Michael Matz:

...
Es gibt auch Benchmarks, die mit GCC besser abschneiden (besonders auf nicht-Intel Hardware).

Dem kann ich nur zustimmen, auf meinem Powerbook laufen mit gcc compilierte Programme deutlich besser als die mit dem Intel-Compiler ;-)

Das ist aber doch auch nicht anders zu erwarten, der Intel-Compiler nutzt halt prozessorspezifische Optimierungen, während der gcc für die Breite und zig verschiedene Architekturen gedacht ist. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

Bernhard Walle

19:15

On Tue, 19 Nov 2002 at 19:40 (+0100), Christoph Maurer wrote:

...

Am Die, 19 Nov 2002 schrieb Manfred Tremmel:

...
Am Dienstag, 19. November 2002 18:10 schrieb Michael Matz:

...
Es gibt auch Benchmarks, die mit GCC besser abschneiden (besonders auf nicht-Intel Hardware).

Dem kann ich nur zustimmen, auf meinem Powerbook laufen mit gcc compilierte Programme deutlich besser als die mit dem Intel-Compiler ;-)

Das ist aber doch auch nicht anders zu erwarten, der Intel-Compiler nutzt halt prozessorspezifische Optimierungen, während der gcc für die Breite und zig verschiedene Architekturen gedacht ist.

Ich denke mal, dass es den icc gar nicht für PPCs gibt ... Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ "Ignorance is inexcusable." -- Waldo Bastian

Manfred Tremmel

19:33

Am Dienstag, 19. November 2002 20:15 schrieb Bernhard Walle:

...

Ich denke mal, dass es den icc gar nicht für PPCs gibt ...

Richtig, daher der Smily :-) Die einzige Möglichkeit IA32 Code zum laufen zu kriegen ist ne Emulation und die kostet viel mehr Zeit, als der beste Compiler reinholen könnte. PS: Hoffe SuSE 8.1 kommt bald für PPC raus, der gcc 2.95.x erzeugt immer wieder fehlerhaften PPC-Code aus C++ Sourcen. Hat SuSE ja auch gemerkt, OpenOffice.org für PPC wurde mit gcc 3.11 compiliert. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de

Michael Matz

20:24

Hi, On Tue, 19 Nov 2002, Manfred Tremmel wrote:

...

...
Ich denke mal, dass es den icc gar nicht für PPCs gibt ...

Richtig, daher der Smily :-) Die einzige Möglichkeit IA32 Code zum laufen zu kriegen ist ne Emulation und die kostet viel mehr Zeit, als der beste Compiler reinholen könnte.

Nur fuer die, die es vor lauter bruellender Lustigkeit nicht mitbekommen haben: Ich meinte natuerlich nicht-Intel, aber Intel-kompatible Prozessoren, sprich AMD. Ciao, Micha.

David Haller

20 Nov 20 Nov

03:34

Hallo, On Tue, 19 Nov 2002, Michael Matz wrote:

...

Nur fuer die, die es vor lauter bruellender Lustigkeit nicht mitbekommen haben: Ich meinte natuerlich nicht-Intel, aber Intel-kompatible Prozessoren, sprich AMD.

Loeppt. Im Vergleich zum gcc2.95.2 den ich hier (gepatcht) verwende bringt der IIRC ca. 5% mehr Performance auf meinem K7 [1]. Deutlich mehr bringt, wenn man die Architektur ausnuetzt, z.B. das Paralleisieren von Ops in Schleifen (siehe suse-linux)... Der gcc 3.2/binutils (v?) unterstuetzt den Athlon aber evlt. besser... (kann der 3dnow?) -dnh [1] /proc/cpuinfo vendor_id : AuthenticAMD cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping : 2 cpu MHz : 499.040 cache size : 512 KB [..] fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx syscall mmxext 3dnowext 3dnow -- SIG kill(ed)

Michael Matz

15:22

Hi, On Wed, 20 Nov 2002, David Haller wrote:

...

...
Nur fuer die, die es vor lauter bruellender Lustigkeit nicht mitbekommen haben: Ich meinte natuerlich nicht-Intel, aber Intel-kompatible Prozessoren, sprich AMD.

Loeppt. Im Vergleich zum gcc2.95.2

Oehh. Die 2.95'er Reihe ist jetzt, hmm *nachschau* 3.5 Jahre alt. Das der aktuelle ICC da vielleicht was rausholt erwarte ich fast. Ich habe von GCC 3.2 bzw. einigen anderen GCC branches gesprochen. Und es sind eben auch nicht alle benchmarks.

...

Der gcc 3.2/binutils (v?) unterstuetzt den Athlon aber evlt. besser... (kann der 3dnow?)

gcc? Ja. Er kann auch SSE und SSE2. Ciao, Micha.

Michael Schulz

19 Nov 19 Nov

16:34

Martin Oehler wrote at 19.11.2002 um 06:52:30 +0100: Hallo Martin,

...

Hi, Philipp! Am Die, 2002-11-19 um 01.04 schrieb Philipp Thomas:

...
Martin Oehler [17 Nov 2002 09:26:01 +0100]:

...
Äh, sorry, ich habe die Logik in dem Satz verhunzt. Nummerische Ungenauigkeiten kriege nur mit Optimierung. :) ^ich :)

Oh je, ich sollte mal wieder die Kaffee-Marke wechseln...

...
Dann solltest du dich evtl. mal mit der Option -ffloat-store befassen.

Eigentlich hatte ich das getan (siehe meine mail mit dem kleinen Programmbeispiel, 3.Compilierung).

...
Mit -ffloat-store werden Fliesskommawerte grundsätzlich nur im Hauptspeicher gehalten, was zu einheitlicher Genauigkeit führt, aber auch deutlich Performance kostet.

Ja. Ich denke das ganze Problem ist gar nicht so furchtbar wild, sofern man das Rundungs-Verhalten seines Compilers kennt. Was bezüglich der Fehlerfortpflanzung gute und schlechte Operationen sind, ist ja bekannt.

Ist der von Michael erwähnte SSE2-Standard im gcc sauber implementiert (seine Anmerkung diesbezüglich klang nicht so)? Leider habe ich keinen Pentium 4, um das zu testen.

Es gibt ja auch noch den Intel-Compiler für Linux. Würde mich mal interessieren, ob der das gleiche Verhalten zeigt. Könnte man die non-commercial version nicht mit auf die distri packen?

Pentium II/Xeon michael@gonzo:~> icc -o genau genau.cc genau.cc: michael@gonzo:~> ./genau 49 michael@gonzo:~> icc -O -o genau genau.cc genau.cc: michael@gonzo:~> ./genau 49 michael@gonzo:~> icc -O3 -tpp6 -xiM -o genau genau.cc genau.cc: michael@gonzo:~> ./genau 49 auf einem Xeon: michael@bert:~> icc -o genau genau.cc genau.cc michael@bert:~> ./genau 49 michael@bert:~> icc -O -o genau genau.cc genau.cc michael@bert:~> ./genau 49 michael@bert:~> icc -O3 -tpp7 -xW -o genau genau.cc genau.cc michael@bert:~> ./genau 49 Bis denne, Michael -- ---------------------------------------------------------- Michael Schulz, Institut f. Geophysik, Universität Münster Corrensstr. 24, 48149 Münster Tel.: 0251-8333938, e-mail: michael@earth.uni-muenster.de

Michael Matz

17:06

Hi, On Tue, 19 Nov 2002, Michael Schulz wrote:

...

Pentium II/Xeon

michael@gonzo:~> icc -o genau genau.cc genau.cc: michael@gonzo:~> ./genau 49

Alle deine Tests haben Optimierungen eingeschaltet, da ICC diese per default verwendet. Du brauchst -O0 um sie auszuschalten, und dann gibt's auch die "falsche" 48. Sobald Optimierungen an sind, sind alle Codeerzeugungsoptionen ueberfluessig, da die 49 schon zur Compilezeit ausgerechnet, und damit hardgecoded wird. D.h. SSE(2) Optmierungen oder was auch immer drehen daran nix mehr. Ciao, Micha.

7834

Age (days ago)

7838

Last active (days ago)

List overview

Download

27 comments

10 participants

participants (10)

Bernhard Walle
Christoph Maurer
David Haller
Manfred Tremmel
Martin Oehler
Michael Matz
Michael Schulz
Philipp Thomas
Ralf Corsepius
Sebastian Huber