Auf welche (kleine) Weise kann ich die Kompilierungsoptionen von Octave ändern, um sie zu verbessern, ohne sie zu beschädigen?

764
irrational John

Wenn der Titel dieser Frage etwas vage erscheint, tut es mir leid. Aber ich war mir nicht sicher, wie ich das, was ich versuche, zu einem einzigen Satz zusammenfassen sollte.

Vor ein paar Wochen habe ich erfahren, dass ich die neuesten Versionen von Octave auf einem Ubuntu 12.04-System erstellen und installieren kann, indem Sie die folgenden Schritte ausführen.

  1. Installieren Sie die zum Kompilieren, Verknüpfen und Ausführen von Octave erforderlichen Tools. Für Ubuntu haben die folgenden Befehle für mich funktioniert. 

    sudo apt-get build-dep octave3.2 sudo apt-get install build-essential gnuplot gtk2-engines-pixbuf sudo apt-get install libfontconfig-dev bison

  2. Laden Sie als Nächstes den Quellcode für eine Octave-Version aus dem Gnu-Projektarchiv für Octave herunter und entpacken Sie das Archiv in einen Ordner auf Ihrem System.

  3. Verwenden Sie die folgenden Befehle, um Octave zu erstellen, zu prüfen und zu installieren. 

     ./configure make make check sudo make install

Leider stellt sich heraus, dass das obige eine Octave erstellt, die alle Debugging-Symboltabellen enthält. Allein die Objektdateien sind mit rund 1,7 GB sehr groß.

Die aktuelle Octave-Dokumentation schlägt vor

Um zu kompilieren, ohne Symbole zu debuggen, versuchen Sie den Befehl
make CFLAGS=-O CXXFLAGS=-O LDFLAGS=
anstelle von nur make .

Als ich das ausprobierte, funktionierte es jedoch nicht . Die -gOption wurde weiterhin für die Kompilierungen verwendet. Ich habe es ausprobiert ./configure CFLAGS=-O CXXFLAGS=-Ound das hat funktioniert. (Statt ~ 1,7 GB benötigt das Build jetzt etwa 253 MB).

Meine Fragen sind

  1. Ist dies tatsächlich die richtige (empfohlene) Methode, um Octave zu kompilieren, ohne Symbole zu debuggen (dh ohne -g)?
  2. Wie würde ich Octave so kompilieren, dass es x86_64 anstelle von x86 verwendet?
    Hinweis: Ich frage nicht, wie Sie Octave kompilieren, um die (experimentellen) 64-Bit-Ganzzahlen für Array-Dimensionen zu verwenden. Ich möchte nur zulassen, dass der Compiler die zusätzlichen Register und Wortgrößen verwendet, die verfügbar sind, wenn eine App im 64-Bit-Modus ausgeführt wird.
  3. Ist eine (vollständigere) Liste für die mit dem Octave-Makefile verwendeten Direktiven verfügbar?
    Ich habe nur gesehen make, make checkund make installdokumentiert. Aber anscheinend make distcleanist auch erlaubt. (Dadurch werden die Kompilierungsergebnisse entfernt, sodass Sie alles komplett neu
    erstellen können .) Ich frage mich, was noch verfügbar ist.

FWIW, ich habe es ausprobiert
./configure CFLAGS="-O3 -mtune=core2 -m64" CXXFLAGS="-O3 -mtune=core2 -m64"
und überraschenderweise schien es nicht nur zu bauen, sondern lief auch und hat die make checkTests bestanden.

Aber das ist natürlich nicht das Gleiche, wenn man sagt, dass es tatsächlich " funktioniert ". Gibt es eine empfohlene Möglichkeit, Octave als x86_64-App auszuführen?

Ich habe auch versucht, in die Oktave Makefilezu schauen, um herauszufinden, welche Befehlszeilenanweisungen er akzeptiert. Ich bin nirgendwohin gekommen. Ich habe keinen einzigen Hinweis darauf, wie dieses Makefile alles tut, was es tut.

2

1 Antwort auf die Frage

1
Charity Leschinski

Es hängt von Ihrer Version von gcc, Ihrer Hardware, Ihrer Distribution und vielen anderen Dingen ab. Normalerweise hätte Ihr Linux-Distributionsanbieter diese Suche für Sie durchgeführt und diese Optionen beim Erstellen Ihres Pakets verwendet. Distributionen versuchen jedoch, die meisten Hardware- und Benutzererwartungen zum Laufen zu bringen. Ich finde die meisten Anpassungen, ohne mit Gentoo zu viel Ärger machen zu müssen . Linux von Grund auf oder das Rollen Ihrer eigenen Distribution ist eine Menge Arbeit. Ich habe eine Gentoo-Installation mit 32-Bit-Emulation im Kernel deaktiviert.

Im Gentoo Optimization Guide ist es am besten, -O2statt zu verwenden-O3

-O3: Dies ist der höchstmögliche Optimierungsgrad und auch der riskanteste. Das Kompilieren Ihres Codes mit dieser Option dauert etwas länger und sollte mit gcc 4.x nicht systemweit verwendet werden. Das Verhalten von gcc hat sich seit Version 3.x erheblich verändert. In 3.x wurde gezeigt, dass -O3 zu geringfügig schnelleren Ausführungszeiten über -O2 führt, dies ist jedoch bei gcc 4.x nicht mehr der Fall. Wenn Sie alle Pakete mit -O3 kompilieren, werden größere Binärdateien benötigt, die mehr Speicher benötigen, und die Wahrscheinlichkeit eines Kompilierungsfehlers oder eines unerwarteten Programmverhaltens (einschließlich Fehlern) wird erheblich erhöht. Die Nachteile überwiegen die Vorteile; Erinnern Sie sich an das Prinzip der Verringerung der Erträge. Die Verwendung von -O3 wird für gcc 4.x nicht empfohlen.

-mtune=core2ist in Ordnung, wenn Sie sicher sind, dass dies die beste Wahl für Ihren Prozessor ist. Ich persönlich mag es -march=nativestattdessen. Siehe Gentoo Safe CF-Markierungen

GCC 4.2 führt die neue Option -march ein, -march = native, die automatisch die von Ihrer CPU unterstützten Funktionen erkennt und die Optionen entsprechend einstellt. Wenn Sie eine Intel- oder AMD-CPU haben und> = sys-devel / gcc-4.2.3 verwenden, wird die Verwendung von -march = native empfohlen.

-m64ist eine Prozessoroption und sollte durch -mtune=core2oder automatisch gesetzt werden -march=native. Siehe GCC-Optionen i386 und x86-64 .

Haftungsausschluss: Sie müssen nicht zu Gentoo wechseln, um deren Ratschläge für die Erstellung aus Quellen zu verwenden.

Verwandte Probleme