qtforum.de

Hallo,

ich finde in den Qt-Dokumentation zwar Hinweise auf andere Comiler als den gcc, aber 2 Fragen bleiben mir noch.
(vgl. http://doc.trolltech.com/4.7/platform-notes.html )

Kann mir vielleicht jemand helfen?
1. Was ist in der Dokumentation gemeint. Das Compilieren von Qt selbst oder das compilieren eines Programmes, welches Qt benutzt?
2. Was ist mit open64? Hat jemand erfahrung damit gemacht? Kann ich damit eigene Qt-Programme übersetzen?
(vgl. http://www.open64.net/
und http://developer.amd.com/cpu/open64/pages/default.aspx# )

Ich freue mich auf Antworten

Gruß,
Volker

Es werden nur die Compiler unterstützt die dort aufgelistet sind. Wenn es mit anderen geht - Glück gehabt.
Und zu Dokumentation - finde auf der Seite nichts bzgl. Dokumentation. Und was hat Dokumentation mit Kompilieren zu tun?

Das Compilieren von Qt selbst oder das compilieren eines Programmes, welches Qt benutzt?

Da die qt-dlls per importlib gelinkt werden (windows) und sowieso ein C++ Interface haben (Binaer nicht definiert), musst du die qt libs/dlls und dein Programm immer mit dem selben compiler uebersetzen, sonst funktioniert es nicht.
Unter linux sowieso standard (system-compiler !) unter windows halt etwas umständlich und dem Konzept der Dlls entgegenwirkend.

Ob open64 und Qt miteinander harmonieren, wirst wohl selber rausfinden muessen.
Normal nimmt man dann eh ne Source-Distri von Linux, und uebersetzt so viel wie möglich selber.
wie hier zu lesen:
http://forums.gentoo.org/viewtopic-t-84 ... art-0.html
ist open64 nicht ganz kompatibel zu einer vom gcc übersetzten glibc(c-interface!) wodurch das ganze in ne menge arbeit ausartet ... , also die Vorarbeit schon, bis ueberhaupt zu kommst die qt zu kompilieren mit open64.

Bleibt die Frage, wozu ?
Exotische HW ?

Ciao ...

Danke für die Antwort.

Wozu?
Ich programmiere an Algorithmen, die selbst auf aktueller Hardware recht viel Zeit beanspruchen.
Natürlich habe ich erstmal versuch den Algorithmus bestmöglich zu optimieren.
Natürlich habe ich als zweiten Schritt versucht Multicore-Programmiertechniken zu benutzen.
Aber der Algorithmus benötigt immer noch recht viel Zeit.

Da ich zufällig dies gelesen habe:
http://www.phoronix.com/scan.php?page=a ... atch&num=1

wollte ich mal testen, ob andere Compiler den (aus meiner derzeitigen Sicht nicht weiter optimierbaren) Algorithmus so zu kompileren, dass er schneller läuft.
Das ich selbst mit Assembler den Algorithmus optimiere ist für mich keine option. Es muss eine plattforumunabhängige Hochsprache sein/bleiben.

naja, bevor dir das mit cem Compiler antust, wuerd ich erst mal andere Bedingungen checken ...

- welche Hardware kommt zum einsatz ? Kommst Du nahe an die HW ran, bei der der Open64 da so gut abschliesst.

- schon mit den Compilereinstellungen rumgespielt ?

- welche Multithreading Bibo('s) werden genutzt ?

- Am code gibts meisten auch immer noch kleinigkeiten ...

- Assembler find ich gar ned mal so schlecht ... mit Beachtung der 90/10 Regel wirds nicht sooo viel sein ... ich wuerds sicher ueberlegen ... wenn notwendig

Ciao ...

Danke für die Antwort.

RHBaum hat geschrieben:- welche Hardware kommt zum einsatz ? Kommst Du nahe an die HW ran, bei der der Open64 da so gut abschliesst.

Hardware ist unterschiedlich, da sie Software von vielen verschiedenen Menschen mit unterschieldichen finanziellen Möglichkeiten genutzt wird. Von "ich bin froh, dass ich überhaupt einen Computer besitze" bis zu "Ich kaufe mir jedes Jahr einen neuen Rechner."
Daher laufen meine Test auch immer unter verschiedenen Betriebssystemen (im Moment Linux und Windows) und verschiedener Hardware (AMD und Intel CPUs. Vom 10 Jahre alten Single-Core mobilen CPU bis zur relativ neuen Desktop Multicore CPU.)

RHBaum hat geschrieben:- schon mit den Compilereinstellungen rumgespielt ?

Ja.

RHBaum hat geschrieben:- welche Multithreading Bibo('s) werden genutzt ?

QtConcurrent und OpenMP.

RHBaum hat geschrieben:- Am code gibts meisten auch immer noch kleinigkeiten ...

Nach 5 Jahren Arbeit an dem Code gehen mir da so langsam die ideen aus. Ich könnte rein theoretisch die assert-prüfungen ausschalten, was ich aber bewußt nicht machen möchte, da mir stabilität wichtiger ist als 1% schnelleres rechnen.

RHBaum hat geschrieben:- Assembler find ich gar ned mal so schlecht ... mit Beachtung der 90/10 Regel wirds nicht sooo viel sein ... ich wuerds sicher ueberlegen ... wenn notwendig

Muss ich aus mehrern Gründen ausschließen.


Ich werde mir aber mal gleich das neue Ubuntu ziehen und es schlicht mal ausprobieren.

verschiedener Hardware (AMD und Intel CPUs. Vom 10 Jahre alten Single-Core mobilen CPU bis zur relativ neuen Desktop Multicore CPU.)

Dann vergiss die Compilerfrage ...
Über den compiler disskutiert man, wenn die Plattform definiert ist. Oder wenn man ne bestimmte Plattform pushen will
Was nuetzt es dir, wenn nen compiler verwendest der auf super auf AMD prozessoren skaliert, du aber wegen kompatiblitaet die meisten performance features abschalten musst ?
Oder willst du dir das antun und zig packete bereitstellen für die unterschiedlichen Prozessorfamilien ... ? Ich denk mal das auf aktuellen Intel PCS der ICC mit entsprechenden schaltern immer ganz gut abschneiden wird, aber auf AMD rechnern froh sein musst, wenns überhaupt laeuft ^^

QtConcurrent und OpenMP.

Ich hoffe OpenMP fuer die Algos, und Qt nur fuer die Oberflächen ^^ Qt ist fuer low level zeugs, also algos und so, die Hölle ^^ Implizietes Sharing (nur noch ein kleiner Schrit zu Garbage Collection) + Multithraeding + Performance vertragen sich ned so ... wenn Algos in qt implementierst, kannst, krass ausgedrueckt, den algo auch gleich in Java schreiben ...

-Assembler Muss ich aus mehrern Gründen ausschließen.

Durch die obige Hardware Bedingung, würd ichs eh auch ausschliessen. Oder Du kommst wieder zu der nummer, das zig packete fuer zig prozessorfamilien anbietest.

Vielleicht isses auch mit "normalen" mitteln gar nicht mehr signifikant zu optimieren. Einige Dinge brauchen halt Ihre Zeit.

Aber vielleicht kannst in ne Andere Richtung denken. -> caching. Sind die Parameter fuer deinen algo immer anderes ? wenn nicht, kannst du den Algo vielleicht verhindern, in dem die ergebnisse chachst ...

die "Sinus" Tabellen waren mal nen beispiel fuer ... weil nen sinus ausrechnen auf bestimmter HW laenger gedauert hat als wie nen file-lookup.

Ich muss hier in nem aktuellen Projekt auch immer oft ein und die selben XML files einlesen, im 3stelligen Megabyte bereich. Das parsen und bearbeiten dauert nun mal "minuten". Die xml files müssen als eingabe bleiben (die sind abgesichert, würd ich da nen anderes vorbearbietetes eigenes fileformat etablieren, würd ich mir prozesstechnisch die Krätze an den Hals holen ...) also cache ich die fuer den User "unsichtbar". beim ersten mal dauerts halt minuten, danach unter 1 sek

Ciao ...