Ben Houge

I'm a bit stumped. I've got a screaming new PC running a fairly demanding Jitter patch. According to the performance stats, the computer is operating well below capacity, but the patch still runs below the desired frame rate.

I'm currently using 1 of 4 GB of RAM, and CPU usage averages around 18%, peaking at 20%.

I can't figure out why the thing is running slower than designed, with all of these resources available. Seems like it should be using more of both CPU and memory. Does Windows 7 somehow cap resources available to individual programs?

The program's basically doing a lot of moving small pictures around (srcdim, dstdim), pulling images from a movie file (encoded using PNG for alpha channel, found JPEG 2000 too slow), randomly choosing frames, plus some feedback. I'm not explicitly calling the GPU, but with a machine like this, seems like I shouldn't have to (though if anyone's got a shader to do the srcdim/dstdim stuff, I'd look into it).

I suspect the movie decompression is what's taking the biggest hit, but just a guess.

I'm a bit stumped.  I've got a screaming new PC running a fairly demanding Jitter patch.  According to the performance stats, the computer is operating well below capacity, but the patch still runs below the desired frame rate.

Specs:
Intel i7 930 @ 2.8 GHz
4GB RAM
Windows 7 64 bit
NVIDIA GeForce GTS 250

I can't figure out why the thing is running slower than designed, with all of these resources available.  Seems like it should be using more of both CPU and memory.  Does Windows 7 somehow cap resources available to individual programs?

The program's basically doing a lot of moving small pictures around (srcdim, dstdim), pulling images from a movie file (encoded using PNG for alpha channel, found JPEG 2000 too slow), randomly choosing frames, plus some feedback.  I'm not explicitly calling the GPU, but with a machine like this, seems like I shouldn't have to (though if anyone's got a shader to do the srcdim/dstdim stuff, I'd look into it).

firing-on-all-cylinders-on-an-i7

I really have no idea so don't take my word but I believe Max/Jitter isn't yet capable of using multiple cores? So with your 4 cores it is only using one..but I could be a huge idiot

Also..the rota shader should do what you need in terms of moving things and scaling them..gpu stuff is awesome

As far as i know the only way to gain access to multiple cores is with the use of poly. For now i would recommend to move as much as you can to the GPU.

As far as i know the only way to gain access to multiple cores is with the use of poly.

That is only the case for MSP. To take advantage of multiple cores, you need to have multiple threads that can run in parallel. For Max--unless you are making your own multithreaded externals, you can run up to two threads when running in overdrive. There is one main MSP thread, but you can spawn others using [poly~] like efe says. Jitter has a parallel processing option that is on by default and by default uses the same number of threads as cores in your computer. I'm no Jitter expert, but I imagine some patches can take better advantage of parallel processing than others as in general, some types of processes/loops are parallizable and others are not (if someone with more knowledge of parallel processing in Jitter or the Jitter SDK has some more info to share on this I'd love to hear it).

Like I said, I'm no Jitter expert, but it sounds like the framerate issue is either with the video decoding, or reading the video from hard disk (hard disk speed can be a big bottle neck this days compared to processor or RAM speed). If you are choosing random frames for your movie, I'd try using the message to [jit.qt.movie]. I think there are some threads on this forum and blogposts out there about optimizing Jitter performance so you may want to look for one of those resources as well.

That is only the case for MSP.  To take advantage of multiple cores, you need to have multiple threads that can run in parallel.  For Max--unless you are making your own multithreaded externals, you can run up to two threads when running in overdrive.  There is one main MSP thread, but you can spawn others using [poly~] like efe says.  Jitter has a parallel processing option that is on by default and by default uses the same number of threads as cores in your computer.  I'm no Jitter expert, but I imagine some patches can take better advantage of parallel processing than others as in general, some types of processes/loops are parallizable and others are not (if someone with more knowledge of parallel processing in Jitter or the Jitter SDK has some more info to share on this I'd love to hear it).

Like I said, I'm no Jitter expert, but it sounds like the framerate issue is either with the video decoding, or reading the video from hard disk (hard disk speed can be a big bottle neck this days compared to processor or RAM speed).  If you are choosing random frames for your movie, I'd try using the  message to [jit.qt.movie].  I think there are some threads on this forum and blogposts out there about optimizing Jitter performance so you may want to look for one of those resources as well.


Thanks for all the help, great suggestions!

An important thing I should have mentioned: when I run the same patch on my dual core laptop (P9700 @ 2.8 GHz, 4GB RAM, Vista 64 bit), it uses 2 GB of RAM, but on the i7, it’s only 1 GB, which is why I was thinking there might be some kind of cap. Or I guess it’s possible that Vista actually uses an extra GB of RAM over Windows 7?

My patch doesn’t have any sound, only video, and I remember reading that Jitter would use all available cores, but as Roth points out, some processes are probably more parallelizable than others. But, yeah, it was a bit of a leap of faith to get this machine, as I didn’t really know what to expect! What I notice in the performance stats is that one thread is running around 50% (the Max thread, I guess), while the others are chugging around 15%. It tells me the overall CPU usage is only about 20%. By comparison, on my laptop the same program averages 60% of the CPU (at a little over 1/2 the framerate).

To optimize, I’ve taken the frames from the movie (there are only 49) and loaded them all into individual matrices in memory, so I don’t have to hit the disk for anything, and there’s no decompression on the fly. This didn’t seem to impact my frame rate much, but it runs more smoothly now; before I would get little jerks from time to time, which I assume were coinciding with decompressing a new frame.

An important thing I should have mentioned: when I run the same patch on my dual core laptop (P9700 @ 2.8 GHz, 4GB RAM, Vista 64 bit), it uses 2 GB of RAM, but on the i7, it’s only 1 GB, which is why I was thinking there might be some kind of cap.  Or I guess it’s possible that Vista actually uses an extra GB of RAM over Windows 7?

My patch doesn’t have any sound, only video, and I remember reading that Jitter would use all available cores, but as Roth points out, some processes are probably more parallelizable than others.  But, yeah, it was a bit of a leap of faith to get this machine, as I didn’t really know what to expect!  What I notice in the performance stats is that one thread is running around 50% (the Max thread, I guess), while the others are chugging around 15%.  It tells me the overall CPU usage is only about 20%.  By comparison, on my laptop the same program averages 60% of the CPU (at a little over 1/2 the framerate).

To optimize, I’ve taken the frames from the movie (there are only 49) and loaded them all into individual matrices in memory, so I don’t have to hit the disk for anything, and there’s no decompression on the fly.  This didn’t seem to impact my frame rate much, but it runs more smoothly now; before I would get little jerks from time to time, which I assume were coinciding with decompressing a new frame.

Firing on all cylinders on an i7