Re: [Csnd-dev] [EXTERNAL] Re: [Csnd-dev] Parallel Csound performance

I'd be careful about it running fast but incorrectly. That's always
been my concern with ParCS is correctness.

On Wed, Oct 29, 2025 at 6:22 PM Victor Lazzarini
<[email protected]> wrote:
>
> No, I don't think we ever disabled it. There were some questions about re-enabling some analysis to the parser (which existed in parser 2) but beyond that we never touched it.
>
> I continued to build with it but had not been actively testing the code. I am surprised at how well it run without any changes.
>
> best
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 29 Oct 2025, at 22:14, Steven Yi <[email protected]> wrote:
> >
> > *Warning*
> >
> > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> >
> > This is odd, as I thought cspar was disabled in Csound?
> >
> >> On Wed, Oct 29, 2025 at 6:08 PM Victor Lazzarini
> >> <[email protected]> wrote:
> >>
> >> I’m back investigating parallel Csound performance and it was interesting to see that
> >> Csound 7 is working well with it, in fact far better than 6.18.
> >>
> >> Running 1000 oscillator instrs for 60 secs I got these stats
> >>
> >> ksmps = 100
> >> -----------
> >> single thread: 3.9s
> >> 8 threads: 3.9s
> >>
> >> ksmps = 150
> >> ----------
> >> single thread: 3.5s
> >> 8 threads: 2.7s
> >>
> >> ksmps = 300
> >> ----------
> >> single thread: 3.2s
> >> 8 threads: 1.6s
> >>
> >> ksmps = 500
> >> ----------
> >> single thread: 3.2s
> >> 8 threads: 1.2s
> >>
> >> ksmps = 1000
> >> ----------
> >> single thread: 3.3s
> >> 8 threads: 0.8
> >>
> >> In comparison with 6.18 the last test ran at 11secs for 8 threads. In fact, 6.18 was always slower in parallel
> >> performance. Something was very broken there. Single-threaded performance is on a par with Csound 7.
> >>
> >> I can only think the new parser is working better with the parallel dispatch, or that something else was wrong
> >> in the 6.x and got fixed in 7. Anyway, I am pleased with these results. In general, ksmps=100 seems to be the break even
> >> point, below that multi-threaded performance is always losing. Also ksmps=1000 is more or less the highest gain,
> >> with diminishing returns after that. In my computer, 8 threads seem to be the optimal.
> >>
> >> best
> >> ========================
> >> Prof. Victor Lazzarini
> >> Maynooth University
> >> Ireland
> >>
> >>
> >>
> >>
> >>
> >>