demo: Max vs JS vs Java

Jul 19, 2012 at 2:43pm

demo: Max vs JS vs Java

Hello,

For some time I decided to learn Javascript and Java by myself, with one goal: getting my MaxMSPJitter patches faster.
You probably know how learn for yourself is hard when you don’t have any skills. But many people go this way and I am there, full of questions, because I made 3 version of the same process: max, javascript and java, and my expectations are not met.
On my computer I only get one or two fps better between each version. Today I wonder if I should go to a lower langage such as C or C++ to get better results. My goal is to keep working in Max, but I need good performances.
Any advice would help very much.

Attachments:
  1. MaxvsJSvsJava.zip
#30530
Jul 19, 2012 at 3:17pm

Hi,
With what numbers of particles are you testing? What fps do you get? On my aging macbookpro they all indeed oscillate between 180 and 220fps with 1 particle. With 5000 particles and ‘qmetro 1′ the max version gets 70fps, JS and java both 165fps (with cellblock removed, see below). That’s quite a difference, no?
Btw, I have to set ‘sync 0′ on jit.window to get the full fps.
Also, for large numbers of particles the cellblock is eating framerate. It’s CPU intensive to update all these values every frame. You might wanna remove that for more accurate testing.
Also 1 of your patches uses metro while the other use qmetro. Might behave differently when pushed to the extremes.

Best D.

#97773
Jul 19, 2012 at 3:54pm

Hello,

If you want to learn those languages _only_ to increase performances i’m not sure at all it’s worth it ; i mean if most part of the cpu cost comes from the jitter / openGL part, will you rewrite all that part ?

I think it is always best to profile your code to know what to change and what to improve ; as in your javascript and java you are using jitter objects i’m not really surprise by your benchmark.

My 2 cents.

#97774
Jul 19, 2012 at 4:35pm

Thanks guys.
Indeed the cellblock eats cpu and the sync attributes eats too.
I wonder if I could get even better results including both jit.window and render in the scripts. todo list. :)

#97775
Jul 19, 2012 at 5:00pm

To be complete: sync locks the rendering framerate to the display refresh rate. In my case that’s 60Hz so it will not go above that. Of course it can go slower if the computer can’t keep up.

#97776
Jul 19, 2012 at 8:09pm

interesting topic! i am in the same position as kyred (need better performance for jitter patches).
in my case, i am using js and java mostly for manipulating big amounts of data. for example large arrays of 3d objects attributes. i was wondering is it hard – as nicolas danet said – to get the whole cpu loaded mostly with opengl part (for example generate matrix with well optimised code in java, and send it to jit.gl.multiple). how could we know, if the fps drop is caused by amount of position calculations, or displaying opengl object?
anyway, my personal goal according to my java learning is to write custom externals for kinect, ps3 cameras and so on. thinking of performance, do you think, that java can handle those, leaving the cpu reserve for smooth jitter patching?
thanks for answers, and sorry for little topic hijack kyred!

#97777
Jul 19, 2012 at 10:52pm

I’ve done too little java etc to give an educated answer to this…

Btw, don’t forget about Gen for optimization purposes. I’ve had good results condensing chains of matrix operations into one jit.gen/jit.pix/jit.gl.pix.

#97778

You must be logged in to reply to this topic.