Supernova cpu usage with ParGroups

  • SuperCollider version: 3.11.2
  • Operating system: Linux
// Server.scsynth;
Server.supernova;
s.options.maxNodes = 8000;
s.options.memSize = 2 ** 16;
s.boot;
s.mute;  // don't forget to mute.

SynthDef(\test, { Out.ar(0, SinOsc.ar!2) }).add;
g = ParGroup()
// h = { Group(target: g) }!4;  // other option, the same.

(
fork {
	3000.do { arg i;
		// Synth(\test);  // one core
		Synth(\test, target:g);  // -T 4 cores
		// Synth(\test, target:h[i % 4]);
		0.001.wait;
	}
};
)

s.numSynths;
s.quit;

For one thread supernova (~70%) uses more cpu than scsynth (~60%) but with four threads (-T 4 option, not configurable from sclang) each thread uses the same amount of cpu (~70%) supposedly doing less work. I don’t remember this being the case, is it working properly or I’m doing something wrong?

I think it is configurable – ServerOptions | SuperCollider 3.11.1 Help – " .threads = value – Number of audio threads that are spawned by supernova."

In any case: In years past, my dual-core machine could almost double performance with supernova. Now supernova performs not significantly better than scsynth.

That’s worrisome.

hjh

Thanks for the tip, I overlooked it. Yep, something is wrong it seems…

I’ve noticed similar problems. Supernova in its current state is pretty unusable. This is quite unfortunate because multi-core support was one of its biggest attractions for me. Would anyone be interested in a paid bounty to fix this?

My guess is that Supernova accidentally pins the audio threads to the same physical core.

I discovered this issue recently and I already have a fix on a local branch. I need to clean it up and then push it to https://github.com/supercollider/supercollider/pull/5618

@jamshark70 & @mikedickey: Can you post the output of cat /proc/cpuinfo?

OK. I’ll remove repeated “flags” lines though.

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping	: 3
microcode	: 0xea
cpu MHz		: 2400.000
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
vmx flags	: vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips	: 4800.00
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping	: 3
microcode	: 0xea
cpu MHz		: 2400.000
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes

processor	: 2
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping	: 3
microcode	: 0xea
cpu MHz		: 2680.053
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
stepping	: 3
microcode	: 0xea
cpu MHz		: 1317.886
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes

With the “performance” governor, and setting 4 threads for supernova (and about the same for 2 threads), I do get parallel performance:

// scsynth: ~18% avg CPU reading in IDE
// supernova: 9-10%
g = ParGroup.new;
(freq: Array.fill(200, { exprand(200, 800) }), amp: 0.001, sustain: 20, group: g).play;

hjh

Hmmm… your output doesn’t seem to support my guess. In your case, Supernova should pin the 2 threads to 2 different cores.

What do you mean by that?

I mean I ran the test once with s.options.threads = 4 and once with s.options.threads = 2 (rebooting, of course). Actually 2 threads is about 12-13% (slower but not twice as slow).

hjh

With the “performance” governor

Ok, so the issue here is really about CPU frequency scaling, probably triggered by Supernova’s spin waiting.

BTW, shouldn’t you always use the performance governor for audio work anyway? What is a "performance governor"? - Linux - Ardour

I use “powersave” when I’m on battery and not doing pro audio work.

I use “performance” onstage or at other times when it really matters (like CPU benchmarks).

That is, I was simply clarifying that I was trying to run the test in as close to an optimal configuration as I can manage. I thought that was a good thing :laughing:

Really, I’ve done the testing I’m gonna do for now. I have a lot of other things to do, I’m leaving this thread for today.

hjh

@jamshark70 Sorry, I think I got confused. In your original post you said that Supernova that doesn’t give you any (significant) speed up, but in Supernova cpu usage with ParGroups - #6 by jamshark70 you say that you do get better performance. Since you explicitly mentioned the “performance” governor, I was assuming that was the reason.

So Supernova works as expected for you after all?

@lucas

How do you measure the CPU usage?

Instead of looking at numbers, you can try to create as many Synths as possible before hearing drop outs. Do this with -T 1 and -T 4 and compare the numbers.

That’s a long time ago. I can’t remember what I was doing to arrive at that conclusion… given that a more controlled test today got the expected result (DSP finished more quickly with multiple cores), and that the earlier post includes no documentation of the test or any numeric results, in hindsight I’d have to say it isn’t a convincing data point.

hjh

Ok. Thanks for clarifying!

Drop outs doesn’t really matter in this case, I have dropouts and jack reports xruns with lower cpu consumption.

Kubuntu 20.04
SC release build.

perl ./realTimeConfigQuickScan.pl
== GUI-enabled checks ==
Checking if you are root... no - good
Checking filesystem 'noatime' parameter... 5.4.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors... CPU 0: 'performance' CPU 1: 'performance' CPU 2: 'performance' CPU 3: 'performance' CPU 4: 'performance' CPU 5: 'performance' CPU 6: 'performance' CPU 7: 'performance'  - good
Checking swappiness... 10 - good
Checking for resource-intensive background processes... none found - good
Checking checking sysctl inotify max_user_watches... >= 524288 - good
Checking whether you're in the 'audio' group... yes - good
Checking for multiple 'audio' groups... no - good
Checking the ability to prioritize processes with chrt... yes - good
Checking kernel support for high resolution timers... found - good
Kernel with Real-Time Preemption... not found - not good
Kernel without 'threadirqs' parameter or real-time capabilities found
For more information, see https://wiki.linuxaudio.org/wiki/system_configuration#do_i_really_need_a_real-time_kernel
Checking if kernel system timer is high-resolution... found - good
Checking kernel support for tickless timer... found - good
== Other checks ==
Checking filesystem types... ok.
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
   Find your sound card's IRQ by looking at '/proc/interrupts' and lspci.

CPU (it’s a very bad cpu btw).

cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 2897.396
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 1
[ trimmed, repeats for each virtual core ]

Running the original test supernova now crashes sometimes after sending the synths, but not always.

commit b6787134d24f8343ae071a70377fd945ffe74d96 (HEAD → main, tag: Version-3.12.1)

scsynth:

supernova t1 (Jack: xrun detected - resyncing clock - all the time), something funny, the waves in the most active cpu usage are browser activity (writing this message).

supernova t4 (Jack: xrun detected - resyncing clock - sporadic)

@lucas

I would need the complete output.

Drop outs doesn’t really matter in this case

What I meant was: looking at the CPU load alone is often not very meaningful. What you actually want to know is how many Synths you can run until the audio callback gets overloaded. I usually play a simple sine tone and add more and more (silent) Synths until the sine tone gets distorted. You can do that both with scsynth and supernova using ParGroup and compare the numbers.

Ok, in my case, I have sporadic but consistent drops (sending osc or by gui updates) with scsynth at 50% cpu 3500-4000 synths, scsynth at 60-70% cpu 5000 synths glitches are random but constant, any gui update breaks the sound, scsynth at 80% cpu 6000 synths (glitches periodically, ~90bpm, can be anything updating), 95%cpu glitches more sostenuto. Jack doesn’t report anything in the scide but they increase constantly in another jack tool.

// used synthdef sent to a ParGroup
SynthDef(\test, { Out.ar(0, SinOsc.ar(mul: 0.0001)) }).add;

With supernova T1, at 50% cpu 2000 synths there are dopouts (like with scsynth at this cpu usage, xruns a reported in the post windows), at 60-70% cpu 3000 synths xruns at ~90bpm, adding 1000 more synths… server crash.

With supernova T4, first try, 1000, 2000, 3000, synth and server crash. Second try: around 50% cpu (each of the 4 cores) 3000 synths, dropouts like before, adding 1000 more and crash. Can’t reach 4000 synths, adding by 1000 each time, same crash. Sending 4000 at once, 70-80 cpu (each of the 4 cores) glitches periodically. I stop here because the try-crash loop is boring.

I tried to be as consistent as possible in the description, I don’t know how to measure cpu usage vs number of synths, scide cpu numbers jump constantly so I used htop, wait for each addition to stabilize and read the shown number by core. Here is the complete output of the cpu:

cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 2868.331
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 3000.118
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 1
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 2836.113
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 2
cpu cores       : 4
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 2909.986
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 6
initial apicid  : 6
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 4
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 2921.960
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 5
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 2796.388
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 1
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 6
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 2805.513
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 2
cpu cores       : 4
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
stepping        : 11
microcode       : 0xea
cpu MHz         : 3000.108
cache size      : 6144 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 7
initial apicid  : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass mds swapgs itlb_multihit srbds
bogomips        : 3600.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

Ok, Supernova shouldn’t crash in the first place… Please open an issue on GitHub!

IIRC from Tim’s thesis, supernova maintains a dependency graph to manage the concurrency, and updates this graph whenever nodes are created, destroyed or moved. I have definitely seen crashes when it had been active for awhile and then I created a bunch of new MixerChannels (and destroyed a bunch of old ones) in one go, in the middle of a set (encountered this during rehearsal! so it didn’t die onstage). That’s relevant because it not only creates and removes a lot of groups but also re-sorts the mixers in evaluation order, so it’s issuing a lot of n_after commands – definitely stress on the dependency graph code.

It’s a hard bug to reproduce and I’m pretty sure nothing was ever done about it.

hjh

That’s true.

It’s a hard bug to reproduce and I’m pretty sure nothing was ever done about it.

I think I found the bug report: https://github.com/supercollider/supercollider/issues/1840. Could it be that it really is just about running out of RT memory? Probably supernova can’t handle it gracefully and just crashes. We should definitely fix this…

@lucas What’s your value for memSize? What happens if you set it to some high value?