Performance

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Ich habe ein etwas seltsames Performance Problem und weiss nicht recht, wo ich anfangen soll zu suchen.

    Ich will gar nicht zu sehr in die Tiefe gehen, daher in aller Kürze.
    Aktueller Stand ist ein Kommandozeilen-Tool zur Farbrezeptierung (ganz viel Rechenarbeit), die UI soll später aussen rum kommen, die spilet im Moment keine Rolle.
    Das Projekt wurde, wegen verfügbarer Bibliotheken und aus Geschwindigkeitsgründen von einem Externen in Rust geschrieben. Die letzten Schritte ware alle betreffend Verbesserung der Performance und nun ist etwas passiert, was sich im team niemand erklären kann.

    Die aktuelle Version erhält im Vergleich zur Vorversion 2 Optimierungen: a) Verwendung eines besseren Startrezeptes, d.h. die optimalen Farbstoffmnegen werden schneller berechnet. b) Unsinnige Rezepte, die nicht zum Ziel führen werden, werden frühzeitig eliminiert und nicht durchberechnet. Beide Varianten sollten die Rechenzeit nachvollziehbar reduzieren.
    Nun ist folgendes passiert. Ein Kollege wurde mit der Windows-Version des CLI-Tools bedacht und kann dort genau den beschriebenen Performance-Zugewinn feststellen (10 - 15% weniger Rechenzeit).
    Mir wurde das CLI-Tool für macOS kompiliert und bei mir benötigt die aktuelle Version sage und schreibe 20% MEHR Rechenzeit als der Vorgänger, was sich niemand erklären kann. Es handelt sich um ein i7 MacBook Pro. Lasse ich die Windows-Version in Parallels auf dem selben Mac laufe, verhält es sich ebenso

    Es ist mir klar, dass ihr das konkrete Problem so kaum werdet lösen können, aber vielleicht hatte jemand mal ein ähnliches Problem und hätte einen Tipp, wo man mal ansetzen könne.

    Hans
  • es würde helfen zu wissen was mathematisch an den Versionen geändert wurde. Ich könnte mit vorstellen, dass irgendeine mathematische Funktion mehr oder weniger intensive genutzt wird und diese einfach in der entsprechende. Bibliothek auf Windows besser optimiert istvals auf dem Mac.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Puh, ohne weitere Info kann man da echt nur raten.

    - Der Code ist nicht für Multiprozessor optimiert.
    - Evtl. wird eine Third-Party Library verwendet, welche nicht für macOS optimiert ist.
    - Wenn das CLI-Tool für macOS nicht mit Xcode bzw. LLVM übersetzt wird, dann optimiert der verwendete Compiler evtl. schlecht/nicht für macOS.
  • Also wenn mir sowas passiert dann hab ich als debug statt release kompiliert ;)
    So wie ich das verstehe ist nicht mit XCode kompiliert worden. Wie geht das genau ?

    Es gibt natürlich zahlreiche Kleinigkeiten, die sich im Endeffekt spürbar bemerkbar machen können. Z.B. können inline eingebettete Funktionen wieder rausfallen wenn sie jetzt größer sind als früher. Auch Typänderungen von int auf float oder double bringen Unterschiede. Bei Objektorientierungen kann es zu unglücklichen alloc/free kommen, die den Speicher belasten. Mehrere Threads bringen nicht automatisch mehr Speed. Wenns gut läuft sind 4 Threads nur etwa 2,5 mal so schnell, wie einer. Wenns mehr Threads als Kerne werden geht die Performance auch mal unter 1. etc....

    Rein von den Zahlen her (15 % schneller und 20 % langsamer) würde ich am ehesten auf eine schlechte Kompilierung tippen. Denn wenn man manuell optimiert dann ist der Effekt doch meist größer. Diese Prozentzahlen hingegen entsprechen durchaus der Bandbreite der Kompilierung.
  • HansGerber schrieb:

    Lasse ich die Windows-Version in Parallels auf dem selben Mac laufe, verhält es sich ebenso
    Bitte klären, was mit "ebenso" gemeint ist:

    Ich nehme an, daß das heißen soll, daß auch im Parallels mit Windows das Programm schneller läuft als die Vorversion? D.h, der Unterschied ist nicht die Maschine sondern lediglich das Betriebssystem (Mac vs. Win)? Und die Win-Version beim Kollegen läuft auch auf einer Intel o. AMD-CPU, nicht ARM, ja?

    Thomas' Vermutung, daß es sich um eine irrtümlich gebaute Debug-Version handelt, erscheint auch mir am Wahrscheinlichsten.

    Ansonsten: Ändert sich das Verhalten (alte vs. neue Version), wenn man in Parallels die Anzahl der verfügbaren CPUs für die Win-VM ändert? Also von maximal auf nur eine CPU?
    Apps: apps.tempel.org (Find Any File, iBored, iClip, Prefs Editor)
    Blog: http://blog.tempel.org
    Über mich: tempel.org/AboutThomasTempelmann
  • mit „strip„ entfernt man nur die Debug Symbole aus der Exe. Da ändert sich die Dateigröße, die Laufzeit bleibt jedoch konstant. Danach kann man nur noch auf Assembler Ebene Debuggen und keinen externen Profiler mehr verwenden.

    Es gibt vile Unterschiede zwischen dem Mac und Windows, Unterschiedliche Prozessoren, unterschiedliche Betriebssystme mit Bibliotheken, unterschiedliche Grössen der Atomaren Variablen (bspw Int bei Mac 64 Bit, bei Win 32 Bit breit) natürlich unterschiedliche Compiler mit unterschiedlichen Optimierungen, …

    …. Die Liste liesse sich endlos fortsetzen.

    Wenn es euch wirklich auf die Laufzeit ankommt, solltet Ihr einen Hochsprachen-Assembler verwenden und den Code auf alle Systeme optimieren, wie bspw C. Dann habt Ihr es selbst in der Hand.