max / msp and multi processor usage?
hey,
first - apologies, I know I've started maybe a few too man topics here of late.
I was just wondering if max / msp and jitter make use of multicore processors? I'm using 4.6 on a macbook. Does make a benefit from the intel duo core processors?
thanks very much
tom
i haven't tried, but i believe you have to open several instances of max or max runtime.
this way, you can also control what runs on which processor(core).
so i guess one instance of max per processor is what you should do to tapin to your dualcore power.
oh no! not this question again :o)
Seriously though, this has been talked about a bajillion times. Try searching the forum. [mandatory smiley face here]
Sincerely,
Shaqielle O Niel
Although note, as a Intel duo core user myself, users don't get to determine what core is used for what application. The system does this for you. However, programmers can write software to take advantage of the duo core system (not sure what new apps are doing this yet). And finally, so you don't think you are wasting the duo core technolgy, even if you are running only one app, the duo core system still runs it more efficiently than a single core intel...all this from my wife, who works for Intel (this was her product) :)
I use a ThinkPad T60p...duo core, 2ghz X 2, 2gig of RAM. I would be interested in seeing how it runs what some folks on this list consider really processor intensive MAX/MSP patches. I've been able to run a MAX/MSP VST host, running VSTs in it for reverb, chorus, delay, amp simulation, the Mobius looping VST, and two heavy duty VSTs (PSP84 and an bitchin' ensemble from Reaktor that sort of emulates an multi-octave/delay sound of the Eventtide), and never get more than 50% processor utilization.
Kris
Quote: isjtar wrote on Thu, 21 September 2006 13:58
----------------------------------------------------
> i haven't tried, but i believe you have to open several instances of max or max runtime.
> this way, you can also control what runs on which processor(core).
> so i guess one instance of max per processor is what you should do to tapin to your dualcore power.
----------------------------------------------------
You don't get more than 50% processor usage because you have two processors; you may be peaking out on the one which is being used for your process, while the other one is still free for other programs.
No, I don't think this is accurate. First, I was using 50% as an average. Of course, I seen it over this for other applications and use cases; however, unless an app is smart enough to report on the utilization of only one core (which in this case I'm sure it isn't...and the XP machine can't even do this to my knowledge, so I'm not sure why an app would), the percentage of utilization you see on your app of a duo core machine is a sum processor utilization of the two cores. These duo core machiens arn't that sophisticed. They are primarily designed for end users and commerical business, not enginners in a lab running HP UNIX machines under their desks with multiple processors, etc.
Kris
Quote: Dayton wrote on Sun, 24 September 2006 01:57
----------------------------------------------------
> You don't get more than 50% processor usage because you have two processors; you may be peaking out on the one which is being used for your process, while the other one is still free for other programs.
----------------------------------------------------
Sorry, it's too early in the morning, with no coffee. I meant to say average below, not sum. Beyond this, I would have to talk to someone in Intel to get the details. It stands to reason, moreover, that if you can report onn two cores, you would see two meters, not one - especially for an app not designed to take advantage of all the features of a duo core. And you don't get to peek into the utilization of only one...it's not that black and white. From what I've been told, the core allocation is much more complicated than this, and both cores would likely be utilized continuously...as you have other things besides the app tapping into them, such as the OS itself.
It may be a good thing XP didn't allow people to see to processor utilization meters...I can imagine all the techy, computer nerd controversy that it would have generated from people watching them obsessively after they run certain apps, getting worried about whether they is allocating efficiently, etc.
...back to my coffee.
Kris
Quote: info@krispenhartung.com wrote on Sun, 24 September 2006 07:07
----------------------------------------------------
> No, I don't think this is accurate. First, I was using 50% as an average. Of course, I seen it over this for other applications and use cases; however, unless an app is smart enough to report on the utilization of only one core (which in this case I'm sure it isn't...and the XP machine can't even do this to my knowledge, so I'm not sure why an app would), the percentage of utilization you see on your app of a duo core machine is a sum processor utilization of the two cores. These duo core machiens arn't that sophisticed. They are primarily designed for end users and commerical business, not enginners in a lab running HP UNIX machines under their desks with multiple processors, etc.
>
> Kris
>
>
>
> Quote: Dayton wrote on Sun, 24 September 2006 01:57
> ----------------------------------------------------
> > You don't get more than 50% processor usage because you have two processors; you may be peaking out on the one which is being used for your process, while the other one is still free for other programs.
> ----------------------------------------------------
>
>
----------------------------------------------------
So, Tom, bringing this back to MAX/MSP, I'm still curious how our duo core systems will fair with some of the more intense patches out there, because even though MAX/MSP isn't written to take advantage of all the architecture of the duo core system, the system does run more efficiently than a single core, simply because it is doing other processor allocations for system tasks, etc....the net result is better performance because both processors are running at once.
Right now the only way for me to push the limits of my system to keep activating VST plugins until I reach 100% processor utilization, which is an unrealistic application. I would never run that many effects in a live performance setting. I have heard of some very intense patches written by MAX users on this list, so for those willing to share, I'd love to put my system through the acid test.
Although, just a few months ago Intel released its duo core 2 system for notebooks which run 40% more efficient than the duo cores...just when I thought I had it good.
K-
Quote: Tom Haig wrote on Thu, 21 September 2006 04:08
----------------------------------------------------
> hey,
> first - apologies, I know I've started maybe a few too man topics here of late.
> I was just wondering if max / msp and jitter make use of multicore processors? I'm using 4.6 on a macbook. Does make a benefit from the intel duo core processors?
> thanks very much
> tom
----------------------------------------------------
hey krispenhartung- sounds like you and you know your stuff about intel chips!
'Although, just a few months ago Intel released its duo core 2 system for notebooks which run 40% more efficient than the duo cores...just when I thought I had it good. '
-yeah it's easy to get into sucked into chasing tech! I just try to bear in mind that some of my favorite albums were made on a G3 powerbook. Any modern machine is a complete luxury compared to the computers of that era!
My macbook, in terms of processor memory numbers is the same as yours, so it's good to know it can handle a decent amount of plugins. I'm hoping to ultimately make and use patches that incorporate jitter too. I hope she'll be up for it. No dedicated graphics card in my macbook- will that be an issue? Judging by what 'isjtar' said, it might be an easier ride if the jitter patch runs in a seperate instance of max?
Thanks for the knowledge!
tom
If you have an Intel duo core, 2ghz, 2gig of RAM mac let's definitely compare performance notes off line. I am thinking of buying a mac in the future, despite being a PC user for 18 years now. Perhaps we can find some monster MAX/MSP patch out there and compare how our systems do with it? Any suggestions? We can start with just a basic patch for comparison.
My personal email is info@krispenhartung.com Send me a note so we can get started. :)
Kris
Quote: Tom Haig wrote on Sun, 24 September 2006 13:42
----------------------------------------------------
> hey krispenhartung- sounds like you and you know your stuff about intel chips!
>
> 'Although, just a few months ago Intel released its duo core 2 system for notebooks which run 40% more efficient than the duo cores...just when I thought I had it good. '
>
> -yeah it's easy to get into sucked into chasing tech! I just try to bear in mind that some of my favorite albums were made on a G3 powerbook. Any modern machine is a complete luxury compared to the computers of that era!
>
> My macbook, in terms of processor memory numbers is the same as yours, so it's good to know it can handle a decent amount of plugins. I'm hoping to ultimately make and use patches that incorporate jitter too. I hope she'll be up for it. No dedicated graphics card in my macbook- will that be an issue? Judging by what 'isjtar' said, it might be an easier ride if the jitter patch runs in a seperate instance of max?
>
> Thanks for the knowledge!
>
> tom
----------------------------------------------------
Since you started the thread, I began finally looking into both the theory and the practice behind using dual-core systems. There are great discrepancies between performance depending on how a program has been written. As an example, the program "Resolume"; it will use 100% of your CPU if you have a single processor, and only 50% if you do the same thing on a dual-core system. I had misinterpreted the reason; the program is, indeed, using both cores, but because it was written for a single-processor arrangement, it does reach a the limit posed by one processor although the work is then divided by the OS.
As this applies to Max/MSP I believe that it is similar; the program is not written to utilize a dual-core system (I would love it if someone will tell me I am wrong; I will be buying a new computer soon...) Jitter, on the other hand, is. Have a look at this mail:
Anyway, I have to keep looking into this.
It was explained many times in this list, there is a way to use the second cpu, you have to
seperate your process into several apps that can talk one to the other thru internal midi or any
network protocol. for instance one patch in max and the other in runtime, or two stand-alone app
and even four if you have a quad G5 or XEON desktop.
and it's wrong that jitter is optimised for multi-core use, only some of its externals are.
hope this make things clearer for you.
and to the people of cycling, as multi-core based coputers begin to be the norm, maybe it might be
usefull to add a note on this in max doc.
//yac
>
> Since you started the thread, I began finally looking into both the theory and the practice behind
> using dual-core systems. There are great discrepancies between performance depending on how a
> program has been written. As an example, the program "Resolume"; it will use 100% of your CPU if
> you have a single processor, and only 50% if you do the same thing on a dual-core system. I had
> misinterpreted the reason; the program is, indeed, using both cores, but because it was written
> for a single-processor arrangement, it does reach a the limit posed by one processor although the
> work is then divided by the OS.
> As this applies to Max/MSP I believe that it is similar; the program is not written to utilize a
> dual-core system (I would love it if someone will tell me I am wrong; I will be buying a new
> computer soon...) Jitter, on the other hand, is. Have a look at this mail:
>
> https://cycling74.com/forums/index.php?t=msg&goto=77958&rid=0&srch=dual+core#msg_77958
>
> Anyway, I have to keep looking into this.
>
>
>
>
> Jitter, on the other hand, is. Have a look at this mail:
>
Jitter is, but only partially. Have a look at this thread:
Mattijs
Oops, we linked to the same thread. Well then, the thread discusses the problem that this part of jitter is Not multithreaded.
This makes sense, Dayton. Though to answer your question, I would find it surprising if Cycling 74 had already modified MAX/MSP or any of their other products to take advantage of the intel duo core chipset (would like this confirmed, however). Not many software companies have done this yet, to my knowledge...though if Cycling 74 did, it would be absolutely delightful and cutting edge. It would be nice to hear a statement from Cycling 74 on what their plans are in this regard. Given the flexibility of MAX/MSP, to create some really intense processor hogging programs, having that extra bit of efficiency would be ideal, rather than relying on the duo core's default way of allocating resources to the two cores.
Kris
Quote: Dayton wrote on Mon, 25 September 2006 06:25
----------------------------------------------------
> Since you started the thread, I began finally looking into both the theory and the practice behind using dual-core systems. There are great discrepancies between performance depending on how a program has been written. As an example, the program "Resolume"; it will use 100% of your CPU if you have a single processor, and only 50% if you do the same thing on a dual-core system. I had misinterpreted the reason; the program is, indeed, using both cores, but because it was written for a single-processor arrangement, it does reach a the limit posed by one processor although the work is then divided by the OS.
> As this applies to Max/MSP I believe that it is similar; the program is not written to utilize a dual-core system (I would love it if someone will tell me I am wrong; I will be buying a new computer soon...) Jitter, on the other hand, is. Have a look at this mail:
>
> https://cycling74.com/forums/index.php?t=msg&goto=77958&rid=0&srch=dual+core#msg_77958
>
> Anyway, I have to keep looking into this.
>
>
>
----------------------------------------------------