C++-Programme erstellen mit make, makefile
-
Warnung: C++-Neuling
Ich versuche momentan mich in die Double-double-Arithmetik einzuarbeiten. Insbesondere Hida, Li, Bailey haben hier Beiträge geleistet und einige Algorithmen in C++ entwickelt (siehe auch Referenzen bei Wiki).
Ich schlage mich nun schon seit etwa einer Woche mit dem Versuch herum, diese Algorithmen zwecks numerischer Tests zum laufen zu bringen. Trotz diverser Software- und Programmiererfahrung bleibt mir C++ und insbesondere auch das Verfahren, größere C++-Programmen das Laufen beizubringen ein Rätsel...
Google, Tutorials, Forenbeiträge, Dokumentationen... hab' ich alles schon durch...
Mir ist das leider alles sogar dermaßen schleierhaft, dass ich nicht einmal in der Lage bin, meine Fragestellung exakt zu formulieren.
Aber ich versuch's mal...
Ich habe mal ein einfacheres C++-Programm herausgesucht, bei deren Ausführung ich bereits scheitere.
Von dieser Seite habe ich zunächst das Paket/Programm/Quellcode (?) doubledouble.tar heruntergeladen und in ein beliebiges Verzeichnis entpackt - enthält ja nur zwei Header- und drei C++-Files. Die Installationsanweisungen sind überschaubar:0. Unpack
1. Edit top part of `Makefile' to suit your hardware and compiler
2. makeInsbesondere der zweite Schritt bereitet mir immense Kopfschmerzen, also die korrekten Einstellungen für Makefile:
# linux-x86, standard setup... CPP=g++ OPTS=-m486 -O3 INC= DEF=-DDD_INLINE -Dx86 RANLIB=ranlib
'CPP', 'OPTS' usw. interpretiere ich mal als Stringvariablen, die entsprechende Kommandozeilenparameter enthalten. Nur ist mir schleierhaft, was hier genau anzugeben ist.
Zunächst soll das ganze wenigstens auf meinem Laptop funktionieren (Ubuntu), evtl. auch auf meinem Homerechner (WinXP) und schließlich müsste das im schlimmsten Fall auch noch an der Uni in Gang gesetzt werden... Bleiben wir aber erst einmal bei Ubuntu, oder beim Problem "Was für einen Prozessor habe ich eigentlich?".
Mittels
sudo lshw -html > ~/System.html
erhalte ich bspw. die Info
id: cpu
description: CPU
product: Intel(R) Celeron(R) CPU 560 @ 2.13GHz
vendor: Intel Corp.
physical id: 4
bus info: cpu@0
version: CPU Version
slot: U2E1
size: 2130MHz
capacity: 2130MHz
width: 64 bits
clock: 133MHz
capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe syscall nx x86-64 constant_tsc up arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm lahf_lmDer man zumindest entnehmen kann, dass es sich bei meiner CPU um einen 64-Bit Prozessor handelt.
Also habe ich eine Zeile in Makefile zu
DEF=-DDD_INLINE -Dx64
geändert und hoffe mal, dass der Parameter so auch korrekt ist... Möglich wäre vielleicht auch noch
DEF=-DDD_INLINE -Dx86-64
weiß ich nicht. Die Kommandohilfe für "gcc" ist hier nicht sehr hilfreich und eine Suche im Netz brachte ebenfalls keine neuen Erkenntnisse.
Nun gilt es noch den Prozessor anzugeben:
OPTS=-m486 -O3
Da brachte mich eine Recherche auf diese Seite, was mir ebenfalls in keinster Weise weiterhilft (sicherlich einer der Pentium-CPUs oben).
Bzw. scheint der Option "-m" veraltet zu sein, und wurde durch "-mtune" ersetzt. Also hatte ich einfach mal die ZeileOPTS=-mtune=pentium -O3
eingefügt was nur zu der Fehlermeldung
Fehler: Die ausgewählte CPU unterstützt nicht den x86-64 Befehlssatz
führte wodurch ich letztendlich nur noch mehr verwirrt bin, als ich es vorher schon war... Klasse. Wahlweises einsetzen anderer Parameter ('pentium3', 'pentium4' usw.) führte ebenfalls zur gleichen Fehlermeldung.
Schließlich ist mir der Parameter -O3 ebenfalls schleierhaft. Auch hier Recherche ohne Erfolg, bis auf die Erkenntnis dass es sich hier um einen irgendwie gearteten Optimierungsprozess handeln soll.
Und zuletzt, darf natürlich nicht ausgeschlossen werden, dass evtl. weitere Parameter nötig sind, da es sich ja bei den angegebenen Beispielkonfigurationen/Templates nur um Beispiele handelt...
Tja, super toll... Wenigstens das Entpacken habe ich noch hinkriegen können...
Das erstellen (von was eigentlich?) mittels 'make' bleibt mir aber ein Rätsel, und von anderen Problemen (Verlinken irgendwelcher Libraries) ganz zu schweigen... wobei das wohl zu diesem make-Prozess dazu gehört, soweit ich es weiß.
Ja... für Hilfe wäre ich also wirklich echt dankbar. Würde ja hier nicht schreiben, wenn ich nicht mit meinem Latein absolut am Ende wäre...
-
sddsmhr schrieb:
DEF=-DDD_INLINE -Dx86-64
weiß ich nicht. Die Kommandohilfe für "gcc" ist hier nicht sehr hilfreich und eine Suche im Netz brachte ebenfalls keine neuen Erkenntnisse.
Die Option "-Dxyz" heisst im Prinzip #define xyz" und ist für die zu kompillierende Datei gültig. Das erklärt, dass -Dx86-64 falsch ist (Bindestriche sind in Makrodefinitionen nicht erlaubt).
Wenn ich den Code deiner Bibliothek überfliege, kennen die jedoch nur den Status x86 oder nicht x86. Du kannst die Definition also weglassen.
Nun gilt es noch den Prozessor anzugeben:
OPTS=-m486 -O3
-m486 optimiert auf i486. Ist aber eher unnötig. Heute macht man vielleicht -march=native, aber ich glaube kaum, dass das viel bring. -O3 heisst auch, dass optimiert wird (Stufe 3 auf einer Skala von 0 bis 3). Wie stark optimiert wird, kann dir IMHO erstmal egal sein.
Die wirkliche Frage ist allerdings, ob du wirklich doubledouble willst oder warum du nicht die GMPLib nimmst. Mit Ubuntu sollte diese einfach zu installieren sein und das kompillieren ist auch einfacher. Zudem ist sie mächtiger.
BTW: Das gehört eher ins Linux-Forum rein.
-
Dieser Thread wurde von Moderator/in volkard aus dem Forum C++ (auch C++0x, bzw. C++11) in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Danke! Das hilft mir wenigstens ein wenig. Jetzt stehe ich allerdings vor dem nächsten Problem, dass er gewisse Header-Files nicht findet... (s.u.)
makkor schrieb:
Die wirkliche Frage ist allerdings, ob du wirklich doubledouble willst oder warum du nicht die GMPLib nimmst. Mit Ubuntu sollte diese einfach zu installieren sein und das kompillieren ist auch einfacher. Zudem ist sie mächtiger.
Hm... da bin sicherlich schon einmal drüber gestolpert. Meines Wissens wird hier aber mit Arbitrary Precision beliebiger Mantissenlänge gearbeitet, welche oftmals recht rechenintensiv und daher für besonders zeitkritische Algorithmen mit vielen Berechnungen ungeignet ist...
Und Double-Double-Precision scheint hier eine ganz gute Zwischenlösung zwischen Performance und Rechengenauigkeit zu sein, aber wie gesagt, müsste ich hierzu erst ein paar Benchmark-Tests durchführen...
(werd' GMPLib aber mal testen)
makkor schrieb:
BTW: Das gehört eher ins Linux-Forum rein.
Ja, das stimmt wohl...
Oha, wurde ja schon verschoben.
Dann also weiter im Text:
Wie gesagt findet er nun gewisse Header-Files nicht.
nan.h - konnte ich bei http://www.koders.com runterladen
iostream.h - dito
bool.h - ditoNun stellt sich doch gleich einmal die Frage, ob das überhaupt die geforderten Files sind, sprich sind das standardisierte Header-Files die mir hier einfach nur noch fehlten...?
Bei 'bool.h' werde ich bspw. nebenbei noch dezent darauf hingewiesen, dass dies eine C-Headerdatei ist (super), was ich aber erst einmal ignoriert hatte - mangels Alternativen.Wie auch immer. 'make' lässt mir keine Ruhe - warum auch, bin ja Student und hab' auch sonst nix zu tun - und macht nun gleich weiter mit der Fehlermeldung:
g++ -I/usr/include/test -DDD_INLINE -c trydd.cc
In file included from doubledouble.h:116:0,
from trydd.cc:8:
/usr/include/iostream.h:475:21: schwerwiegender Fehler: _iostream: Datei oder Verzeichnis nicht gefunden
Kompilierung beendet.
make: *** [trydd.o] Fehler 1Kommt mir bekannt vor (s.o.)... Nur jetzt heißt das Kind "_iostream" (man beachte auch den Unterstrich). Google hilft? Schön wärs...
Irgendwelche Ideen...?
-
sddsmhr schrieb:
nan.h - konnte ich bei http://www.koders.com runterladen
iostream.h - dito
bool.h - ditoOje, um die Bibliothek steht es schlimmer als befürchtet. iostream.h ist veraltet. So veraltet, dass der "neue" GCC es nicht mehr kennt. <iostream.h> heisst heute nur <iostream>, entferne also die Endung und es sollte gehen. nan.h gibt es nicht, das liegt (wenn überhaupt) in cmath. math.h heisst heute übrigens cmath. bool.h ist Teil der Sprache und kann ersatzlos entfernt werden.
Bei so veraltetem Code stellt sich die Frage, wie schnell der denn sein kann. Aber ich will dir die GMP nicht aufzwingen (die ist übrigens in Assembler programmiert, hat aber eine moderne Schnittstelle in C++). Stimmt schon, deine Lib dürfte schneller sein.
-
nur mal so als Tipp würde mich nicht unbedingt mit Makefiles herumschlagen Cmake ist sogar einfacher zu bedienen und flexiber. Besonders wenn du system Abhängigkeiten hast wie unterschiedliche gcc versionen ... etc ...
http://www.linux-magazin.de/Heft-Abo/Ausgaben/2007/02/Mal-ausspannen
-
Endungen habe ich geändert aber das nen cmake bsp.
project(doubledouble) cmake_minimum_required(VERSION 2.6) set(doubleSrcs doubledouble.cpp math.cpp trydd.cc ) add_library(doubledouble STATIC ${doubleSrcs})
-
makkor schrieb:
Oje, um die Bibliothek steht es schlimmer als befürchtet. iostream.h ist veraltet. So veraltet, dass der "neue" GCC es nicht mehr kennt. <iostream.h> heisst heute nur <iostream>, entferne also die Endung und es sollte gehen. nan.h gibt es nicht, das liegt (wenn überhaupt) in cmath. math.h heisst heute übrigens cmath. bool.h ist Teil der Sprache und kann ersatzlos entfernt werden.
Ich hab' zwischenzeitlich mal Keith Briggs' Homepage durchwühlt...
Keith Briggs schrieb:
doubledouble
About 1996 I developed software under this name for quad-precision floating-point arithmetic, which has been used by many people and referred to frequently in publications. I no longer support or recommend this software. Instead, I recommend QD or SCSlib.
QD sind die Quad-Double-Algorithmen von Hida, Li, Bailey...
SCSlib enthält wohl ebenfalls solche Algorithmen...
Auf Seite 10 dieser Publikation findet man ein kleines Benchmark aus dem Jahre 2002 zwischen SCSlib, GMPlib, QD und noch einer vierten Bibliothek.
QD schneidet hier recht schlecht ab... Letztendlich will ich aber noch eigene Tests durchführen, da Laufzeiten wohl mitunter auch von der Prozessorarchitektur abhängen können.
makkor schrieb:
Bei so veraltetem Code stellt sich die Frage, wie schnell der denn sein kann. Aber ich will dir die GMP nicht aufzwingen (die ist übrigens in Assembler programmiert, hat aber eine moderne Schnittstelle in C++). Stimmt schon, deine Lib dürfte schneller sein.
Wäre Assembler nicht ein Argument pro Geschwindigkeit, weil maschinennaher Code?
Das Paket oben wollte ich aber eh lediglich für ein paar Einstiegstests nutzen... Eigentlich wollte ich auf die QD-Algorithmen hinaus. Aber an und für sich würde ich natürlich ungern andere Alternativen unberücksichtigt lassen.
Neben GMP bin ich aber wie gesagt auch noch auf SCS und auf MPFR gestoßen... Da muss ich mir jetzt selbst erst einmal einen Überblick verschaffen.Tuxi schrieb:
nur mal so als Tipp würde mich nicht unbedingt mit Makefiles herumschlagen Cmake ist sogar einfacher zu bedienen und flexiber. Besonders wenn du system Abhängigkeiten hast wie unterschiedliche gcc versionen ... etc ...
http://www.linux-magazin.de/Heft-Abo/Ausgaben/2007/02/Mal-ausspannen
Uff... die Bedienung lernt man hier aber ebenfalls nicht gerade mal eben in 10 Minuten...
Hatte mich mittlerweile noch einmal durch eure Antworten motiviert an dem ursprünglichen QD-Paket zu schaffen gemacht. Dort wird Makefile hübsch automatisch durch ./configure erzeugt - so wie es sich gehört.
Allerdings gab' es dort noch einen kleinen Bug, da nun make stets automake-1.10 ausführen wollte, während aber nur automake-1.11 installiert war...
Außerdem hatte ich laut Konsole irgendwann einmalgcc -o runme qd_test.cpp
eingetippt, während aber
g++ -o runme qd_test.cpp -lqd
richtig gewesen wäre...
Demos, Beispiele funktionieren jetzt, und ich kann mich den wirklich wichtigen Aufgaben widmen: Tutorials, Coden, Testen. :xmas1:
Antworten waren (teilweise indirekt) sehr hilfreich, danke nochmal.