3. Java-Programm doppelt so schnell wie C++-Implementierung?!

Java-Programm doppelt so schnell wie C++-Implementierung?!

  • ?

    Ikaron schrieb:

    Soo, ich hab jetzt die Lookup-table auch in Java eingebaut und siehe da: 0.381 Sekunden, also immer noch 80% schneller als C++. Aber danke schon mal für den Tipp, somit ist es wenigstens schon um Faktor 2,5 schneller geworden 😃

    Wie rufst du den C++-Compiler auf?

    0
  • I

    wermisstmisstmist schrieb:

    Ikaron schrieb:

    Soo, ich hab jetzt die Lookup-table auch in Java eingebaut und siehe da: 0.381 Sekunden, also immer noch 80% schneller als C++. Aber danke schon mal für den Tipp, somit ist es wenigstens schon um Faktor 2,5 schneller geworden 😃

    Wie rufst du den C++-Compiler auf?

    Ehm... Ich such eben das Command raus.. Nicht wundern, ist automatisch generiert. Gibt's hier auch Tricks um nicht immer C:/Projects/speedtest/... schreiben zu müssen?

    C:\MinGW\bin\g++.exe -IC:/Projects/speedtest/src/ C:/Projects/speedtest/src/main.cpp C:/Projects/speedtest/src/mathext.cpp C:/Projects/speedtest/src/mathext.hpp -o C:/Projects/speedtest/out.exe -lmingw32
    0
  • ?

    Ikaron schrieb:

    C:\MinGW\bin\g++.exe -IC:/Projects/speedtest/src/ C:/Projects/speedtest/src/main.cpp C:/Projects/speedtest/src/mathext.cpp C:/Projects/speedtest/src/mathext.hpp -o C:/Projects/speedtest/out.exe -lmingw32

    Na dann ist klar. Versuch in der IDE den Release-Mode einzustellen. Es sollte mindestens das Flag -O3 erscheinen, besser wäre -Ofast -march=native -flto.

    0
  • I

    wermisstmisstmist schrieb:

    Ikaron schrieb:

    C:\MinGW\bin\g++.exe -IC:/Projects/speedtest/src/ C:/Projects/speedtest/src/main.cpp C:/Projects/speedtest/src/mathext.cpp C:/Projects/speedtest/src/mathext.hpp -o C:/Projects/speedtest/out.exe -lmingw32

    Na dann ist klar. Versuch in der IDE den Release-Mode einzustellen. Es sollte mindestens das Flag -O3 erscheinen, besser wäre -Ofast -march=native -flto.

    Die "IDE" ist zur Zeit nur ein kleiner Compiler-Wrapper, den ich mir selbst geschrieben habe, deswegen wäre es ganz nett, wenn du mir die Commands schnell erklären würdest. Und noch eine Frage, warum genau 524288?
    Tatsache. Von 600ms auf 125ms.

    0
  • ?

    524288 ist 2^19 und war der grösste Nenner, mit dem cos aufgerufen wurde. Wie gesagt, ich habe das sehr quick'n'dirty geschrieben, der Code muss noch aufgeräumt werden.

    Tatsache. Von 600ms auf 150ms.

    Ist die Welt jetzt wieder in Ordnung?

    Ich rufe meinen Compiler mit
    g++ -std=c++11 -Wall -Wextra -march=native -Ofast fast.cpp -o fast
    auf. Wenn das Working Directory richtig gesetzt ist, kann auf die Pfadangaben verzichtet werden.

    0
  • I

    wermisstmisstmist schrieb:

    524288 ist 2^19 und war der grösste Nenner, mit dem cos aufgerufen wurde. Wie gesagt, ich habe das sehr quick'n'dirty geschrieben, der Code muss noch aufgeräumt werden.

    Tatsache. Von 600ms auf 150ms.

    Ist die Welt jetzt wieder in Ordnung?

    Ja. Ja das ist sie. Auch, wenn ich mich frage, warum C++ mit vector schneller klar kommt als mit einem Array...

    wermisstmisstmist schrieb:

    Ich rufe meinen Compiler mit
    g++ -std=c++11 -Wall -Wextra -march=native -Ofast fast.cpp -o fast
    auf. Wenn das Working Directory richtig gesetzt ist, kann auf die Pfadangaben verzichtet werden.

    Okay, gut, vielen Dank Dir. Jaa das mit dem Working Dir ist mir eig schon klar, aber dann kommt es zu so unsinnigen Fehlern, weil man z.B. keine \ verwenden darf oder ein / vor dem Pfad braucht oder so... Hab schon lange genug mit -L und -l gekämpft, locker 5-6 Stunden, da verlass ich mich lieber auf absolute Pfade.

    0

  • wermisstmisstmist schrieb:

    Fakt ist jedenfalls, dass die JVM cos/sin extrem optimiert hat (z.B. mit argument reduction), weshalb sie ev. schneller ist als die Default-Implementierung der C++-Standardbibliothek. Aber im Grund vergleicht man da Äpfel und Birnen.

    Die JVM hat sin/cos auf Genauigkeit optimiert, und ist daher langsamer als sin/cos der CPU. Steht auch so in dem Artikel.

    0

  • Ikaron schrieb:

    Ja. Ja das ist sie. Auch, wenn ich mich frage, warum C++ mit vector schneller klar kommt als mit einem Array...

    Tut es ja nicht.
    Der Code mit vector verzichtet darauf bei jedem Aufruf von internalfft neue Buffer anzulegen, sondern übergibt die Buffer an internalfft als Parameter, so dass sie wiederverwendet werden können.
    Das kann man mit new/delete natürlich genau so machen.

    Nur dass vector viel praktischer ist, weil man sich nicht ums delete kümmern muss, und die Freigabe dadurch automatisch Exception-safe wird.

    0
  • ?

    Freu dich doch, dass Java sich nicht verstecken brauch und dazu noch 1000mal angenehmer zu programmieren ist. Wenn du nicht gerade der C++-Profi schlechthin bist, ist eh Java meist schneller.

    0
  • ?

    Javareichtoft schrieb:

    Wenn du nicht gerade der C++-Profi schlechthin bist, ist eh Java meist schneller.

    Man muss nicht gerade der Ober-Checker sein um beim Compiler Optimierungen anzuschalten ...

    0
Anmelden zum Antworten