performance digital

[Thala]

hallo.
ich bin nun schon an dem punkt angekommen, wo ich prozesse optimieren muss.
gibt es eine liste welche module wieviel performance schlucken? vor allem auch die kleinen, wie add; subtract; multiply; and; or.

beispiel. polyplex random funktionen.
diese zufallswerte muessen je nach schalterstellung beim wuerfeln an diverse eingaenge verteilt werden.
nun gibt es ja zig arten dieses umzusetzen.
meine idee dazu. buttons direkt an den core anschliessen und dann mit AND und OR bearbeiten.
oder ist multiply effektiver? waere wohl ein wunder...
oder ist primary hier effektiver?
switches fallen aus, da sie knackser produzieren.

[Quietschboy]

Dazu wurde in den Foren schon einiges verglichen und geschrieben. Nur wenn man es sucht, findet man es ja nicht.

Aber dafür gibt´s was im R6 Core Handbuch, unter 5.6 Opimization Hints, zu lesen:

Relative Cost
The relative CPU cost of various operations can vary from one processor to the other. However,
broadly speaking, the following hints can be kept in mind:
• The cheapest operations are float/int addition, float/int subtraction, float multiplication.
Negation, absolute value and integer bitwise operations are equal or slightly more expensive. DN Cancelin the current implementation is using an addition internally.
• Float/int division and integer multiplication are noticeably more expensive.
• Float exp and log Modules are the most expensive.
• The cost of runtime condition checks (occurring in routing and non-split endpoint merging) can noticeably vary depending on the circumstances. At any rate they are probably
less desirable than a couple of cheap mathematical operations such as addition, so whenever possible, the latter might be preferred.
• The Readand Writeoperations are comparable in cost to the cheapest mathematical operations. They might be marginally more expensive for the arrays (this applies to the array
memory access, array indexing is more expensive).
• Array indexing internally contains a safety clipping mechanism, which is essentially a runtime check. So avoid sending unnecessary events to the array IndexModule. Equally, consider sharing an array IndexModule between a Readand a Writein such situations.

Grundsätzlich hängt die tatsächliche CPU Last auch vom eingesetzten Prozessor, bzw. dessen zur Verfügung stehenden Befehle ab.
In einem eigenen, aber nur unvollständigen Test, mit Core Compare Modulen scheint es wurscht zu sein, ob beispielsweise ein > oder ein = verwendet wird. Die floating point comparison schien gegenüber integer comparison um einen winzigen Hauch schneller zu sein, was mich sehr verwunderte. Aber es war nur ein Test auf die Schnelle. Da schleichen sich leicht Denkfehler, was den Testaufbau angeht, mit ein.
Der Overhead des Aufbaus muss immer mit berücksichtigt werden. Auch gibt es Unterschiede, ob das Testmakro über mehrere Voices läuft, oder die selbe Anzahl Testobjekte seriell verschaltet ist (nur eine Voice). Da muss man teuflisch aufpassen. Auf die CPU Anzeige in Reaktor kann man sich auch nicht immer verlassen. Insbesondere die CPU Anzeige auf Makroebene ist sehr wackelig (Debug structure --> "Measure CPU Usage")!

[Thala]

auf AND und OR wurde dort aber nicht eingegangen, oder überlese ich da etwas?
müssten die nicht noch weniger performance schlucken, da es ja den den prozessor, der im hintergrund die daten schaufelt seiner eigenen arbeitsweise am meisten entgegen kommt. oder?
weil add, multiply etc werden doch intern im prozessor eh mit NANDs berechnet?
oder habe ich hier einen denkfehler?

[Quietschboy]

Bit Operatoren sollten eigentlich die leichtgewichtigsten "Verbraucher" sein. Allerdings kannst du die natürlich im Allgemeinen nicht mit den numerischen Operatoren vergleichen.
Aber es gibt da doch ein paar Tricks:
Z.B. bedeutet ein Bit Shift um 1 nach links dasselbe wie eine Multiplikation mit 2! Das ist allerdings nur mit integeren Zahlen möglich.
Angeblich ist der Core Compiler ziemlich clever. Es ist also nicht auszuschließen, dass im Falle von "Multiplikation mit 2" unter der Haube sowieso nur ein Bit Shift ausgeführt wird.
Probier´s doch mal aus. Würde mich auch mal interessieren.

[Thala]

also ich habs grad geschafft reaktor zu killen
also 4096 schalter auf einmal einfügen kostet schon 3 sekunden.
als ich diese wieder ver8facht habe, und die 32000 schalter ausschnitt um sie abermal in ein macro zu tun, ist reaktor abgestüzt.

das witzige aber war die performance:
bei 32000 schaltern, die über ANDs miteinander verbunden waren sank die cpu leistung sogar leicht. der LFO braucht 1,3% allein. mit 32k schalter sank die CPU auf 1,0-1,1%.

alle schalter waren direkt an core cells angebunden.

dann mal auffi zum multiplikationstest.

[Thala]

multiplikationstest:
das selbe in grün.
32000 schalter auf einmal ausschneiden sind zu viel für reaktor.
aber bei 32000 sank die CPU von 1,3% auf 0,8%.
exakt die leistung, die die cpu benötigt wenn der LFO nicht angeschlossen in der ecke rumliegt. seltsam.

sowohl die AND als auch die Multiply Lösung waren beide im verhalten (also gefühlte schaltgeschwindigkeit) bei 32k schaltern immer noch direkt und ohne denkpause.
ich muss schon sagen,das hat NI gut geregelt.

dann mal auf in den primary test

[Thala]

also auch in primary sind 32k schalter zu viel zum ausschneiden.
aber nun kommts.
während im core test die CPU von 0,9 auf 1,3% hoch geht, allein indem man das LFO signal nur in eine core cell rein und wieder raus schickt, bleibt die CPU in der Primary AND variante immer stabil auf 0,9%. kein hin und herwackeln wie bei core. sieht runder aus...
erst als ich bei 32k schlatern angekommen war sank die CPU auf 0.7% und blieb da stabil stehen.

edit: was ich aber grad beim rumspielen bemerke:
ich habe in der primary varinate eine core cell erstellt. wenn ich dort nun module (+,-,etc) hinzufüge ist das system auf mal träger (gefühlt 500ms) bei 32k schaltern. also nur beim hinzufügen in der core cell.
dies war im core test nicht der fall. dort flutschte immer noch alles in den cores

edit2:
die primary variante schmiert schon beim löschen von 4096 schaltern ab. in der core variante waren 8000 kein problem...

edit3: es reicht ein einzelnes AND zu löschen um Reaktor abzuschiessen. das ist schon heftig und sollte evtl weiter beobachtet werden.

[Thala]

Primary Multiply version.
das selbe verhalten wie bei Primary AND.
nur dass es beim anschliessen der letzten verbindung, welche die 32k schalter ans ziel bringt auf 0,6% cpu fällt.

auch träge, wenn man dann in einem core arbeitet.
und es reicht auch ein einzelnes multiply in der kette zu löschen um reakter auszuschalten.

womit ich zur nächsten stufe komme... wieviel dauerhaft bewegte schalter gehen? oder anders gesagt: die schalter werden durch einen LFO ersetzt.

[Thala]

vielleicht eine blöde frage, aber...
man nehme einen LFO (audiorate) und hängt an diesen einen normalen "A to E".
der LFO liefert ein Signal von -1 bis +1. an ausgang des "A to E" ist dauerhaft +1 !?!
warum?

beim "A to E Perm" klappt das.

[Quietschboy]

Sorry, aber für einen Aussenstehenden sind deine Erläuterungen nicht so ganz nachvollziehbar.
Was möchtetst du denn überhaupt herausfinden?
Wie sieht dein Testaufbau aus?
Was sind das für "Schalter" und "ANDs"?
Screenshots?
Testensemble? (Dateigröße hier max. 256kB; kann auch gezippt sein)
Ich habe den Eindruck du schmeißt gerade viele Parameter durcheinander.

[Thala]

ich bin begeistert von Core
in Primary gibt es nicht zufällig so etwas wie den distribution bus in core?
sonst fallen die Primary Action tests leider wegen kabelsalat aus...

aber nun zum ersten hardcore test.
4.194.303 AND werden mit 200 Hz befeuert: 50-51% CPU
bei 300Hz 75-78% skaliert sauber
weiter gehe ich nicht, das compilieren dauert ewig. und bin schon sehr gespannt auf den multiply test.

[Thala]

den testaufbau kann ich leider nicht schicken. der kleinste ist 24MB.
32000 schalter bedeutet, ich bin angefangen mit 8 schalter. diese werden durch 7 ANDs (logisches UND) oder eben durch 7 multiply module verrechnet und gehen an einen ausgang. dieses macro wird im matrushka prinzip immer wieder in einander kopiert (potenziert), bis Reaktor den geist aufgibt.
alle schalter sind an. und dann schaltet man einen aus und die cpu muss rechnen.
in dem reihen und parallelschaltungs mix juckt die CPU das nicht, bis anscheinend eine adressierungsgrenze erreicht ist (oder ein ähnliches phänomen schiesst reaktor dann ab).

ich hab grad nochmal versucht den action test, zu zippen. winrar schafft es die 32MB auf 932kB zu drücken. leider noch zu viel.

[Thala]

und zum letzten test für heute:
4.194.303 Multiply module wurden mit 200 hz befeuert:
stabile 73% CPU.
wenn ich aber nun auf 210Hz erhöhe, springt die CPU anzeige auf mal panisch zwischen 78% und overload (95% cpu max eingestellt). da haben sich die ANDs bedeutend ruhiger/gleichmässiger
verhalten.
fazit:
die multiplies sind besser als erwartet
Pi mal Daumen kann man also sagen 1 AND-Module = 1,5 Multiply-Module von der performance her, wenn man mit digitalwerten arbeitet.
solche zahlen wollte ich *gg*
und der primary test fällt aus, bis mir eine möglichkeit kommt auch in primary die signale so einfach, wie im core streuen zu können.

interessant wäre jetzt vllt noch eine andere verdrahtungsvariante im core:
in diesem test habe ich alles per strippe im core verbunden. es wurde nur der distribution bus verwendet. kein quickbus.
ob das mit quickbus evtl noch flotter läuft?
naja, der abend ist rum.
und meine eigentlice frage wurde mit den tests auch beantwortet:
es ist schietegol bei digitalwerten, wenn man erst einen performance unterschied oberhalb von 500k module wirklich mal merkt!
ich glaub kaum, dass jemals jemand so eine grosse modmatrix baut. ich jedenfalls nicht und selbst bei 100 schaltern würde kein unterschied bemerkbar sein. das wären dann ca. 0,00013% performance unterschied.

[Quietschboy]

Du meinst 1 AND Modul entspricht ungefähr 0,66 Multiply.

Für "selten" auftretende Events ist es in der Regel tatsächlich unerheblich, ob eine Struktur auf absolute Performance getrimmt ist, oder die "normalen" Rechenoperationen zu Gunsten der Lesbarkeit verwendet werden.
Bei Audiorate oder Event-Iterationen sieht das allerdings ganz schnell ganz anders aus. Insofern sind deine Tests durchaus berechtigt.

Quickbusse dürften nur eine rein optische Angelegenheit sein und sollten sich nicht auf die CPU Last auswirken.
Scoped Distribution? Weiß nicht. Ist noch neu.

[Quietschboy]

Hm, ich komme auf ein anderes Ergebnis, wenn ich Core AND mit MULTIPLY INTEGER vergleiche:

Testen tue ich bei Audiorate. Trigger dafür ist die Sample Rate Clock in Core.
Diese "latcht" eine integere Eins, nur um die Clock Ticks ins Integer-Format zu wandeln.
Darauf folgen 512 ANDs oder eben 512 Multiplys, jeweils in Reihe geschaltet, so dass auch wirklich alle berechnet werden müssen.
Anschließend geht es über einen Event-Outport nach Primary, um mittels Switch zum schnellen Vergleich zwischen beiden Szenarien umschalten zu können.
Damit überhaupt etwas geschieht, dient ein Numeric Readout als Aktivator.

Zuerst muss der Overhead des Testaufbaus ermittelt werden. Er beträgt 0,7%

01 Overhead.jpg

Und nun Overhead plus 512 AND (3,9 %):

02 AND Last.jpg

Hier nun Overhead plus 512 MULTIPLY (14,8%):

03 MULTIPLY Last .jpg

Insofern beträgt die Nettolast für AND 3,2%
und für Multiply 14,1%

Das Multiply (Integer) verschlingt also ungefähr 4,4 mal soviel CPU Power wie das AND.