Linked by Thom Holwerda on Tue 12th Oct 2010 21:52 UTC
Java "Oracle and IBM today announced that the companies will collaborate to allow developers and customers to build and innovate based on existing Java investments and the OpenJDK reference implementation. Specifically, the companies will collaborate in the OpenJDK community to develop the leading open source Java environment."
Thread beginning with comment 444917
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Why all the fuss about Java?
by Kebabbert on Wed 13th Oct 2010 16:22 UTC in reply to "Why all the fuss about Java?"
Kebabbert
Member since:
2007-07-27

3. Java is bloated and a memory hog. Well there is no secret about that, if your aim is to develop fast, responsive software, then do not use Java.

These days Java is mainly used for web applications.

Java is extremely fast, and mostly used for backends today. The large servers. Not web anymore. Several of the large Stock Exchange systems are developed in Java. The worlds(?) fastest stock exchange system at NASDAQ is developed in Java.

You obviously dont work with large Enterprise servers with huge demands on performance and latency.

Reply Parent Score: 4

rom508 Member since:
2007-04-20

I obviously (like many others) don't have infinitely deep pockets to run a small cluster of mainframes that Java needs to achieve those levels of performance that you're implying.

But hey, what the hell, these days it's the taxpayer who bails out banks and other financial institutions, no wonder nobody gives a shit how much the IT infrastructure costs (amongst other things...).

Reply Parent Score: 1

Kebabbert Member since:
2007-07-27

I obviously (like many others) don't have infinitely deep pockets to run a small cluster of mainframes that Java needs to achieve those levels of performance that you're implying.

Oh, you are totally off from reality. I suggest you do some heavy catch up.

First of all, the new Stock Exchange systems are all trying to compete and be fastest in the world. The fastest, with the lowest latency, earns most money. There are billions of dollars involved and they want the best and fastest systems. And NASDAQ's are using, not C nor C++, but... Java! They can afford any amount of money or any investment, and they choose Java. Why is that, if Java is so slow? It isn't. Wrong of you.

Second, your example program with hash tables are not relevant for real servers. You have merely done a basic for loop, and try to extrapolate how a big server will perform. That is pure fail logic and wrong.

Third, NASDAQ runs their systems on Linux on x86 servers. Mainframes are DOG SLOW. Yes, they are. Wrong of you, again. Any modern high performant x86 cpu is 5-10 faster than the best IBM Mainframe cpu. Recently, IBM released their newest Z196 cpu, which runs at 5.5GHz and has ~250GB cache (L1 + L2 + L3 + L4) - check the specs. Yes, it is a quarter of a TB in cache!!! Ridiculous. And STILL, it performs as slow as a single core 2GHz Xeon cpu. Now THAT is bad and a waste of GHz and cache.

The Mainframe cpus are dog slow. You would use a Linux cluster on x86 instead. Here are three links:

Here is a source from Microsoft http://www.microsoft.com/presspass/features/2003/sep03/09-15LinuxSt...
"we found that each [z9] mainframe CPU performed 14 percent less work than one [single core] 900 MHz Intel Xeon processor running Windows Server 2003."

The z10 is 50% faster than z9, and the z196 is 50% faster than z10, which means a z196 is 1.5 x 1.5 = 2.25 times faster than a z9. This means a z196 corresponds to 2.25 x 900MHz = 2 GHz Intel Xeon. But todays modern server x86 cpus have 8 cores, which means they have in total 8 cores x 2 GHz = 16 GHz. We see that x86 at 16GHz is plenty faster than z196 at 2GHz. This shows that a z196 is dog slow

Here is another independent source from a famous Linux expert that ported Linux to IBM Mainframe, who says 1MIPS == 4MHz x86.
http://www.mail-archive.com/linux-390@vm.marist.edu/msg18587.html
This shows that a z196 which has 1400 MIPS corresponds to 5,6GHz x86. But a modern x86 has 8 cores, that means it has in total 16GHz, which is 3x faster than 5.6GHz. Again, we see that the Mainframe is dog slow.

Here is another link where the cofounder of TurboHercules says that a 8-way Nehalem-EX gives 3.200 MIPS using software emulation:
http://en.wikipedia.org/wiki/TurboHercules#Performance
But software emulation is 5-10x slower. This means a 8-way Nehalem-EX running native code should be 5-10x faster, that is, 16.000 - 32.000MIPS. This big MIPS number matches a fully equipped z196 mainframe with 64 cpus. Again, we see that the Mainframe is dog slow.

In short, an 8-way Intel Nehalem-EX PC will be as fast as the biggest IBM Mainframe with 64 cpus, in terms of cpu performance. Of course the Mainframe has higher throughput, but the Mainframe latency sucks. No exchange uses Mainframes.

You need to do some heavy catch up.

Reply Parent Score: 2

rom508 Member since:
2007-04-20

This is a follow up on how fast Java is, compared to C. I did a quick benchmark - create hash table, insert 100K integers, lookup all those integers, then remove them from hash table.

One program is Java, using Java's HashMap. Another program is C, using my own hash table implementation. Both test were run on dual Pentium 3 machine, running NetBSD and native openjdk7-1.7.0.92.20100521nb1. Each program was run several times to warm up CPU cache and get average time values.

Java program time:
time /opt/pkg/java/openjdk7/bin/java -hotspot test
0.58 real 0.39 user 0.14 sys

Here is the time for C program:
p3smp$ time ./test.exe
0.08 real 0.05 user 0.02 sys

C program is about 7 times faster than Java.


Below is the source code for both programs:

import java.util.*;
import java.io.*;

public class test
{

public static void main(String args[])
{
/* Create hash table */
HashMap htab = new HashMap(100000, 0.75f);

/* Create array of integer objects */
Integer[] int_obj = new Integer[100000];

for(int i = 0; i < 100000; i++)
int_obj[i] = new Integer(i);

/* Hash table insert */
for(int i = 0; i < 100000; i++)
{
htab.put(int_obj[i], int_obj[i]);
}

/* Hash table lookup */
for(int i = 0; i < 100000; i++)
{
if(htab.get(int_obj[i]) == null)
{
System.out.println("Error: htab.get() returned null");
}
}

/* Hash table remove */
for(int i = 0; i < 100000; i++)
{
htab.remove(int_obj[i]);
}
}
}


#include "htab.h"
#include <stdlib.h>
#include <stdio.h>

int main(void)
{
int i;
uint32_t *int_obj;
htab_t htab;
union htab_key key;
union htab_val val;

/* Create hash table */
if(htab_init(&htab, 100000, 0, 0, 0.75, HTAB_UINT32_CMP, NULL) != 0)
{
printf("Error: line=%d\n", __LINE__);
exit(1);
}

/* Create array of integers */
if((int_obj = malloc(100000 * sizeof(int))) == NULL)
{
printf("Error: line=%d\n", __LINE__);
exit(1);
}

for(i = 0; i < 100000; i++)
int_obj[i] = i;

/* Hash table insert */
for(i = 0; i < 100000; i++)
{
key.uint32_key = int_obj[i];
val.uint32_val = int_obj[i];

if(htab_insert(htab, &key, key.uint32_key, NULL, &val, 0) != 0)
{
printf("Error: line=%d\n", __LINE__);
exit(1);
}
}

/* Hash table lookup */
for(i = 0; i < 100000; i++)
{
key.uint32_key = int_obj[i];

if(htab_lookup(htab, &key, key.uint32_key, NULL, &val) != 0)
{
printf("Error: line=%d\n", __LINE__);
exit(1);
}
}

/* Hash table remove */
for(i = 0; i < 100000; i++)
{
key.uint32_key = int_obj[i];

if(htab_remove(htab, &key, key.uint32_key, NULL, NULL) != 0)
{
printf("Error: line=%d\n", __LINE__);
exit(1);
}
}
}

Reply Parent Score: 1

RshPL Member since:
2009-03-13


C program is about 7 times faster than Java.

I think you should have included a full source code to gain more credibility but I can give you a benefit of the doubt, mainly because the result is in the line of mine opinion (which is 'Java sucks'). You could gain even more speed with C++ templates inline functions and get rid of these pointer dereferences and get a more continuous memory model with more local accesses.

Reply Parent Score: 1

Moochman Member since:
2005-07-06

Oh, well of course if you factor in the time the JRE needs to get started it will be slower. Why not do a test where the user is prompted to press "Enter" and the time to completion is measured programmatically? Would be a heck of a lot more meaningful.

Reply Parent Score: 3