Probleme mit Intel C++ Compiler



  • Hallo Zusammen.

    Um verschiedene Compiler zu testen habe ich mir u.A. den Compiler von Intel besorgt. Damit erziele ich auch sehr gute Ergebnisse, nur habe ich ein Problem:

    Das ganze funktioniert anscheinend nur einen Tag lang. Also gestern habe ich mir eine Studentenlizenz besorgt und mit den Tests angefangen. Ich habe mit dem Intel Compiler ein Projekt in eine .dll übersetzt und konnte diese auch ohne Probleme ins Hauptprogramm einbinden.

    Gerade wollte ich das Programm noch mal starten und weiter daran arbeiten. Leider funktioniert nichts. Die .dll wird nicht gefunden obwohl nichts anders als gestern ist. Benutze ich den MS-Compiler geht auch alles wieder wunderbar.

    Zum Projekt:
    Das Hauptprogram ist in C#.NET (VS 2013) geschrieben.
    Dieses ruft eine .dll auf, welche ziemlich langwierige Berechnungen durchführt.
    Die .dll ist in C++ geschrieben.

    Kennt jemand vielleicht solche Probleme, oder hat es vielleicht was mit der Lizenz zu tun?

    Grüße
    Marcel Benders



  • Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (alle ISO-Standards) in das Forum Compiler- und IDE-Forum verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.


  • Mod

    Bitte genauere Problembeschreibung.



  • Ich arbeite an einem neuronalen Netz. Die GUI ist mit C#.NET realisiert. Weil die Berechnungen mit C# viel zu langsam sind habe ich dies in eine .dll ausgelagert, welche ich in C++ geschrieben habe.

    Um noch Zeit zu gewinnen habe ich diverse C++ Compiler getestet. Darunter war auch der Besagte von Intel. Ich habe ihn mir ganz normal von deren Seite besorgt, installiert und den Lizenz-Key eingegeben (Studentenversion).

    In Visual Studio hab ich dann den Compiler gewechselt (rechtsklick aufs Projekt und Intel C++ gewählt). Die fertige erstellte DLL hab ich dann ins Hauptprojekt eingebunden. Es hat soweit alles wunderbar geklappt, das Programm lief.

    Und heute (einen Tag später) wollte ich weiter an dem Projekt arbeiten. Ich habe die DLL neu erstellt (aber nichts geändert an den Einstellungen). Die neu erstellte DLL liegt auch im richtigen Verzeichnis und alles andere ist auch wie gestern. Beim starten des Programms bekomme ich heute aber eine System.DllNotFoundException geworfen. Wenn ich die DLL doppelklicke (in Visual Studio im Projektmappen-Explorer kommt auch eine Meldung, dass die Datei nicht da ist).

    Wenn ich jedoch den Compiler wieder auf "Visual C++" setzte läuft alles wieder und die DLL wird gefunden. Da der Intel Compiler aber einen Geschwindigkeitsschub von ca 73% bringt würde ich ihn natürlich gerne einsetzen.


  • Mod

    Marcel.b schrieb:

    Wenn ich jedoch den Compiler wieder auf "Visual C++" setzte läuft alles wieder und die DLL wird gefunden. Da der Intel Compiler aber einen Geschwindigkeitsschub von ca 73% bringt würde ich ihn natürlich gerne einsetzen.

    Ich kann zwar zum Rest deines Problems nichts sagen (außer dass es anscheinend ein Bedienproblem ist, kein Lizenzproblem), aber das hier klingt eher so, als würdest du deinen anderen Compiler nicht richtig benutzen (fehlende Optimierungen, irgendwelche Debugchecks aktiv). Derart weit überlegen ist der Intel-Compiler nämlich auch nicht.



  • Gibt es denn eine empfehlenswerte Quelle wo man sich informieren kann wie man den Compiler richtig einstellt? Ich bin jetzt einfach davon ausgegangen dass die Defaulteinstellung schon in Ordnung ist.

    Geändert hab ich seit gestern nichts, deshalb bin ich ja verwundert, dass es heute nicht mehr klappt. Bedienfehler bei F5 drücken schließe ich jetzt einfach mal kategorisch aus.



  • So, ich habe es gestern wieder zum laufen gebracht.
    Ich habe noch sämtliche Einstellung probiert und auch mal neue Projekte angelegt. Alles half nichts.

    Zum Schluss habe ich dann den Projektordner des Programms "aufgeräumt" und alte Lösungsversuche gelöscht. Danach ging es dann merkwürdigerweise. Also hatte es wohl irgendwas mit der Projektverwaltung von Visual Studio zu tun, was ich eigentlich sehr schade finde bei so einer teuren IDE.

    Danke für die schnellen Antworten gestern und noch einen schönen Sonntag.

    Grüße
    Marcel Benders



  • Soweit ich weiß, sind Optimierungen standardmäßig an. Was man noch machen kann, ist für INTEL64 zu kompilieren. Diese Einstellung finde ich jedoch ziemlich grob, da es diese Plattform schon länger gibt.

    https://msdn.microsoft.com/en-us/library/ms173505.aspx

    Zum Vergleich: Der gcc unterscheidet da deutlich granularer. Man kann z. B. core2 oder corei7 oder schlicht 'native' mitgeben, das die aktuelle CPU-Architektur automatisch bestimmt.

    https://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/i386-and-x86_002d64-Options.html


  • Mod

    VS-Compiler schrieb:

    Soweit ich weiß, sind Optimierungen standardmäßig an.

    Aber sind Bereichsprüfungen, Checked Iterators & Co. standardmäßig aus? Ich meine mich zu erinnern, dass nicht bei allen Arten von Prüfungen im Release standardmäßig aus waren. Zumindest bei älteren Versionen. Benutze aber kein VS und kann es daher nicht prüfen. Bloß Erinnerung an zahlreiche "C++ ist so lahm!"-Threads, bei denen sich am Ende herausstellte, dass irgendwelche Prüfungen noch aktiv waren.



  • O2 ist standardmäßig bei Release-Builds an. Schneller gehts nicht.

    Creates the fastest code in the majority of cases. (default setting for release builds)

    https://msdn.microsoft.com/en-us/library/8f8h5cxt.aspx


  • Mod

    VS-Compiler schrieb:

    O2 ist standardmäßig bei Release-Builds an. Schneller gehts nicht.

    Optimierungsstufen, Laufzeitchecks und Debugsymbole haben nicht direkt etwas miteinander zu tun.


Anmelden zum Antworten