Cycling 74 » Topic: Dual quad core slower rendering than a single i7 ???

Dual quad core slower rendering than a single i7 ???

Parmerud — Mon, 02 Jan 2012 13:18:11 +0000

I am running a jitter patch with some rendering and movie playback on my Mac Pro with dual 2.6 GHz quad core but end up having lower frame rate than on my Macbook Pro with a single 2 GHz i7 processor. Same OS (10.6.8) and same Max version on both machines… Can anyone explain to me what´s going on?

Re: Dual quad core slower rendering than a single i7 ???

timtom — Mon, 02 Jan 2012 15:39:38 +0000

Does your Mac Pro has multiple grafic cards ?
If yes, make sure that your outputting window is rendered by a single gpu and cut one pixel from the width of that output. (using the rect message NOT fullscreen.)

It is a known bug since years.
Perhaps its solved by max6.

Re: Dual quad core slower rendering than a single i7 ???

Parmerud — Mon, 02 Jan 2012 21:40:20 +0000

Nope, just dual output ports….. It´s a mistery’

Re: Dual quad core slower rendering than a single i7 ???

Parmerud — Mon, 02 Jan 2012 21:41:27 +0000

Guess I will have to run some (time consuming) tests

Re: Dual quad core slower rendering than a single i7 ???

vade — Mon, 02 Jan 2012 23:19:56 +0000

This will depend greatly on how your patch is constructed. If you are leveraging any jit.gl. objects, then your GPU may play a larger role in determining framerate than your CPU. If you are using jit.mop (matrix operators), those run on the CPU, and depending on which type of operation, may not be multi-threaded (meaning it will only leverage a single CPU ‘core’).

If you are playing back Quicktime movies, depending on the codec you are decoding, those may or may not be substantially multi-threaded either, meaning some codecs will run better on faster clocked single core systems than systems with multiple CPU’s. Additionally, for playback, your disk subsystem may be a limiting factor if you are playing back uncompressed or high-bitrate video.

Basically, a lot of things can determine your FPS in Jitter, not just system clock speed or number of CPUs.

Do some tests.

Re: Dual quad core slower rendering than a single i7 ???

Augustine Bannatyne - Leudar — Tue, 03 Jan 2012 00:09:04 +0000

It could be that even though you have four processors Max is only taking advantage of one of those processors – say each one of the four is 2.1 ghz it would look like its slower than one 2.5 ghz processor. On pcs theres a setting somewhere where you tell a program how many processors to use – its probably the same on the mac – though Im not sure where this setting can be found.

Re: Dual quad core slower rendering than a single i7 ???

Parmerud — Wed, 04 Jan 2012 20:56:51 +0000

Well, I got the answer straight from C74 and it seems Max is not supporting multiple processors (yet…?) so that´s the reason. The i7 is simply a faster processor.
Thanks for your tips anyway… :)

Re: Dual quad core slower rendering than a single i7 ???

Andrew Pask — Wed, 04 Jan 2012 22:23:21 +0000

Max 6 supports multiple cores or processors. Each top level patch runs in its own thread, which the OS may choose to run on any processor core.

-A

Re: Dual quad core slower rendering than a single i7 ???

antialias — Thu, 05 Jan 2012 02:16:58 +0000

Interesting. Is this in the documentation somewhere?

Re: Dual quad core slower rendering than a single i7 ???

justin bennett — Sun, 08 Jan 2012 02:31:16 +0000

Hi, I am having the same problem actually with a patch playing qt files back on a machine with Dual quad processors. on max 6

> is splitting the patch into multiple top-level patchers the only way to deal with multiple cores ?

> does this mean that the parallelthreads message to Jitter doesn’t have any effect?

> and why on my mac mini does my patch seem to be neatly divided across the 2 processors?

best, Justin.

Re: Dual quad core slower rendering than a single i7 ???

justin bennett — Tue, 31 Jan 2012 15:06:49 +0000

I thought I’d try and “finish off” this hanging thread with some tips. I got my patch working well on dual quad processors in the end.

I was “editing” HD video files on the fly, controlled by an algorithm. Often with two files being played back
at once, with the 2 files being combined into a split-screen “wipe”.

I used Apple ProRes medium codec. Apparently this is more suited to multi-core processors. The files are large but the decompression is quick and can be spread over the CPU’s. as opposed to e.g. h.264 where the files are small but decompression is more difficult for the machine + apparently runs only on a single processor

I used half-size HD 960 x 520 instead of 1920 x 1040. but still at 25 fps because there was a lot
of smooth movement in the shots which I wanted to preserve.

I shifted all the video compositing I was doing onto the GPU by doing it with jit.gl.videoplane and
jit.gl.slab (you have to write a shader program but there are lots of examples to hack!)

and I learnt to CLEAN UP after myself : use unloadram command to force the jit.qt.video players to
free up the memory.

Still the biggest problem was loading the large video files into ram (using loadram). I used loadram for one videostream and asyncread for the other, which spread the load enough to make it run smoothly.

I also put my msp bits all together in a separate top-level patch just in case it would help the CPU but it didn’t
seem to make so much difference.