Salt - tech preview / test demo

[mystran]

One thing I'm noticing is that although restarting the simulation makes sense when you're changing components radically, small changes should be possible to cope by starting the next cycle with the previously known values. Then having a "reset" or "panic" button to actually zero and start from scratch would be needed of course for cases where that fails but making minor changes wouldn't result in the whole circuit having to settle back into its stable state.

Yeah, the problem is the GUI objects don't track the state-variables, and the state-ordering is not totally deterministic so seemingly trivial things like clicking at the wrong place can sometimes change the state-ordering... and it doesn't help that I currently can't detect this. I'll fix that eventually.

[andy-cytomic]

Basically I think that anyone writing circuit simulation code manually is just wasting their time, and lots of it.

It will be interesting to get Andy's reaction to this.


Although I know nothing about DSP, I suspect you are underestimating some of the difficulties that aciddose mentioned.

I'm all for it, I really like Mystran's work and I will support him as much as possible. Hopefully we can continue to share fairly open discussions via email / forums and mutually help each other.

I already have a pipeline that does a similar thing to what Mystran is doing, but I use netlist type text files as the input rather than a gui editor, and I auto generate sse2 code from them which I have to manually compile and run (although I do want to do this dynamically in the future). If I had to manually solve all the circuits by hand it would take way too long to try things out.

[andy-cytomic]

I don't know. I'm not terribly excited about the whole "stereo by SIMD" thing, since it means accepting the worst-case iterations for both channels.

If you run scalar (mono) you still have a thread tied up completely but the worst case, but the entire second channel is set to zero. Instead you may as well use it and solve stereo case at the same time (for circuits where stereo makes sense) and just stick in zero if you want to solve the mono case, it will be just as quick since the cpu does that anyway.

I looked into LLVM before I went with the custom compiler strategy. I could try and see if it can extract something out of my output, but I suspect it, since I already work at floating-point instruction level.. [so basically it can maybe schedule instructions better.. register alloc it probably could match but probably not do much better]

Keeping the pipeline full is critical for performance, and not trivial, llvm does a really good job of this.

Just to make clear, I have no plans of emitting "high-level" C-code because.. there is no high-level code that would make sense. Rather the whole point is to emit C code is just to be able to include it projects, because it is portable where the JIT is not (it'll still look like portable assembler).

The remaining issues with that have to do with things like handling sample-rate changes: with the JIT I can just recompile, but for external code I need to include the logic to rebuild the constant pool, because that stuff is constant folded (because otherwise it could prevent a lot of other constant folding). It's not exactly rocket science, but it's not done yet.

It is pretty easy to auto-generate the three functions you would call: Set (samplerate) Clear () and Process (input), I'm not sure how a JIT makes any difference here.

Anyway, if you have a JIT up and working then please don't spend time on going llvm stuff, I just thought I would mention it for long term consideration.

[mystran]

It is pretty easy to auto-generate the three functions you would call: Set (samplerate) Clear () and Process (input), I'm not sure how a JIT makes any difference here.

Yeah. I just don't have the code to track which values I actually need, since constant folding can mess with that. So I need to track the constant folding as rational functions (instead of pure constants) and then generate from that.

It's not a technical problem. It's purely an implementation issue, but it's not done.

[mystran]

I had a bug with the solver quit working. Was just messing with some diodes for a half wave rectifier, changing their polarity. I set it back to how it worked previously and still no audio.

Is there a way to delete components?

Shift-right-click.

Urgh.. can you maybe send me a screenshot (teemu@signaldust.com) of the circuit where you had trouble [if you still have it]. In general though.. power-cycling SHOULD fix any situation where the simulator gives up. If you found a way to permanently break it, then .. that would be a bug (and not just a simulation problem).

Will do the next time it happens, and thanks!

Actually I found some code that might be suspect: it appears that I recently changed the output clipping code, and right now it doesn't look like it's NaN safe (it used to be). So if you get a particularly ugly simulation failure (eg 0/0 or something similar), power-cycling might reset it internally, but something down the line might get poisoned, and then it could be happily processing as usual (and you'd still see Vdc levels and iteration varying) but you wouldn't hear anything.

Like I said.. not exactly production quality.

[camsr]

This circuit has been providing some fun
http://www.electroschematics.com/138/dy ... er-supply/
It is soft clipping above -34dbFS, I can't seem to work out how it "compresses" or if it's even supposed to.

[aciddose]

This circuit has been providing some fun
http://www.electroschematics.com/138/dy ... er-supply/
It is soft clipping above -34dbFS, I can't seem to work out how it "compresses" or if it's even supposed to.

It works by varying the current through the diode ring. There are quite a lot of old VCAs and filters made this way. These are some of the sort of circuits you might have first seen when silicon diodes became widely available in the late 1920s.

Generally atrocious performance and only really useful as a novelty until transistors became available.

[andy-cytomic]

This circuit has been providing some fun
http://www.electroschematics.com/138/dy ... er-supply/
It is soft clipping above -34dbFS, I can't seem to work out how it "compresses" or if it's even supposed to.

This uses each side of the waveform to charge a capacitor with (roughly) the opposite voltage, which then drains current through the diodes. This is a cool little circuit and its operation is very similar to how the synthacon filter sets the cutoff, but in this case instead of charging a capacitor with the current it just adjust the gain of the output.

[aciddose]

What you could do to fix the distortion on signals below the diode threshold voltage is feed in that voltage through a resistor to both sides of the circuit. It's still passive, you're just biasing it.

Take a voltage source, feed into a resistor like 22k, then a diode, then ground.

Same thing again only with negative voltage, reverse the diode, ground.

Take the voltage between the diode and resistor through another resistor like 22k and apply it to the left side of the 22k resistor in the existing circuit. Top side positive, bottom side negative.

This will act as a threshold and while the signal is below that level (usually 1.5v) its level won't be affected. You're stuck with a -30db gain reduction then so you need to add about 30db gain with an amp on the output

Ratio is about 2.8 / 100. (For 30db gain.)

Compression ratio is about 1/1.42.

[mystran]

I looked into LLVM before I went with the custom compiler strategy. I could try and see if it can extract something out of my output, but I suspect it, since I already work at floating-point instruction level.. [so basically it can maybe schedule instructions better.. register alloc it probably could match but probably not do much better]

Keeping the pipeline full is critical for performance, and not trivial, llvm does a really good job of this.

So I couldn't resist a quick test.. so I hacked a totally very awful test together, so I could get a quick idea of the speed difference against MSVC2k8..

In terms of C code, it doesn't seem to make any difference, whether I tell it to load constants from a data-buffer, or just inline it all as literals (which would not be realistic anyway, but I wanted to try). That's encouraging.

In terms of C vs. JIT.. with the relatively small test-circuit (the "hifi amp preset") running 6 copies in series (with saw-wave excitation) I reach about 60% with JIT vs. 55% for MSVC as unscientifically measured by FL's meter, so I'm approximately 10% less efficient. That said, I do realize that MSVC2k8 isn't the best in terms of SSE2 floating point code.. just the one that I can easily test against (there's some shared overhead, but not enough to change the numbers significantly).

Looking at the MSVC assembly.. the two main differences are:

1. MSVC seems to schedule loads earlier. That's the most obvious pipeline improvement that I notice.. but I suspect that it's not getting huge improvements from that because..

2. MSVC also seems to cheat .. yeah .. so I apparently forgot to disable whole-program optimizations, so where the JIT code will call the Newton-solvers as separate functions the hard-way, the MSVC assembly just inlines them. The most obvious consequence is that it doesn't need to save all registers either, just make some room for the inline. Not going to redo the test right now though. [and it does suggest that I might want to try doing that too]

But in general.. this test wasn't enough to convince me that there is a huge problem with the native code output. I'll test against better compilers at some later point.

[andy-cytomic]

But in general.. this test wasn't enough to convince me that there is a huge problem with the native code output. I'll test against better compilers at some later point.

Apart from taking near half the cpu for dual mono (stereo) circuits! That is great that the JIT is doing a very good job for the mono case

[mystran]

But in general.. this test wasn't enough to convince me that there is a huge problem with the native code output. I'll test against better compilers at some later point.

Apart from taking near half the cpu for dual mono (stereo) circuits! That is great that the JIT is doing a very good job for the mono case

Yeah well, it's a tech preview... the proof of concept version that is supposed to show that this stuff is actually workable in the first place. Before now and the eventual product, there will plenty of time for s/(...)sd/\1pd/g and I'd rather have the final product be twice as efficient than the other way around.

[eidenk]

Doesn't load in Cantabile 1.2 and I get an "entry point not found - not a vst plugin" message. All your other plugs load OK with this host. Loads fine in Cantabile 2 Lite and savihost however.

[andy-cytomic]

But in general.. this test wasn't enough to convince me that there is a huge problem with the native code output. I'll test against better compilers at some later point.

Apart from taking near half the cpu for dual mono (stereo) circuits! That is great that the JIT is doing a very good job for the mono case

Yeah well, it's a tech preview... the proof of concept version that is supposed to show that this stuff is actually workable in the first place. Before now and the eventual product, there will plenty of time for s/(...)sd/\1pd/g and I'd rather have the final product be twice as efficient than the other way around.

Definitely, which is why I said previously you should just get on and use the JIT for now, this was only ever meant as an observation for you to consider for the future

[mystran]

Doesn't load in Cantabile 1.2 and I get an "entry point not found - not a vst plugin" message. All your other plugs load OK with this host. Loads fine in Cantabile 2 Lite and savihost however.

MM.. probably missing the older pre-2.4 VST entry point then. I really thought I solved that problem once and for all.. but apparently not.