As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Lately I've been thinking about the difference about native and bytecode.
I did some research and all information I've read was about C++ code compiled into native code vs Java code compiled into bytecode(runs on JVM which takes advantage of multi-core processors). The conclusion was that applications written in Java run faster.
Does C++11 change this?
Does applications written in C++11(since adds threads) run faster than Java ones?
The conclusion was that applications written in Java run faster.
That's a big leap to come to. There are so many factors which contribute to the performance of a system that it's very hard to say one approach will always be better or even faster than another.
C++ has always been able to use threads, it just didn't have as much detail on how they could be used. I don't believe C++11 is about performance but standardising things like memory models.
IMHO Given any amount of time and expert developers, a C++ program will always be faster than a Java program. However, given a limited amount of time and developers of mixed ability you are more likely to get something working and performing well in Java. Your mileage will vary. ;)
Making my answer clearer...
Does C++11 change this?
No. I don't agree it is the situation nor does it change it.
Does applications written in C++11(since adds threads) run faster than Java ones
Yes, but not always, Just like earlier versions.
Neither C++ nor Java automatically split your program into multiple threads. The closest you can get to automatic parallelization in modern languages is to use parallel collections. There are libraries to do that in C++ but there is better support for that kind of stuff in more functional languages e.g. Haskell, Scala, Clojure.
Another way to get automatic parallelization is to use an actor library and write your entire program with actors. Erlang was the first language with full support for that but the Akka framework for Scala/Java is also very good.
I would just say All Your Java Bases Are Belong To C++.. The JVM itself is written in C/C++. C/C++ run at native speeds on the bare-metal of the machine, while bytecodes are interpreted by a C/C++ code(that's running on top of the metal). One byte-code instruction could translate to about 5-10 asm instructions(or more). Hence speed of execution of C/C++ is considered faster than Java's. Ofcourse, if Java's runtime were thrown onto the metal and we had bytecode interpreted at machine speed, then it would be a fair comparison.
That said, see an example in the book called "Programming Pearls" where the author runs an interpreted BASIC program on a Radioshack personal computer, which with sufficient optimizations, runs faster than it does on a super computer. Which means, speed of execution of your program depends on your algorithms and coding/optimization practices.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to write a backend system for a web site (it'll be a custom search-style service). It needs to be highly concurrent and fast. Given my wish for concurrency, I was planning on using a functional language such as Haskell or Scala.
However, speed is also a priority. http://benchmarksgame.alioth.debian.org results appear to show that Java is almost as fast as C/C++, Scala is generally pretty good, but Haskell ranges from slower to a lot slower for most tasks.
Does anyone have any performance benchmarks/experience of using Haskell vs Scala vs Java for performing highly concurrent tasks?
Some sites I've seen suggest that Scala has memory leaks which could be terrible for long running services such as this one.
What should I write my service in, or what should I take into account before choosing (performance and concurrency being the highest priorities)?
Thanks
This question is superficially about performance of code compiled with GHC vs code running on the JVM. But there are a lot of other factors that come into play.
People
Is there a team working on this, or just you?
How familiar/comfortable is that team with these languages?
Is this a language you (all) want to invest time in learning?
Who will maintain it?
Behavior
How long is this project expected to live?
When, if ever, is downtime acceptable?
What kind of processing will this program do?
Are there well-known libraries that can aid you in this?
Are you willing to roll your own library? How difficult would this be in that language?
Community
How much do you plan to draw from open source?
How much do you plan to contribute to open source?
How lively and helpful is the community
on StackOverflow
on irc
on Reddit
working on open source components that you might make use of
Tools
Do you need an IDE?
Do you need code profiling?
What kind of testing do you want to do?
How helpful is the language's documentation? And for the libraries you will use?
Are there tools to fill needs you didn't even know you had yet?
There are a million and one other factors that you should consider. Whether you choose Scala, Java, or Haskell, I can almost guarantee that you will be able to meet your performance requirements (meaning, it probably requires approximately the same amount of intelligence to meet your performance requirements in any of those languages). The Haskell community is notoriously helpful, and my limited experience with the Scala community has been much the same as with Haskell. Personally I am starting to find Java rather icky compared to languages that at least have first-class functions. Also, there are a lot more Java programmers out there, causing a proliferation of information on the internet about Java, for better (more likely what you need to know is out there) or worse (lots of noise to sift through).
tl;dr I'm pretty sure performance is roughly the same. Consider other criteria.
You should pick the language that you know the best and which has the best library support for what you are trying to accomplish (note that Scala can use Java libraries). Haskell is very likely adequate for your needs, if you learn enough to use it efficiently, and the same for Scala. If you don't know the language reasonably well, it can be hard to write high-performance code.
My observation has been that one can write moderately faster and more compact high-performance parallel code in Scala than in Haskell. You can't just use whatever most obviously comes to mind in either language, however, and expect it to be blazing fast.
Scala doesn't have actor-related memory leaks any more except if you use the default actors in a case where either you're CPU-limited so messages get created faster than they're consumed, or you forget to process all your messages. This is a design choice rather than a bug, but can be the wrong design choice for certain types of fault-tolerant applications. Akka overcomes these problems by using a different implementation of actors.
Take a look at the head-to-head comparison. For some problems ghc and java7-server are very close. For equally many, there's a 2x difference, and for only one there's a 5x difference. That problem is k-nucleotide for which the GHC version uses a hand-rolled mutable hashtable since there isn't a good one in the stdlibs. I'd be willing to bet that some of the new datastructures work provides better hashtables than that one now.
In any case, if your problem is more like the first set of problems (pure computation) then there's not a big performance difference and if its more like the second (typically making essential use of mutation) then even with mutation you'll probably notice somewhat of a performance difference.
But again, it really depends on what you're doing. If you're searching over a large data set, you'll tend to be IO bound. If you're optimizing traversal of an immutable structure, haskell will be fine. If you're mutating a complex structure, then you may (depending) pay somewhat more.
Additionally, GHC's lightweight green threads can make certain types of server applications extremely efficient. So if the serving/switching itself would tend to be a bottleneck, then GHC may have the leg up.
Speed is well and good to care about, but the real difference is between using any compiled language and any scripting language. Beyond that, only in certain HPC situations are the sorts of differences we're talking about really going to matter.
The shootout benchmark assumes the same algorithm is used in all implementations. This gives the most advantage to C/C++ (which is the reference implementation in most cases) and languages like it. If you were to use a different approach which suited a different language, this is disqualified.
If you start with a problem which more naturally described in Haskell it will perform best in that language (or one very much like it)
Often when people talk about using concurrency they forget the reason they are doing it is to make the application faster. There are plenty of examples where using multiple threads is not much faster or much much slower. I would start with an efficient single threaded implementation, as profiled/tuned as you can make it and then consider what could be performed concurrently. If its not faster this more than one CPU, don't make it concurrent.
IMHO: Performance is your highest priority (behind correctness), concurrency is only a priority in homework exercise.
Does anyone have any performance benchmarks/experience of using
Haskell vs Scala vs Java for performing highly concurrent tasks?
Your specific solution architecture matters - it matters a lot.
I would say Scala, but then I have been experimenting with Scala so my preference would definitely be Scala. Any how, I have seen quite a few high performance multi-threaded applications written in Java, so I am not sure why this nature of an application would mandate going for FP. I would suggest you write a very small module based on what your application would need in both scala and haskell and measure the performance on your set up. And, may I also add clojure to the mix ? :-) I suspect you may want to stay with java, unless you are looking at benefiting from any other feature of the language you choose.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm interested in learning a dynamic language after at least 10 years on the Java platform. There are two choices that I was considering. One, learning one such as Clojure / Groovy that ride on top of the Java JVM. Secondly, a language off the JVM, which would include Ruby / Rails or Erlang.
Having knowing alot about the Java side, I'd like to choose a JVM based solution, but considering an off the JVM solution.
My question is:
What advantages / disadvantages would I get by choosing a language off of the Java JVM?
One of my biggest pain points is deployment memory footprint. I'd like to have a solution that allows low memory consumption, because most cloud / ISP providers require high dollar for anything greater the 512 MB / server. I've been so used to using High Memory JVM's which just don't work well with my costs. Maybe this isn't a concern for using clojure or groovy, but I'd expect a high memory footprint since it's running on the JVM.
I've already started using Ruby / Rails lately and I've been impressed with it.
If you go off the JVM then you have a good tool you can use in the cases where the JVM is poorly suited, like command line utilities where JVM startup time is really annoying.
If you go with Clojure you get both, with the clojure compiler you can produce classes for the JVM and with the ClojureScript compiler you can produce javascript that will run on very nearly anything.
My personal and therefore unverifiable advice is to go with the option that will expand your programming mind cough clojure but I am personally rather biased.
You could try JRuby to support ruby on and off a JVM.
I wouldn't assume that using JVM means using lots of memory. This depends on how you use the JVM. Using a profiler and more compact data structures can minimise memory usage. You can look at using C++, but if you are not careful C++ can use more memory. (But not if you know what you are doing)
How much memory you use is more about how you develop your program than which language you use.
For a low footprint solution, you may wish to consider JavaScript coupled with the V8 JS engine and Node.js technology
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Java is slow.
That's more than an "urban legend", it seems to be a fact. You don't use it for live-coding because of latency and you don't use it for clusters/parallel computing. There are thousands of benchmarks out there, specially "Java vs C# vs C++".
http://benchmarksgame.alioth.debian.org/
According to the above site, not only is Java performance almost as good as C (far from the rest), but Scala and Clojure (both functional languages which runs on the JVM) both have a better performance that OCaml, Erlang.
And there are a lot of "Java is faster then X" out there, also (for instance, a question here on SO: Java Runtime Performance Vs Native C / C++ Code?).
So Java seems to be fast, for certain cases. Can someone explain why?
Why is it that bytecode might run faster then native code, in some cases, given dynamic code (Scala, Clojure) and garbage collection? How come if it is faster, there is still latency?
It seems to be a contradiction here, can someone shed light?
In the book masterminds for programming, James Gosling explained:
James: Exactly. These days we’re
beating the really good C and C++
compilers pretty much always. When you
go to the dynamic compiler, you get
two advantages when the compiler’s
running right at the last moment. One
is you know exactly what chipset
you’re running on. So many times when
people are compiling a piece of C
code, they have to compile it to run
on kind of the generic x86
architecture. Almost none of the
binaries you get are particularly well
tuned for any of them. You download
the latest copy of Mozilla,and it’ll
run on pretty much any Intel
architecture CPU. There’s pretty much
one Linux binary. It’s pretty generic,
and it’s compiled with GCC, which is
not a very good C compiler.
When HotSpot runs, it knows exactly
what chipset you’re running on. It
knows exactly how the cache works. It
knows exactly how the memory hierarchy
works. It knows exactly how all the
pipeline interlocks work in the CPU.
It knows what instruction set
extensions this chip has got. It
optimizes for precisely what machine
you’re on. Then the other half of it
is that it actually sees the
application as it’s running. It’s able
to have statistics that know which
things are important. It’s able to
inline things that a C compiler could
never do. The kind of stuff that gets
inlined in the Java world is pretty
amazing. Then you tack onto that the
way the storage management works with
the modern garbage collectors. With a
modern garbage collector, storage
allocation is extremely fast.
Fast JVMs use Just-In-Time (JIT) compilation. The bytecode gets translated into native code on the fly at run time. JIT provides many opportunities for optimization. See this Wikipedia article for more info on JIT.
JVM's come in many flavours!
The fastest ones compile byte code to native code on the fly, based on performance characteristics being collected. All this require extra memory, so they buy speed at the cost of memory. Also, top speed takes a while to reach, so the benefit does not show for short-lived programs.
Even so, the JamVM interpreter (which is tiny compared to the Oracle JVM) still reaches a top speed of a reasonable fraction of the compiled JVM's.
Regarding garbage collection, the speed again comes from having plenty of memory available. Also the true benefit come from the removal of responsibility from the code to keep track of when an object is not in use anymore. This result in simpler, less error prone programs.
Well this is an old argument. Almost all prevalent as Emacs and VI.(but definitely not as old). I have seen lot of c++ developers providing lots of arguments on why most of the performance benchmarks (especially mentioning how java is as fast as c++__) is skewed and to be honest they have a point.
I do not have enough knowledge or time to go deeper in to how Java could be as fast as C++, but the following are the reason why it could be...
1- When you ask two very capable developers to write code in Java and C++ for a real world problem (same problem), then I would be surprised if java performs faster than C++. C++ when well written uses a fraction of memory Java will use. ( Java objects are slightly more bloated).
2- Java is inherently meant to be a simpler language and it was written to make sure that sub- optimal code is hard to write. By abstracting memory management and also by handling low level optimization, its easy to write good code in Java than c++. (this I believe is the most important thing.... Its difficult to write bad code in Java).On the flip side a good C++ developer could handle memory management much better than automatic GC in java. ( Java stores everything in heap, so uses more memory... )
3- Java compiler has been improved consistently and ideas like hotspot has proved to be better than marketing term. (when JIT was introduced, it was just a marketing term.. according to me.. :))
4- Ergonomics or tailoring the settings based on the underlying operating system parameters makes java handle variation better. So in some environments, its not hard to imaging Java performing as good as C++.
5- Opening up high level concurrency and parallelism api's for java developers also is a reason. Java concurrency package is arguably the easiest way to write high performance code that could leverage today's multi processor environments.
6- As hardware as become more and more cheaper, developer competency has become a bigger factor and that's why I believe that lots of c++ code in the wild is probably slower than Java.
Java Byte code is much easier to optimize than most native opcode. Because the byte code is restricted, and you can't do some dangerous things, you can optimize more fully. Take pointer aliasing, for instance. http://en.wikipedia.org/wiki/Pointer_aliasing
In c/c++ you can do
char[] somebuffer = getABuffer();
char* ptr = &someBuffer[2];
memcpy(ptr, somebuffer, length);
this makes it difficult to optimize in some cases, because you can't be sure what is referring to what. In Java this kind of thing is not allowed.
in general the code mutations that you can perform on a higher level of abstraction are much more powerful than can be had on object code.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Why is Java the most used programming language ? Why are the most programmers jobs for Java ?
Don't get me wrong here ? I like Java and I work in Java ? I don't have anything against it ?
Also, I'm trying to learn some other stuff out of the OOP box, like Clojure with its functional programming.
But, I'm wondering, why is Java number one ? I mean, dynamic languages (Ruby, Python, Php, JavaScript) people says that static types languages (Java, C/C++, C#) people envy them for their productivity ? They say they get the job done faster...
Ok then, if dynamic languages are more productive, how come Java stands where it stands ?
It was backed by a major commercial company Sun -- which other business value when decided on adopting such things.
It continued in the syntactic tradition of C++ -- already a widely used language at the time. In many ways, it was sold as a far improved C++.
It came with batteries included -- the framework.
Superb marketing effort of write once / run everywhere (platform independence).
The fear of Microsoft's dominance at the time forced a lot of companies to collaborate in the Java endeavor, notably IBM.
I don't think other languages on your list had these qualities (even if I fall into the dynamic/productivity camp). Arguably Python filled some of those niches at the time.
Typically it's easier for people to conceptualize in imperative languages with garbage collection (C#, Java)
Spolsky considers Java to be an easy language, he has a famous post on it.
Java is well-defined and thus easier for formal analysis efforts
Java runs on most modern platforms without massive grief
Java is "enterprisey", by which I mean it seems to be heavily adopted and developed by large corporations, which, due to sort of a best-practice risk-minimization approach, means other large corporations will also use it.
Java is taught in many universities.
Just off the top of my head...
Huge potential user base.
Large set of libraries.
Established community.
Fast VM.
Platform independent.
It's free.
It's been around for ages.
Some of the factors that have given Java its popularity are:
Its Maturity
Easiness to learn
Great API
Also, due to its philosophy of "Write Once Run Everywhere", Java programs are extremely portable and the Java platform itself is quite mature, in terms of the kind of applications that can be developed with it; not to mention the plethora of new languages that are being developed to run on the JVM.
Remember, most used, doesn't mean better; for many purposes you'll find that Java simple falls short of a viable solution.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Which language is faster for web, Java or PHP?
It is a difficult one to answer as in theory Java should be faster:
it's precompiled, any trivial algorithim will run faster in Java than PHP and there has been a vast amount of work done to optimise Java from improving the code, standard libraries, to JIT compilers, etc.
PHP is loaded and interpreted every time if you're not using the Zend optimiser, objects are intialised on every execution, even the most trivial string varaible is actually a complex object with many methods to support.
The problem is that in practice PHP sites seem to run faster using fewer resources.
I think this is because PHP developers take a more straightforward approach to design and don't get lost trying to implement exotic design patterns and implementing endless pointless abstractions.
Speed doesn't matter
in most cases.
Processing is cheap. Code in what you're comfortable with. Writing proper code goes much further for speed then choosing a language. Solid coding conventions and design plan will also help more.
Best answer I could find
"stuff to consider:
Java web applications are compiled
to bytecode. Even JSPs, which are
compiled at runtime. This is an
advantage over most uses of PHP,
where the Zend Optimizer is not in
use.
Data can be cached in a live servlet
instance - no direct/easy way of
doing this in PHP to my knowledge
(there is only ever a single
instance of a servlet/JSP in memory)
If anybody knows how to cache data in PHP without resorting to ugly
hacks, please enlighten me!
Java applications tend to be
n-tiered, which generally results in
a more maintainable application at a
slight performance penalty. This
probably sounds trollish, but
honestly: even within Java itself
direct use of JDBC will always be
faster than going through three
layers of objects to the database.
But is an n-tiered Java application able to hit the database sooner than an uncompiled, hacked-up monolithic PHP script? I don't think there's an answer to that question.
All that said, I'm working on an n-tiered MVC framework for php 5 (it's called Pure (http://www.sf.net/projects/php-pure)), so my PHP applications are generally n-tiered too. I'll worry about speed when and if it becomes an issue. For now, it's definitely not an issue."
courtesy of krumms
Speed aside, I believe the performance of Java is better than PHP. But developing a project in PHP is faster.
Can't answer this question with one or the other unless you define what you want to measure the speed of.
Some things are much faster in PHP (in a native function for example), other things are much faster in Java.
The intent of each language is substantially different from the other, so if you're debating over which to use for a particular task, you should generally based the decision on that task (and how well suited each language is to it) rather than performance.
For raw performance of code written in the language (as opposed to simply calling code in the standard library), Java will probably run faster than PHP as an extremely general rule. If that matters, chances are that PHP just isn't very well suited to the task at hand.