Talk:Java performance

"x times slower"

In the "Program Speed" section it says that "The C implementations are on some examples 4-5 times slower". Nothing can be "x times slower" than something else. That doesn't make sense. —Preceding unsigned comment added by 129.53.219.20 (talk) 14:50, 12 May 2010 (UTC)

Why can't something be 'x times slower' than something else? E.g. 40km/h is 2 times slower than 80 km/h. Tcotco (talk) 06:07, 21 July 2010 (UTC)

Even if "Foo is X times slower than Bar" is technically correct, it's easier for readers to understand "Bar is X times faster than Foo" or "Foo is an Xth as fast as Bar". --70.41.70.6 (talk) 05:28, 22 October 2010 (UTC)

Comparing C++ and Java is not that easy

Please take care not to mingle Java and the JVM. Java is a programming language, the JVM a hosting architecture. C++ is a programming language, the x86 a hosting architecture. One might just as well decide to compile Java source code for the x86 or C++ code for the JVM. It is in general wrong to state "Java is slower than C++" instead of "A Java program on some JVM on some architecture is slower than a semantically equivalent C++ program run on the same machine." —Preceding unsigned comment added by 141.35.13.50 (talk) 12:41, 24 October 2008 (UTC)

Sun vs Microsoft Windows

This also belongs in the Criticism of Java article, but it should be noted that the lawsuit Sun brought against Microsoft hurt the consumer. Since the Microsoft VM no longer ships with Windows XP (or can be downloaded), any page that contains a Java applet will be frozen for up to 3min on slow systems while the JRE loads, This has not changed with , and is a significant detriment. There are some advantages to having a VM built into the OS's structure. LaVieEntiere 16:51, 30 April 2007 (UTC)

The JRE only loads once, not each time an Applet is encountered. This is similar to having to download a new version of the Web browser, and not a significant obstacle. —Doug Bell 20:22, 7 August 2007 (UTC)

Need to differentiate Sun vs generic implementation

A general problem with several of the Java articles, but especially this one. SUN DOES NOT HAVE THE ONLY JAVA IMPLEMENTATION!!! Several of the "new" techniques discussed here (such as global register assignment) were done by other implementations in 1.2. Escape analysis and lock coarsening in 1.3 (if not bfore).

In another of the articles the concept of a stack-oriented IL is discussed as if it were a new idea, but it dates back to at least the P-code compilers for the original PC. IBM System i was using a stack-oriented IL (targeting a RISC engine with full global register allocation) several years before Java was introduced.

There needs to be some general technique introduced to distinguish between the quirks of Sun's implementation and the general architecture of the language. drh 03:07, 4 May 2007 (UTC)

Program Speed

Surely we need more references or benchmarks to support the claim "Java's speed is now comparable with C or C++ and in some cases Java is significantly faster". I am a professional programmer who works with both Java and C/C++ and in my experience, everything done in Java is MUCH slower. At the moment there is only a very questionable benchmark as a reference, which uses a 3D engine. This is a bad example, as the drivers/OpenGL api implementation would have more of an influence on the FPS than the actual language used. CptAnonymous 14:47, 8 September 2007 (UTC)

I added the Jake example, but then I wrote: Java programs take more time to start, are slower and use more memory than their C or C++ equivalents. But I don't completely agree with you: OK Java is slower than C/C++, but not MUCH slower; and I think that the Jake example is relevant (but I agree that it is not a benchmark). 3D engines typically create a LOT of objects (outside the OpenGL API), and they need to update frames every few milliseconds. OK, the OpenGL driver performance is very important, but after that, the 3D engine used on top of it, and the game itself, are also important. Badly coded (or unfinished) video games typically lag (see Stalker, for example), regardless of the driver. Hervegirod 22:05, 8 September 2007 (UTC)

I use C/C++ for real works (used to it + more portable), however if to think for desktop then my impression is that the java as language is also good looking, often easier to write than C++ and very quick language. Articles about "java perfomance" in wikipedia can no way raise the speed of the programs you write. What makes the real applications in java commonly slow is probably the widespread programming style. Feels like java developers do not often concentrate on solving the real problems of their users quickly and simplily and elegantly. Java developers seemingly concentrate (as first thing) on the modularity of software and the engineering process and feature-richness of their classes and modules (also important and welcome). However when one forgets for what he does it all ... it may result with perfect-looking foam factories (just a waste of power). java engines now optimize the bloat out runtime. Adjusting things with such a powerful engines drags down the starting and loading performance. So like usual ... the problems may lay between the chair and keyboard. Vambola Kotkas 212.47.207.152 (talk) 13:58, 4 February 2008 (UTC)

Stating "Java is comparable or faster than C++ in benchmarks" is dubious at best. Even the reference given lists Java only slightly slower in the best case and three or four times slower in the worst case. The only benchmark which shows a significant speed ratio in favour of Java is a ten year old benchmark run on a Pentium II 400, which was very selective and biased from the beginning. 87.167.157.146 (talk) 09:04, 23 April 2010 (UTC)

It is worse than dubious at best: Im a programmer I eat code for breaky, Ive written blindly fast code for many platforms and architectures, I know just what is wrong with c++ and c

and how they neccessarily confuse the heck out of the compilers optimiser. aka Im qualified to read or even write whatever authoritative' sources that you are going to cite. The cited references, disprove what the page claimed them to support. One satement was that java was not 'significantly' slower, I went to the reference and examined the data it was best summarised as "java is twice as slow", your page summarised it in sunesk java speak. Ive used real world java apps and c++ ones the java ones are in gamer speak laggy. That a useless distinction, probably as are the benchmarks. Everytime I have tried to speed up numerically intense code written in c++, by someone other than me, it generally went between 2x and 10 times faster... The next refrence I checked was that low level or numerical code could be comparable. On that link I actually found two benchmarks where java was faster. Generally it was slower, by an amount hat is not insignifcant to me. However I also have some suspicions about the benchmarks. Java was measured I beleieve on the task of say puttign all the apples in the box, whereas c++ was measured on putting them in and taking them out. Huh? Well I suspect the java program had allocated all the memory(there was oodles of allcoations) and had not yet garbage collected it. This means that in the real world when you do the next task, the garbage collector will still be running and slow it down. To be a real test, the test needed to be long enough to force that distinction out of the equation. Indeed most tests, dont simulate the real behaviour of java in real apps as they run trivial apps for trivial time frames. Real java behaviour for typical programs allocates and garbage collects lots of fluff. This fragments the heap, fragmenting the heap has always slowed down c++ code that I have written. The list of issues pitfalls with any formal testing game unless perused by 'real' experts, is monumental. The most accurate scientific non subjective estimate I have for the speed difference of Java and C++, is I feel mature java apps Ive used were laggy when compared with native ones. Any attempt Ive seen tto examine actual data and refeneces on the wikipedia page, is more subjective, in that it doesnt even measure what it claims to, speed on sane benchmarks, nor does it report the actual numerical results accurately. Frankly its the wrongest page Ive seen on wikipedia. Frankly it smells of marktroid drone speak. Are you sure your editors do not have (at best)divided allegences, yeah thats rude, but sorry I smell a rat. My advice if your a rat reading this, hide the sun speak better. BTW Im going now got to get back to coding my current project in my lanuage of choice for the project Java. Write once run anywhere, trumped my other requirements/considerations. Note i described something above as a 'formal testing game' as agame because benchmarking (producing fair tests) and cheating them is game played by languages compiler vendors and the benchmarkers. The benchmarkers are the least well funded. Oh and BTW if a benchmark is heavily efefcted by escape analysis, then IMO its crap as ameasure of speed as it impacts the readers of this page. Amyone who actually evaluates saya a fibonacci using dumb recursion down the buinary tree, deserves runnign logN times slower. if it was trivially optimisiable like that then agood programmer never wrotew it in place that mattered to real apps importance. Yes its handy to have escape analysis, yes it will speed up real apps small amounts, but showing that alanguage that has it suddenyl does much better on some benchmark simply proves the bencmark is crap as measuring how real world things could be expected to work.

I take issue with the statement: "its performance is generally:...lower than the performance of compiled languages as C or C++". The reference provided to support this claim, i.e. indicates that Java is 2 times slower. Can we change this statement? Tcotco (talk) 06:37, 20 July 2010 (UTC)

Escape analysis

Quote from article:

"Escape analysis techniques can not be used in C++ for example, because the compiler can not know where an Object will be used (also because of pointers)."

While Java may be able to do escape analysis more often than C++, it can be used sometimes in C++. For example the following code:

class Bar {
   int inc(int i) { return i + 1 }
}

void foo() {
   Bar b = new Bar();
   cout << b.inc(7);
   delete b;
}

with this code the compiler can know, that b will never be used outside of the function foo. I agree that pointers make escape analysis harder, but under certain conditions the compiler can verify that varibles do not escape a funciton. BTW, I have not programmed in C++ in a long time. Thus I may have made some syntactic errors. 213.237.48.86 18:48, 11 October 2007 (UTC)

Casts

The article says "that are possible in Java and similar languages are not possible in C or C++". To be fair it should be said that some optimizations made in C++ are not possible in Java. For example Java casts all objects extracted from collections. With C++ template-based collections, there is no need to cast extracted objects. I know Java has added generics, but the compiler still inserts casts. See http://www.jprl.com/Blog/archive/development/2007/Aug-31.html in the paragraph starting with "Runtime casts are inserted by the compiler" - I know, a better reference should be looked up. 213.237.48.86 19:21, 11 October 2007 (UTC)

"the compiler != the compiler". Java is compiled twice. Generics and there cast are added by the javac complier. The JIT-Complier may produce different code. In the case of generics hints are added for the runtime, which can be used to optimize the code. However you can't guarantee type-saftie as you can cast any Collection to a generic collection and add different types of Objects. Java7 or Java8 will propably address it by introducing generic types into the jvm itself. --141.84.69.20 (talk) 17:37, 5 May 2008 (UTC)

Program Speed 2

It is really funny to compare java performance to C native code, and to conclude java is faster. The comparison of cost per functionality isn't discussed here, which is right, but virtually everyone knows that it is a big achivement if well writen java code is working only 2 - 3 times slower than well writen C code. My opinion is these conclusions to be erased. If most of you think in similar way, let erase them. Dobrichev 21:38, 23 October 2007 (UTC)

I have seen a proof that ... current java actually often performs comparably runtime. Still slower, true, but not by the factor of 3 anymore. Real apps we see around however are really slow. It seems is not as the fault of the engine but the engineers. Maybe java fans do not know what is "profiler"? Vambola Kotkas 212.47.207.152 (talk) 15:54, 4 February 2008 (UTC)

I would like to see your unreferenced proof, not because it does not exist but because you probably misinterpreted it. The almost certain misinterpretations is that they measured characteristic X of java and C (via a benchmark) and you concluded characteristic Y ought be the same(Y is performance of Apps). Java has certain limitations (on purpose) (they took stuff out to make it) the is no (double * const) just a (const double *) (sorry I forget which means which, but java only has one of them, aka final Double). Anyway this amoungst other things has actual ramifications on speed when you design an app the size of a real world app, and endeavor to make it encapsulated, modularised, etal al. In java they have garbage collection no delete etc to relieve the programmer from the burden of worrying about such stuff. Show me the benchmark that measures the effect of only having const ptrs to char instead of ptrs to const chars.

Thrashing memory is a good way to lose performance, managing your implicit thrashing of memory is more challenging than in C++. Believe it or not the lack of a preprocessor is also speed challenging for java. In C/C++ #idef debug \n debug code \n #endif is h\ guaranteed to cost nothing in a release build, achieving similar functionality in java is a tad more challenging and if my mind is occupied by that tad there is that much less of it left over for worrying about optimal design for speed/functionality/maintainability.

Öhm?

I'm not an expert on this, but I just wonder how much of Java VM and all that stuff is written in C/C++? --212.149.216.233 (talk) 13:25, 20 February 2008 (UTC)

AFAIK, the whole Sun's JVM / JIT-compiler is in C++. The bytecode compiler (javac) is in Java itself. Hervegirod (talk) 23:09, 1 April 2008 (UTC)

Contradictory speed discussion

Clearly there is some disagreement about speed. Nothing wrong with that. But the article makes two statements that directly contradict each other: 1) "Hence, when Just-in-time compiled, its performance is lower than the performance of compiled languages as C," and 2) "Java's speed is now comparable with C or C++." Perhaps there is not a sufficient consensus that can be backed up by verifiable references in which case the article should not make claims either way (and should just point out that performance is a controversial issue, citing appropriate references to the controversy). Or perhaps there is. Either way the article should not say both that Java performance is lower and that the performance is comparable. —Preceding unsigned comment added by 71.84.19.38 (talk) 22:15, 1 April 2008 (UTC)

Collections microbenchmarks

There was a comment about these microbenchmarks saying: However the test is probably biased against C++ since it creates "dynamic objects" even if C++ can create stack objects while Java can't. Heap allocation is slow in C++ since its a general mechanism that should be used only if really needed.. I rewrote it a little to make it more neutral (the probably was not sourced based, so I changed by may be), and I put a fact tag, because when looking at the article in question, I saw nowhere if the author used heap or stack for initial memory allocation of the Objects. Plus Objects defined by STL are allocated on the stack, even if the memory itself can be allocated on the heap. Hervegirod (talk) 19:11, 4 August 2008 (UTC)

I took that out, because generally we shouldn't argue against citations in Wikipedia's voice. If someone else criticized the benchmarks for that reason, we can say so and attribute the criticism to them. In general though this section is fairly bad; it seems to consist mostly of poor benchmarks run by random people on the internet (or journalists) rather than peer-reviewed papers. --Delirium (talk) 19:37, 10 March 2009 (UTC)

this page is clearly biased

this wikipage is clearly biased, doesn't give enough references and is cherrypicking the ones it does, for example in the quake2 example it gives the impression that the java implementation is faster but if you look at the page you will see its not that simple, actually the fastest performance overall was for c ( http://www.bytonic.de/html/benchmarks.html)

sorry i dont have more time to go over this page but its so biased its ridicolous, and i even like java —Preceding unsigned comment added by 85.83.19.244 (talk) 21:36, 4 April 2009 (UTC)

Hey if you don't like these references, add some, but I don't think that this article is biased overall. Plus you also seem to do cherry picking. The part about Quake2 is The Java 5.0 version performs better in some hardware configurations than its C counterpart. And some other parts you did not pick: Performance of trigonometric functions can be bad compared to C, JVMs still have scalability issues for performing intensive communication on a Grid Network, Java memory usage is heavier than for C or C++, Java startup time is often much slower than for C or C++. Hervegirod (talk) 22:56, 4 April 2009 (UTC)

Hervegirod: I also found this article to be biased. You had initially stated that Java is "generally just as fast as compiled languages such as C or C++" which is not supported by the reference you gave in that same sentence (i.e. the "shooutout"). Also it seems to dwell more on the theoretical reasons why Java might be faster than on the theoretical reasons why it might be slower or equivalent. I've fixed the first, but not the second. Tim Cooper Tcotco (talk) 06:15, 21 July 2010 (UTC)

This page is now close to being neutral. I think we should move some of content into Comparison of Java and C++, because there is much duplication. Alliumnsk (talk) 04:14, 30 August 2010 (UTC)

A controversial paragraph

This paragraph appears to be biased:

Despite all these improvements complaints are being voiced about user programs written in Java, which continue to offer poor user interactivity after years of development and a decade of JVM improvements. Supporters point out the progress made so far and detractors compare the user experience with that of a program written in C++. An example is Eclipse, which pauses for several seconds when doing trivial operations and in general has delays that break programmer flow. There is a communication problem because supporters of managed languages often use them so much that they subconsciously accept the load delays and the pausing of the program. It's worth noting that it remains impossible to write a program like Maya or Cubase in a managed language, chiefly for usability reasons.

The author needs to cite his/her references, and how these conclusions were made (When the test was done, by who, the conditions, etc.) —Preceding unsigned comment added by Valenajarro (talk • contribs) 22:13, 9 June 2009 (UTC)

Seems POV to me. Hervegirod (talk) 22:18, 9 June 2009 (UTC)

Additions in the introduction

Concerning the addition in the intro:

• Comparing the performance of Java programs with those of the ones written in C, C++, Object Pascal or other (usually) natively compiled languages, is a tricky and a controversial task. Java, Like C++, is a programming language, but its target platform is (usually) the Java Platform, nowadays implemented in the JVM. The programs written in C, C++ or Object Pascal are compiled specifically for a hardware-OS combination that conforms a platform.

I think there's a difference between evaluating Java programs and C / C++ programs performance, but not as it is stated in this sentence. Performance of C / C++ programs also very much depend on the compiler and the OS architecture. What is different is the fact that Java programs are JITted, and the performance of a program very much depends on it's history. Hervegirod (talk) 22:57, 10 June 2009 (UTC)

Introduction changed to clearly reflect this situation (it was implied) . Valenajarro (talk) 22:18, 9 June 2009 (UTC)

Article non-neutrality

As other posters have pointed out, many parts of the article use biased wording and there is also apparent cherry-picking of benchmarks and benchmark results. I am marking this article POV until the problems are fixed (unfortunately it seems to require a lot of rewriting). Tronic2 (talk) 14:30, 19 March 2010 (UTC)

A lot of my time critical code executes in Java (video codecs specifically), but I compile from C++ when I develop (clever macros convert the same source code to either Java or C++). This makes it easy to compare the code speed - as it is the same code. My experience at least is consistent with the article - comparable execution speed in Java and C++. It's worth mentioning that there are a few things I avoid to encourage this - such as no garbage generation / collection. Stephen B Streater (talk) 21:25, 19 March 2010 (UTC)

I think I have to write again my previous answer to somebody else, a long time ago: "(...)I don't think that this article is biased overall. Plus you also seem to do cherry picking. The part about Quake2 is The Java 5.0 version performs better in some hardware configurations than its C counterpart. And some other parts you did not pick: Performance of trigonometric functions can be bad compared to C, JVMs still have scalability issues for performing intensive communication on a Grid Network, Java memory usage is heavier than for C or C++, Java startup time is often much slower than for C or C++".

About garbage collection, reclaiming memory is not only Java related (every real-life C++ program must claim and reclaim memory all the time, with the associated risks of course), and studies (not Java related), show that: good GC can have the same performance as good manual allocation / deallocation (even faster in some cases), but uses much more memory(see here). The fact that Java programs uses more memory than their C counterparts is mentioned clearly here.

In my personal experience, it's very easy in Java to create programs which create and garbage a lot of objects (much more than in C++, where you have to be very careful to avoid memory leaks). But creating / deleting objects comes at a cost where you do this VERY often. Hervegirod (talk) 22:20, 19 March 2010 (UTC)

While we're on the subject of garbage, the time taken to perform a garbage collect in some implementations depends on the number of objects allocated - so it is worth having fewer objects if speed is important. Stephen B Streater (talk) 23:02, 20 March 2010 (UTC)

Oh and by the way, wikipedia itself holds POV. A standard wikipedia POV(bias) is that it is possible to not inject your own bias and just reference sources and thus escape the need for expertise and judgment in the authors of authoritative articles(that POV in fact holds true surprisingly often). While that sentence is picking a rather large fight which I cant possibly win even if I am right, just suspend disbelief for paragraph or so and listen, because Im not picking fight with wikipedia just trying to point out rather large pothole that this wikipedia article may be about to fall into and make itself look sillier than the article already does. You wont find references or any objective measures that using Open Office, or eclipse feels like a laggy computer game, but it does, but with no cites you cant say it does. You can get citations saying compiled to assembly java (JIT compiler) is as fast as C, because it ought be just as fast for some tasks. Any task that can be elegantly expressed in java ought be ust as fast as C. If you manufacture a task that C aliasing of pointers makes the optimiser particularly confused the C or C++ compiled code may go slower than the java one. The fact that a good C++ programmer optimising for speed will never write it that way because it compiles slow has no effect on whether a benchmark will measure it as slower.

Thus if you guys who wish to move the article more in the direction of java is as fast as C want to start deleting anything without a citation, I have a dare for you. I dare you to find the citation that shows that any benchmark you cite is in anyway correlated with performance of a real world app written in that language. Thus any benchmarks that are not related to real world performance ought not be cited as they measure something other than what real people, readers of the article are interested in. Also benchmarks ought not be cited unless both version measure the same things, unfortunately you'll need actual expertise to know if thats true. One trap is the java code needs to have done enough work that the average cost of the garbage generated is largely amortised into the benchmark timing. As my wife is fond of saying i have not done my turn at cooking until I have also cleaned up. (Stuffing it all in a cupboard to be done later does not count) I posit that most people interested in finding out about the performance of language are not interested in finding language because they have benchmark they want executed quickly, but because they are choosing between, apps written in different languages. One reason I would want to know if java is slower than c++ is to know if my lovely compiler Eclipse, is written crap inside(it isnt) because it goes slow or thats just the penalty of being portable using java(it is).

Obvious non-sense

I won't add to the bias debate although this would probably provide one more evidence: "Java garbage collectors can do more than collect garbage, they may also defragment memory by moving objects that are not garbage near to each other in memory. This is, for example, a common feature of the generational garbage collectors mentioned above. This may result in a smaller working set of memory pages, and therefore quicker memory access.".

My problem is with "and therefore quicker memory access". Come on! Unless I am completely mistaken, memory accesses with respect to RAM is random and direct and linear, meaning that whatever the position where you read data from (or write data to), the operation is performed in a constant time, all other factors (for instance, the size of the data) remaining the same. The position/address is totally orthogonal to the operation. So claiming that a smaller working set means quicker memory access is clearly putting anything on the advantages side just for the sake of putting something (by the way, the defragmentation feature of garbage collectors is mind-blowing in and of itself, no need to add anything). As far as I know, whatever the language (C, C++, Java), all blocks of memory allocated are contiguous; so each object's fields are always in one single block even if individual objects' blocks may be non-contiguous. How on earth could a smaller working set provide faster memory access? We are not talking about disk sectors here, or page ins/page outs or virtual memory as handled by the OS. We are talking about memory from the point of view of the garbage collector. What is claimed would sometimes be true if virtual memory or paging were evoked in one way or another, which was not the case. If there's no paging in the picture, a smaller working set does not equate, imply, guarantee, or whatever you name it, quicker memory access. That's just plain wrong. A smaller working set means more readily-allocatable memory for other processes and the system, but that's not what is dealt with here. —Preceding unsigned comment added by Amenel (talk • contribs) 16:29, 15 May 2010 (UTC)

Well, smaller working set sometimes may be beneficial, sometimes not. It depends. What is not true, that smaller working set is obtained. Programs using GC require much more memory than without GC, so even with defragmenting GC programs still consume more memory than programs not using GC.Alliumnsk (talk) 03:44, 27 May 2010 (UTC)

This is a benefit. I am not a pro-Java advocate. Think about caching. Suppose a page size is 4k. Then a set of 256 bytes could take 256*4k=1M of actual memory. If the system must write some memory to disk to satisfy this criteria, then de-fragmenting the memory is a big pay off. Most C allocations use sbrk underneath and are binning. So the extreme example would never seldom happen, but it illustrates the problems of fragmentation. With generational GC, seldom used objects can be pushed to disk (virtual RAM) faster. Err, sorry that is un-true. I had thought about mentioning that to Doug Lea. You could coallse seldom used active memory so that the pages can be swapped. ... Given my real life experiences, with Java developers piling package after package on to a problem, I haven't seen this in real life. I would like to be surprised. Java has some very elegant features. However, the morass of un-intentional memory references usually ends up depleting memory sooner. I believe that 'C' and 'C++' generally require more analysis up front, which might lead the average program to pay more attention to these issues. Bpringlemeir (talk) 21:06, 9 June 2010 (UTC)

Revetred edits 23 August

I object to this edit, as it removes quite important point that Java code, even if JIT compiled, is considerably slower than native code, generated by modern optimizing compiler. I agree that the reference is written in anti-Java style and that it should be replaced by more appropriate one, however the style has nothing to do with the validity of material presented there. As of now, I revert the objected revision because the reasons specified in the edit summary are not valid: 1) stack allocation is considerably faster than heap allocation and allocates memory area which is almost certainly cached. 2) lock-elision is important only for Java applications as Java makes everything thread-save by default, what is not needed for most code. 1exec1 (talk) 16:36, 23 August 2010 (UTC)

The Jelovic source is absolutely not reliable. The document itself has no date (judging by the version of FrontPage used, and some of his sources, the document may date from 1998 or 1999, that would be Java 1.2), Delan Jelovic is unknown on the radar, and he did not substantiate any of his claims except by very general sources that are not relevant to the performance subject. Therefore I'm obliged to revert your own edits. Remember that one of the principles of Wikipedia is No original research. I have nothing at all with such claims, but they must me substantiated by a reliable source, which was not. BTW, I was not the one who reverted the source the first time. Hervegirod (talk) 07:53, 24 August 2010 (UTC)

Agreed. After quick search I found two recent sources, which should not be considered POV: this, this.1exec1 (talk) 12:50, 24 August 2010 (UTC)

Programming contests

There's 5 sources.

• First says that Java solutions are typically slower, TLs same,
• Second says that Java solutions are often slower, TLs same, some problems might be not solvable in Java (as TLs are set after non-java reference solution, which is faster)
• Third says they use 3x TL + 150ms/file
• Fourth says they use 2x TL
• Fifth says they use TL + 1sec

where's problem? Alliumnsk (talk) 22:16, 21 September 2010 (UTC)

I don't think these references are really valid. Unfortunately, some people here look everywhere to find sources saying that Java is *much* slower than other languages, regardless of their consistency and validity. Hervegirod (talk) 21:49, 27 November 2010 (UTC)

Sort performance

presenting the winning of terabyte sortbenchmark is misleading on indicating something on the Java performance. The rules of the graysort benchmark stating nothing about a defined hardware base for the competitors. So the setup with the most ressources had won, not the best implementation ('most efficient'). Hadoopsort run on approx. 4000 working nodes by far more then the next one. This can be also be seen by the non-ranking in the efficency benchmarks Penny- and JouleSort. [1] For comparision google was able to beat hadoop by raw speed as efficiency in 2008 (not in benchmark): http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html . 141.52.232.84 (talk) 14:26, 26 November 2010 (UTC)

Yes, this was an issue I noticed some time ago, but didn't fix because someone kept reverting me. Fixed now. 1exec1 (talk) 21:19, 27 November 2010 (UTC)

This is your personal interpretation, and it's not backed by valid sources, so I'm putting it back. let's stay on facts guys, not on our personal conceptions: Hadoop won the benchmark several times, hadoop is written at 99% in Java. All of what your are writing here is YOUR personal interpretation of the reason why hadoop won the benchmark. Rather than putting you own OR interpretation here, I would prefer seeing valid sources commenting the fact that hadoop won, and that (maybe) it was only due to the fact that it won only because of hardware. Hervegirod (talk) 21:32, 27 November 2010 (UTC)

agree, problem is the interpretation of a benchmark with multiple free parameters (this is an benchmark not about languages or implementation but of complete systems). nowhere in the references it is stated that the mentioned sort system won BECAUSE of the underlying framework or even the programming language. Nor can such conclusion be taken because of undefined constraints on hardware, connection etc by the Gray sort definitions. so, putting this on a wiki-page about java performance at all is a highly speculative interpretation. (here someone discussion the problem of undefined hardware-setup http://databeta.wordpress.com/2009/05/14/bigdata-node-density/) 95.114.244.145 (talk) 18:04, 28 November 2010 (UTC)

many high-profile distributed database management systems use Java rather than C++: for example, Cassandra, Gemstone, GigaSpaces, DataSynapse, etc... and it's for a reason. And the reference is not speculation, it's facts. Note that it does not state that "Java is faster in HPC other other languages", but that Hadoop, a Java MR implementation,, has won HPC benchmarks. I don't see where is the speculation here. You are more than welcome to point to sources explaining that the major reason explaining that the reason why Hadoop won the benchmark was not java, but the hardware. However, I was not able to find any (which does not mean that there are no valid ones). The sentence above quote sources explaining in what ways java has issues for HPC. And about the google implementation that was quoted in an above comment, it is not public, so we don't have any detail on how it work (except that it use MR). Hervegirod (talk) 19:07, 28 November 2010 (UTC)

sorry, wikipedia has not a policy of "true until proven wrong". So it's way around. references are required which proof that this hadoop sort benchmark setup allows a undebatable conclusion that the performance is definded by the underlying java (and not the hardware: the reference above (http://databeta.wordpress.com/2009/05/14/bigdata-node-density/) show doubt about this point, with even the conclusion that the hadoop setup is overly pessimistic and therefore approx. 40x times more hardware hungry (slower) then alternative setups). If such references are not available this benchmark is not relevant and note-worthy for this article. Or at least some additional information should be added which are helping the reader in understanding the undefinedness in the gray benchmark about the hardware setup. 95.114.244.145 (talk) 22:33, 28 November 2010 (UTC)

This is the second time yo put the DataBeta blog in the discussion. DataBeta is not a valid source. It's a blog from an "unknown" individual. Blogs are not considered valid sources here, except when they are from prominent figures in their fields, which does not seem to be the case here. His post is challenged by a lot of comments. The other source (the google's one) is even more "gray", because how google pbtianed these results is not public. They only posted a result, without explaining how they obtained it. So I'm sorry, but I still consider the paragraph valid. Hervegirod (talk) 00:30, 29 November 2010 (UTC)

doesn't matter if the google implemenetation or this blog are unreliable, undefined etc. because they wasn't given for inclusion, but for discussing the invalidity of conclusion presented in the included paragraph. The included paragraph is on a unencyclopedic level by indicating an invalid conclusion on the java performance from an benchmark which is not well defined enough for allowing such an conclusion. still, bring an reference which clearly state/proof that this benchmark result has something to do with the underlying java, not one of the given/included (redundant) sources is saying that. 95.114.236.201 (talk) 10:55, 29 November 2010 (UTC)

several people were already noticing the problem of this paragraph, see edits 380704995, 312698980 ... at least this already existing sentence should be re-added ..., although the hardware setup in the benchmark competition was not fixed and the Hadoop cluster had more than 9 times as many processing cores as the next closest contestant. Also, hadoop seems not 100% java http://hadoop.apache.org/common/docs/current/native_libraries.html 141.52.232.84 (talk) 17:32, 29 November 2010 (UTC)

hervegirod, the additional NPOVing text is some form of compromise...if you keep removing and standing on this invalid point of view the strict alternative would be to remove this paragraph at all, because no resources were presented which concluded java as reason 95.114.32.28 (talk) 23:57, 30 November 2010 (UTC)