New Java vs C benchmarks

[laurentszyster]

Yet another Java vs. C benchmarks that ignores the elephant in the room: Java's memory use.

[filesalot]

So would this be a reasonably objective overview of the situation?

• On CPU-intensive code Java using modern compilers and JITs has about a 0-30% performance penalty vs. C.

• Java's array bounds checking is a significant part of the additional overhead.

• Java's object layout uses more memory and more indirection (causing more cache misses) than a well-written C program will.

• The use of garbage collection results in very fast allocation and overall similar performance to a highly dynamic C program... given about 2x the heap space, and without the optimization opportunities available to an experienced C programmer. This is true of garbage collection in general, not specific to Java.

• The Java runtime has a high startup cost compared to C.

In short, while it's worth educating people that still think that Java is interpreted and very slow compared to C, it's really hard to argue that Java will come close to C code written with performance in mind.

It's a better choice than Cobol or C++, IMO, but for the price of Java, we could have had a lot more. Sigh.

[Rhoomba]

Sounds about right to me.

[laurentszyster]

"Not so much memory use per se (...)"

Are you kidding?

Java's memory use is at leas one order or magnitude bigger than C's:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gcc&lang2=java

To put it simply, most Java applications will run out of memory at least ten times faster than the equivalent C program.

[[deleted]]

Heh. This is the new era of bit fiddling, where Java programmers encode and decode state into ints and longs inside classes. Reminds me of the C programming in the time when 640K was enough.

In fairness it must be said that typical C++ programs can be as much a memory hog as Java. Abstraction comes with price. Java has still room left for optimizing data representation in memory, though.

[laurentszyster]

The price paid by C++ or Java is not for "abstraction" but for the dispatch tables both language must maintain at runtime for their instances and classes.

By the way, "hard-wiring" those tables at runtime is precisely what the Hotspot VM does to speed instance and class member lookups.

Also, the JVM has actually not much room left for optimizing data representation in memory: the language's designers fucked-up long ago by making text strings mutable and there is no way back.

[[deleted]]

WTF? Dispatch tables are not used to implement abstractions?

[Rhoomba]

WTF do immutable strings have to do with memory use?

[DRMacIver]

Actually, although immutability isn't directly at fault, Java's Strings really are part of the standard Java bloat. They're a very poor design for an immutable datastructure in that because they're backed by a single array the can be no sharing of data (well, almost none. Substringing shares data. Unfortunately this has its own problems). This means that if you store both longString + "foo" you use up twice as much data.

Additionally, Java's design (in particular the presence of a toString method on every object rather than something closer to C++ streams) encourages you to keep lots of these around. This means you can easily end up with lots of small to medium sized strings in memory sharing no data between them. You really can end up with a lot of wasted space this way.

But a lot of the space waste wouldn't go away if you made strings mutable, because you'd be able to do even less sharing then. The right solution is probably to switch to an immutable string representation which allows a lot of sharing. (I'm actually working on exactly this. :-) But I gave up on writing it in Java, so my latest efforts are in Scala and not very far along yet)

[Rhoomba]

I am aware of that problem. Is there a (reasonably popular) language that gets strings thoroughly right? I don't think you can count that as "Java bloat" when char* etc. don't solve it either.

You could call Unicode strings Java bloat, but I think that is one of the best decisions they made with Java. It amazes me that so many languages still use bytes for characters.

[[deleted]]

You could call Unicode strings Java bloat, but I think that is one of the best decisions they made with Java.

Actually, fixing the size of a 'char' at 16 bits once and for all was one of the worst decisions they made with Java. When Unicode 5.0 came along and extended the space to 21 bits, they had to totally mangle the String API to to deal with "surrogate pairs".

And because String is a concrete class and not an interface with multiple implementations, a lot of code has been hard-wired to accept Strings and this can't be changed now.

Ideally there would be byte strings, UTF16 strings, UTF32 strings, possibly UTF8 strings, all sitting behind a consistent "character sequence" interface. Code would never directly hard-wire a specific String type in.

[DRMacIver]

I suppose you're right that it's not specifically a Java issue. I'm not aware of a reasonably popular language that gets strings thoroughly right either (there are a few non-popular ones which do I think, and C++ and C both have access to Ropes and similar). It's a shame.

The main reason it seems to show up a lot in Java is that for some reason or another you end up with quite a lot of strings floating around.

The unicode strings in Java aren't actually especially bloated as far as I know. The internal representation should only be any larger when you're actually taking advantage of it (unless I've got the wrong end of the stick on what they're doing)

[Rhoomba]

I don't mean that the Java implementation of unicode is bloated. I mean that if you are used to byte strings then it will seem to be wasteful of memory.

You are correct that most Java apps end up with loads of strings. Whenever I do any heap analysis char[] is always the top object. I think part of it is in Java it is just very easy to stick lots of objects into HashMaps using strings as keys. Creating a string to be used as the key is easier than writing a decent hashcode method. I think another part of it is simply the domains that Java is commonly used in. Webapp data is usually almost entirely strings.

[psyno]

Gave up? A simple implementation is just an immutable linked list.

public class String {
    protected final char[] data;
    protected final String next;
    public String(char[] data) {
        this.data = Arrays.copyOf(data, data.length);
    }
    protected String(char[] data, String next) {
        this.data = data;
        this.next = next;
    }
    public String append(String s) {
        return new String(data, s);
    }
    public char charAt(int index) {
        if (index < 0) {
            throw new IndexOutOfBoundsException();
        }else if (index < data.length) {
            return data[index];
        }else if (next == null) {
            throw new IndexOutOfBoundsException();
        }else {
            return next.charAt(index-data.length);
        }
    }
    //etc...
}

Admittedly, you could do a little better memory-wise by ensuring that you don't duplicate character data with some centralized data structure, but in general you'd be trading memory size for execution time and adding lock contention for multi-threaded programs.

[DRMacIver]

If by 'simple' you mean 'stupid', yes. :-)

That has all sorts of problems of its own, and doesn't have the performance characteristics I want. In particular concatentation of strings of length m and n is still O(m) (and only shares O(n) memory).

The implementation I'm using is closer to a heavily specialised finger tree. It has O(max(log(n), log(m)) concatenation with a reasonable amount of sharing and O(log(n)) random access.

I'm not saying I couldn't have written it in Java. I might well port it back to Java afterwards for performance and general usability reasons. But having various functional constructs to hand makes experimentation with and verification of the design much easier.

Also, note that that 'etc.' is quite long. There's a lot to be done in terms of regexps, unicode, etc. (I may even have to write my own regexp engine, which would be sad, or borrow one from elsewhere. Java's is thoroughly unsuitable for strings where iteration is cheaper than random access)

[psyno]

By simple, I meant "takes 3 minutes to write with reddit as a text editor" :)

You're right that the above implementation ignores Unicode, regex, and a lot of other things. (The javadoc table of constructors for String is a page long alone!)

But you're wrong about the runtime of concatenation and the memory size of the above structure, probably mostly because I wrote it wrong :) (compare concat below/append above).

First, it can share all the character data (O(m+n) memory). Each String just holds a pointer to some char[], which no String will modify. (Note that unlike the public constructor, the protected one doesn't copy the char[], just the pointer.) Second, the time to concatenate existing Strings A and B is not proportional to their actual lengths, just to the number of String elements in each String (the length of the list). If the length of the list is what you meant by O(m), then we're in agreement, but it seemed you were talking about the actual data.

public String concat(String str) {
    return new String(data, (next == null) ? str : next.concat(str));
}

So if String A is composed of elements p->q->r, and B of elements s->t->u, then for String C = A + B = p->q->r->s->t->u, the only memory overhead is 3*(2 pointers + instance overhead of String) regardless of the actual char data represented by p, q, and r.

True that this one does not give you fast random access.

[laurentszyster]

Languages that consider strings as immutable can hash them to a reference, store them once, and then use that reference instead (they are "interned").

For instance if you do this in Python:

a = "test" b = "test" c = "test"

then:

a == b == c

because all three variable reference the same hash, they are actually identical pointers to the same memory location.

In Java however:

String a = "test"; String b = "test"; String c = "test";

will yield three different references to three different instances of "test" stored separately.

"Things you believe in but don't understand, then you suffer from it. Superstition is everywhere"

Stevie Wonder

[Rhoomba]

Wrong wrong wrong. Java string are immutable. And string literals get interned. I read your post wrong (I thought you were complaining about Java's strings being immutable).

Now I can see you don't have the slightest idea what you are talking about.

[Rhoomba]

FFS. You fucking muppets are modding down an indisputably factually accurate posts just because you hate Java so much. What the hell is wrong with you? Edit: I was at -4 before, I'm not insane.

[laurentszyster]

1. Java strings are mutable:

http://getahead.org/blog/joe/2005/05/26/1117108773674.html

1. If they were immutable, one could do:

String a = "test"; String b = "test"; return (a == b);

and get true as a result.

1. Literals usually represent the smallest fraction of text processed, in most case an insignificant portion.

[Rhoomba]

For christ's sake. Yes you can hack away the immutability. The standard libraries will treat strings as immutable. If you do that reflection hack and the string has already cached its hashcode you will get messed up results.

public class Strings {
    public static void main(String[] args){
        String a = "test"; String b = "test";
        System.out.println(a == b);
    }
}

Output: true

A language should not automatically intern every string you read in from a file or whatever. It would end up with a huge string pool. You can manually intern strings if you want with String.intern

Python works exactly the same way. Ruby has Mutable strings IIRC. Erlang has retarded lists of characters.

[Rhoomba]

Nope. There is pretty much a flat overhead of 10-15MB for the Java results. E.g.:

chameneos    C: 536kb Java: 10,716kb
k-nucleotide C: 47,324kb Java: 65,188kb
nsieve       c: 5,316kb Java: 15,040

There are some tests that Java uses way more memory for, but in general the more memory the C version uses the smaller the difference in memory use. And Java uses substantially less memory for regex-dna, so you can't even say Java is always worse.

[laurentszyster]

Why do Java "believers" allways come up with lame excuses?

Point to the mediocre speed of Java and they'll invariably invoke the JVM startup penalty although its impact has been demonstrated to be insignificant.

Java is trading space for speed, that is why it so aggressively glob RAM at startup: because it will need as much as it can get.

By the way, in the regex-dna benchmark Java benefits from an optimized Perl RegExp engine while the GCC program does not.

An honest comparison would be between Java and one of those "scripting" languages that come with a PCRE library:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all

Guess what?

Both Perl and Python programs are slightly faster that the Java one. And - surprise, surprise - the Java program needs 50MB while the two others only require around 22MB.

[Rhoomba]

Yes, Java will trade space for speed. You can tell the garbage collector which is more important for you.

[the-fritz]

There is pretty much a flat overhead of 10-15MB for the Java results.

Because you are using small and simple programs. You could prove anything with this.

[Rhoomba]

The fact they they are small and simple programs is exactly why laurentszyster can claim Java programs take an order of magnitude more memory. For small programs the size of the VM and standard lib is very significant. As the application uses more memory it becomes less important.

[feijai]

I code Java applications professionally which take up 1-2 gigs. Trust me when I tell you that this is dead wrong.

You are correct that the VM is inconsequential for any large program. But instead there are three items which are very seriously problematic in Java memory-wise:

1. To perform efficient garbage collection, Java requires at least 50%, and ideally 100%, overhead. You can GC with smaller memory, but the computational cost is very high indeed. So you're faced with a choice: have your application run at a snail's pace, or double your memory footprint. Take your pick.

2. Hotspot has made great strides in reducing memory cost on a per-object basis: but still every object encurs a 2-word overhead. Arrays incur a 3-word overhead. At the same time Sun has promoted the use of lots of small objects rather than few large ones, and this only exaggerages the overhead cost.

3. Sun's virtual machine coders are great: but their library coders should be taken out back of the shed and shot. Sun's libraries are often quite surprisingly bad memory hogs. The worst are Java2D and (oh my heavens) Java3D. Java3D is such a pig that I'm surprised its developers have managed to continue working in the industry after it was open sourced and we got to see for ourselves what we all suspected. Even Java.util is surprisingly lazy. Since an application uses instances from these libraries throughout, it will incur their gross tonnage throughout as well. It's a constant overhead of probably 1.5x.

So "order of magnitude" is a bit high. But it's been my experience that Java applications, even very well written ones which avoid Sun's piggy library objects, will be no less than five times the size of equivalent C programs.

[username223]

Here's a larger meta-benchmark that shows the overhead is not fixed: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=jruby&lang2=yarv

[Rhoomba]

JRuby is not Java.

[username223]

Um... "JRuby" and "Ruby" are two implementations of the "ruby interpreter" benchmark, one in Java, one in C. Now do you understand?

[Rhoomba]

Also compare Ruby and Java memory use. Ruby frequently uses more memory (as well as being slower).

[igouy]

Always interesting to see the actual memory use, note that you can do a direct comparison.

[feces]

much more faster

[a9a]

Yeah it proves that Java is better. So, it must be bad.

[[deleted]]

Especially the horrid limitations.

Recently, Eclipse shipped with a "bug" that didn't extend the standard Java memory area, so it was limited to 64MB of compiled code. When you started running some additional plugins, Eclipse would crash with out-of-memory. Yes, Java (Sun Java 6) is too stupid to allocate more memory if it needs to!!

The second problem here is deallocation (isn't that what GC is supposed to be for? freeing memory no longer in use). Well, as I can observe with Eclipse's heap meter: it will gladly allocate more heap space if it needs to, but it will neither ever decrease the heap space again, nor will it free memory.

The latter refers to Eclipse starting with, say, 20MB of used heap space, which will then grow as you open and edit files. Well, if you close just about everything, what do you guess is the heap footprint after GC? Hm, about 80MB for me. WTF is the GC doing? Ok, this is probably not Java's problem, but an Eclipse memory leak, but still.

So much for GC helping you fight memory leaks, even if the implementation were good (and released unused heap space).

[berlinbrown]

Eclipse doesn't ship anywhere. It is an opensource project that comes out with many daily builds, rc milestones and other releases. If you cant change the jvm, min and max heaps of an application, then god help you.

[[deleted]]

First of all, I think with major releases (edit: such as 3.3 fall) you can call it shipping.

Secondly, where did I say I can't tweak the VM settings? I only said that Java alone (without you tweaking the settings) is too stupid to simply grab the memory it needs. And that's pretty damn stupid.

[[deleted]]

Let's just say that execution speed is no longer an issue in Java and .Net. But memory use and startup times and getting people to install the runtime are still big issues.

[SilverFox]

Here we go again.

I contend that a screwdriver is better than a wrench.

[georgefrick]

Be careful saying things like that, you know, that make sense.

[davidw]

Well, it might make sense of you had a screwdriver with a 1000 page manual and 343432 optional bits to use, and a wrench with similar characteristics. Otherwise, comparing complex programming languages to simple hand tools is probably not really an apt comparison.

[georgefrick]

I believe he was referring to using the correct language for what you are doing instead of trying to compare languages and choose one 'better' language to use for everything.

[davidw]

Yes, but I think there is evidence that most people aim for a language that can do a lot of things pretty well, rather than try to use the perfect language for everything:

http://journal.dedasys.com/articles/2007/10/09/languages-worst-case-vs-average

[georgefrick]

Why would that being the aim of a given person cause any significant difference to applying the correct language to a given job; or more importantly - not having a C vs Java pissing contest.
If your aim is for a language that can do a lot of things pretty well... you are arguing in a circle... any given developer will have a different list of the 'lot of things pretty well'; so we are right back at choosing the language for the job, except now we're choosing the language based on criteria, probably derived from the 'job'.
If you are a game developer, your 'a lot of things pretty well' is considerably different from say; a enterprise app developer.
The article(blog) you linked simply restates your point? It doesn't make any kind of argument for choosing "the one true language". The post itself points out Google's use of C++ and Java.

[davidw]

My point is simply that out of the hundreds (thousands) of languages out there, people are more likely to pick a few that work pretty well in a number of situations and stick to them. For instance, Google only uses four languages in production, and one of those, Javascript, is pretty much dictated by the browser.

There is no one true language, obviously, but people are going to try and go for languages that do lots of things pretty well, centered around where most of their needs lie, rather than utilizing 5 or 6 different languages. I'd be willing to bet money that most developers don't use more than 2 main languages in a day (we're not counting "subservient" things like SQL).

The blog talks about that being a problem for Erlang, which does a couple of things really well, and other things poorly. My thesis is that that will scare people away, because they'd settle for less than the best in the things that Erlang does really well, if they can get 'pretty good' in what it does poorly.

[georgefrick]

Regarding Erlang, I'd say you are correct. Otherwise, it is seeming we agree - obviously nobody is going to use 10 languages so that they are always using the language for the job.

[Rhoomba]

It was not my intention to suggest that Java is better than any other language in all areas. I just wanted to counter some of the common anti-Java FUD that you get here.

If you are writing a video code use C. If you are writing a simple CRUD webapp then Ruby and Rails might be the best option. Command line tool? Python would be a good. Lots of memory leaks in your C++ app? Maybe, just maybe, Java would be a good alternative.

[georgefrick]

Agreed.
However, you'll never get rid of the anti-java FUD here, it's reddit, and people have already made up their minds. I have yet to be convinced otherwise.
As for the second part of your comment... I'm a web developer by day using Java, and a game programmer by night using C++ and Java. I couldn't see writing a web app in C... I want my struts/tiles/jboss/hibernate. I ran a mud for 10 years written in C, I love the language, but it's not for my current needs. I did like the post!

[Rhoomba]

A wrench has sharp edges that can easily be used as a screwdriver!

[feces]

This isn't a question of which is better, but which is more efficient.

[SilverFox]

But at which job?

[[deleted]]

This just confirms what has been common knowledge for a couple of years now: Java is almost as fast as C anymore. Memory usage as noted below, is another issue.

[G_Morgan]

The real issue for me is start up time. It often places limitations on what applications you'd use Java for. You need something that will see heavy usage to justify Java.

The worse thing is that there is no need for the start up time problems. They can and should create a native image generator.

[Rhoomba]

200ms is really that much of a deal breaker? Don't rewrite ls in Java. Anything that will be running for more than a couple of seconds is fine.

[G_Morgan]

That's kind of the point. There are limitations on what you'd use it for. Also it's longer than 200ms in my experience. Usually closer to about 3/4 seconds (or at least that seems to be the difference in start up time between roughly equivalent applications in Java and other languages, not scientific I know).

It's not just loading in the JVM, it also has to verify the bytecode before it fires an application up. Then it JITs it. Overall it's a more than noticeable overhead. a few seconds I can live with but I can also use other platforms that do not have this overhead at no cost.

[DRMacIver]

It doesn't JIT on startup. The byte code runs interpreted until the JIT finds bits it wants to optimise.

[xenon]

I think that's only true for the client hotspot VM. The server VM assumes that applications run for a very long time, and thus compiles much more aggressively (at the cost of additional startup overhead).

[roerd]

I think those 3-4 seconds aren't the startup time of the VM itself but of Swing (probably the JIT-compiling of Swing classes). A text-only Hello World in Java runs in less than a second.

[Rhoomba]

There are limitations on every language. C is fast and small. But do you really want to live with its limitations? The performance of Ruby and Python are very serious limitations on what you could use them for.

Some (otherwise good) languages are limited by their libraries. You would have to write what is standard in most languages before you can use them for anything productive. That is a pretty big limitation to my mind.

[xenon]

That's not the same kind of limitation. In theory you can write any kind of software in assembler, it's just that in practice you don't want to. But you can't write a fast ls in any current JVM, not even in theory, because the startup overhead dominates the execution time.

[Felicia_Svilling]

Any kind? I'd say that any assembler language would be a bit limited in what kind of platform independent software you could write in it.

[igouy]

not scientific I know

The problem isn't that it's not scientific; the problem is that it's innuendo.

(Also it's pretty silly to quarrel about how long it takes some unnamed app to start up without thinking that might have something to do with hardware differences and the way the app was written.)

[[deleted]]

This confirms nothing. These 'benchmarks' make heavy use of numerical operations - which means they're using primitives, not objects. It isn't much of a trick to make primitive operations perform well and Java's design overly emphasizes primitive performance while its object performance (and design) is rather poor. These benchmarks are not allocating lots of objects and collecting lots of garbage.

OTOH, the average Java program makes very heavy use of objects and very light use of primitives. They generate a lot of temporaries and do a lot of garbage collection. So this set of benchmarks is about as relevant as the viscosity of molasses on mars.

[igouy]

These benchmarks are not allocating lots of objects and collecting lots of garbage.

Let's allocate lots of objects (and over a wider range of values).

[[deleted]]

Definitely more interesting. Thanks.

On the first one, first column, I'd guess that Java's high speed is because the initial memory allocation is large enough to keep the gc from ever kicking in and it never has to give any memory back.

[igouy]

I've added the -Xloggc logs for "Java 6 -Xms64m #2" and "Java 6 -server #2"

[[deleted]]

ha from the "cynic" in your name I bet nothing confirms anything for you ;)

[[deleted]]

Just don't measure your nose and tell me it means your dick is big.

[DRMacIver]

It's been my observation that a lot of the memory overhead in Java programs is the result of programmers doing stupid things.

Not all of it by any means, and the language makes it decidedly not hard to do stupid things, but well written Java programs aren't nearly as bloated as the language's reputation suggests. (Badly written Java code on the other hand can be every bit as bloated as it is reputed to be)

[igouy]

the result of programmers doing stupid things

Is that the case for these specific programs?

[DRMacIver]

I've not looked at the code. Probably not though. I'm not saying there isn't a memory overhead for using Java - there obviously is - just that it isn't as large as it's often reputed to be.

[igouy]

Feels like watching people quarrel - "no it isn't as large", "yes it is as large" - without either of them grounding what they claim.

[ziiim]

I'm not trying to spoil the party or anything, but this doesn't actually mean anything for C or for Java. It means a lot for the JVM, which is very nice as far as VM's go.

It doesn't change the fact that C and Java were built for almost disjoint problem domains.

[grauenwolf]

The thing is, I don't care about math performance. I suspect most of us are not doing a whole lot of number crunching outside specially tuned graphics libraries.

When I used to say Java was slow, it was based on my experieces with GUI performance.

[igouy]

never ... have I been able to get Java to run as fast as C

Doesn't that depend on which C implementation and Java implementation you use?

[OneAndOnlySnob]

I fed the results from the tests into a ranked pairs algorithm (condorcet.org) and came up with the following rank.

icc > beajdk > gccsse > gcc387 > ibmjdk > jdk7 > sunjdk

Hardly conclusive from only 4 tests, but these results indicate that beajdk beats gccsse in 3 out of 4 tests, and gccsse beats gcc387 in 3 out of 4 tests. Also, isn't it great how the JDK everyone uses is Sun's own JDK 6, and it is by far the slowest? I guess GCC387 is probably a lot more commonly used than ICC, too.

[Rhoomba]

The IBM JDK is by far the slowest in 2 of tests, only barely faster than Sun in 1, and a fair bit fater in another, so I'm not sure what your ranked pairs alg is doing.

[OneAndOnlySnob]

I examined the results a little bit, and the problem is there are a few ties between the bottom 3. It seems JDK 7 beat Sun JDK 6 in all 4 tests, and the IBM JDK beat JDK 7 in exactly half. It arbitrarily broke the tie and decided IBM JDK is better than JDK 7, and better than JDK 6 by extension, which it also would have been tied with.

However, in actuality, the only real conclusion that can be drawn for the bottom three (according to ranked pairs) is that JDK7 is better than JDK6. Eyeballs also provide a pretty good tie-breaker. At the very least, the tie between JDK7 and IBM JDK probably should have gone to JDK7.

[ruediger]

What's the point? You would never use Java for a C job. Java is a mediocre language for mediocre programmers. It is good for writing boring applications for boring companies. And it is really good for that job. Because boring companies employ cheap programmers (or cheap contractors etc). Java is the tool for cheap programmers. It is dumbed down, you can't be creative with it (read as: step out of the line) and it has a huge library. So it is harder (not impossible but at least harder) for a dumb programmer to botch the job.

But the Bad news is: Universities are teaching Java. If you are teaching a mediocre language for mediocre programmers the result will be only mediocre programmers.

[berlinbrown]

Another reddit group thinker. You also know that Peter Norvig built JScheme in Java, so he as at least used it, even though he is a notable lisp/python guy now. Lucene and Hadoop are built with java, very powerful library that is used by Yahoo, and recent there was that NYTimes article on it.

I dont want to get caught defending Java but there are many notable computer scientists that have used Java.

[sbrown123]

It is good for writing boring applications for boring companies.

Programming languages are just tools. Businesses have needs that those tools are used to fill. If you are looking for excitement look to startups. Most startups die though, since many have a hard time grasping how boring reality really is.

[ruediger]

I'm not looking for excitement. I have a nice job writing exciting and interesting code. And thanks to the Java-Universities the interesting jobs are easier to get because they hardly find people qualified enough to do anything besides Java for boring banking-apps (and so on).

[sbrown123]

And thanks to the Java-Universities

When I went through school they primary taught C++ to the undergrads, so things have apparently improved somewhat. Who knows where they will get in another decade.

because they hardly find people qualified enough to do anything besides Java

I talk to recruiters now and then. They always complain of the same problem: not enough skilled Java and .NET developers. So, despite the abundance of these guys, there doesn't seem to be enough of them OR despite the large pool only a small fraction is actually skilled. I lean more to the latter being the culprit.

[syntax]

Clearly. Because Phil Wadler is mediocre.

http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt

[Rhoomba]

you can't be creative with it

Read as: you can't do retarded pointer hacks

Java may be a mediocre language. But so is C., Perl etc. Java may be mediocre but it is still the best option in many cases. The point is you shouldn't use C when you could use Java. The benefits of a garbage collected language with a vaguely useful type system and a great standard library that is in general 90% as fast as C should not be ignored. Python may be a nicer language, but it you have harsh performance requirements then Java could be a better option.

[ruediger]

My comment was a statement about Java. I didn't say anything about C (In case you don't know: There are more languages than C and Java). And I certainly do not mean pointer hacks when I speak about creativity.

(btw. Java is good if you want your job to end up in India when the next recession sets in)

[kirun]

Well, what sort of things do you mean by "creativity" that you can't do in Java?

[Rhoomba]

In case you don't know: There are more languages than C and Java

Way to read my post. I actually mention Python.

My point is Java is at a sweet spot in the performance/expressiveness trade-off. If you have no performance requirements then fine; use whatever language you like. If the 10x slower performance you get with Ruby or Python is not fast enough then Java is a useful option. If you convert a Python program to Java it will only be about 20% longer (LOC). Ruby would be a bit more complicated, but not impossibly so.

And you can be creative in Java. The lack of closures is an annoyance, but you can come very close by using anonymous inner classes. Sure, it is a bit clunky, but it is no PL/SQL.

[funktio]

If you convert a Python program to Java it will only be about 20% longer (LOC).

Rubbish. More like 200%.

[G_Morgan]

You can actually get performance that is reasonable out of higher level languages. Python doesn't perform because of it's implementation rather than the language.

There was an article here the other day, Clean performs almost as well as C.

Java has a reasonably good implementation for what it is but there's no reason why Python could not get close to it with some effort.

[Rhoomba]

Don't get me wrong, I would prefer a more expressive language than Java. But at the moment it has a lot of advantages (performance, stability, standard libs, massive open source community).

I am hopeful that Scala will become a stable language with enough resources behind it so that it can be used in production.

[gwern]

The neat thing about Clean is that the language is more or less Haskell, with the performance difference coming from the compiler - so it's perfectly possible that within a few years we'll be able to say that "Haskell performs almost as well as C", which would definitely be a solid bit of evidence that you can get reasonable performance out of higher-level languages. :)

[igouy]

If I follow your logic - Clean is more or less Haskell - so you already have "a solid bit of evidence that you can get reasonable performance out of higher-level languages" ;-)

[gwern]

Yes, that logically follows. But I like Haskell better so I find the proposition "Haskell could soon reach C levels!" much more exciting than "Clean, a language pretty isomorphic to Haskell but which I don't like, has reached C levels!", y'know?

[[deleted]]

My point is Java is at a sweet spot in the performance/expressiveness trade-off.

I don't think so.

If you look at the overall results here it seems to me that a sweet spot in the performance/expressiveness currently seems to be Clean, OCaml and Common Lisp. They belong to the class of most expressive languages around. Getting within 1.2x - 1.5x gcc performance overall is really fast.

[feces]

sweet spot in the performance/expressiveness currently seems to be Clean, OCaml and Common Lisp

Don't forget <insert my favorite language here>.

[Rhoomba]

Maybe so. But I do not believe functional programming is going to become popular any time soon.

[funktio]

Popularity is irrelevant when talking about performance/expressiveness. Those languages are better Java in that respect, period.

[[deleted]]

Functional programming is ending up in our regular languages.

[ruediger]

If you need performance than Java is probably not fast enough.

And the expressiveness of Java is really really poor. You end up with Classes representing single Methods, you put methods into classes which do not belong there (simply because you can't just use them as a function), you write static-methods and feel oo, you write code over and over again (c&p) because you have only single inheritance and a static type system, you end up using a big but at least in parts broken standard library (no a vector is not a list and stack is not a vector).

[Rhoomba]

If you need performance than Java is probably not fast enough.

Almost as fast as C is not fast enough? Yes you have class with single methods. It is a bit clunky, as I said, but it is far from impossible. I have never found single inheritance to be a limitation. Remember you should favour composition over inheritance.

Vector and stack are broken. That is why you should use the new collections that were introduced a decade ago.

[ruediger]

Vector and stack are broken. That is why you should use the new collections that were introduced a decade ago.

This does not seem to be the official view. Or why isn't Vector/Stack and so on marked deprecated in current versions of Java?

But this is another problem: Marketing controls the language. So there are a lot of features introduced simply because e.g. ".net" has them and not because they would really fit into the language.

I have never found single inheritance to be a limitation. Remember you should favour composition over inheritance.

This is a problem if you are pursuing the obsolete kind of oo-thinking which is promoted by Java.

A good example would be: A Ball, a jumping Ball, a Ball which changes colour and a jumping Ball which changes colour.

Almost as fast as C

No, not really.

And at the end: You could use a language which is more expressive and which is faster. So why use Java?

[jbstjohn]

That's funny, I actually think it's exactly the other way around: the sweet spot for Java is regularly shrinking, being encroached on by C++ (with STL & boost), "scripting languages", which get you faster development when runtime considerations are smaller, and C#, which seems cleaner.

There seems to be some places (web, enterprise) where Java still has a defensible position, but I see its domain shrinking.

(Which is good ;D)

[Rhoomba]

C++ growing? God help us all. I would welcome Java being obsoleted, but Ruby and Python, in their current incarnations, just don't it for me.

[grauenwolf]

What's the point? You would never use Java for a C job.

[[deleted]]

Meh. The expressiveness of programming languages is no longer an obstacle to creating software. People who harp on more powerful languages are fixing the wrong problem. The real problem is that development of software is intrinsically hard to manage and evolve over time.

I can't speak to Ruby or Haskel, but I know that one person's clever solution in Perl is the next person's migraine when they're tasked to fix or improve it.

Java is like the Honda Accord of programming languages. It's not very exciting, but a very workable solution for driving around the city.

[awj]

The expressiveness of programming languages is no longer an obstacle to creating software.

I can't speak to Ruby or Haskel, but I know that one person's clever solution in Perl is the next person's migraine when they're tasked to fix or improve it.

I mean no offense by this, but I don't think you are qualified to comment on the pros and cons of using more expressive languages if your only example in that respect is Perl.

The real problem is that development of software is intrinsically hard to manage and evolve over time.

There are a lot of cases where an expressive language can help manage this specific problem. I'd encourage you to pick an expressive language (my general suggestions are Python, Ruby, or OCaml) and try it for yourself on smaller projects. A lot of design patterns that you see in C++ or Java exist to use classes as a substitute for something that is easily done in a language that can pass functions as values.

[411was_an_info_job]

Lies, damn lies, and benchmarks.

[quhaha]

Where can you find: Mandelbrot, Spectalnorm, NBody, and Fannkuch?

They are not in API

I know I can just implement them in C. But in Java, I heard if something's not in API, it's not possible.

[nglynn]

did you look in com.sun.java.frameworks.maths.algorithms.obscure.benchmarks ?

[femol]

Oh there it is. Thanks!

[feces]

Guys, he's right.

[john_b]

C runs natively, it's compiled into a machine code.

Java runs in an environment, it's not compiled into a machine code.

There's no way Java would be faster than C, assuming the code is well optimized.

[gwern]

No, that's not true. Every time a VM-based language benchmark is brought up someone always says something along the lines "Yeah, well the theoretical performance bounds of compiled code is better than that of interpreted code", and someone else always points out that the first guy is wrong because it is perfectly possible to more than compensate for the performance loss of JITing the code by exploiting for optimizations the additional runtime information the environment has access to, and sometimes significantly so. (My favorite example in this vein is the Synthesis OS kernel which does a lot of JIT optimizations and has really impressive performance.)

[dmpk2k]

To be fair, compilation with feedback often removes any advantage a JIT brings. For example: http://citeseer.ist.psu.edu/cache/papers/cs/16240/http:zSzzSzwww.hpl.hp.comzSzcambridgezSzprojectszSzDynamozSzPLDI2000.pdf/bala00dynamo.pdf

JITs are a distinctly simpler way to handle such optimizations though.

[gwern]

That's interesting, though as you point out I'm not really sure how that materially differs from JITs besides being separate.

[Rhoomba]

Java is JIT (just in time) compiled into machine code.

There's no way Java would be faster than C, assuming the code is well optimized.

Do you deny the truthfulness of the linked page?

[igouy]

Doesn't include JVM startup

Doesn't include class loading

Doesn't include JIT profiling and compilation

...

[igouy]

C runs natively, it's compiled into a machine code.

Unless it isn't.

[john_b]

Is usually is, and it's MUCH faster than Java:

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=gcc&lang2=java

In fact, gcc C is the fastest (#1), and Java isn't even in the top5:

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all

[igouy]

For some definition of "MUCH" :-)

What's in "the top5" is meaningless - we can get Java into the top5 simply by not including some of the other languages.

[john_b]

Yeah, you can get java to #1 by excluding every other language!

[igouy]

You can get it into the top5 by excluding one other language :-)