BoxSim: Neue Ideen

[UweG]

Diesen Unsinn kann ich jetzt wirklich nicht so stehen lassen:

Man braucht für Multithreading nichts beachten

Die Berechnungszeit würde auf 1/4 bis 1/8 der aktuellen Berechnungszeit auf jedem PC fallen.

Boxsim läuft seit Version 0.6 in zwei Threads, seit es den Optimierer gibt in 3 Threads. Einem kundigen Programmierer würde zumindest auffallen, dass da ein zweiter Thread sein muss, denn sonst würde kein Menü aufgehen, wenn die Berechnung noch nicht abgeschlossen ist. Mit einer Aufteilung des Berechnungsthreads in mehrere Threads habe ich auch schon experimentiert, vor allem im Rahmen der Rechnungen des Optimierers und kann deshalb die obige Aussage nur ins Reich der Fabeln verweisen. Wie soll das auch gehen, dass ein Rechner mit nur 2 Kernen 8 mal so schnell wird, wenn jedes Mutithreading zwangsläufig auch Overhead, ungleichmäßige Auslastung, Kollisionen um Speicherschnittstellen etc. erzeugt. Dass ein 8-Kerner zweimal so schnell wird, halte ich für bei weitem realistischer.
Was ich viel dringender bräuchte als eine Berechnungsbeschleunigung wäre eine Baubeschleunigung. Das dauert bei mir immer extrem lange.

[F.H.]

Boxsim simuliert ja so, als ob das Mikro im Unendlichen platziert wäre. Bei kleinen Boxen ist das OK. Bei hohen Standboxen macht es allerdings einiges aus, ob man in 3 m oder 2 m Abstand sitzt und wie hoch die Ohren über dem Boden sind.

1. Deswegen wäre die Berücksichtigung des Abstands und der Höhe des Mikros interessant.

Es wurde schon mal der Wunsch geäußert, mehr Frequenzgänge unter Winkeln zu simulieren. Uwe hat darauf geantwortet, dass das zu aufwändig wäre, was ich gut nachvollziehen kann. Da aber 30° nach oben und unten bei vertikaler Anordnung der Chassis schon ein zu großer Schritt ist, frage ich, ob folgendes möglich ist.

2. Statt so viele Winkel hinter der Box zu simulieren, zwei Frequenzgänge mehr nach vorn zu verlegen. Also z.B. in der Vertikalen 10°, 20°, 30°, 60°, 90° und auf der Rückseite weniger Frequenzgänge berechnen.

Generell möchte in eins betonen: Boxsim sollte auf keinen Fall zu kompliziert werden. Es ist wichtig, dass auch Neulinge möglichst schnell und ohne zu großen Aufwand einen Anfangserfolg haben.

[Peter K]

Kallo Friedemann,

Boxsim simuliert ja so, als ob das Mikro im Unendlichen platziert wäre. Bei kleinen Boxen ist das OK. Bei hohen Standboxen macht es allerdings einiges aus, ob man in 3 m oder 2 m Abstand sitzt und wie hoch die Ohren über dem Boden sind.

1. Deswegen wäre die Berücksichtigung des Abstands und der Höhe des Mikros interessant.

War auch einer meiner Hauptwünsche.

Es wurde schon mal der Wunsch geäußert, mehr Frequenzgänge unter Winkeln zu simulieren. Uwe hat darauf geantwortet, dass das zu aufwändig wäre, was ich gut nachvollziehen kann. Da aber 30° nach oben und unten bei vertikaler Anordnung der Chassis schon ein zu großer Schritt ist, frage ich, ob folgendes möglich ist.

2. Statt so viele Winkel hinter der Box zu simulieren, zwei Frequenzgänge mehr nach vorn zu verlegen. Also z.B. in der Vertikalen 10°, 20°, 30°, 60°, 90° und auf der Rückseite weniger Frequenzgänge berechnen.

Fände ich zwar auch sinnvoll, beim Verzicht auf rückseitige Frequenzgänge funktioniert aber die Berechnung des Energiefrequenzgangs nicht mehr.

Generell möchte in eins betonen: Boxsim sollte auf keinen Fall zu kompliziert werden. Es ist wichtig, dass auch Neulinge möglichst schnell und ohne zu großen Aufwand einen Anfangserfolg haben.

Da kommt mir gerade der Gedanke, warum nicht mit zwei Varianten des Progs arbeiten ?
a) die reine Variante für Neulinge, die könnte dann sogar gegenüber der jetzigen Version deutlich abgespeckt werden (Wozu z.B. benötigen Neulinge die Möglichkeit des Imports eigener Messungen ?), die dann nur mit den Visaton-Chassis arbeiten kann.
b) Und eine gegenüber der heutigen Version "aufgebohrte" Variante, die mehr (wie hier schon angesprochen) Möglichkeiten für fortgeschrittene User bietet ?

Man wird ja mal träumen dürfen....

Gruß
Peter Krips

[Mr.E]

Zum Optimierer und der Zielgruppe:

Ich hab von der Materie keine Ahnung. Ich hab auch den Optimierer bisher kaum benutzt, weil ich ihn ehrlich gesagt nicht ganz verstehe. Aber wenn Boxsim nicht für Profis gedacht ist, was macht man dann als Hochschulangehöriger, der Zugang zu einem RAR und Meßgeräten hat, und Boxen entwicheln will, die »richtigen Studiomonitoren« das Wasser reichen können? Da wäre es, wie schon erwähnt wurde, sehr hilfreich, die Mikroposition angeben zu können, aber zum Beispiel auch, in etwas kleineren Winkelschritten zu simulieren. Vielleicht bis 90° oder zumindest 45° in 5-Grad-Schritten. Oder ist das übertrieben?

Chassis unabhängig voneinander auf verschiedenen Schallwänden zu platzieren ist im Moment ziemlich umständlich. Einige Angaben, die man da machen soll, verstehe ich überhaupt nicht (unten links im Dialog, Schallaustrittsposition im Raum oder so, bin mir grad nicht sicher).

[AlphaRay]

Boxsim läuft seit Version 0.6 in zwei Threads, seit es den Optimierer gibt in 3 Threads. Einem kundigen Programmierer würde zumindest auffallen, dass da ein zweiter Thread sein muss, denn sonst würde kein Menü aufgehen, wenn die Berechnung noch nicht abgeschlossen ist. Mit einer Aufteilung des Berechnungsthreads in mehrere Threads habe ich auch schon experimentiert, vor allem im Rahmen der Rechnungen des Optimierers und kann deshalb die obige Aussage nur ins Reich der Fabeln verweisen. Wie soll das auch gehen, dass ein Rechner mit nur 2 Kernen 8 mal so schnell wird, wenn jedes Mutithreading zwangsläufig auch Overhead, ungleichmäßige Auslastung, Kollisionen um Speicherschnittstellen etc. erzeugt. Dass ein 8-Kerner zweimal so schnell wird, halte ich für bei weitem realistischer.
Was ich viel dringender bräuchte als eine Berechnungsbeschleunigung wäre eine Baubeschleunigung. Das dauert bei mir immer extrem lange.

Im Taskmanager unter Win10 hat BoxSim sogar 19 Threads Aus welchen Gründen auch immer..

Habe mal die La Belle geladen: 13 Sekunden bei 12-13 % CPU Auslastung (Projekt geöffnet -> Einstellungen -> "Fein / 250").
CPU: i7 3770 (4x3,4 GHz, HT). Ich denke, dass die reale Auslastung eher bei 25 % liegt, da er hier durch das Hyperthreading vier echte und vier Virtuelle Kerne hat = 8 Kerne = 1/8tel = 12,5 % CPU Last.
Der Optimierer lastet um 23-24 % aus.

Mir ist schon klar, dass du einzelne Funktionen schon als Thread startest. Was ich meinte war, dass du das ja nur mehrfach parallel starten müsstest um mehrere Kerne auszulasten. Und acht Threads auf nem Dual-Core machen nun wirklich nicht so viel Overhead wie du glaubst (ich meinte bei diesem natürlich 1/4 der Rechenzeit - 1/8tel bezog sich auf Achtkerner) - es wird immer schneller sein als nur ein Thread.

Was war denn das Ergebnis, wenn du das schon gemacht hast? Bei z.B. CineBench macht sich jeder Kern und das HT bemerkbar - bis auf eine CPU immer ziemlich linear:


Hier hat einer (mit Code) eine Berechnung auf mehrere Threads aufgeteilt:
https://solarianprogrammer.com/2011/...read-tutorial/
Auf Dual-Core (Mac) und 4 Threads = doppelte Geschwindigkeit. 4-Kern i7 (Linux) mit 8 Threads = dreifache Geschwindigkeit.

Hier ein anderes beispiel mit C++ unter Windows auf einem alten Core2Duo:
https://software.intel.com/en-us/art...ading-benefits
3,82-fache Geschwindigkeit 1-Thread vs. 4-Threads

Hauptsächlich würde das Multithreading bei der Initial-Berechnung beim Öffnen (ist das die "Baubeschleunigung" die du meinst?) und beim Weicheneditor Sinn machen. Wenn Projekte beim Öffnen schon nach zwei Sekunden mit 250 Punkten auf dem Bildschirm wären - traumhaft Weicheneditor braucht hier übrigens bei der La Belle 2,5-3 Sekunden für jede Akutalisierung bei "Übernehmen". Mit Multithreading könnte das Übernehmen durch ne Checkbox "Automatisch Aktualisieren" ergänzt werden, wo jede Änderung direkt sichtbar wird, wenn die Berechnung auf ne viertel bis halbe Sekunde fallen würde.

[squeeze]

Hauptsächlich würde das Multithreading bei der Initial-Berechnung beim Öffnen (ist das die "Baubeschleunigung" die du meinst?)

Ich glaube eher damit meint er, das ihm das handwerkliche Bauen einer Box zu lange dauert. Ich finde auch das die Ladezeiten nicht unbedingt erheblich sind. Lieber mehr Features im Programm als die Zeit für Ladezeitenoptimierung raushauen.

Ich wünsche mir eine Implementierung von PEQ´s in den Aktiven verstärkern ala REW. Damit man mit Boxsim auch eine komplette aktive Box simulieren kann.

[AlphaRay]

Ahso Jetzt, wenn ich mir das noch mal durchlese, könntest du Recht haben

Es ist ja nicht nur das Laden - dort wird denke ich ne Grundtabelle mit z.T. festen Werten vorberechnet, weshalb weitere Änderungen schneller berechnet werden können. hier auf der Arbeit habe ich einen schnellen i7 - das hat nicht jeder. Ich gehe von durchschnittlich 15-30 Sekunden Ladezeit (250 Punkte) bei 3-4 Chassis, und Berechnungen im Weicheneditor von 3-8 Sekunden aus.
Es ist ja auch nicht nur das Laden. Jede Änderung am Gehäuse oder Chassis benötigt eine komplett neue Grundberechnung, welche lange dauert (wie beim Laden eines Projekts).

Dazu kommen vielen, tollen neuen Features - welche Berechnungszeit kosten... Dann dauert irgendwann das laden ne Minute und Änderung an der Weiche ne halbe für ne Neuberechnung, wenn hier einige Vorschläge dazu kommen Daher ist die Bereinigung/Beschleunigung der Berechnungen schon sehr sinnvoll.

[squeeze]

Gibt es eigentlich jemanden, der die vorschläge hier filtert und sie ggf. im ersten Threat quick&dirty zusammenfasst?

und alte vorschläge zu verlinken finde ich macht hir gar keinen Sinn, weil sich mit Sicherheit nicht jeder die alten Threats nochmal durchschauen möchte.

[UweG]

@Squeeze: VISATON schrieb:

Unser Anliegen war einfach, dass es Zeit für ein paar Veränderungen an dem Programm ist und dass die Benutzer wohl die meisten Erfahrungen und somit die besten Ideen für Veränderungen haben. Diese sollen hier zusammengetragen und am Ende ausgewertet werden. Natürlich folgen Machbarkeitsanalysen und eine sinnvolle Auswertung der Ideen. Das sollte dann aber in unseren Händen (Visaton intern) und vor allem bei Uwe bleiben.

Mit "Baubeschleunigung" meinte ich tatsächlich das Bauen der Kiste. Das dauert manchmal mehr als 100 Millionen Sekunden und da hilft Boxsim irgendwie auch nicht.

[Mr.E]

Da läßt sich die Anzahl der Threads aber auch nur begrenzt erhöhen. Oder besser gesagt: Die kann man schon erhöhen, aber spätestens wenn alles geleimt ist, muß man doch wieder warten.

[UweG]

@Mr.E: Da kommen dann noch die Wartezeiten auf "bis ich mal wieder Zeit und Lust habe" dazu. Die sind manchmal ziemlich lange - jedenfalls bei mir.

@Alle: Wie logisch findet ihr eigentlich die Festlegung von rechts und links in Boxsim? Ich muss leider selbst gestehen, dass ich nach längerer Zeit der Nichtbenutzung erst mal wieder nachsehen musste. Wäre es logischer, rechts und links aus Sicht des Lautsprechers zu definieren?

@auch alle: Was stört Euch an diesem BR-Utility? Das benutzt irgendwie keiner.

[yoogie]

Normalerweise sieht man die LS an beim hören und bauen. Deswegen finde ich das so ok. Bretter beim bauen markiere ich so.

Reparaturanleitungen vom Auto werden beschrieben in Fahrtrichtung. Aber das eben eine andere Logik. Karte im Navi läuft logischerweise auch verkehrt. Meist in Richtung Ziel, nicht nach Norden.

[AlphaRay]

Bei L/R habe ich dann immer in den Frequenzverlauf geschaut was wo gemeint war, wenn ich's nicht mehr wusste - eine einfache, kleine Grafik in dem Formular mit 3D Ansicht einer Box + L/R Beschriftung würde da ausreichen

[Rainer_G]

Aus der Sicht des Hörers ist die linke Box links und die rechte Box rechts. So sind i.d.R. auch die Lautsprecherklemmen am Verstärker angeordnet. Nur die Engländer mach das teilweise umgekehrt (z.B. Naim). Aber die haben ja auch Linksverkehr.

In diesem Sinne ist die BoxSim Anordnung logisch und sinnvoll.

[AlphaRay]

Das ist ja klar - dass die rechte Box beim rechten Ohr steht. Hier gehts aber um die Entwicklung eines lautsprechers: normal müsste man da natürlich vom Lautsprecher ausgehen und nicht von dem Hörer, der ja nicht existiert

Einfaches Beispiel: du entwickelst Autos. Stehst VOR dem Auto - ist der rechte Blinker nun rechts oder links..? Das zu entwickelnde Objekt wird normal immer von der Sichtweise des Objektes gesehen - auch du dich. Dein rechter Arm ist rechts. Stehst du vor einer Person ist dann laut deiner definition sein linker Arm für dich der rechte...