Hi, Miller. I'm glad to see that we're getting there. 

If the same "object-problem" could result in different CPU load differences between .46 and .47 depending on the context they're in, then maybe delwrite~ and/or vd~ alone could explain the ~20% difference I had loading the same patch with the two versions of the software. 

Most of the objects in my project include audio math objects (arithmetic, pow, cos, pow, abs, wrap, samphold), but I doubt that these have changed. I also have quite a few tabwrite~ and tabread4~ objects, how about these ones?

Thanks,
Dario

On 3 August 2016 at 19:47, Miller Puckette <msp@ucsd.edu> wrote:
Aha... I tried again with a patch with lots of vd~/delwrite pairs and got
47 taking about 10% more CPU than 0.46.  (That I didn't get 15 could be that
I had a different mix of objects than yours.)  So something is wrong... I don't
know what yet.  (I did fix a small bug in delay reading/writing that could be
affecting this someho but I can't imagine how :)

M

On Wed, Aug 03, 2016 at 09:17:28AM +0000, Dario Sanfilippo wrote:
> Hi, Miller.
>
> The comparison was between 64bit versions of the software. Like a mentioned
> in another email, there was ~15% higher CPU load (however accurate that
> estimation is) in .47 when running 512 instantiations of a simple patch
> with an [osc~]-driven [vd~] and [delwrite~]. I can try putting together a
> list of the most used objects in my project to narrow down any potential
> problem.
>
> Cheers,
> Dario
>
> On Wed, 3 Aug 2016 at 01:21 Miller Puckette <msp@ucsd.edu> wrote:
>
> > I just loaded a nice fat benchmark patch (based on smeck, the guitar
> > processor) in a few different versions of Pd.  I got no difference between
> > Pd-0.46-7 and pd-0.47-1 ... however, in each version the "64 bit" compile
> > ran in about 85% of the CPU load that the non-64-bit version did.  Perhaps
> > you're comparing 0.46 634 bit with 0.47 32 bit?
> >
> > cheers
> > Miller
> >
> >
> > On Mon, Jun 27, 2016 at 09:19:35AM -0700, Miller Puckette wrote:
> > > Yes, the whole thing is baffling, but I gather something changed from
> > 0.46
> > > to 0.47 ... I've gt a coupld of benchmark patches I can try to see if I
> > can
> > > see what's going on.
> > >
> > > cheers
> > > Miller
> > >
> > > On Mon, Jun 27, 2016 at 12:14:56PM +0200, cyrille henry wrote:
> > > >
> > > >
> > > > Le 27/06/2016 11:58, Dario Sanfilippo a écrit :
> > > > >Hi, Christof.
> > > > >
> > > > >It is a rather large project and relatively new, so I'd prefer not to
> > share it at this point as it still kind of a work in progress. I will try
> > putting together some test patches isolating some of the most used objects
> > and see if there's any significant change in the different PD versions when
> > instantiating many of them.
> > > > >
> > > > >Cyrille: I'm just using PD's Load Meter patch. The test I performed
> > had had just the patch on, without me doing anything. In 0.46-7, the
> > average CPU load when turning DSP on is around 40-50%, with peaks at about
> > 60-70% when acting on the patch. No dropouts experienced. In 0.47, the
> > initial CPU load is around 60% or more and it gets to the point of
> > producing audio dropouts when acting on the patch. So, empirically, 0.47
> > does seem to have a different CPU load.
> > > > >
> > > >
> > > > different cpu load: yes, but since you don't know the cpu frequency,
> > you can't know if it's a higher load, a lower load, and if it's a
> > significative change.
> > > >
> > > >
> > > > >I can see the same behaviour by looking at Activity Monitor on OSX. I
> > wouldn't know how else to measure the CPU load, though.
> > > > i'm afraid it's the same problem with activity monitor.
> > > >
> > > > cheers
> > > > c
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > >Thanks for your help, guys.
> > > > >
> > > > >Dario
> > > > >
> > > > >
> > > > >
> > > > >On 27 June 2016 at 10:00, cyrille henry <ch@chnry.net <mailto:
> > ch@chnry.net>> wrote:
> > > > >
> > > > >    hello,
> > > > >
> > > > >    how are you doing cpu load measurement?
> > > > >
> > > > >    I find it very hard to do reliable measurement of cpu load
> > nowadays, since computer have a variable cpu speed depending on load.
> > > > >
> > > > >    For exemple, pd CPU load can be at 75%, with CPU frequency at
> > 800MHz. When increasing the patch complexities, the CPU frequency increase,
> > and the apparent load reported by pd decrease.
> > > > >
> > > > >    On linux, you can bloc the processor to a fixed frequency, and
> > then make reliable load measurement.
> > > > >    But i don't know how to do than on OSX. Did you find a way?
> > > > >    otherwise, your measurement are useless.
> > > > >
> > > > >    cheers
> > > > >    c
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >    Le 27/06/2016 10:44, christof.ressi@gmx.at <mailto:
> > christof.ressi@gmx.at> a écrit :
> > > > >
> > > > >        Do you want to share your patch? I could test it on my
> > machine with 0.46 and 0.47
> > > > >
> > > > >        -----Ursprüngliche Nachricht-----
> > > > >        Gesendet: Sonntag, 26 Juni 2016 um 13:27:23 Uhr
> > > > >        Von: "Dario Sanfilippo" <sanfilippo.dario@gmail.com <mailto:
> > sanfilippo.dario@gmail.com>>
> > > > >        An: pd-list <pd-list@iem.at <mailto:pd-list@iem.at>>
> > > > >        Betreff: [PD] Experiencing a higher CPU load with 0.47-0 and
> > 0.47-1.
> > > > >        Hi, list.
> > > > >
> > > > >        I'm loading the same patch with 0.46-7, 0.47-0 and 0.47-1 -
> > all 64bit. The
> > > > >        last two have a significantly higher CPU load. I'm on OSX
> > 10.11.5.
> > > > >
> > > > >        Has any of you experienced anything similar?
> > > > >
> > > > >        I haven't changed my [vd~] objects into [delread4~], are they
> > calling the
> > > > >        same piece of code?
> > > > >
> > > > >        The patch is almost exclusively using signal objects, have
> > some of these
> > > > >        been modified in 0.47-0 and 0.47-1?
> > > > >
> > > > >        Thanks for your help.
> > > > >
> > > > >        Dario
> > > > >        _______________________________________________
> > > > >        Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing
> > list
> > > > >        UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> > > > >
> > > > >        _______________________________________________
> > > > >        Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing
> > list
> > > > >        UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >Pd-list@lists.iem.at mailing list
> > > > >UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> > > > >
> > > >
> > > > _______________________________________________
> > > > Pd-list@lists.iem.at mailing list
> > > > UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> > >
> > > _______________________________________________
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> >
> > _______________________________________________
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> >

> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list