ARM: Intel Has An Uphill Climb Ahead

[palladin9479]

As I've said, we've received a 50~200% performance increase from moving away from Java. Java as a language is horrible for performance, no amount of tweaking seems to fix it. Its a lot more then just the JIT, the whole JVM idea is that spawns a new process and grabs memory then runs the JAR inside that memory space. What we've noticed is that Java isn't very memory efficient and you need to grab a space significantly larger then what your program ~could~ use.

Each system has about a dozen core process's that need to run, their basically control daemons. Each daemon reads a configuration file and spawns a process that corresponds to the entries for channels and connections and so forth. This is a complicated system and you end up with 40 ~60 javavm's running simultaneously all doing a ton of encoding / decoding work. The system is a SUN T5220, running an insane number of process's is what this system is designed to do.

The javavm instances consume too much memory and are very inefficient for code execution. By recoding and running straight on binary we saved a ton of performance and allowed us to scale higher.

Java is a great language for university's or some web applications, but for core process's and daemons it absolutely sucks.

 

[duzcizgi]

As I've said, we've received a 50~200% performance increase from moving away from Java. Java as a language is horrible for performance, no amount of tweaking seems to fix it. Its a lot more then just the JIT, the whole JVM idea is that spawns a new process and grabs memory then runs the JAR inside that memory space. What we've noticed is that Java isn't very memory efficient and you need to grab a space significantly larger then what your program ~could~ use.

Each system has about a dozen core process's that need to run, their basically control daemons. Each daemon reads a configuration file and spawns a process that corresponds to the entries for channels and connections and so forth. This is a complicated system and you end up with 40 ~60 javavm's running simultaneously all doing a ton of encoding / decoding work. The system is a SUN T5220, running an insane number of process's is what this system is designed to do.

The javavm instances consume too much memory and are very inefficient for code execution. By recoding and running straight on binary we saved a ton of performance and allowed us to scale higher.

Java is a great language for university's or some web applications, but for core process's and daemons it absolutely sucks.

Although I deal with Java programs or systems written in Java very often I am not myself a Java programmer. I am a C# programmer.

I agree with you that JVM tends to use up a lot of memory. It can be tweaked but to some extent only.
The main reason for JVM to use a lot of memory is the fact that many Java programmers do not have understanding of the underlying hardware and as garbage collection is granted, they write inefficient code. During your convertion to C, you must have seen tons of inefficient code that would hog both CPU & memory, regardless of the language used.

I can be more specific regarding CLR of Microsoft, though.
CLR is also a JITed environment. With CLR, the JIT is a one time process. There is even a port of Doom 3 to C++/CLR running totally within virtual machine and it runs only 10% slower than the original native C++ version.

The reason that CLR apps running much faster is mainly MS spent a lot of effort in training programmers.

Anyway, it's getting off-topic here. MS is quite ready to switch the platforms any time. They have a CLR implementation on ARM already and nearly all UI of Win7 is already ported to CLR.

 

[palladin9479]

I believe our issue isn't that we have one, two or even three but 40+ javavm instances per server all expected to communicate within themselves as well as many other systems. It wasn't the source code, although Lockeed Martin did write the original code so lots of cleanup had to happen. I'm not a coder myself, I manager the implementation on the target Sun Sparc's, more of a OS / HW position then an application one. Using dtrace and other hooking methods we saw the jvm's just being inefficient with resources. It really seems that the jvm wasn't designed to be run with as many instances as sub process's as we do.

In reference to the topic, as long as MS implements it properly there isn't anything wrong with JIT dynamic recompilation. It'll always be less efficient then native code due to the coders not being able to take advantage of the different quirks of each platform. But in general if their careful is should work, I'm really looking forward to see Windows NT on an Arm. Always thought the would make a killing if they built it for Sparc.

 

[duzcizgi]

I believe our issue isn't that we have one, two or even three but 40+ javavm instances per server all expected to communicate within themselves as well as many other systems. It wasn't the source code, although Lockeed Martin did write the original code so lots of cleanup had to happen. I'm not a coder myself, I manager the implementation on the target Sun Sparc's, more of a OS / HW position then an application one. Using dtrace and other hooking methods we saw the jvm's just being inefficient with resources. It really seems that the jvm wasn't designed to be run with as many instances as sub process's as we do.

In reference to the topic, as long as MS implements it properly there isn't anything wrong with JIT dynamic recompilation. It'll always be less efficient then native code due to the coders not being able to take advantage of the different quirks of each platform. But in general if their careful is should work, I'm really looking forward to see Windows NT on an Arm. Always thought the would make a killing if they built it for Sparc.

Worked with SPARCs in the past. Telco companies use SPARC systems extensively.
40+ jvm processes doing IPC would kill any system. - Actually 40+ processes, be it jit or native doing IPC all the time is enough to bring any system on its knees. You need to consolidate your processes and reduce the chat that they are doing.

On the long run JIT systems tend to work more efficiently than hand optimized native code. - By analyzing the code path taken most, JITter can choose more optimized paths depending on the data structures presented or workload shifts among parts of the application.

Windows on SPARC is a dream, I'm afraid. - The Windows kernel is not very good at high throughput/high thread count type of works.

 

[palladin9479]

Well the super heavy process load is the reason we went with the T5220 series for our box's. We're also using T6000 chaises with T6340's inside. Sun's idea with the T2+ and now the T3 CPU's was pure genius, a single socket clocked @1.6~2.0Ghz but with 8 cores (16 for T3) each having 2 integer units, 1 FPU, 1 MMU and 8 register stacks. Extremely good for multiprocessing.

Well we're not using a standardized "IPC" method of communicating from one process to another but rather a set of sockets and files. Its a really archaic piece of defense software. Really just goes to show that different processing requirements favor different languages / methods.