People repeatedly demonstrate that Java is as fast as C.
Indeed.
They do this for the same reason that members of religious groups keep having to tell themselves that their prefered creator of the universe is better than anyone else's
Er - I thought demonstrating that Java is as fast as C is not a matter of faith... there is evidence.
Write some CPU intensive code in C and Java yourself and report back.
And don't just write some silly benchmark that tests out a tiny part of the optimizer. Write some well rounded code that does a mixture of different things.
This sounds very much like the Intelligent Design debate - you get to define any code that anyone else writes that shows that Java can match C as 'not well rounded enough', so that you never lose the argument.
So when C starts to lose its advantage on the 'processor intensive' benchmarks (like those above) you move the goalposts....
However, why not look at Hypersonic - it is full-featured SQL-compliant relational database written in Java - should be well-rounded enough, surely.
You haven't worked for a defense contractor before, have you? Management is responsible for many bone-headed decisions that are technically flawed and sometimes downright specious.
So all of Boeing's avionics are determined by defence contractors? How about automotive systems, like BMW and Mercedes - is their use of Java determined by defence considerations?
Bottom line, IMHO, is the efficiency/performance/reliability/security of the software depends more on the skill of the programming team than on anything innate.
No, I really don't go with this. Developers always make mistakes and are fallible, so it is far better to have a language that has speed and security built in, to avoid mistakes.
actually cut the second paragraph from my previous comment before posting, but since you bring the subject up: yes, I do challenge the claims in those articles.
Sorry, but then it is you versus Boeing, Mercedes, and others who are investing millions in this.
as I understand you can in the more recent versions of Java, then you pick up the performance but you give up any pretence of getting the same results on all platforms.
But then in that case it is no worse than any other high-performance language (C or Ada), but with enormous advantages in terms of ease of memory management.
(I write highly portable floating point code for a living; trust me, you can't have both complete portability and optimal performance, ever.)
I believe you.
I suspect it's far more likely that the management teams believe, rightly or wrongly, that their staff will be more productive using Java than, say, C++ or ADA.
This is an outrageous claim - are you seriously suggesting that such highly technical decisions (and they are highly technical) are left to management?
And security problems are not just C problems, any language like Java,.NET, PHP, C# can also have their issues.
Apart from the fact that.NET isn't a language, I would be interested to know what issues you think Java and C# have. Almost all the problems with C (and almost all problems with security) are due to bounds checking. Java and C# have automatic built-in bounds checking.
PHP can have issues because it is interpreted, and so you can get code injection. Java and C# aren't interpreted.
It's fascinating that there are two replies to the GPP, post mentioning using Java in a real-time context, as if that somehow implies that its performance is equivalent to something like C or C++. "Hard real-time" and "fast" are completely different qualities, and having one does not imply the other either way around.
Of course it doesn't, but if you carefully read the replies it states that Java certainly does match C in speed:
"Aonix engineers have demonstrated hard-real-time Java that reaches the run-time efficiency of C and offer true compliance with hard real-time constraints".
This is perfectly clear - speed and real-time capability.
Perhaps you don't believe one source. Here are some more:
"Exemplifying the movement toward Java, Boeing has expressed a clear preference for the technology over other software languages. Winner of the lead system integrator contract for the U.S. Armys Future Combat Systems (FCS) program, Boeing is farming out their FCS requirements and telling suppliers they want to use Java; they dont like C++ and they dont like Ada for any new system development. Many suppliers to FCS are therefore tasked to convert reams of Ada code over to Java."
Boeing use a version of Java that is designed for C performance and real-time work.
"Aonix engineers have demonstrated hard-real-time Java that reaches the run-time efficiency of C, which makes it able to meet the needs of command-and-control applications such as network-centric warfare, Future Combat Systems, and low-level telecommunications control-plane software, Aonix officials say."
"The Navy Open Architecture guidelines also state that all new development will be done in Java and C++, he adds. "
Laughing now? Or perhaps feeling a little foolish?
Please take, for an example, the well-tested sections of the Linux Kernel as an example.
If you have some issues with the performance, reliability or security of Linux, look sidelong to the Mach kernel.
I have no issues with the performance or reliability of Linux or Mach. Did I say otherwise?
What I have issues with is someone saying that only C or assembler are suitable for critical high-performance work. Other languages have been used for this for decades. It is just that C has been the traditional language of Unix/Linux for a long time.
Now, if you don't mind, please pull your heade from your ass.
Great way to debate. Perhaps you might want to actually educate yourself about such matters before posting?
because C and ASM are still the only choices for coding performance sensitive applications
No. If you look at an area where performance and reliability is critical, you will find that Ada is the dominant language (with Java having increasing use)
its ALOT easier to believe in 1 big miracle for the world/plants/animals/people to be here than trillions of "evolutionary" miracles.
What miracles? Evolution is not a miracle, it is trillions of trial-and-errors with the best of those trials having more offspring. What on Earth is miraculous about that?
I agree Out of Nothing comes Nothing. Something had to always have existed out side of the dimension of time and space. What you call it depends on your worldview.
No it doesn't. There is no comparison between come vague principle of existence and an 'interfering' God who creates each species. The latter is simply not needed, so to assume He exists is pointless.
Then you have the problems of the statistics of just 1 cell coming about by chance and the numbers are obscene, 10 to the 100th power or something like that.
But don't you see that that isn't a problem? Have you any concept of how many molecules could be trying various combinations of reactions over the surface of an entire planet for hundreds of millions of years?
Also, you don't need to get an entire cell - just replicating molecules that catalyse other things. We have already seen that evolve by itself in the laboratory, using short RNA strands (which can form naturally). If we can get RNA reproducing, mutating and evolving (these RNA strands showed that the could evolve to protect themselves against certain chemicals) in a test tube in a few days, just imagine what could happen over the entire surface of the Earth over hundreds of millions of years.
Actually we don't have to imagine - we see it all around us - it is life.
Sadly a lack of transitional forms in this area leads me to doubt the fossil record.
There are plenty of transitional forms. For the evolution of purely aquatic fish to land-based amphibians is very clearly illustrated, with each step obvious.
Sorry, but saying 'there is a lack of transitional forms' is simply wrong.
The Radioisotope dating method also has its problems and has widely varying results.
In a very few cases there are interpretation problems, but in almost all others it tells the same story.
This is the macro/micro evolution debate. A pug mates with a beagle you get a puggle. But its still a dog. You never get a cat. A Zebra with a Donkey, you get a Zonkey but its still part of the Horse kind. And the lack of transitional fossils suggest that these gradual changes did not occur as Darwin theorizes.
There ARE plenty of transitional fossils, and there never has been a macro/micro evolution debate amongst those who study evolution. Again, saying there is a debate is simply false.
DNA and all the rest of it to show that we are here by design and that it defies rational thinking to think it could be otherwise.
No. There are plenty of ideas about how DNA could have arisen. Just because you don't understand it does not mean it defies rational belief.
Even as a scientist, I still look up at several hundred tons of plane in the sky and part of me thinks 'that is impossible', but that does not mean it is impossible - just that I don't understand how it happens.
You have to be humble and accept you simply are ignorant about things.
Humans then migrated to places where it was easier to live and started a civilization.
It was very unlikely to have been so planned. All you need for 'migration' is population growth, so that an increasing number of people need to find new places to live and find food. This may involve little movement in a generation (building a house or finding a place to live a short distance away from the parents), but over thousands of generations, it will look like a 'migration'.
My message is simple: Embrace science, reject religion and it's false promises. The afterlife is a lie. When you die that is it, you're dead.
This isn't a very scientific point of view. Science is about doubt, so how can you definitively say that the afterlife is a lie?
Not that I believe in an afterlife, but a true scientist would have an open mind, even about these things.....
What we should be embracing is neither something called 'science' or 'religion' but a mature ability to doubt things, to not accept dogma from anyone and a desire to find things out for ourselves.
Because fossils showing a progression of types of animals and plants have been found in rock strata which have been carefully dated in a range of ways show that life on this planet has changed over billions of years. Because analysis DNA has shown that all species are related, and the way that they are related is by descent from a common ancestor. Because we have actually observed evolution happen, both in microbes and in bird and insect species.
If it is been proven then why is there such a debate over the evidence, or lack there of?
Because evolution (unlike many other types of science) directly contradicts many people's religious beliefs. Without those beliefs many people would feel insecure and that life is without meaning. So, instead of taking a mature attitude and realising that they have to accept facts and come up with new ways to cope with reality, many take comfort from vain attempts to attack the evidence for evolution.
Much of these attacks are based on simple ignorance, but many are from a plain refusal to accept a level of evidence that any rational person would accept in any other area of science, philosophy, or life. For example, some interpretations of the bible imply that the Earth is 'fixed' at the centre of the universe, but I don't see Christians rushing to dismiss the evidence of astronomy...
so, the theory assumes that 200,000 years is not enough for such a migration?
And, of course, talk of 'migration' is nonsense. It would have been more like 'hey, it is getting a bit crowded here, let's find a cave or tree a bit further away'. A few thousand generations of this and a species can spread a long way!
Yes, it works well. Or, adequately. Just not as great as a simple algorithm looped well over 6000 times...
No - it works at C speed. The optimisation processes it used on code hotspots is exactly the same no matter what the code size. As there is no 'Just in Time' compiling of classes as they are loaded, there is no delay in executing them.
at the time. It means, whenever a new chunk of code is to be executed ( and there are many in a huge codebase ), the user experiences that nice stuttering feeling...
No.
Java is no longer a JIT compiler. It is a hotspot system. The code starts up immediately with no delay under a fast java bytecode interpreter (Those who say 'ruby or perl is fast enough for most purposes' can't criticise Java), and then the hotspot optimiser kicks in as a background thread (so as not to impact performance) and the code starts to accelerate. As time-critical sections are optimised to C speeds.
There are no delays. There is no 'stuttering'.
I really don't know why this myth about slow speed and 'stuttering' persists. Java is now being used for real-time control in applications such as aeronautics (Boeing demonstrated a small drone flying entirely under the control of Java software last year).
Do you really think that major aircraft and car companies would be using Java if there was 'stuttering'?
I just said before, though: in real software projects -- not small, simple algorithms with a constant flow -- there's no time, nor enough memory, for doing nice runtime optimizations or bottleneck analysis in such huge codebase...
That simply isn't the case. Java is being used for real large projects and works well. The point is that Hotspot doesn't care about the side of the codebase, it works on what is actually being run at the time. Hotspot works best on these larger projects, as that is what it was designed for, in contrast to the far slower JIT process, which can cause significant delays.
Let me give an example: An application running on the Tomcat web server involves a huge codebase, yet on Tomcat 5.5, application can serve web pages and even images at close to the performance of the latest Apache.
oh, man! well, at least here is a 'myth' about java performance that isn't that old and that can be verified by hand, or should i say, eyes?...
Why not try it? I was a very strong critic of Swing years ago, but it really is fast on Java 1.5. I use NetBeans on Linux and Windows, and find no speed problems at all.
"the ratio of performance java:C changes dramatically as time goes on."
somehow, i doubt the ratio will be that agressive once we walk away from simple algorithms to programs consisting of thousands of classes...
Why not? There is no reason why it should not. It is the same process - agressively optimising slow code. Why should the volume of code matter at all?
yes, it's used heavily in certain applications. Hybernate, for instance. As a proponent of dynamically typed languages like myself, i like that java has a way to do it -- though a stupid and verbose one. But fact is: it slows down things a lot, because is all done at runtime...
You insist on repeating this, but without evidence. If you actually have a look at how things are done, you will see that introspection performance improved dramatically between Java 1.3 and 1.4. So it simply does not slow things down.
close to that of Apache running mod_php, mod_python and others...;)
No - close to 'raw' apache serving web pages and images.
that even worse: they're compiled just short of being called!
As I keep repeating - things don't work like this.
well, it's exactly that "just at run time" part that is kinda silly...
No it isn't, because it means (1) the developer need only ship one binary (not source code) for dozens of platforms and (2) there are good theoretical reasons why run-time profiling and compiling could soon exceed the speed of pre-compiling.
After all, it is optimising what actually happens, and not what is predicted to happen.
i'm sure the swing vs swt 'myth' is pretty new.:)
It is not a myth. Obviously, an OpenGL/DirectX accelerated GUI (Swing) is going to be faster than one that isn't (SWT).
ok, i think i'll finally take a break for the holidays... how about it?:)
Fine - have a good break!
All I would say is - don't believe a word I say! Try it for yourself - look at start-up times, and the speed of large Java applications like NetBeans and Tomcat. Don't stick with the myths about Java performance put forward by those who for whatever reason don't like the language. There are many reasons to dislike Java, but speed is not one of them.
Actually, yes - if you look at it's performance metrics under Linux it is faster than SWT. It can use DirectX and OpenGL acceleration on various platforms.
ok, i'll give you the benefit of doubt, mister...
Don't:) - try it for youself! Take some of the programs shown in that benchmark, and run them for 10, 50 or 100x longer. You will almost always find that the ratio of performance java:C changes dramatically as time goes on.
never heard of them. Had them be around for so long, surely some languages may have used them before java? What was there before java that could use it?
The standard optimisations used by other languages. I have already mentioned them - loop unrolling, variable re-arrangement, inlining etc. Hostpot uses these (amongst others). I think you are misunderstanding me. I am not saying that Hotspot is doing anything special, all I am saying is that because it does the same sort of profiling and optimising as other languages have done for decades, then you are going to (and do) get high-quality code from it. Hotspot does for Java code what a high-performance C++ compiler does for C++ code - but just at run time.
I heard Self used many techniques that were later incorpored into Hotspot. But Self is not that much older than Java...
No, but self was and IS very fast, and it's optimisation techniques were included in Java (as HotSpot).
Quickly?! For hello_world.java and qsort.java perhaps. For large real world apps load several thousand classes and the like, it takes well about one minute or so to be done...
Actually, no. Such a large real-world app is Tomcat - it has tens of thousands of classes, but starts up in less than a minute, and has been shown (with version 5.5) to server most pages at a performance close to that of Apache.
Why not try it and and see?
Anyway, I think you are misunderstanding me again. Just because a program has thousands of classes does not mean that all these classes are compiled. This was a fault with older Java VMs and the 'traditional' JIT technique - you had to wait for all classes to be compiled - this gave rise to bad delays on start-up. With Hotspot, you don't wait. Instead what happens is that only the bits of code that give rise to poor performance get compiled and very highly optimised. In some programs this may be the majority of code. In others, it may be very little. Because there may be very little, this can be done very effectively and quickly.
but somehow, people seem to not be using it a lot, huh?
Yes, because there is (and I am sure, always will be) a persistent attitude amongst many C/C++ developers that everything has to be done by hand - that automatic memory management is somehow less effective, in spite of years of evidence from other languages that it isn't.
because it has an associated runtime which has to take care of such things as introspection among others...
Garbage collection has nothing to do with introspection. Introspection is a specific set of user libraries that allows user code to look at it's own methods and classes. Different Java implementations use different well-established garbarge collection techniques, that have been around for years.
i'm starting to agree.
Ouch!
If I may be acid in return - surely the most boring thing is to keep repeating old 'myths' about Java performance? (sorry)
perhaps you should live by your name and cut the java...:))
Hey - I said being working was a winning strategy:)
Further to my previous post - I just didn't believe some of these benchmarks, so I tried them myself. I tried 'nbody', as I have a particular interest in maths:
I compiled the gcc and g++ code with exactly the same optimisations a specified, and I used both -client and -server switches with Java - the lastest Java 1.5.
a few seconds?! even SWTed Eclipse begs to disagree. Many very useful perl batch scripts are done while most Java apps are still loading!
This is true. Java is not an appropriate language for for small apps that only take a few seconds (or milliseconds) to run. However, there are other performance issues with eclipse - SWT is not the fastest of systems.
Which run thoughroughly simplified GUIs and the like. Let's focus on real everyday stuff running on current desktop systems, ok?
This is irrelevant. The point was to show that Hotspot is not a CPU or memory hog. As for 'simplified GUIs', these platforms aren't simple at all - they have 3D drawing APIs, some of which are implemented in pure Java.
Which I have seen, and is missing the point. As I have already discussed, the optimisation in Java takes some seconds to kick in. Most of what you are dealing with in these benchmarks is the startup time of the JVM. This is like comparing the performance of two different operating systems but neglecting to exclude the boot times.
In a recent Slashdot thread I showed that if you ran benchmarks like this for 5, 25, or 100x longer then Java easily caught up with C in most cases.
decades?! Java itself is barely 2 decades old, JITting is a pretty newer technique and the "Hotspot" compiler has just came out a few years ago. I think you making things up in order to give your arguments some substance they lack...
No, you are misinterpreting me. I am not saying that Hotspot has been around for decades, I am saying that the optimisations it uses have.
The compilation time, the library loading times, the Garbage Collector thread cycles, some eventual runtime introspection techniques... the actual scenario is a lot worse than what you paint it to be.
You simply can't say this without evidence. Repeating that this 'must' impact performance is meaningless unless you can show that it actually does. I have already stated that the compilation time can be over with quickly, and the fact that Java can be used for high-performance real-time applications shows that garbage collection does not have an impact. After all, there are now modern garbage collectors that can be used with C and C++ - they usually have little impact when used in place of 'manual' memory handling, so which should things be any worse for Java?
Which also means the optimizer is up and running and consuming memory and cpu cycles.
Only 'every now and then', and as I have already discussed, the optimiser runs fine and with little impact on performance even in low memory and slow CPU systems.
"It is the use of the '-server' switch that allows Java to easily match the output of most C or C++ compilers in most benchmarks providing code runs for more than a few seconds."
hmm, perhaps this influenced the java benchmarks above? i don't know.
Absolutely. If those benchmarks were run for 10 or 100 times longer, I suspect the results would be very different. When I have tried one or two of them, they certainly have been.
well, then i guess this will likely be the longest running _dialogue_ *nobody* in slashdot has ever witnessed...:)
No - because I always beat opponents in the end - through boredom if nothing else!
Slashdot Mirror
People repeatedly demonstrate that Java is as fast as C.
Indeed.
They do this for the same reason that members of religious groups keep having to tell themselves that their prefered creator of the universe is better than anyone else's
Er - I thought demonstrating that Java is as fast as C is not a matter of faith... there is evidence.
Write some CPU intensive code in C and Java yourself and report back.
Righto. Here you are:
http://www.shudo.net/jit/perf/
And don't just write some silly benchmark that tests out a tiny part of the optimizer. Write some well rounded code that does a mixture of different things.
This sounds very much like the Intelligent Design debate - you get to define any code that anyone else writes that shows that Java can match C as 'not well rounded enough', so that you never lose the argument.
So when C starts to lose its advantage on the 'processor intensive' benchmarks (like those
above) you move the goalposts....
However, why not look at Hypersonic - it is full-featured SQL-compliant relational database written in Java - should be well-rounded enough, surely.
It is fast.
You haven't worked for a defense contractor before, have you? Management is responsible for many bone-headed decisions that are technically flawed and sometimes downright specious.
So all of Boeing's avionics are determined by defence contractors? How about automotive systems, like BMW and Mercedes - is their use of Java determined by defence considerations?
Of course not.
Bottom line, IMHO, is the efficiency/performance/reliability/security of the software depends more on the skill of the programming team than on anything innate.
No, I really don't go with this. Developers always make mistakes and are fallible, so it is far better to have a language that has speed and security built in, to avoid mistakes.
actually cut the second paragraph from my previous comment before posting, but since you bring the subject up: yes, I do challenge the claims in those articles.
Sorry, but then it is you versus Boeing, Mercedes, and others who are investing millions in this.
as I understand you can in the more recent versions of Java, then you pick up the performance but you give up any pretence of getting the same results on all platforms.
But then in that case it is no worse than any other high-performance language (C or Ada), but with enormous advantages in terms of ease of memory management.
(I write highly portable floating point code for a living; trust me, you can't have both complete portability and optimal performance, ever.)
I believe you.
I suspect it's far more likely that the management teams believe, rightly or wrongly, that their staff will be more productive using Java than, say, C++ or ADA.
This is an outrageous claim - are you seriously suggesting that such highly technical decisions (and they are highly technical) are left to management?
And security problems are not just C problems, any language like Java, .NET, PHP, C# can also have their issues.
.NET isn't a language, I would be interested to know what issues you think Java and C# have. Almost all the problems with C (and almost all problems with security) are due to bounds checking. Java and C# have automatic built-in bounds checking.
Apart from the fact that
PHP can have issues because it is interpreted, and so you can get code injection. Java and C# aren't interpreted.
It's fascinating that there are two replies to the GPP, post mentioning using Java in a real-time context, as if that somehow implies that its performance is equivalent to something like C or C++. "Hard real-time" and "fast" are completely different qualities, and having one does not imply the other either way around.
h p?id=100149
Of course it doesn't, but if you carefully read the replies it states that Java certainly does match C in speed:
"Aonix engineers have demonstrated hard-real-time Java that reaches the run-time efficiency of C and offer true compliance with hard real-time constraints".
This is perfectly clear - speed and real-time capability.
Perhaps you don't believe one source. Here are some more:
http://www.cotsjournalonline.com/home/printthis.p
"Exemplifying the movement toward Java, Boeing has expressed a clear preference for the technology over other software languages. Winner of the lead system integrator contract for the U.S. Armys Future Combat Systems (FCS) program, Boeing is farming out their FCS requirements and telling suppliers they want to use Java; they dont like C++ and they dont like Ada for any new system development. Many suppliers to FCS are therefore tasked to convert reams of Ada code over to Java."
Boeing use a version of Java that is designed for C performance and real-time work.
I was right with you until you mentioned Java, thanks for the laugh.
f m?Section=Articles&ARTICLE_ID=234337&VERSION_NUM=2 &p=32
http://mae.pennnet.com/Articles/Article_Display.c
"Aonix engineers have demonstrated hard-real-time Java that reaches the run-time efficiency of C, which makes it able to meet the needs of command-and-control applications such as network-centric warfare, Future Combat Systems, and low-level telecommunications control-plane software, Aonix officials say."
"The Navy Open Architecture guidelines also state that all new development will be done in Java and C++, he adds. "
Laughing now? Or perhaps feeling a little foolish?
Please take, for an example, the well-tested sections of the Linux Kernel as an example.
If you have some issues with the performance, reliability or security of Linux, look sidelong to the Mach kernel.
I have no issues with the performance or reliability of Linux or Mach. Did I say otherwise?
What I have issues with is someone saying that only C or assembler are suitable for critical high-performance work. Other languages have been used for this for decades. It is just that C has been the traditional language of Unix/Linux for a long time.
Now, if you don't mind, please pull your heade from your ass.
Great way to debate. Perhaps you might want to actually educate yourself about such matters before posting?
I was right with you until you mentioned Java, thanks for the laugh.
Enjoy your laugh. Boeing is using Java for real-time aeronautics.
because C and ASM are still the only choices for coding performance sensitive applications
No. If you look at an area where performance and reliability is critical, you will find that Ada is the dominant language (with Java having increasing use)
its ALOT easier to believe in 1 big miracle for the world/plants/animals/people to be here
than trillions of "evolutionary" miracles.
What miracles? Evolution is not a miracle, it is trillions of trial-and-errors with the best of those trials having more offspring. What on Earth is miraculous about that?
I agree Out of Nothing comes Nothing. Something had to always have existed out side of the dimension of time and space. What you call it depends on your worldview.
No it doesn't. There is no comparison between come vague principle of existence and an 'interfering' God who creates each species. The latter is simply not needed, so to assume He exists is pointless.
Then you have the problems of the statistics of just 1 cell coming about by chance and the numbers are obscene, 10 to the 100th power or something like that.
But don't you see that that isn't a problem? Have you any concept of how many molecules could be trying various combinations of reactions over the surface of an entire planet for hundreds of millions of years?
Also, you don't need to get an entire cell - just replicating molecules that catalyse other things. We have already seen that evolve by itself in the laboratory, using short RNA strands (which can form naturally). If we can get RNA reproducing, mutating and evolving (these RNA strands showed that the could evolve to protect themselves against certain chemicals) in a test tube in a few days, just imagine what could happen over the entire surface of the Earth over hundreds of millions of years.
Actually we don't have to imagine - we see it all around us - it is life.
Sadly a lack of transitional forms in this area leads me to doubt the fossil record.
There are plenty of transitional forms. For the evolution of purely aquatic fish to land-based amphibians is very clearly illustrated, with each step obvious.
Sorry, but saying 'there is a lack of transitional forms' is simply wrong.
The Radioisotope dating method also has its problems and has widely varying results.
In a very few cases there are interpretation problems, but in almost all others it tells the same story.
This is the macro/micro evolution debate. A pug mates with a beagle you get a puggle. But its still a dog. You never get a cat. A Zebra with a Donkey, you get a Zonkey but its still part of the Horse kind. And the lack of transitional fossils suggest that these gradual changes did not occur as Darwin theorizes.
There ARE plenty of transitional fossils, and there never has been a macro/micro evolution debate amongst those who study evolution. Again, saying there is a debate is simply false.
DNA and all the rest of it to show that we are here by design and that it defies rational thinking to think it could be otherwise.
No. There are plenty of ideas about how DNA could have arisen. Just because you don't understand it does not mean it defies rational belief.
Even as a scientist, I still look up at several hundred tons of plane in the sky and part of me thinks 'that is impossible', but that does not mean it is impossible - just that I don't understand how it happens.
You have to be humble and accept you simply are ignorant about things.
Humans then migrated to places where it was easier to live and started a civilization.
It was very unlikely to have been so planned. All you need for 'migration' is population growth, so that an increasing number of people need to find new places to live and find food. This may involve little movement in a generation (building a house or finding a place to live a short distance away from the parents), but over thousands of generations, it will look like a 'migration'.
My message is simple: Embrace science, reject religion and it's false promises. The afterlife is a lie. When you die that is it, you're dead.
This isn't a very scientific point of view. Science is about doubt, so how can you definitively say that the afterlife is a lie?
Not that I believe in an afterlife, but a true scientist would have an open mind, even about these things.....
What we should be embracing is neither something called 'science' or 'religion' but a mature ability to doubt things, to not accept dogma from anyone and a desire to find things out for ourselves.
Oh so evolution has been proven as a fact now???
Because fossils showing a progression of types of animals and plants have been found in rock strata which have been carefully dated in a range of ways show that life on this planet has changed over billions of years. Because analysis DNA has shown that all species are related, and the way that they are related is by descent from a common ancestor. Because we have actually observed evolution happen, both in microbes and in bird and insect species.
If it is been proven then why is there such a debate over the evidence, or lack there of?
Because evolution (unlike many other types of science) directly contradicts many people's religious beliefs. Without those beliefs many people would feel insecure and that life is without meaning. So, instead of taking a mature attitude and realising that they have to accept facts and come up with new ways to cope with reality, many take comfort from vain attempts to attack the evidence for evolution.
Much of these attacks are based on simple ignorance, but many are from a plain refusal to accept a level of evidence that any rational person would accept in any other area of science, philosophy, or life. For example, some interpretations of the bible imply that the Earth is 'fixed' at the centre of the universe, but I don't see Christians rushing to dismiss the evidence of astronomy...
so, the theory assumes that 200,000 years is not enough for such a migration?
And, of course, talk of 'migration' is nonsense. It would have been more like 'hey, it is getting a bit crowded here, let's find a cave or tree a bit further away'. A few thousand generations of this and a species can spread a long way!
Wouldn't it be possible that pre-humans migrated to different locations and finished their evolution separately?
Because we are all so very similar genetically - it suggests common descent.
Yes, it works well. Or, adequately. Just not as great as a simple algorithm looped well over 6000 times...
No - it works at C speed. The optimisation processes it used on code hotspots is exactly the same no matter what the code size. As there is no 'Just in Time' compiling of classes as they are loaded, there is no delay in executing them.
at the time. It means, whenever a new chunk of code is to be executed ( and there are many in a huge codebase ), the user experiences that nice stuttering feeling...
No.
Java is no longer a JIT compiler. It is a hotspot system. The code starts up immediately with no delay under a fast java bytecode interpreter (Those who say 'ruby or perl is fast enough for most purposes' can't criticise Java), and then the hotspot optimiser kicks in as a background thread (so as not to impact performance) and the code starts to accelerate. As time-critical sections are optimised to C speeds.
There are no delays. There is no 'stuttering'.
I really don't know why this myth about slow speed and 'stuttering' persists. Java is now being used for real-time control in applications such as aeronautics (Boeing demonstrated a small drone flying entirely under the control of Java software last year).
Do you really think that major aircraft and car companies would be using Java if there was 'stuttering'?
I just said before, though: in real software projects -- not small, simple algorithms with a constant flow -- there's no time, nor enough memory, for doing nice runtime optimizations or bottleneck analysis in such huge codebase...
That simply isn't the case. Java is being used for real large projects and works well. The point is that Hotspot doesn't care about the side of the codebase, it works on what is actually being run at the time. Hotspot works best on these larger projects, as that is what it was designed for, in contrast to the far slower JIT process, which can cause significant delays.
Let me give an example: An application running on the Tomcat web server involves a huge codebase, yet on Tomcat 5.5, application can serve web pages and even images at close to the performance of the latest Apache.
oh, man! well, at least here is a 'myth' about java performance that isn't that old and that can be verified by hand, or should i say, eyes?...
;)
:)
:)
Why not try it? I was a very strong critic of Swing years ago, but it really is fast on Java 1.5. I use NetBeans on Linux and Windows, and find no speed problems at all.
"the ratio of performance java:C changes dramatically as time goes on."
somehow, i doubt the ratio will be that agressive once we walk away from simple algorithms to programs consisting of thousands of classes...
Why not? There is no reason why it should not. It is the same process - agressively optimising slow code. Why should the volume of code matter at all?
yes, it's used heavily in certain applications. Hybernate, for instance. As a proponent of dynamically typed languages like myself, i like that java has a way to do it -- though a stupid and verbose one. But fact is: it slows down things a lot, because is all done at runtime...
You insist on repeating this, but without evidence. If you actually have a look at how things are done, you will see that introspection performance improved dramatically between Java 1.3 and 1.4. So it simply does not slow things down.
close to that of Apache running mod_php, mod_python and others...
No - close to 'raw' apache serving web pages and images.
that even worse: they're compiled just short of being called!
As I keep repeating - things don't work like this.
well, it's exactly that "just at run time" part that is kinda silly...
No it isn't, because it means (1) the developer need only ship one binary (not source code) for dozens of platforms and (2) there are good theoretical reasons why run-time profiling and compiling could soon exceed the speed of pre-compiling.
After all, it is optimising what actually happens, and not what is predicted to happen.
i'm sure the swing vs swt 'myth' is pretty new.
It is not a myth. Obviously, an OpenGL/DirectX accelerated GUI (Swing) is going to be faster than one that isn't (SWT).
ok, i think i'll finally take a break for the holidays... how about it?
Fine - have a good break!
All I would say is - don't believe a word I say! Try it for yourself - look at start-up times, and the speed of large Java applications like NetBeans and Tomcat. Don't stick with the myths about Java performance put forward by those who for whatever reason don't like the language. There are many reasons to dislike Java, but speed is not one of them.
then i suppose Swing is?
:) - try it for youself! Take some of the programs shown in that benchmark, and run them for 10, 50 or 100x longer. You will almost always find that the ratio of performance java:C changes dramatically as time goes on.
:))
:)
Actually, yes - if you look at it's performance metrics under Linux it is faster than SWT. It can use DirectX and OpenGL acceleration on various platforms.
ok, i'll give you the benefit of doubt, mister...
Don't
never heard of them. Had them be around for so long, surely some languages may have used them before java? What was there before java that could use it?
The standard optimisations used by other languages. I have already mentioned them - loop unrolling, variable re-arrangement, inlining etc. Hostpot uses these (amongst others). I think you are misunderstanding me. I am not saying that Hotspot is doing anything special, all I am saying is that because it does the same sort of profiling and optimising as other languages have done for decades, then you are going to (and do) get high-quality code from it. Hotspot does for Java code what a high-performance C++ compiler does for C++ code - but just at run time.
I heard Self used many techniques that were later incorpored into Hotspot. But Self is not that much older than Java...
No, but self was and IS very fast, and it's optimisation techniques were included in Java (as HotSpot).
Quickly?! For hello_world.java and qsort.java perhaps. For large real world apps load several thousand classes and the like, it takes well about one minute or so to be done...
Actually, no. Such a large real-world app is Tomcat - it has tens of thousands of classes, but starts up in less than a minute, and has been shown (with version 5.5) to server most pages at a performance close to that of Apache.
Why not try it and and see?
Anyway, I think you are misunderstanding me again. Just because a program has thousands of classes does not mean that all these classes are compiled. This was a fault with older Java VMs and the 'traditional' JIT technique - you had to wait for all classes to be compiled - this gave rise to bad delays on start-up. With Hotspot, you don't wait. Instead what happens is that only the bits of code that give rise to poor performance get compiled and very highly optimised. In some programs this may be the majority of code. In others, it may be very little. Because there may be very little, this can be done very effectively and quickly.
but somehow, people seem to not be using it a lot, huh?
Yes, because there is (and I am sure, always will be) a persistent attitude amongst many C/C++ developers that everything has to be done by hand - that automatic memory management is somehow less effective, in spite of years of evidence from other languages that it isn't.
because it has an associated runtime which has to take care of such things as introspection among others...
Garbage collection has nothing to do with introspection. Introspection is a specific set of user libraries that allows user code to look at it's own methods and classes. Different Java implementations use different well-established garbarge collection techniques, that have been around for years.
i'm starting to agree.
Ouch!
If I may be acid in return - surely the most boring thing is to keep repeating old 'myths' about Java performance?
(sorry)
perhaps you should live by your name and cut the java...
Hey - I said being working was a winning strategy
You can take a look here and compare for yourself:
http://shootout.alioth.debian.org/
Further to my previous post - I just didn't believe some of these benchmarks, so I tried them myself. I tried 'nbody', as I have a particular interest in maths:
I compiled the gcc and g++ code with exactly the same optimisations a specified, and I used both -client and -server switches with Java - the lastest Java 1.5.
Here are the results:
1000000 loops
gcc 0.9 seconds
g++ 1.1 seconds
java -client 1.3 seconds
java -server 1.1 seconds
5000000 loops
gcc 4.3 seconds
g++ 5.2 seconds
java -client 6.1 seconds
java -server 4.0 seconds
10000000 loops
gcc 8.6 seconds
g++ 10.4 seconds
java -client 11.4 seconds
java -server 7.6 seconds
Interesting, isn't it? When given enough time to optimise, java -server is even beating raw C.
Mind you, this is a bad general benchmark (most benchmarks are!), but it impresses me. Why don't you try it? The code is simple and easy to run.
I think I am going to re-run more of these benchmarks, and for a longer time - this should make an interesting report.
a few seconds?! even SWTed Eclipse begs to disagree. Many very useful perl batch scripts are done while most Java apps are still loading!
:)
This is true. Java is not an appropriate language for for small apps that only take a few seconds (or milliseconds) to run. However, there are other performance issues with eclipse - SWT is not the fastest of systems.
Which run thoughroughly simplified GUIs and the like. Let's focus on real everyday stuff running on current desktop systems, ok?
This is irrelevant. The point was to show that Hotspot is not a CPU or memory hog. As for 'simplified GUIs', these platforms aren't simple at all - they have 3D drawing APIs, some of which are implemented in pure Java.
You can take a look here and compare for yourself:
http://shootout.alioth.debian.org/
Which I have seen, and is missing the point. As I have already discussed, the optimisation in Java takes some seconds to kick in. Most of what you are dealing with in these benchmarks is the startup time of the JVM. This is like comparing the performance of two different operating systems but neglecting to exclude the boot times.
In a recent Slashdot thread I showed that if you ran benchmarks like this for 5, 25, or 100x longer then Java easily caught up with C in most cases.
Here are some benchmarks that run longer and illustrate what I mean:
http://www.shudo.net/jit/perf/
decades?! Java itself is barely 2 decades old, JITting is a pretty newer technique and the "Hotspot" compiler has just came out a few years ago. I think you making things up in order to give your arguments some substance they lack...
No, you are misinterpreting me. I am not saying that Hotspot has been around for decades, I am saying that the optimisations it uses have.
The compilation time, the library loading times, the Garbage Collector thread cycles, some eventual runtime introspection techniques... the actual scenario is a lot worse than what you paint it to be.
You simply can't say this without evidence. Repeating that this 'must' impact performance is meaningless unless you can show that it actually does. I have already stated that the compilation time can be over with quickly, and the fact that Java can be used for high-performance real-time applications shows that garbage collection does not have an impact. After all, there are now modern garbage collectors that can be used with C and C++ - they usually have little impact when used in place of 'manual' memory handling, so which should things be any worse for Java?
Which also means the optimizer is up and running and consuming memory and cpu cycles.
Only 'every now and then', and as I have already discussed, the optimiser runs fine and with little impact on performance even in low memory and slow CPU systems.
"It is the use of the '-server' switch that allows Java to easily match the output of most C or C++ compilers in most benchmarks providing code runs for more than a few seconds."
hmm, perhaps this influenced the java benchmarks above? i don't know.
Absolutely. If those benchmarks were run for 10 or 100 times longer, I suspect the results would be very different. When I have tried one or two of them, they certainly have been.
well, then i guess this will likely be the longest running _dialogue_ *nobody* in slashdot has ever witnessed...
No - because I always beat opponents in the end - through boredom if nothing else!