Performance differences between Windows & Mac OS Jit/Java
This is a follow-up of sorts to my previous query about TCP & Java.
We (John Dekron and I) have a Jitter/Java based standalone which is supposed to run on a Mac Pro. The basic processing consist of jit.scissor-ing a 360x50 matrix into 8 parts, each of which is then sent by TCP to a custom wall-sized display using a custom TCP-based protocol. The app runs well enough when we only send a single portion of the matrix, but the CPU demand is pretty high. By the time we use all 8 TCP connections, our standalone is using 100% of its processor's capacity and we're down to about 9fps.
The thing is, if we boot the same machine into XP via Boot Camp, the Windows version of our standalone can handle about 20fps and Task Manager says it's using about 80% of CPU capacity (am I right in my understanding that Task Manager is talking total machine capacity, ie 40% of a single core?).
In any case, we've got identical hardware, identical Java code, identical Jitter patch. So where does the performance difference come from? Are the JVMs so different? The TCP/IP implementations? Something else? My experience in Max/Jitter is that the OS doesn't make a big performance difference given identical hardware.
I'm attaching the .java & .class files if someone would care to look (Ben?). I know that I'm instantiating an InputStream that I don't really need (there was a lot of Copy&Paste to get this working at all) but I don't think that can be slowing things down. I'm wondering if there's anything I can do in my jit_matrix() method to speed up copying the Jitter data into our TCP packet data structure. The other obvious bottleneck is DataOutputStream.write(), but what can one do to speed that up?
If a test patch would help I'll cobble something together. The biggest problem in testing is that currently the only test hardware on the planet exists in a village outside Leipzig and is inside an intranet. Not an ideal testing environment? Tell me about it-(
Finally, before someone asks "Why not just use Windows?" the computer needs to run other processes as well as our standalone, and Mac OS is really what we need.
Thanks for suggestions.
On Jan 22, 2008, at 5:55 AM, Peter Castine wrote:
> Finally, before someone asks "Why not just use Windows?" the
> computer needs to run other processes as well as our standalone,
> and Mac OS is really what we need.
Perhaps you can use VMWare or Parallels? i.e. run Windows under OS X.
I don't have time to investigate your patch/code, but the JVMs are
different. There may be some JVM settings which are by default used
on windows, but not OS X, or vice versa.
One other thing. Make sure you are not stalling in the main thread
while you don't need to be. One example is to copy your matrix to
send, add it to a queue which is serviced by your networking thread
(I assume you're using a separate thread for networking, which is
*essential*).
-Joshua
Just to add.
Historically the JVM implementation for windows has always been
higher performance than the OS X JVM so it is not so surprising.
Like josh said though some sort of queing mechanism might be worth
investigating regardless.
T
On Jan 22, 2008, at 08:48 AM, Joshua Kit Clayton wrote:
>
> On Jan 22, 2008, at 5:55 AM, Peter Castine wrote:
>
>> Finally, before someone asks "Why not just use Windows?" the
>> computer needs to run other processes as well as our standalone,
>> and Mac OS is really what we need.
>
> Perhaps you can use VMWare or Parallels? i.e. run Windows under OS X.
>
> I don't have time to investigate your patch/code, but the JVMs are
> different. There may be some JVM settings which are by default used
> on windows, but not OS X, or vice versa.
>
> One other thing. Make sure you are not stalling in the main thread
> while you don't need to be. One example is to copy your matrix to
> send, add it to a queue which is serviced by your networking thread
> (I assume you're using a separate thread for networking, which is
> *essential*).
>
> -Joshua
Thanks, guys, for the feedback.
Some examination last night turned up another bottleneck... I was using the very convenient JitterMatrix.getcell2dInt(), but the copyMatrixToArray() methods appear to be a lot more efficient. After thinking about it a bit I'm feeling a little stoopid for having chosen the cell-by-cell approach at all, but just based on the docs it's not immediately obvious that the one approach would be more efficient than the other.
-- P.