On Nov 21, 2007, at 5:51 PM, Thomas Grill wrote:

cyrille henry schrieb:

...

could anyone with a macbook pro could test this patch and tell me
the CPU used? does anyone know why the macbook is so slow?

Hi, you could use Shark (Apple's profiler) to have a look what exactly uses up the cpu. greetings, Thomas

Do you have an tips on profiling Pd with Shark? I just noticed that
Pd-0.39.3-extended is using 13-14% of my CPU just having it open. I
just did a quick naive run of Shark, and this is the most striking
thing:

46.7% of the load at idle is in a narrow area, with 33.5% being
caused by "find_user_regs":

46.7% 46.7% mach_kernel ml_set_interrupts_enabled 0.0% 36.5% mach_kernel thread_block_reason 0.0% 36.5% mach_kernel thread_block 0.0% 33.5% mach_kernel semaphore_wait_internal 0.0% 33.5% mach_kernel semaphore_timedwait_signal_trap_internal 0.0% 33.5% mach_kernel semaphore_timedwait_signal_trap 0.0% 33.5% mach_kernel find_user_regs 0.0% 3.0% mach_kernel uiomove 0.0% 3.0% mach_kernel selprocess 0.0% 3.0% mach_kernel select 0.0% 3.0% mach_kernel unix_syscall 0.0% 3.8% mach_kernel thread_invoke 0.0% 3.6% mach_kernel thread_run

It seems that Max/MSP also can have this problem:

http://www.cycling74.com/forums/index.php? t=msg&goto=113971&rid=0&S=5e7272d91a36744f59361372f5753bee

You can see that the Tcl/Tk GUI is not the problem at all. It's a
separate process (MacOS/Pd-extended vs Resources/Scripts/../bin/pd ),
and here it's using 0.0% of the CPU:

hans@palatschinken.local:tkwidgets > ps auxwww | grep '[P]d' %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND 15.0 -0.7 420424 15364 ?? S 1:40PM 0:30.37 /Applications/ Pd-extended.app/Contents/Resources/Scripts/../bin/pd -guiport 5600 0.0 -0.5 372052 10692 ?? S 1:40PM 0:01.58 /Applications/ Pd-extended.app/Contents/MacOS/Pd-extended -psn_0_36438017

As for Tcl/Tk versions, Pd-0.39.3-extended is using something around
8.4.15, while the nightly builds are using basically the newest in
CVS from "core-8-4-branch".

.hc

You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie

lluisgomez@hangar.org a écrit :

S'està citant cyrille henry cyrille.henry@la-kitchen.fr:

...

could anyone with a macbook pro could test this patch and tell me
the CPU used?

you are only interested in macOX performance test or also in linux on
the macbook?

anyway, here using ubuntu-gutsy(x86) and pd-extended the pmpd
example22 takes 26% of one cpu.

(it's an intel Core2 CPU T5600 @ 1.83GHz)

ok. thanks. i've got 22% with a 2Ghz CPU, so this confirm that a macbook pro is about the same hardware as my laptop (also on ubuntu gutsy).

now, i'd like to understand why the same computer on osX is about 2 time slower.

thanks Cyrille

---

This message was sent using IMP, the Internet Messaging Program.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

MBP 2.33, 3GB ram, OS X 10.5.1, also @ 40%

Just for another data point.

:'(

hello, thanks all for your answer. yes, switching to jack improve performance, but it still not as good as in linux (i use oss).

i was able to use this computer for 2 days (it's not mine), so now i can't make more test. i did not have time to install a newer version of tcltk. does pd-extended (nightly build) use standard version of tk, or a better one? (using nightly build did not change anything)

Derek : do you know if this performance problem happend only with pd, or also with other software?

thanks Cyrille

Derek Holzer a écrit :

Hi Cyrille,

cyrille henry wrote:

...

now, i'd like to understand why the same computer on osX is about 2 time slower.

I've been asking myself that for years!!! I have 1.67 GHz PPC G4, and I never use OSX for live work, only Linux. It's true, the exact same patches on OSX are twice as slow on the same computer as on Linux. I've brought this up on the list many times, but the only solutions were to get into compiling against better native versions of some of the supporting software such as Tcl/Tk and X11 instead of relying on the Aqua interface, which adds most of the burden. I don't recall all the things that needed to be done...largely had to do with graphics interface (surprise surprise!)

But I didn't get too far into it. I've moved away from development/testing in the last couple years due to increasingly busy performance schedule. Easier to reboot into Linux and get on with the show! Maybe check the archives and see if it's something you want to get involved with fixing (as was suggested to me when I complained about it).

best, d.

Derek Holzer a écrit :

Hi Cyrille,

cyrille henry wrote:

...

Derek : do you know if this performance problem happend only with pd, or also with other software?

I didn't take a lot of time to benchmark different applications between the two platforms, although I did spend about 3 months (2 years ago) seeing how much stuff from the Linux Audio world was or could be ported to OSX. I use Ardour quite frequently without noticing a big loss of performance from Linux to OSX. But you have to keep in mind how big and bloated the Aqua/OSX desktop manager is!!! I'm sure it can account for a lot of overhead. But I still saw PD running a surprising amount slower than on Linux.

I use JACK almost always on OSX with PD (when I use it on OSX at all), and still the speed is quite poor. I'm fairly positive it has to do with whether Aqua handles the graphical interface or not. All those brushed chrome windows and colorful spinning widgets sure are expensive! Maybe do comparisons with "--nogui"? (Although for GEM patches this wouldn't help much would it?)

But in general, I've lost interest in using up valuable working/performing/recording time in debugging things. I keep a Linux partition on my laptop for PD live sets, sound editing in ReZound and heavy-duty Ardour/Jamin recording/mastering work these days, and do my day-to-day computer business under OS X. That seems like a working solution for me.

Sorry not be more helpful...

this is very helpful : it mean i will not buy a mac for the next years...

thanks Cyrille

best, d.

vade wrote:

Why do you think this? There are plenty of high performance
applications that run just dandy on OS X.

And PD isn't one of them. PD's GUI has always kept one of it's feet permanently nailed to the floor. The problem is just exaggerated on OSX. Previous discussions, back when I still had time to investigate things like this, pointed to Aqua versions of Tcl/Tk as being a possible offender. I tried getting into recompiling PD against different versions of Tcl/Tk, but found it easier to just use the same computer running Linux for high-performance [PD] situations.

Wouldn't it be great if there was a way to pipe all the time people spend rambling about political correctness, beer, philosophy and theoretical physics on this list into solving basic problems like this? <duck!>

d.

helo, you're right, i should update pmpd exemple.

i tried this patch with gem turn off. performance did not really increase. so i don't think openGL was the problem.

thanks Cyrille

chris clepper a écrit :

I suspect it is Apple's subpar OpenGL causing this. Rather than use a ton of sphere objects use [model] and an obj of a sphere. Performance should increase.

On Nov 21, 2007 1:38 PM, cyrille henry cyrille.henry@la-kitchen.fr wrote:

...

hello,

i just made a performance test on osX, using pmpd exemple 22 (i had similar problem with other patch, this is just an exemple)

with pd extended, or pd/Gem and pmpd compiled from cvs, this patch use about 40% CPU on a macbook pro 2.33Ghz.

on my computer (dual core 2Ghz), it use about 22% (in both case, % are mesure for only 1 CPU : both computer are dual core) i did not do any thing special in my computer to optimise compilation, nor in the macbook.

could anyone with a macbook pro could test this patch and tell me the CPU used? does anyone know why the macbook is so slow?

thanks Cyrille

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list