Modartt user forum - multicore rendering and performance

Re: multicore rendering and performance

2009-05-19T22:31:37Z

I just added in the same picasaweb album an image of my choice of midi inputs in ptq3.

Re: multicore rendering and performance

2009-05-19T20:27:16Z

Yes I would like to know which midi input is causing that "slow quit" bug, that would be interesting (especially if it is the same midi input for both of you)

Re: multicore rendering and performance

2009-05-19T20:09:45Z

Gilles wrote:

This is probably the origin of the delay, and maybe it exists also on non-AMD cpus if many soundcards are available.
Thanks!

I have an Intel Pentium M 1.86GHz, single core CPU, single soundcard Edirol UA25 and I get the quitting "bug" too. I'll check when I'm at home which MIDI inputs PTQ is set to listen on.

Best//Neil

Re: multicore rendering and performance

2009-05-19T15:21:38Z

Well, Julien, you were right again! If I uncheck all MIDI input devices and play with the included keyboard, the problem goes away. If I use the current MIDI input port correctly, everything is fine.

The thing is I was lazily checking "Listen to all midi input" instead of the current MIDI port I am using (Tascam or Audigy).

This is probably the origin of the delay, and maybe it exists also on non-AMD cpus if many soundcards are available.

Thanks!

Re: multicore rendering and performance

2009-05-19T14:47:41Z

maybe you could try to uncheck all midi devices in the pianoteq options/device panel, and see if it still slow to quit. That would be a good hint. You can also select "none" as the audio output and see if it helps ? If not, then you can try to uncheck multicore rendering ?

Re: multicore rendering and performance

2009-05-19T14:36:25Z

While Julien is in a bug-chasing mood, I would like to recall the curious 5 second delay I get when closing ptq3 (Windows 32 bits) on a double-core AMD. It is a random bug, but it happens I would say 80% of the time. I uploaded a short video on picasaweb to demonstrate this:

http://picasaweb.google.ca/gllsprs/Pian...L8qZCP9gE#

(Please display in high quality on a normal size window for best results)

The reason I mention it is that there were also quitting bugs reported on the Linux version and I thought it might be related.

As far as I can see, my keyboard doesn't issue MIDI events if I don't play.

I get the problem with either of my two soundcards (Tascam US-122 or Creative Audigy 2 ZS) so it is not a driver problem.

I get it also if I disable multi-core rendering and I use the AMD dual-core optimizer.

As soon as I hit the quitting icon, cpu usage goes down and memory is released.

I just don't understand why the GUI takes another 5 seconds to go away.

Is it a threading problem? Or a quirk with JUCE on AMD?

Re: multicore rendering and performance

2009-02-24T15:08:34Z

julien wrote:

as far as I know, it is not an initialization error, but difference between the local clocks of the two cores, they are not synchronized so if the windows scheduler moves the thread from one core to another during the frequency measure, you can obtain any value, even a negative one. It is something the amd prog is supposed to fix (never tried myself , we don't have dual-core amds here)
Maybe should I remove the cpu freq estimation as it is raising many questions for which I don't have definive answers

You were right, Julien! I installed the dual core optimizer and now I the get correct frequency each time. I notice also that there seems to be less parallelism when looking at the task manager graphs, but total cpu usage is the same as before.

Probably, as was already mentioned, multi-core rendering of pianoteq is better with Intel Core 2 duo. Doesn't matter, it sounds great!

I still have the slow shutdown most of the time, maybe other AMD users could confirm if they have the same behavior.

Re: multicore rendering and performance

2009-02-24T11:49:14Z

teamsterjim wrote:

I route hardware effects into my projects because I hate the sound of IR's and see no need to waste CPU cycles on them.

Try RaySpace, it's a realtime modelled space reverb... you can draw your own room and some crazy stuff... I find it realistic and a good companion to Pianoteq. And it's VERY cpu-effective, in contrast to convolution reverbs!

Re: multicore rendering and performance

2009-02-24T11:47:10Z

I am happy to see the polyphony metering where I can hit a single note, then do a short passage and watch as the poly doesn't climb until many notes, and sos or sustain pedals come into play.
With most Piano libraries it is alarming to watch the polyphony sky rocket from the massive amounts of layers that my controller cannot even possibly access.
I have multicore rendering on an E8600 DAW and hardly see a CPU hit.
I have always used Scope DSP cards to avoid being a slave to a CPU.
So most of my CPU cycles go to romplers, Giga and Modartt.
I have played for 2 days, and today I will report back with results of disabling the reverbs, etc.
I route hardware effects into my projects because I hate the sound of IR's and see no need to waste CPU cycles on them.
There's a possibilty I might keep different IR's on the Grand, Upright preset, Rhodes and Wurly though, as they sound pretty good and I can apply a splash of the PCM91 to all of the above while altering their Early reflections and mic placements. They are all on the same channel so this might be necessary.
GigaPulse's Pedal Down IR's were all I ever used before, so I will definately be saving cycles by removing those libraries.
Many developers of gigantic romplers are probably watching Modartt with a cautious eye.
These same developers offer no sostenuto pedal, or a Harmonic pedal,...they need tons of HDD space, lot's of RAM, quad core CPU's, etc.etc.......and here comes the low power laptop masterpiece which has to make them nervous. But then again, many rompler lovers seem to enjoy all of the pictures and dozens of layers that can only be accessed by a sequencer editing pass.
I happen to love all of them, but I will be using P3.0 for my live work, and I finally have a 3rd hand thanks to the sostenuto feature, which the rompler developers don't think is necessary.
That little trade-off choice just might come back to bite them in the arse....

Re: multicore rendering and performance

2009-02-24T10:06:58Z

This CPU frequency reading is not only happening on AMD. I have an Intel E4400 @2.2 GHz and I get various readouts too, as I said in betatest phase. Currently it's on -12000 Hz

Re: multicore rendering and performance

2009-02-24T08:56:39Z

I am not surprised that wine has issues with multicore rendering, this is something that is very demanding on the scheduler, and as wine is just a layer above linux, it is hard to ask it to mimic the windows behaviour. Especially if you are using stuff like wine-asio.

However if you are satisfied with single core perf. I would suggest that you do not lose too much time with multicore !

Re: multicore rendering and performance

2009-02-24T06:33:28Z

hmm, Pianoteq 3 seems to be detecting my processor and max frequency correctly.

i don't think i am going to report a bug in Wine, though, here's why:

My system monitor shows both processors under load when running Pianoteq through Wine with "multicore rendering" option disabled. i think Pianoteq broadcasts a "single processor" signal out to Wine, which then translates it to Linux as a dual processor signal. so my guess is when the option is enabled, it's just doubling the processor load without any real performance. pianoteq locks up very quickly and i have to force quit and restart (i noticed Pianoteq now has crash detection .

so maybe it has "multicore rendering" already without that option enabled by the design of how Wine interfaces with the Linux O/S. Maybe i'm wrong though and there is a bug that could increase performance if fixed...

ethan

PS VERY NICE upgrade to the VST interface!!!! It now responds fully in real-time, which makes it just as usable for tweaking under Linux as the Standalone program!! (previous versions the display did not update correctly in VST mode, so i had to do all sound tweaking in Standalone and then import the fxp to the VST)

Re: multicore rendering and performance

2009-02-23T22:19:05Z

That looks like a good explanation. In fact version 3 doesn't always start on the same core as 2.3 did! Sometimes (rarely) it uses only a single core.

Another AMD quirk I guess...I'll give a try to the Optimizer you mentioned.

Maybe this also explains the slow shutdown.

Thanks!

Re: multicore rendering and performance

2009-02-23T22:12:02Z

as far as I know, it is not an initialization error, but difference between the local clocks of the two cores, they are not synchronized so if the windows scheduler moves the thread from one core to another during the frequency measure, you can obtain any value, even a negative one. It is something the amd prog is supposed to fix (never tried myself , we don't have dual-core amds here)

Maybe should I remove the cpu freq estimation as it is raising many questions for which I don't have definive answers

Re: multicore rendering and performance

2009-02-23T22:03:02Z

Just to add more confusion

Just tried with my desktop PC, a core 2 duo 6600 at 2400 MHz

5 times and always perfect, 2400

Regards