Closed for Company Meetings: Between September 18 (5pm PDT) and September 22 (12pm PDT), Support and Sales requests will be delayed. Only time-sensitive issues will be addressed during that time. Thanks for your patience.
Wild Allegations
Jun 11 2010 | 8:05 am
Hello!
From what I’ve read, and from my own tests, I believe the following to be true. Would anyone care to confirm, amend, or refute these statements?
Max/MSP/Jitter only takes advantage of multi-threading if you use the poly~ object.
Poly~ only multithreads audio; running Jitter objects in the poly~ object does not improve performance.
If you open and run two instances of a program, they will still run on the same core (unless you are using poly~).
Jitter only takes advantage of a fancy graphics card if you directly invoke it using the jit.gl objects.
Max is a 32-bit application; running it on a 64-bit machine has no impact on performance.
As a 32-bit application, Max can only utilize 3 GB of RAM.
Given all of this, for Jitter-intensive projects, it's better to go for a higher speed dual core (e.g. Intel Core i5 3.46 GHz) than a quad core machine with a lower clock rate (e.g., i7 3.06 GHz).
It’s probably still good to go for a 64-bit OS with 4 gigs of RAM, to let Max use all it can and still have extra room for OS overhead.
Unless you’re doing sophisticated shader stuff with jit.gl, it doesn’t really matter what video card you use; any basic video card will do.
Thanks for any comments, corrections, clarifications, or suggestions!
-Ben.
- Jun 11 2010 | 10:54 ami was under the impression that jitter objects are optimised for multi-core threading... but i may be wrongvideo cards do make a difference as the intel GMA ones share RAM with motherboard, so it would be best to have a fully independent graphics card (preferably with lots of RAM) to get a better FPS rate.i know its still on the horizon, but open CL may be beneficial in the not too distant future.
- Jun 14 2010 | 6:02 pmyes, poly~ only multithreads audio, and only when you tell it to.two instances of max (either by duplicating the max app or the max runtime, or creating separate standalone apps) will run on whatever cores the OS tells them to, ie, they can run on separate cores.any jitter work where graphical performance is one of your primary concerns, should utilize opengl, and therefore would benefit from a fast GPU.max is 32 bit, and i believe that means it can utilize 2GB or RAMit depends on the application. if you are able to split up processing tasks (eg, if you have a lot of audio processing and jitter processing), then 4 cores could very well be utilized fully. if you are just using a single app to perform jitter CPU calculations, then probably a faster dual-core would be better.if you haven't already, take a look at the event priority article: https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/
- Jun 15 2010 | 12:14 pmGreat article, thanks Rob for the pointer and thanks to jkc for the clear explanations.Wondering if there are more recent developments along these lines? Would be nice to know if there have been significant changes with how the threading etc. operates.
- Jun 21 2010 | 6:35 amHey Rob, thanks for the article. I am really curious: does anyone here knows how max is handling multi-core architecture?. A gpgpu implementation would be great, is Cycling planning to bridge cuda or openCL with jitter?
