Slashdot Mirror
C Faces Java In Performance Tests
catseye_95051 writes "An independent programmer in the UK (he does not work for any of the Java VM makers) has done a series of direct C vs. Java speed comparisons. The Results are likely to surprise some of the Java skeptics out there. " Author Chris Rijk admits, "This article is not supposed to be an attempt to fully quantify the speed difference between Java and C - it's too simple and incomplete for that," but the results are nonetheless food for thought.
I read about FOURTH in an assembly book once, mentioned in passing only as a language that had about the same appeal/hype as java.
What exactly was it? My only guess is that it was supposed to be a Fourth generation language...
ReadThe ReflectionEngine, a cyberpunk style n
Likewise, he doesn't use the -fprofile-arcs or -fbranch-probabilities options which would probably speed up some of the code quite a bit, I would imagine.
For team coding, Java just makes things easier. I can take home my piece of code and work on it on my Linux box; another person can test the code in Windows or Solaris. The final project can be run on anything. It greatly simplifies things, since you don't have to worry about platform or implementation idiosyncrasies.
Also, I think it's _REALLY_ not important what language you learn, but the overall programming concepts you retain. Once I knew C++, it was simple to learn Java, Perl, etc. Even Lisp was easy to pick up, once I understood recursiveness. Learning every bit of a language seems a *tremendous* waste of time, to me, especially if it's at the expense of learning how to code properly.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
As someone thinking of picking up Java and adding it to my set of job skills, I must say that this discussion has been very valuable for me. I think it's fantastic that many posters here seem to loathe Java. As experience has shown me, if someone does the opposite of whatever /. recommends, they'll tend to be quite successful -- where success is defined as actually making a living, rather than shaving two microseconds off an executable's run time.
/. bunch, I'm going to be employed for a long, long time.
If the next generation of programmers are as inflexible and intolerant as the
Am I the only one who thinks that Sun over did it with all the pluggable look and feel stuff? It's definitely very cool to be able to click a button and have your application switch from Metal to Motif to Win32, but this comes at an enourmous complexity (and presumably speed) penalty. Try running a simple swing program through an analysis tool like OptimizeIt and you'll be horrified about how many classes need to get loaded for even the most simple app. I kind of wish they'd done a straight forward implementation of Metal (Which looks great in my opinion.)
Nobody can catch everything, and to assume a "good" programmer won't write code which leaks memory is very naive. Why do you think people are trying to retrofit C and C++ with rudimentary GCs now?
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
A universities job is not to learn students how to fix memory leaks (an activity that cannot be avoided by newby c programmers) but to learn them the basic concepts of programming.
The fact that "leaks" of objects, "forgotten" by sloppy programmer yet referenced by program are harder to detect does not make them go away.
Contrary to the popular belief, there indeed is no God.
One more comment on aliasing: if you tell the MSC that aliasing isn't going to happen (/Oa), the speed of your FFT example improves by about 15%. Since Java does not have any usable pointers, it can always assume no aliasing. With any modern C/C++ compilers on all existing x86 CPUs well-written FP-heavy code will usually be bound only by the FPU performance (the non-FP part is so much faster on x86...). While it is certainly possible to replicate the results in other languages/compilers, it should be practically impossible to beat them by any decent margin. The huge deviation in your FFT results shows that something is badly wrong with the code. Anyhow, an interesting article.
There are some constructs in C that are almost impossible to optimize. Pointer arithmetic is an example. When the compiler cannot tell if two pointers point at the same place, it has to be very careful during optimization. Also, here's an example of what I mean by loop unrolling having an effect: consider these two dot product implementations:
/*this loop is unrolled by 4*/
/*this loop computes the remaining (non multiple of four) */
/* This one is not optimized and looks like the one for the FFT */
double prod(double *x, double *y, int len)
{
double sum=0;
int i;
for (i=0;ilen;i++)
sum += x[i]*y[i];
return sum;
}
/*This function in an optimized version of the previous */
double prod(double *x, double *y, int len)
{
double sum1=0, sum2=0, sum3=0, sum4=0;
double *end = x + len
while (x end-3)
{
sum1 += *x++ * *y++;
sum2 += *x++ * *y++;
sum3 += *x++ * *y++;
sum4 += *x++ * *y++;
}
while (xend)
sum1 += *x++ * *y++;
return sum1+sum2+sum3+sum4;
}
I have recently used this optimization on my code and found a performance increase of about a factor of 3 (on a Athlon 500). The fist version of the function has three problems:
1) The loop overhead is very expensive compared to the 2 float operations inside it.
2) The indexing is ofter more expensive than simple pointer increment (thought not always).
3) This one is the most important. In the first example, each sum (+=) requires the previous result of the sum to compute. Now, the problem is that the FP ADD pipeline is stalled. The time it takes for each addition is no more one cycle, but the length of the pipeline. In the second example, the use of multiple partial sums prevent that.
Also, as I said before, a good FFT coded in C can be as fast as the processor is. The Java code can be as fast if it is good, but not twice faster, as in the benchmarks. But because, the FFT code wasn't optimized, the performance difference likely came from the loop overhead.
Opus: the Swiss army knife of audio codec
...Oops, the post screwed up all the less-than signs in the loops... but it should still be obvious what's missing.
Opus: the Swiss army knife of audio codec
bigFORTH+MINOS
>java's floating point arithmetic is blighted by five gratuitous mistakes
>My question is, is this analysis and the observations still valid now?
The current version of the JDK (1.3) provides two math libraries one "fast" and one "accurate."
Jim
Two pissy things to avoid if you want C++ code to run really fast:
results suddenly change about, which happens to be where the array size starts to exceed the Athlon's 64KB level-1 data cache
AFAIK, the double values (and probably the float) aren't cached in the L1 on the Athlon.
Also, I think I've found another problem with your FFT: the use of the "sin" function instead of tables. This function is very slow, and it's performance depends a lot on the math library implementation. It is possible that the JVM implementation of the sine was faster.
Opus: the Swiss army knife of audio codec
The relevant questions are all about time to market, scalability (hand-helds to mainframes), networking, security, and quality. We should have benchmarks on these. Java would win hands down.
Interested parties should check out the JavaLobby and consider joining. There is a very interesting discussion on JSP vs. ASP performance there now.
I beg your pardon, FORTH is anything but dead. It has just evolved for example the plugin-and-play ROMs on all your PCI cards are written in a FORTH derivative, the original aim being to achieve platform independence.
Just because something isn't on view anymore doesn't mean that it doesn't exist.
-dp
Then take a proper multiple-process JVM and compare THAT with you're native code, and see which one hogs the most resouces...
You are making a complete unfair comparison.
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
Java as a language is fine. But Java on a VM just doesn't cut it for real-world apps.
I am currently developing a product series of WAP servers and gateways. A few competitors have chosen Java and they can support a maximum of 500 simultaneous users, and that with at least 256 MB RAM and 2 to 4 Pentium III 600 MHz+ processors.The C versions of similar products have no problem supporting several thousand users on a single processor 64 MB machine. Java just ain't in the ballpark.(I should also point out that the Java VM's are not very stable and crash frequently.)
Java's specs as a language are really nice. Why don't we leave this VM stuff to the specialty apps that need it and start using Java as a COMPILED language?
Life is a tale told by an idiot, full of sound and fury, signifying nothing.
William Shakespeare
And the fact of the matter is, the author of the article neglected to mention that gcc's optimizer is well known to be horrible.
Conventional programming wisdom is that "the compiler's optimizer can do far more than you could ever do in your source code". This is an indisputable fact, since the compiler optimizes not only the high-level language (e.g., C), it also optimizes at the assembly level, even taking into account specific assembly instructions for the architecture that you are running on.
Don't get me wrong -- gcc is a fine compiler. But anyone who knows anything about high performance computing knows and acknowledges that gcc is not used for performance-oriented code. One reason for this is because one of gcc's main goals is to be portable. As an author of portable unix software, I can appreciate how demanding this task is. Making software portable is extremely time-consuming and resource-demanding. Making software high performace is doubly so, particularly across multiple platforms and operating systems. It is extremely difficult to get both high portability and high performance, particularly for something as large and complex (and system-depedant) as a compiler.
gcc has (rightly, IMHO) chosen to emphasize portability and give reasonable optimization (vs. extraordinary optimization).
More conventional wisdom -- this time from the "Beowulf" side of the fence -- get your hardware cheap (i.e., x86), pay for good RAM and hard disks, but don't pay for any software except for a commercial compiler. There are several vendors who produce very high quality C compilers for x86/Linux, and there's even at least one freeware effort that has produced a pentium-optimized version of gcc (Mandrake Linux uses this compiler, for example). The difference in real-world performance between code produced by gcc and code produced by a good optimizing compiler can be measured in orders of magnitude.
So while the rest of his article seemed to be reasonable (although admittedly short and incomplete), I believe that the results are extremely skewed by using gcc as the "base-C" and "max-C" cases. I would like to see the tests re-done with a better compiler.
Final note: why does it matter how long it takes you to come up with a good set of optimization flags for a C/C++ compiler? By definition, optizations are highly configuration-specific (e.g., OS, architecture, etc.). The fact of the matter is that they can provide substatintial performance improvements. Java, despite the uniformity of VM behavior across platforms, might very well benefit from the same thing (it may only be a matter of time before such specific optimization flags are introduced, anyway).
Besides templates, macros, and multiple inheritence (which can sort of be done using interfaces instead of classes) ... there really isn't an incredible amount of difference between OPascal and C++.
At least they borland and freepascal have implemented it.
The entire MacOS, at one point, was written in Pascal.
I think it's unfair to compare the two languages by using test programs that are algorithmicly identical between the two languages. Any language can translate simple math and array functions into nearly equivalent assembly. The differences between the languages comes from the types of constructs that can be produced.
While I am only vaguely familiar with Java, I am a seasoned C++ programmer. My understanding is that Java doesn't support pointers. A well designed algorithm will often do things such as walk a pointer through an array instead of indexing off of it. I can't speak for everybody, but most veteran C/C++ programmers I know use pointers extensively to create optimizations in their algorithms that simply can't be simulated with references or other constructs. It's the ability to design these sorts of things that makes C++ a more powerful language.
I look at Java as little more than a C++ that has been dumbified so a Visual Basic programmer can use it. All that said, I have to agree that the vast majority of program time is spent waiting for external dependencies like SQL servers, hard drives, system calls, etc... As such, Java is likely to produce just as acceptable of programs as C++ the vast majority of the time.
Umm no. C++ Builder's compiler is most definitely not written in Pascal. You're confused with the VCL which is largely written in Pascal, but linked as .obj files after compiled with Delphi's compiler. And I'm not certain that is that case in anymore.
Actually the Borland OOP Pascal / Java objects models are almost identical. You want native Java code try Delphi (loose32) / Kylix (happy penguin and loose32 with qt ). Different language, same model..., faster (?) code.
It's not the same model, although there are striking similarities; just like there are striking similarities between the VCL and BEOS's APIs.
I take it you haven't read the article, and probably have no intention of doing so. Go read, then post.
Sure, but the point is that GCC can be used with several different libc implementations.
I think I get you point, but seriusly, would you like to assemble a house using a skrewdriver as hammer?
And I still belive that you never should prechoose a tool for ANY situration, no matter how convenient it is for me to use my favorite programming tool.
"Theres alotta savages in this town.."
'On traditional processors: probably, but what about the MAJC processor (see article) or Crusoe?'
Purpose built processors don't usually help. Sure they start off fast, but unless you have a huge development budget (and Intel has a huge budget!) you quickly get outdeveloped and then you are slower.
Purpose built processors may remain slower than the traditional x86 platforms but that is irrelivant. *If* the Crusoe processor becomes a success and *if* it would have special morphings code for Java then the end-user would experience no difference between traditional and Java programs.
And isn't that what it's all about?
Monkey sense
Most Java VM's are quite good at executing Java code, so the results are not all that surprising.
Java's biggest problem is in memory requirements. Metadata for classes is frequently much larger in size than both bytecodes and allocated objects. This needs to improve if Java is to become a more mainstream language.
There's a few things they've done that make Java look better than than real world situations.
1. Medium to big Java apps need 128mb-256mb system RAM to be useable. HotSpot increases memory footprint (uses memory for compiler + bytecode and native code is in memory), but does not enhance every type of app. HotSpot looks great on many benchmarks (small loop intensive apps tested on systems with much memory), but for many apps it slows things down.
2. By pre-running the code for 1 second to get how many iterations to use for 10 seconds, you're making sure that hotspot and JITs fully kick in, without countin any of their execution overhead.
3. Contrary to what you might expect, there's no UI in the game of Life benchmark.
4. The benchmarks are set up to favour run-time optimizations by having function parameters that are constant for long periods of time (ie matrix size)
Java is just fine when you have tons of memory, but if your users have 64mb or less, go with vb or cpp.
The benchmarks in the article have completely avoided any JVM/hotspot initialization overhead, as well as sticking to things JIT compilers are good at.
So it's a Mindcraft test?
;)
___
Yes, usually the faster code is much older than just 2 years back!
Where I work, most people un-install gnome and use fvwm, because its so much faster.
When I draw simple low-res diagrams for my web site, I use MacPaint 2.0 (1988) on a 50 Mhz '030 mac, and it's certainly the fastest and most responsive simple pixle-level paint program I've seen, running on 386-class hardware!
I think any long-time computer user can think of many examples where a newer version of a program ran more slowly than the last, often times much more slowly... and on the flip side of the coin, it seems (at least to me) that a newer version of a program rarely ends up being faster than older versions.
What actually happens, year after year, is an effort to add new functionality, sometimes very useful, other times bells and whistles. What doesn't tend to happen is an effort to make programs execute faster. Sometimes there is an effort to not hurt performance "too much", but the comparison (when made at all) is between the older version running on older hardware, and the new version running on state-of-the-art hardware, or sometimes even the hardware expected to be on the market when the program comes into wide-spread use!
Often times the tests of performance are highly subjective, and the subjective decision is made by the programmer (who would have to do a lot of difficult work re-writing his code), or worse yet by a manager, who would have to cost-justify the time and money spent to improve performance without adding new functionality!
Using gnome as an example, the last two interviews I've read with their developers, someone complained about general slowness. The attitude expressed by the developers was the usual "fast enough". Maybe it is, but it certainly is quite slugish compared to fvwm if all you want to do is run a bunch of xterms, netscape, and maybe a couple other plain X apps.
PJRC: Electronic Projects, 8051 Microcontroller Tools
It would have been nice if he'd also tested Java compiled to native code (such as with gcj) . He says the the point of his tests is to measure dynamic vs static compilation, so his experiments would be better if that were the only variable. It would also help squash the myth that coding in Java requires using a VM at runtime.
Patriot Sci. has a Java processor - actually it was a FORTH in Si processor origionally, but was 'retargeted' since FORTH bit the big one and became as relevant as LATIN. I'd like to try one out, since the RTX2010 only comes in (expensive) radiation hardened form.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
On the other hand, I am currently writing a prototype for a system that needs a lot of graphical bells and whistles (for demo purposes). I'm glad I have the Java AWT and Swing that I can use for this. In the past I worked on a project that needed a GUI, and needed to be written in C/C++. Our GUI code was produced by a GUI builder. You really don't want to touch the C-code that those things produce, it is typically a case of "it works, so let's keep our fingers off it".
It seems to me that software projects do not pay enough attention to the choice of the implementation language. It is often determined by personal preferences, without a proper analysis of the problem.
As for taking it seriously: it seems to me that the author makes plenty of disclaimers in the article. I think the purpose of his experiment is to see if all the prejudices against Java are justified. At the very least his conclusion should be food for thought.
MSN 8: Now Microsoft even has bugs in their ad campaigns.
IF Program equals
OS or Driver use C
ELSE Java does fine!
by Mike Buddha -- Someday the mountain might get him, but the law never will.
I agree. Did you know that COBOL is the programming language that is still used the most nowadays? So, let's bring COBOL back in the universities' curriculum.
MSN 8: Now Microsoft even has bugs in their ad campaigns.
I constantly see people struggling to get their java programs working- a new release comes out, and poof things break
Sun describes which classes that becomes dated when ever they update the JDK? And are you suggesting that java dont work?(which would be kinda lame, the language works, if somebody has problems. 99% of the cases the problem will be a programmer related one)
My colleague spent a few days trying to use java app to access a database and do a simple web app. At every step there were obstacles - money, flakiness, etc. In the end, he switched to perl, and he was doing stuff in no time
Ok, im sad to hear that. J2EE is far more suited for web apps. but ok, youll need to learn the language first. (AND NOT JUST READ SOME FREAKING TUTURIAL ON THE EXACT SUBJECT YOU FIND INTERESTING).. I bet the reason that the process was easier in perl, is simply your colleague has more experince with CGI perl.
At the moment, Java is good for mobile phones and smart cards. But for other things I'd give it a miss till the third/fourth generation of Java.
Ok, if you say so..
"Theres alotta savages in this town.."
Benchmarks are HOTSPOT-friendly. The same functions are called again and again.
:-).
The Life game is the only test which requires the garbage collector a little bit, but here C looks not so bad.
The Fibonacci test is not so important, it proves only that HOTSPOT and the IBM JVM do function calls faster on Athlon. It seems that both C compilers don't do good opimizations here for Athlon. Pipeline stalls might be the cause.
The FFT C code uses calloc() to create the FFT matrixes. malloc() would be sufficient. For arrays with 2^16 doubles the clearing of half a megabyte needs some time. A for-loop is used for copying data and not memcpy(). The Java code uses System.arraycopy()
The result is predictable.
Running current C compilers on an Athlon is also not fair, because both compilers will not produce good code for it. The Visual C++ didn't even had the Pentium specific flags.
I think that the compiler-based JVMs have gone a long way. I wish some of that developement resources had gone into the C++ compilers of both companies.
My conclusion: The Java performance penalty is reducing on some platforms. Linux on x86 is one of them, thank IBM. I doubt, that we will see a free JVM with that performance anytime soon.
C is a low level language. It is like ASM but with lots of structure that allows for much faster coding. The programmer is supposed to be in tune with his/her hardware, and so be able to write code to best suit it. It is amazing the number of C/++ programmers I see now who do not know the difference between the stack and the heap, or who do not know the mechanics of a function call or a memory allocation.
Java may be owned by a corp, but it has a good side-effect that it doesn't takes years for a 'standard' to appear. Sun is extending and changing Java as new ideas and problems arise. This is good, as Java probably has a lot more evolving to do.
On the other hand, there are small problems with objects moving to different packages in new releases, stuff being deprecated already, etc.
I really wouldn't mind a compiled version of Java. I know it's against Sun's cross platform philosophy, but having a fast version of Java for certain uses would accelerate its acceptance in some new areas.
Since the bytecode is compatible, we only need each OS to provide a single compiler that converts the bytecode to native code. We could even have this done by the user, and not the developer!
---
I really feel that Applets are the way things are going to have to go. Thin clients running with limited permissions in a secure environment, this lets you do what you need to do.
Sure, there's "everything you need" in HTML constructs, but you either have to have every step go through your server, which doesn't let you do dynamic things like updating the list of stated based on the country selection, or you have to use some *other* client-side language, all of which have horrible problems in my experience.
Sure, you could say that applets have bushels of their own problems currently, but in the end, isn't this how we want applications to work on the net?
Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
First, I wouldn't say it has everything one could want in an OOP language. The language feels like watered-down C++: templates (and STL), objects on the stack, const, references, and true multiple inheritance, are all missing from Java, but clearly would be useful. Yes, the absence of these features makes life easier for beginners, but it's painful to work around Java's deficiencies when you know how to use such features.
Unfortunately, Java isn't really multiplatform, either, unlike what Sun's marketing team would have you believe. Java is multiplatform in the same way that my Super Nintendo ROM is: I can play it on windows, linux, solaris, etc. I need an emulator, of course. Similarly, I need a "Java Virtual Machine" to run my Java bytecode: it's really just an emulator for a platform that doesn't exist. And if the emulator isn't ported to your favorite platform, well, tough.
But the main thing I don't like about Java is how gratuitously integrated it is. Why should the Java standard library (which is really a platform in itself) be inextricably bound with the Java language? It could easily have been made into a C++ library, since C++ has direct support for all the language features of Java. Then, they could have written the Java language/bytecode interpreter separately, and made it an option to use the Java platform. This would clearly be better for everyone (except Sun): I could use the well-designed Java APIs in my C++ project with no loss of speed.
The same thing goes for much of Java. Why does Javadoc, a program that generates documentation from comments in your code, have to be integrated with the rest of Java? It could also be used to document C/C++ code, with minor modifications.
IOW, Sun is trying to lock you into their platform in the same way that MS is with their strange APIs ; except that Sun's method is much more effective. I am sticking with C++.
I constantly see people struggling to get their java programs working- a new release comes out, and poof things break.
And the thing is, the old release isn't good enough to stick to - you can't say, sod the new release.
My colleague spent a few days trying to use java app to access a database and do a simple web app. At every step there were obstacles - money, flakiness, etc. In the end, he switched to perl, and he was doing stuff in no time.
At the moment, Java is good for mobile phones and smart cards. But for other things I'd give it a miss till the third/fourth generation of Java.
Cheerio,
Link.
would love to get my hands on Smart Firmware - Imagine switching on your PC, having it boot FORTH from ROM, ala Sun workstations. Sweet. Demo for Linux available.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
someone mod this up as funny.
It would be handy for anyone who wanted to write code that would run on Linux and Windows. This is important if you think that Linux is going to be sucessfull (chuckles) Marcus
Comment removed based on user account deletion
I hate to be pedantic, but wouldn't:
struct vec { double x; double y; double z; double w;};
double prod(vec* a, vec* b){
return a->x*b->x+a->y*b->y+a->z*b->z;
}
be even faster, since it involves no loops at all? You don't have variable-length vectors anymore, but are you going to do dot products in four dimensions, or two?
Actually, in modern processors, the trig asm ops are faster than a lookup table, and have more precission. To get the accuracy required today with a lookup table, you would have to use megabytes of memory, which is clearly unacceptable.
You are correct in that it relies upon the implementation, yes.
He really shouldn't have used any standard library functions at all (except for output).
pgcc produces very fast code, even *gasp* on non-intel platforms. It sometimes generates internal compiler errors, but in this case, simply send in a bug report and either reduce the optimizations or do what you were trying to do another way.
Also, why are portability and performance manually exclusive? The x86 gcc backend is certainly not suitable for a ppc, and, although large portions of the code are shared, the backend for each processor supported are not, and should be able to optimize heavily for that processor, in the same way that a JVM probably optimizes for the platform it is running on. Much of the optimization can also be done by the frontend, before intemediate code is generated; this does not rely much on the specific backend (and much of the system-specific things can be done by the backend). If this is not the case, and the frontend needs to optimize for one specific processor, there is always the -m option.
Why does everyone hate Java so much? Is it really based on its shortcomings or is it like a teenager not liking a band as soon as everyone else starts liking it? You're all too cool for Java!
Chris Rijk's "Game of Life" benchmark is completely bogus because it only uses a fixed array. Real world applications have to allocate, use and free memory. A realistic benchmark must allocate, use and then free large mounts of memory (more than will fit into cache). A much better benchmark is John Tromp's Fourstones benchmark, which is implemented in both Java and ANSI C.
Hey, you are one hell of a strange dude ...
Seriously.
C/C++ has dynamic optimization too. It has for a while now; try using the -pg flag sometime and gprof on the generated file. You will be amazed.
Actually, because of the memory usage of Java and our under estimation of the bottle necks of our system, we've had our server run on WinNT and AIX wihout a hitch.
I develop on Linux and deploy on NT all the time. It's a pretty sweet feeling to be able to do that.
Joe
Joe Batt Solid Design
...never focused on the fact that it is slow. It was always the fact that they had to go and invent another language that isn't any better than C or C++. I'm all in favor of cross-platform development, but forcing us all to maintain yet another codebase, in yet another language is just a royal pain.
If Sun had produced a platform independant C/C++ environment... wow... just imagine. We may never know how good it could have been.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
As of 8/14/99 the ratio of Javascript demand to Java demand was .304 and as of 4/6/00 it was .331
Since the dynamic optimiazation of Hotspot is actually in the lineage of dynamically typed languages (Smalltalk, CLOS, Self, etc.) it is poetic justice that the most widely deployed programming language, Javascript, is not only of that lineage, but it is overtaking Java -- the language that made dynamic optimization fasionable despite its less-dynamic heritage of Object Pascal and Objective C.
Seastead this.
Well - what to do when you have to hire programmers that only know C because they were all trained into it by using Unix and Winblows ? You have to switch to C. This is not because it is the best language, it is because of the market... in the IT industry, the winner is rarely the best products. Can you say "Microsoft" ?
Don't forget that before Windows came out people were still using all kinds of languages. When MS-DOS was king, plenty of guys used Turbo Pascal to code, as well as assembler.
If the code spends most of its time executing system calls, why not use something easier and faster to develop in than Java, such as Python, Perl, Tk, or Pike?
Java has no asynchronous networking - every time you make a networking call, you block the thread that made it. I can't think of a less suitable language for network server programming than Java.
this is important with regards to server-side java. i build on my nt station and just drop in the jars on the production hp-ux server. I LOVE THAT. plus the fact that i can use my classes across various different application servers is a big plus. we're using the same business logic that we use as our gui client application. they say java doesn't live up to the hype but it definitely lives up to the portability and scalability hype! java is very powerful in this arena. i plan to use it for years to come.
--
J Perry Fecteau, 5-time Mr. Internet
Ejercisio Perfecto: from Geek to GOD in WEEKS!
--
And Justice for None
Here's the link: http://java.sun.com/aboutJava/communityprocess/jsr /jsr_051_ioapis.html
C doesn't have any particularly aesthetically pleasing IO libraries for this, primarily because by the time network programming becase so ubiquitous that better frameworks were needed, much new development had moved to C++. For an example of an extremely well designed C++ networking framework, see the ACE project which supports many different single and multi-threaded programming models in a portable fashion while still allowing you to use high-performance features (such as asynchronous IO) that are not supported on all platforms if you want to.
Thanks for your efforts benchmarking Java - it was very interesting to me, and I've been thinking of doing similar benchmarks myself. You beat me to the punch!
I ran your code through some tests on my Linux laptop (Mobile Pentium II 400MHz, 128 MB RAM, Red Hat 6.2) using Sun's (Blackdown) JDK 1.2.2 and the 1.3 preview releases from Sun (utilizing HotSpot) and IBM (with their high-performance JIT).
Overall results: compared to un-optimized GCC baseline, IBM's JVM ran 22% faster (while full GCC optimization was only 17% faster than the baseline!). Sun's "stable" 1.2.2 release was 72% slower, and the 1.3 preview (with HotSpot) 17% slower. Interestingly enough, the 1.3 classic JVM was 5 times slower than the 1.2.2 release, so there's probably a huge amount of debugging code in the preview release. Full release might be a totally different story.
Anyhow, bottom line is that the IBM 1.3 JVM runs faster than C, given the type of code in the benchmarks - which, incidentally, is probably algorithmic optimization wise pretty much like most code out there: written in a hurry, and "good enough".
Ask a silly person, get a silly answer.
Yep. Never understood the JVM, which is essentually an arbitrary definition of a stack
based processor that happens to rub every modern
RISC CPU the wrong way. Why not use the AST for executable format instead of some arbitrarily
chosen instruction set with no connection to reality?
Pascal is a toy language, but I remember Turbo Pascal being the most wicked PC compiler by far for a while. It did really evil things, but the generated code kicked the crap out of contemporary C compilers.
The product I work on has over 3000 .java source files and various other non-java compilation related activities interspersed in the build process. We did have solution similiar to what I imagine your "ant" is like, but for us jikes is still faster.
does not apply to CPUs which have a special fully
pipeling int-float conversion instruction like SPARC, otherwise hell yeah. Even consider float loop iteration counters...
A faster VM would certainly help, and perhaps better algorithms in their painting and event dispatch schemes.
Heh, painting algorithms.... Swing can paint just fine, at 640 by 480 I was getting a full 3 FPS on a simple 2d app (I had to draw about 50 circles of average radius 5, onto a black background).
And that's why Swing is worthless. Because you can't even write a turn-based space strategy game in it.
-Dave Turner.
Become a FSF associate member before the low #s are used
Note that C now has a "restrict" type qualifier, specific to pointers, which addresses the very optimisation problem you describe. If a pointer is restrict-qualified, it is a hint to the compiler that the objects pointed to by that pointer cannot and will not be referenced by any other pointer.
Test C and Java?
They fit not in the same mold
Apples, Oranges
That's why the math guys use Fortran ;)
Seriously, though, C's never been known for even decent math performance.
I didn't check out the source to these tests, if available, but my guess is they don't use very many OO features. (Probably about the same code for C and Java).
I'm not surprised that java performance can approach C's for for loops on integers. Since the base types aren't Objects, you don't have any of Java's class mechanism overhead. There's a reason that they made these (int, char, etc) not be classes, and that's because without it, performance would be hideous. (Of course, you lose a lot of orthogonality and beauty... too bad.)
The java class mechanism is cute and easy to learn (with some exceptions), but incurs a lot of overhead because of the way it was designed. Some of this stuff must use runtime checks to make sure the language is still safe (like during downcasts and modifying arrays of objects). No matter how many optimizations you perform, OO in Java will be significantly slower than static languages like C++. And Java without OO is just a dumbed-down (but perhaps more portable) C.
Sorry, I did mean 2.96. I think they are planning to go directly to 3.0, but I'm not sure.
There is no standard C library under Win32. (However, the Microsoft C/C++ library is sort of standard under Windows CE.)
Actually, I believe Mandrake no longer uses pgcc because of the instability (someone correct me if I'm wrong). If pgcc barfs on you during compile, that's one thing. If it causes wrong answers or segfaults during program runtime, that's completely another (in response to another poster).
Your comments about gcc tho are pretty much on the mark, although I was under the impression that on x86 gcc was a decent optimizer.
Apart from the obvious memory footprint and CPU overhead problems - java did not come anywhere close to GTK for the actual problem at hand.
90% of our displays will be running on remote Xservers over 100mbps links, and Java's lowest-common-demoninator approach to graphics means that the whole screen gets updated as 1 big pixmap refresh each time through the loop. Some of our displays need to do 5-6 fps over 100mbs LAN connections on 1024x768 8bit displays, and Java cannot acheive that using swing.
For remote displays, Java is not there yet.
Having said that, we got good performance using Java-GTK bindings, and writing the demo application in a totally non-swing fashion. But then again, python-GTK looked better all round (faster, leaner, easier to read, etc).
In the end, we are going all C/C++ using Motif, for politcal reasons, (adaptability of all the old codebase ...) but GTK or Qt is not out of the game .. yet.
Btw - we did not get any measurable difference between Qt and GTK. GTK was generally a bit quicker and leaner in most cases, but required more code than doing the same thing in Qt. For some other things Qt was quicker and leaner.
The results of these numeric tests surprised me, but I'd like to have seen Watcom/Borland C compilers used, as both have a reputation for superior numeric code generation to Microsoft's Visual C++ product and GCC.
I'm sceptical. I would doubt any review that puts Java even close to C in terms of raw performance of code.
Sure...
Bill, embedded software developer.
For an example of loop unrolling in C++ code, see the Matrix Template Library. Pretty cool.
One of the easiest languages to learn (provided that you understand OOP). I tried C++, and I failed (for now). I tried Java, and it is very easy for me. And for the ease of learning, it gives me immense power. Everything anyone could ever want in a true OOP language.
It is also multiplatform... we all know about that.
The only language I can think of that comes close is VB. VB is Windows-only, (well, you have VBA in Office98 on MacOS, OK) and it doesn't give you much of OOP (inheritance, etc.).
Finally, there are a lot of people out there that will learn a language simply because it's in demand, so that they can get a lot of money paid for writing things in it, and Java wins here as well. Just go do a search on Dice.
The only thing that bothers me is that Java is now definitely being controlled by a corporation. I'm pretty glad it's not Microsoft, but I'd still rather have it controlled by an unbiased group. OTOH, without Sun's promotion and development, who knows if Java would ever rise to where it is today.
Let's just hope that the damn applets will fade out... I just hate them! Please correct me anywhere you think I'm wrong - that's what the Reply link is for.
--
Just a thought... If you have to rewrite your Java code, it might be because that it wasn't written well in the first place. Of cause we all know, that if we write something in M$ java, it will only be able to run on a Windows PC. But if we write some Java code based on Sun's Java specifications, we have a piece of code, that needs no rewriting. ... and just another thought: If a programmer makes some good Java code, that runs well and stuff, the user of the program (or the webpage) won't see that it is Java. But if the programmer makes some bad, slow Java code, then user will right away see that its java (u know: "Loading Java..." for example, if we are talking applets). Then here is my point: Every time people use some bad Java code they see it's Java right away, but if they use some good Java code, they don't even regencies that they are running Java! (because it runs just as well as a program written in C/C++ or another good/fast language) - That could be one of the reasons why Java have such a bad reputation and why it's having such trouble getting rid of it... but who am I to know?
In my experience, aside from gross overheads such as those imposed by interpreted languages, the actual performance of server-side business applications depends primarily on database access. Put simply: the cost of database access is so high that it wipes out subtle shades of difference between language A and B. The key to building fast applications is the choice of good tools, and an understanding of the impact of SQL clauses like ORDER BY. The relative speed of compiled Java over C would be a very bad basis for chosing the language for an important project.
My blog
The main problem with the metadata and the bytecodes are that they reside in the data portion of the process running the Java VM, and hence are typically not shared among processes, the way code portions can be shared.
I'm aware that Sun and Apple are working on this, but I'd like to see a day when my Swing application doesn't eat 24 megs just to show a simple window.
I was quite astonished by this benchmark, especially the fibancci part; there is virtual nothing to optimize her beside perhaps calls and inlining (which all compilers should handle somewhat descend in this simple case) and tried to reproduce the benchmark using the given source code. The results where somehwat different from their results...
:)
Results on unmodified (*) source taken from the website: (Average values given by the program)
Sun JDK 1.3 HotSpot + javac: 111.8,120,123,120,119.0,119.8,120,118.8
Borland CBuilder 5 C++ mode, max optimization (IDE button+PPro setting+use registers): 133,135,130,131,132,131,132,131
(*) I adjusted the baseline for my PC but that's just a constant factor to the results for all programs.
Of course if you do yourself a havor and change the declaration of doFib from "int doFib(int fib)" to "inline int doFib(register int fib)" the results are much better...
Again Borland CBuilder as above: 210,188,162,161,161,161,161,160
I would think the benchmark is somewhat strange, especially at the fibonacci benchmark both languages should be nearly the same (given a reasonable JIT resp. C++ compiler) since the function is so simple that it could be written by hand in ASM without any trouble!
Not that I get jollies from plugging one of my own projects, but perhaps you should take a look at
http://pysdl.sourceforge.net
It's a Python binding for SDL, SDL_image, SDL_mixer, and SDL_ttf. Currently there is no circle primitive, but adding one would be trivial.
The only problem with JAVA is that the poseter is right about the write once, rewrite anywhere. Java under LInux != Java under MacOS != Java under Windows != java under Solaris. In fact on the Mac, Java can take three forms, Apple JVM, Microsoft explorer JVM, or Netscape JVM, and they are not the same.
To say nothing of JVM versions within a given platform...
Sun tried to make a great technology, where you could have true cross-platform compatability, and where it was easy to learn to code for it because of its similarity to other languages (most like C++ IMHO). It is not working for the same reason networking and the www are not working, Vendor-introduced incompatabilities.
The only reason these technologies are thought viable at all is mainly the dominance of certain technologies (eg 90% of pc's are Wintel, so if you write for MSJVM, you have 90% of the audience.)
In order to help you choosing the best VM, you can check the Volano Benchmark .
You will see there that the best VM is Tower TowerJ 3.1.4 for Linux !
Second point, I never doubt that java on the server is a good solution now. For me, the only trouble with java now is the memory gluttony.
If some of you want to test Jsp/Servlet, here are some good open source products : java.apache.org (JSP, servlet), www.enhydra.org (JSP, servlet, EJB)
Hopefully we will see an effort to optimize the Java libraries soon, for startup time as well as for speed, or else Java will become a pure Serverside language.
Try out fish, the friendly interactive shell.
Wouldn't a logical way to workaround this problem be to run multiple Java applications using one JVM?
I believe I saw some Java application a while back that would start up the main() function of other classes, acting as a sort of shell for Java...
Of course, in doing this you lose isolation between your applications (which can be a problem if your application doesn't play nicely with other threads that are running in the current JVM) but still...
-Felix
arvind rulez
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
The problem is many of these sort of /.'ers have no actually (sic) programming skills, they just want to say Open Source in a zealous fashion.
I, a professional programmer, whose life depends upon the sale of my services rather than my code, would like to comment.
I scream "Open Source", because it makes my life a lot easier. I use a lot of proprietary software in my work (Oracle, Sybase Jaguar, etc. etc), and I can think of many times when a quick glance at a source code would've answered my question, rather than pouring over the endless amounts of absolutely useless documentation.
Of course, I see useless documentation in the Open Source world as well, and they annoy me as well. However, with OSS, I can just as easily read the source, and find my answers within. The overhead of doing so many be higher than reading a good set of documentation, but when such documentation does not exist, then with OSS, one is left with an alternate source of information.
OTOH, many /.'ers sound like I did in college--eager, intelligent, but lacking in experience. They scream "Open Source", may or may not have actual programming experience (and for the most part, undergraduate academic experience do not count), and tend not to see the picture from a "business standpoint". Yes, performance is important in many cases. However, at the same time, only in a handful of cases is it the most important aspect. My managers (and therefore, my paycheck) will not give a rat's ass if my code was the most optimised piece of art available if it was even days overdue. At the same time, if it were "acceptably" fast, they'll see me as "effective", "efficient", "productive", blah blah blah.
I see their point, though. Most traffic I see on these sites that I create tend to garner more revenue-per-user than your average portal (or even the average ecommerce site) does, making them a low-volume site. At the same time, many of the clients we service have strict deadlines; a manager at a Fortune 500 company's time being wasted for even hours due to a slipped deadline ends up costing us greatly.
Of course, this often means that I write code that is not even up to par with my own standards of cleanliness and performance, but that is life. Fast, cheap, good. Please choose any two.
Thanks for the information. I had never heard of this before.
the problem with the relative-to-baseline normalization of the graphs is that a bump in performance could actually represent a dip in the baseline performance and vice-versa. they should have been done relative to the average performance (and shown the absolute average performance somewhere).
It's a bit unfair to blame gcc for poor memory allocation: unlike Java memory allocation isn't built into C.
www.eFax.com are spammers
These results are of some interest to me, because my department (I'm a CS adjunct at GMU) has asked me to consider learning Java well enough to teach the third-year OOP course in it; my daytime employer has asked me to get up to speed in it for a proposal; I'm very interested in multithreading (which C++ is not so hot at); and I'm currently using a Java application (CCTool, built using the IBM compiler) to write security targets for a gov't agency. Current Java compilers remind me of the first Ada compilers back in the early 1980s. The Java application sloshes as it walks around, mostly due to thrashing. The thread features and the garbage collection are just a bit dangerous to use, and I've been told that Java applications have to be carefully written if you want them to run faster than a turtle. The posted comparisons don't seem to fit the real world experience I've been having, but most such comparisons tend to be cooked to favor one or another language. Cheers,
But real world applications use objects extensively- we go to Java partly because it lets us do that (although there are other reasons, like added security.)
OK. I hear you say- why do you like it?
Well, it shows that if you really get stuck with a Java applications performance, it is often possible to redesign it to get C's level of speed.
And besides I love seeing the C++ lovers choking in their beers. (Java is as fast as C?! sppkkthth) - I get wet but its worth it.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"You have overhead of loading JVM each time. If you don't than it's different.
I'm using "ant" - java compile utility, which compiles something very complicated at one JVM run.
We are compiling our company product - 500 Java classes with jikes and ant/javac. You know the result? Time is equal.
So java is NOT slower than C anymore, even on big tasks, like compiling 500 files.
Andrew
The problem with writing servers and gateways in Java is that there is no way to do non-blocking i/o, or select(2) in the Java libraries. Instead, you need (at least) one thread per fd, which is often memory expensive. VolanoMark shows this off, and the fastest Java VM for Volano (TowerJ) is the one with the most scalable thread implementation. There is a proposal in process (java.nio) to fix this, but who knows when it will see the light of day.
I couldn't agree more. In my mind, Java is an integral part of the "Web API" when building wide area applications. I think the original post on this thread nailed it right on the head when he pointed out that the overhead is in the DB and not the logic before or after. Given this situation, portability and stability are higher priorities than eeking out another .1% of overall speed of the wide area application.
___
--
Java references are even more than that. They are in fact abstractions, "handlers" to refer to the object. In fact, you can imagine JVM where you have reference to the objet, which is located at the different computer. And the program doesn't know that!
Andrew
. .who more than 4 million registered users in 2,500 cities across the United States all using Java.
___
A good JIT will perform optimizations that C will never attempt, like code inlining. Inline functions are not standard C, but they are part of C++.
I modified the life source for C++, adding `inline' in a few strategic places... compiled with g++ it runs up to 50% faster than gcc.
Add garbage collection for C++ and I doubt if the HotSpot VM will do much better, if at all. At a certain level (i.e. machine instructions) they work about the same, anyway.
I understand, that to properly optimize the run time, a good profile of the code will be required.
My real point was that if the guy didn't even know that calloc() 'c'lears the memory then it sort of indicates a general misunderstanding of the language. A good
C/C++ programmer will have a firm grasp of the language and what kind of code his compiler is generating. This allows him to structure his code in a way that is
just as readable (maybe more so since there won't be any extraneous fluf) and performs far better.
Of course a good grasp of the algorithm helps too. Life is a program that should never have its main loop coded in more than 5 lines of code.
it's also true that the JVM takes a serious performance hit, due to its very nature. interpreted languages are slow. period. using a native compiler can result in a drastic speed increase, but the trade-off there is that most of these native-code compilers are in their infancy, and have difficulty compiling perfectly valid Java code. and compiler errors on valid code is a very frustating thing indeed.
in an ideal world, Sun would step up and produce a native-code compiler for their favorite platforms (solaris, windows, and linux, in that order, leaving apple to fend for themselves). this native-code compiler would also compile Java byte-code. does this sound like JIT? sort of, but let's keep in mind the phrase "optimized for speed". while JIT is faster, it still does not approach the speeds of native code.
however, this is actually indicative of a deeper problem. writing tight Java code is tough. it's hard to do. the standard API is large, bloated, and plagued with inefficiencies. this may sound sacriligeous, but it's true. to their credit, Sun has managed to tighten the code with every subsequent release. Java 1.0 ran slower than 1.1, which in turn was slower than 1.2, and in keeping with this, 1.3 seems to improve the speed even further, especially the JFC stuff.
but the real problem simply comes from OOP overhead. when you write "proper" Java code, you try to rely on Sun's supplied API as much as possible (so that you reap the development-time gains). but there is a penalty for doing so: you have no control over the inheritence, the efficiency, and the size of the API code. in a few projects i've done, i've been forced to go into the API, and tweak certain parts that i needed. specialize parts of the API, or rewrite them. this may take away their general-purpose nature, but also removes unnecessary crap from my core loops, which is most important to me.
a further problem with this is that development time then increases. i have yet to meet a project manager who truly sees the value of making code efficient. especially since doing so makes that little bar on the Gant chart, the one that represents me, stetch a little farther. they don't care. do it quick. dirty. they don't care so long as it's done _on_time_.
i've basically come to the conclusion that if you want it to run fast, you should (still) write it in C. if you can afford a slight performance hit (or your mind has been permanently warped into OO thinking), use C++. on the other hand, if you want to write it quickly, and speed isn't such an issue, go ahead and use Java. hey, it's fun to write. it makes sense.
but it's going to be a long wait for efficiency. i don't think that was really ever more than an afterthought with Java.
I have just done my own little and dirty performance test: http://www.physik.uni-freiburg.de/~stier/Miletus/p ub/Programming/Algorithms/Sorting/SortCl ass.doc.html Gnu C++ may be slightly slower than IBM JDK 1.1.8, but GNU C seems to be a lot faster.
Well, I think the problem is that since it is code, it is prone to bugs. One thing I have foudn in my cursury examination of standards in general, is that there are often grey areas, and in those grey areas differences. Often this turns out to be harmless, but sometimes it does not.
In particular there was a problem with MSNT DHCP at one point, in that it did not work properly with Macs. Both were technically following the standard, but there were enough differences in the messages Macs were sending at particular times, and the MSNT DHCP server's interpretation of those messages, that the end result was no IP for the Mac. Apple ended up changing their behaviour just so that this would not happen anymore.
HTML is a great standard, as is TCP/IP, but with different browsers/oses/etc YMMV. Ethernet can be subverted with the "wrong" frame types, etc.As for Java, I would imagine that basically you would find that your program works in one JVM but not in others, variously because of differences, grey areas, or bugs in the implementation you are using.
Java does not refernce count.
Anotrhr common misunderstanding.
Java Garbage Collects, but no VM I have ever heard of uses reference counting for that.
Go to the java.sun.com page and read up on the Hotspot compiler if you want to get a bit of a picture of how mdoern garbage colelction works.
The problem with "real" benchamrks is that, sicen they are a fixed and rpecitable test suite, all the vendors trick out their systems to do maximally well on them.
The BEST benchmarks actually are randomly selected real world programs. Unfortunately they can be tricky to measure, and none exist for the cross-platform type of tests Chris is doing.
They are too system dependant to be of any value.
A well seasoned benchmarker always does so by comparison. You could argue about what to chose as your baseline, but I think Chris's choice of gcc -o was reasonable, myself.
B. Johannessen
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
Then what happened to Corel Office for Java, or Lotus SmartSuite for Java, or any of the other apps that were promised.
In the real world, Java apps are slow, and feel sluggish, the way VB apps feel also.
The diff between C and C++ is fairly minor. the difference between any compiled language and Java is quite large.
Every couple of months for the last 5 years, some Sun shill has put out numbers "proving" that Java is as fast as C/C++. Too bad the JDKs aren't compatible, and the apps that really get written are pigs.
Java has been all hype since the very start. A lot of anti-MS people grabbed on to it, but it will always be too slow.
Look, I code Java for a living. I don't want to be a Java-evangelist (Javangelist?), but I've got a few problems with your post.
As far as getting the latest JDK in anything but Windoze, you can currently get Java2 v1.3 in Windoze, Solaris and Linux (with other ports on the way). The fact that they came out with the Windoze port first should be no real surprise to anyone: most folks are still using Windoze, hence there is more demand for upgrades on this OS than any other.
I've written Java stand-alone apps that are monumental in size and I've written Java server-based apps. I think that Java's main glory lies in server-side programming for web-enabled applications, but it is no slouch in the large stand-alone application market. You keep hearing people complain that Java eats up so much memory when all you want is a simple Notepad app. You need to understand what Java is doing and learn to work with/around it.
If you load a large app that utilizes many of the Swing widgets and interfaces, the memory load becomes a bit more understandable. On the large apps that I've written for Java, it has actually performed quite well (sub-second sorting and display on a 10K row table, etc).
Most of the comments that I see bashing Java are from people that have only taken a cursory pass at the language. If you try to code a Swing interface using the same paradigms as AWT (or C, C++, etc), you'll wind up with a slow monstrosity. If you code Swing the way it was intended to be coded (using the MVC architecture), you'll find that it's a remarkably powerful and full-featured GUI API.
At any rate...I'll get off my soapbox now. I really don't mean to tout Java as the be-all end-all of programming languages (it's not). But it is one of the better languages out there for the current direction of Internet-enabled programming.
In the immortal words of Socrates, "I drank what?!?"
For all the reasons already mentioned.
Spec98 (www.spec.org) is a much better, much more compelte test of the entire system.
However I STRONGLY recommend when I speak on this topic that you take ALL standardized synthetic benchmarks with a healthy dose of salt.
(1) They don't behave like real apps.
(2) ALL the manufacturers trick their systems out to do unnaturally well on these tests. That one manufactuer can trick its VM out for a particular stadnardized benchmark then another says NOTHING about how it will run your app.
To paraphrase Mark Tawin, there are 3 kinds of lies: "Lies, Damn Lies, and Benchmarks." The only real test is the speed of your own applications.
On the bright side, since Java is a standard, if you stay away from VM specific tricks 9aa bad idea for many reasons) you can plug a different VM under your app and test it with no effort at all.
www.
Well thats new. A self-reflexive troll :)
I don't see how anyone can make such a sweeping generalzation that Java is faster than C from these tests. Java and C are both compiler languages, what determines their speed is the compiler, or JVM used. So these tests mearly show that some JVMs can beat some C compilers. Since Java is a fad it is getting a lot of attention and optimization so some JVMs may be better optimized than some C complilers. I just doesn't make any sense to me to attribute speed to a language.
1. The first problem with java : Have any of you ever given thought as to how many of the business production systems you've seen is limited by I/O or memory, as opposed to the number of systems limited by CPU ? The problem with java is the HUGE size (MEGABYTES) of libraries,JVM etc. A program twice the size will give a severe performance reduction on an I/O and memory limited system. A factor of 10 will ... slow everything to a crawl. 2. The second problem It's easy to learn ... for small tasks, thus when making large systems you'll end up having inexperienced people, who cut their teeth to fast to really learn anything creating things .... not good ! (As some say - No pain , no gain) 3. who really needs portability Have you ever wondered how much of the software you wrote, would need instant portability - why risk suffering any performance penalty. - just my view
The answer is that,as Java matures, more and more of the run-time system in general is moving to Java code.
Obviously there always has to be a central "bootstrap" layer that starts out in compiled code. How muich of that rmains in C++ in the various VMs only time will tell.
those slow RDBMS and start using an object db like Versant to take one example. If you do it right with client side caching the database shouldn't be too much issue.
http://java.sun.com/j2se/1.3/docs/api/java/lang/S
Actually, there is a StrictMath in 1.3 now. It produces slightly slower results than regular Math, but it conforms to c floating point exactly.
it looks pretty useful
-jim
I agree with that actually.
A big one is that VMs don't yet share the calss data so every time you launch a VM you get a significant memory hit (6 or 8 meg currently, I believe.)
The point thoguh is nto that java i 100% perfect but that at least one "intractable problem", Java computational performance, has been solved to some degree and is likely to gwet even better.
As someone else pointed out, dyncamic compilers are in their infancy. If they can already compete favorably with the older, well evolved technology of static compilers, it doesn't take much imagination to guess what the future holds.
In re memory usage, thats actually a much easier problem. I would expect to start to see solutiosn in the next few major releases of the VMs from the top VM makers.
The tests they did here didn't use any memory in comparison to any normal, usable program out there... the game of life ? Why didn't they test this with 'Hello World!' ?
What I'm trying to say is that if they had used a little more advanced program then you would see that Java would start coughing and choking and crying for memory and other resources in no-time!
Write a little graphical app for example... use swing if you like (gnah gnah gnah:)
You know, when I saw the headline I seriousely thought about quiting C and start using Java!
(Wow that was so funny, I'm can't stop laughing:)
This post is powered by caffeine
Another test would be of course to take some C algorithms then convert them into Java and compare the performance.
Also interesting to note is that no other typical C coding techniques are being used - such as variable localizing, all variables have been set to scope an entire function not just the loop / section it is used in. However gcc and MSVC should be able to automagically perform those optimizations for you.
And they give several examples where java will produce incorrect results in numerically intensive applications.
My question is, is this analysis and the observations still valid now?
in the last 2 years i've seen some *beautiful* applications written in java and implemented using swing..
just because the average bear might not be able to build great applications with the toolkit does *not* mean the toolkit is horribly deficient.
check out argouml, togetherj, etc, etc, etc.
there are some really well done ui's these days in swing..
cheers.
I can't estimate the extent to which dynamic optimizations went into the results of the article in contrast to good optimizations from scratch.
Nevertheless i think dynamic optimizations are the thing to come: it costs a lot of man hours to find ideal optimizations to code, (you need to figure out the core routines, think about which optimizations make most sense for the current architecture, check those assumptions against reality) and man-hours, in contrast to cpu-time, don't become much cheaper. The dynamic optimizer does all that work for you, and even optimizes for different starting conditions/parameters by looking at what is *really* taking time now.
Look at the success (regarding computing power per bucks) of transmetas crusoe. A dynamic optimizer can gather far more hints for optimisations (branch predictions, loop length, array sizes, memory lookups) than a static one, in the latter case the programmer has to give all the hints (compile a subroutine with the correct set of optimisations, sort the loops right, sort branches, keep in mind some ranges for parameters and how they affect loop length, for some compilers throw in compiler directives, etc.) and even has to reconsider when porting to another architecture.
So with static optimizations it's either optimization limited to the part the compiler can see at compiletime (except for very basic stuff, every decent compiler will get that matrix multiplication right) or man-hour intensive and thus costly optimization.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
The pity of it is that the Java VM is not quite general enough to cleanly and nicely support all kinds of programming languages. Wouldn't it be nice if you didn't _have_ to use the Java language to take advantage of all the work put into the VM and libraries? Not that Java stinks that much, but lets face it, there are better things out there for sure.
Well of course you can, you can use Kawa for example to write Scheme, but there were a lot of hoops to jump through to do it and even then there are difficulties.
I guess Sun couldn't care less about this. Probably they actually consider it a feature. It would be great if the open source community developed a competing VM specification that is designed to support pretty much all languages equally as well.
...what the analysts may say.
As a user, for me Java applications are second-rate applications. The bottom line is that on my computer and OS of choice they slow and buggy as hell. That is my perception as a user, and until that problem is addressed, really, who cares what the numbers say?
Mind you, as a developer, I love Java.
(Please browse at -1 to read this comment.)
... I'd have to congratulate whoever came up with the coffee cup to attract all those coders :)
This post is powered by caffeine
You're a fucking moron. I would argue against what you said in that post, but it is so retarted that isn't worth any more keypresses then what is here. I pray to God that you are just trying to be a troll, and you're not really serious.
WAR IS PEACE, FREEDOM IS SLAVERY, IGNORANCE IS STRENGTH. The Party - 1984
Uh dude? Most companies who want to make a profit on their software don't want to release their code to the public without licensing fees. Open Source is not nearly as profitable as closed source. Support and advertisments are pidly shit compared to licensing fees. And to help you out, Java is a good language for portability because there is no porting. If you want it to run quick on your processor you just compile the code for your system. C++ and C are portable but across platforms you need to make library changes and such things. Java needs none of that. And of course you can always compile a Java applet as just bytecode which will be run on a machine's JVM. If we could get some JVM modules in our kernels things would be awfly nice...
I'm a loner Dottie, a Rebel.
first off , pick the tool that suits your need. Now with that out of the way, i must vent my frustrations. I really cant understand the all the "Java is slow", "Java dont work" , "Java arent opensource" i am getting from my fellow coders around the world. Most of which never have use the language for a serius task. (cumon, a hello world applet arent a application). It seems like the Java is facing fire from to camps, both the Pengiun coding dudes, AND the Microsoft community. The Microsoft coders i understand, they see Java as an attack on their bread and butter, VB. But the linux folks? Why? As an example i created a node on a certian (very cool)website (claming to contain Everything :o) about why you should use serverside java for webside application logics instad of perl based CGI.. Im a freaking consultant, people pay me to hear what i have to say about theise things(and I actually have tested thiese things in different senarios). But my node? Was offcource heavily down voted(same as bad carma), and well i guess that tells a bit about our linux developer community. Look at the other comments.. The linux developers have a problem. They do not belive in the saying "use which tool fit".. They just wanna code C/PERL/Phyton or what ever..
I know i am being very general in my judgement, but I belive the fact that Linux users are a bit TO nerdy for their own good. I for example have convinced my boss(a side node is that we are VERY much in bed with M$(i work for Denmarks third largest IT consulting firm)), that Open Source arent that bad an idea for consultant firms. But convince one of my good (linux using)friends to try out photoshop for instad of that crappy little gimp(i hate it.. after working with Image manipulation programs like PhotoShop, Photogenius(amiga) and likes.. It seems very unmature(well, stop crapping D, and help out..!)) they blow up.. Why? ALLWAYS LOOK AT THE JOB YOUR DOING, THEN PICK A TOOL TO DO IT WITH
"Theres alotta savages in this town.."
At some technological Universities such as Michigan Tech they have actually dropped C/C++ as a class, and have replaced it with java. If you want to learn C/C++ you have to take this small post Java class that basicly only teaches you the difference between the two languages. Personally I think it's stupid to replace C/C++ with a language that's less used in todays industry.
WAR IS PEACE, FREEDOM IS SLAVERY, IGNORANCE IS STRENGTH. The Party - 1984
Try : "And the big benefit Hotspot gets here is that Hotspot inlines recursive calls to a certain depth. I doubt the C compilers are doing that."
100 is the baseline. 110 means 10% faster than 100
You're wrong because Java is a compiled language, just one compiled at run-time.
This is unfortunate for start-up times of gui apps because the whole swing stuff needs to be compiled on startup. I'm sure someone, sometime will solve that. In the meantime it's fine for non-gui apps, and not all that bad for gui ones as well.
I have the impression that the aliasing problem happen only on "real" programs, not on benchmarks. Aliasing is usually a problem only if the program contains a number of function which calls each other. At this point there are ways for variables to be aliased. For benchmarks, usually every big things happen in a single function which define everything as local variables, there is no problem of alias at all.
... if you're running the raw 1.3 then your running Hotspot 1 -- client. Try Hotspot 2 for Servers.
Again I'd like to know all the details of your envrionment. If your running so low on memory that Java is swapping, for instance, then we KNOW what the outcome will be before you start.
Nobody has suggsted that a VM can run in as memory tight conditions as native aseembly code executables do. That would be ratehr amazing if anyone pulled it off. BUT memory is below a buck a meg these days. I'd argue systems with less then 128meg are becoming pretty rare and outdated. After all, even Winfroze 2K requries more memory then 64M.
Hi,
Those graphs in the article are extremely deceptive since the y-axis does not start at zero. If they did, the curves would be much closer together. As it stands the difference between most curves is less than 30 percent and that is nothing to get your shorts and knickers all bunched up over.
Still, it was a good article even though the sample programs are a little trivial.
There were a couple of ideas from the article that struct me. A) Java is run-time optimized B) Java requires (most of the time except things like jcc) a JVM. Another point mentioned was that the size of memory blocks allocated by one of the JVMs (HotSpot?) would adjust to conditions given enough time. Well, I wonder if any one has considered a system whereby the JVM caches and constantly improves operating parameters for a given program (somewhat like Transmeta's architecture).
Of course, this raises some classic questions about amount of resources to spend on optimization vs. running the code, yadda, yadda, yadda.
Oh well. It is early and it is going to be a long day....
The real silver bullet to good programs is caffeine; lots and lots of caffeine! *twitch, twitch*
I can't comment about the other tests, but I've looked at the FFT code and can say it is very badly optimized. There are some things a C compiler can't optimized because of aliasing, but a Java compiler can. There are ways to code these kinds of things so it can work, for example doing explicit loop unrolling. In the FFT code he had, the FPU pipeline would always be stalled, because lots of loops only have 4 multiplications and 2 additions.
What makes me even more suspicious is that I have a K7-500 too and I have done some tests with a heavily optimized FFT (fftw) and I get a performance around 400 mflops. There's just no way a JVM can be 220% faster than that. So my comclusion is "with poor code and poor optimization, Java can be faster than C".
I don't want to take position of the whole Java vs C speed, but what I'm saying is that at least his FFT test is flawed.
Opus: the Swiss army knife of audio codec
Let's get a full qunatification of the speed differences between C and assembly, then we'll talk. Meanwhile, asm rules.
Has anyone looked at this subject? It may bring up interesting results: even in this test GCC did generally better then MSVC, and MSVC is available on 1 platform only (Windows), while GCC is available on many.
Every expression is true, for a given value of 'true'
The latest JDK is only in beta for either Solaris or Linux, which hardly constitutes "Java 2 v1.3" as being available.
;-)
Plus, this is Java's mantra; "Write once, run anywhere."
Java applications, in general, will start off being memory hogs. This is just allocating memory for the VM, for use with the application when needed. This of course is only part of Java's memory footprint, in any sizeable application.
Even non-graphical Java applications can be slow. For instance, take a look at Sun's own Java compiler for JDK. Compare that to Jikes
C and C++ interface programming is not defined by one paradigm, so it doesn't belong in your statement regarding slow graphical Java applications. You can use any number of design patterns, for any number of toolkits, so it's an inappropriate blanket to group it with AWT.
Anyway, If you were to use MVC with C, would you somehow consider the interface faster?
Using the MVC paradigm will not make a Swing application faster. Generally speaking, it means using more classes. This means larger bytecode, and more memory consumption. Of course you can clump more or less all of the interfaces into one class, but this isn't really following the MVC paradigm. If anything, it defeats the purpose.
Swing also has the disadvantage (over normal AWT) of having its widgets implemented in Java. This is why Swing applications feel much more sluggish to even AWT applications. No matter of paradigm can help that.
This, of course, doesn't even cover the tons of drawing problems Swing has.
That said, Swing certainly has a good API; the only interface API I like more is GTK--'s.
Ok, go out and write a program in java.
Then, go out and write the program in LPC.
Now, tell me which one has a better object oriented design philosophy.
If I had to rate how well a language was designed to be object oriented, I'd rate them as follows (on a 1 to 10 scale):
C: 0
C++: 2
Java:3
LPC: 10
Too bad lpc isn't generalized to be used for any task. I wish someone'd write extensions for the language.
In case you want to know what I mean by how smooth objects work in LPC, I'll put it this way. In lpc, for example, you can do a switch statement on an object (or a string, or any other variable for that matter). Objects can be referenced in many different ways, from simply running functions on the filename of the object in question, to using find_object to find objects matching certain critera to filtering through all objects currently loaded in memory. (this is neglecting the simple way, of just storing it in a variable when you create it - this is assuming what you're writing knows nothing about the object). Everything just interfaces so smoothly in lpc... grr, I miss it : P
- Rei
Hey, guys, I'm just pleased as punch to report that it's a fleet of a hundred Vogon Battle Destroyers!
My main problem with this comparison is the fact that its quite apparent that this person is attempting to distort results. For example, they try to make it look like some C and Java compilers are running several orders of magnitude faster than the others, but if you look at the scale on the side of the graph you can see that they're all running fairly close to each other in speed (it doesn't start at zero). This is a commonly used distortion tactic by people trying to push something. Memory issues aren't addressed, nor is load time, two of the biggest issues. Then, the person pushes a statistic that java code is developed 2 to 4 times faster than C code. From my experience with college projects this is just *not true*. This is a statistic, assumedly pushed by Sun, to get companies to make their programmers use java. Compare the file size of a java program vs. the size of a c program, and the first issue (amount of "stuff" you have to write to make the compiler content, since it refuses to typecast even the most simple of things (if I do "if (someint) { do_stuff(); }, it should compile, dern it! ;) ).
Not only amount of typing should matter, of course. You need to look at debugging time. Java doesn't debug for you. I haven't found the language to be less prone to any kind of bug except memory leaks, but it eats up so much memory on its own it might as well have them. As for its multiplatform aspect, it doesn't even work the same with different JVMs, let alone different platforms.
So, I cast my vote against java here. The only thing I found it did better than C is object oriented programming, and yet its implementation of that is still quite poor. If sun writes another programming language, I'm not going to touch it with a 10 foot pole, and use a language written by people who know and care what they're doing, not just trying to hype something.
- Rei
Hey, guys, I'm just pleased as punch to report that it's a fleet of a hundred Vogon Battle Destroyers!
While this is true, it's not supposed to be. By design it's supposed to be write-once, run-anywhere. It's just stupid vendors who try and subvert this idea. Java under Linux and under Solaris are essentially the same...I've personally never had any issues between the two. Windows has it's own special problems, thank you M$.
This is the problem. It shouldn't be like this at all. A JVM should be a JVM, regardless. Maybe some performance differences, but Sun's and Apple's and Netscape's should all be in line. This pisses me off to no end. Corporate short-sightedness is ruining an otherwise wonderful concept.
Microsoft's fux0ring of the JVM is to be expected. But I don't know what Apple or Netscape's excuse is.
----
----
"I used to listen to Null Device before they sold out."
Has anyone looked at the code? I looked at some of his C code. Its in the directory with the makefile life.c, fib.c and fft.c
Take a look at life.c and draw your own conclusions.. For example
init0 = (int*)calloc(max_x,sizeof(int));
init1 = (int*)calloc(max_x,sizeof(int));
init2 = (int*)calloc(max_x,sizeof(int));
for (x=0; x< max_x; x++) {
init2[x] = 0;
init1[x] = 0;
init0[x] = 0;
}
I could at least double the speed of his code in about 15 minutes. I didn't look at his java code but I suspect there aren't nearly as many dumb things in it.
I might have just blown the whole thing off if it weren't for the fact that he claims MSVC with full optimization is slower than GCC in 'braindead' mode for a couple of tests. I've seen code GCC generates with -O, it makes me laugh.
Perhaps the FFT algorithm used in the benchmark's C version isn't hand-optimized. The hand-optimization works because it relies on deep knowledge of the FFT structure that no optimizer can hope to grasp. I THINK THIS IS BESIDE THE POINT.
The person who wrote the benchmark just needed some compute-intensive algorithm, and a simple FFT does OK, and is a perfect stand-in for general floating-point/array-using algorithms. A lot of other code will look (from an optimizer's point of view) similar to the simple FFT, and so we might generalize C vs. Java comparison to general computational algos.
Sorry about the mention of C/C++ when I was talking about coding paradigms for GUIs. I'm not a C/C++ coder by trade, so I'll gladly rescind my inclusion of them in my statement.
You actually make my point quite well without this, however.
Swing is built from the ground up on the MVC paradigm. If you do not use this paradigm when coding a Swing GUI, you'll effectively "disable" much of the work and code that has gone into Swing. No wonder people think it's a memory hog -- they're turning off half of its features.
Swing, when coded under an MVC architecture, operates quite smoothly and quickly. For those not "in the know" on MVC, let me give an example from my own experience:
In the old days of the AWT, if you wanted to display a list of data, the data was an integral part of the list widget. If you wanted to change the data that was displayed in the list, you would perform an operation on the list widget itself. Similarly, if you wanted the same data displayed in a table, you would need to replicate the data and insert it into your table.
In Swing, you use the model/view/controller architecture (MVC) to separate content from display. Actually that just accounts for model and view. The controller refers to the interaction between the data and the display. This control is typically bundled together with the view (display widget), but can be separated out rather easily.
The benefit of the MVC paradigm becomes readily apparent when you take one of the examples I used above. If you want to display the same data in a list and in a table, you don't need to replicate the data. You set the model for both of the GUI widgets to the same source. When you want to change this data, you simply change the source (the model) and both of the GUI widgets are automatically updated with the change (all Swing GUI widgets have listeners on their models that watch for changes).
With a subtle change in your coding model/paradigm, you can acheive _huge_ benefits in both coding time and performance by simply operating within the parameters that Swing was built on.
In regards to your question of using MVC with C, it would have to depend on the libraries that I was using in C. If the libraries that I was using were built to use MVC, then yes, I would consider this a better idea. If not, then no, I wouldn't use MVC. The use of MVC is really up to the individual's coding style, much like OOP in general. However, if you don't want to code using MVC, then don't choose a tool that is based on it.
If you don't like OOP, then you really don't want to program in Java. Similarly, if you don't like MVC, then you really don't want to code in Swing.
--------------------------
In the immortal words of Socrates, "I drank what?!?"
mod_perl is much better than standard cgi, but it doesn't even touch servlets.
First, mod_perl doesn't eliminate the startup time. Each time a new httpd is forked to handle requests, the script must be recompiled. Is there some way around this?
More importantly, servlets answer all the requests from one instance of the servlet. This makes it extremely easy to reuse database connections, share information between requests, track sessions within the servlet, etc. Java servlets are much more powerful than mod_perl for that reason alone.
Mike
I am not here to question this benchmark, but have any one notices that this result shows how easy is to fake a result? Each of the compilers have at least one that it goes well, so let's say that I want to make a benchmark that says that gcc is the best. What I do is to do this study and then publish a lot of data or create a lot of tests that are similar to first (and maybe taking other areas in witch the gcc is good from the other graphs).
Then I publish the resulting benchmark, but don't mention the firt batery of tests or how I choosed witch test I would use.
This is also true for statistics, statistics can be used to prove/unprove almost anything. Did you know that you have 50% of chance of not dying? Yes this is true for only half of the people that ever borned had actualy died.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
From what I hear, there's a big wodge of effort going into improving graphics performance for 1.4, and it's already well underway. Of course, it'll be at least a year away, *sigh*
The embedded Java market seems to be taking off though...
Certianly the meta data for each class is huge, often bigger than the code itself. Still both Sun and (believe it or not) Apple are putting in work designed to only load the parts of JAR files that are actually used, I believe (though this is vague and from memory) by memory mapping the file and providing a good index so classes are loaded on demand. (some of this may already be in Java 1.3). The other strategy is to enable the sharing of meta data more effectively, or so I'm told, but I'm not sure what it meant by that... Smart people *are* working on the memory overhead. Sun is claiming up to 40% reduction in memory for the new HotSpot in JDK 1.3, but by all accounts 5%..20% is the common range. Still a 20% memory saving is very good.
Lord Pixel - The cat who walks through walls
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
I'll check it out fully sometime, but some things are definately out of date. (the authors also seem to have a flair for the dramatic) I haven't done a great deal of FP work in Java, but I'm quite happy with the results.
The poor showing of Visual C++ was very surprising, given that Visual is held to be one of the fastest x86 compilers. The fastest x86 compiler at the moment is Intel's own x86 compiler and it would have been interesting to see how it would fare on the benchmark. I have done performance tests between Visual and Intel's on graphics apps on a PII, and Visual's is rarely more than 5-10% behind Intel's. A future extension to this could be to test this code with Intel's compiler since it is downloadable on the web (full but time limited) and easily pluggable into Visual. I suspect that the weakness of the Visual complier may have something to do with Microsoft not optimizing as much of a non intel CPU and the recent K7 optimizations gcc has gotten.
A deep unwavering belief is a sure sign you're missing something...
Another post I sent in last night which quickly got rejected was this:
Unfortunately, that release came a little too late for me to do much about, though I have quickly tested the Solaris x86 (on the same hardware as the Windows tests), and the rests are pretty much identical, though Solaris was a bit faster. (but then, I was running without the desktop running which does help).
Also coming a bit too late was results from IBM's Windows 1.2.2 JDK, which I found a bit surprising - it did worse on some tests, and better on others, though I didn't have much time to test things.
Thanks for the replies... kinda makes it all worth it - it took me about 100 hours over 4 weeks to do this. (took up a lot of my evenings)
I better re-install Linux sometime so I can test on it again... (my last install stopped working for unknown reasons)
It'll probably be some time before I update the article - first I want to finish off my MAJC article, which really is too damn big. (22,000 words... ouch).
I don't think so - Pascal is fully capable of dealing with very large projects. I think the Mac apps used to be coded in Pascal...
Java 2 added some accurate cross platform math classes to address these issues.
You really don't need to replicate data, when it's stored in a widget, in those archaic and poorly designed systems that do that ;-)
You could just as easily query the widget, and then store changes back to it. This is somewhat similar, in effect, to doing this by event.
What you'll conserve in memory, you'll lose in execution speed, since you need to use several function calls to retrieve information.
Alternatively you could cache model data, and update on hearing of a model being changed, but then you don't conserve memory.
I honestly think Java's MVC memory consumption problems are mostly to do with the class overhead involved, and its interpreted nature.
As for the C MVC question, it was a bit rhetorical. A pure non-caching MVC system would be slower than a statically designed interface and model in one big clump. This is simply a matter of function call overhead and the like.
This, however, really doesn't matter in my opinion. The benefits are clear; ease of extensibility and portability. Proper object oriented C++ will be slower than procedural C, at a specialized task, but the development time difference is clearly in favor of C++ or object oriented C.
Swing's slowness goes beyond MVC, though. Certainly the class and function overhead is part of it, but ony a part. No amount of "proper" MVC coding will remove the unfortunate overheads. A faster VM would certainly help, and perhaps better algorithms in their painting and event dispatch schemes.
I use nail clippers to undo the hex-screws on the serial ports/ video card etc. Its not the right tool for the job, but its a pain in the arse and downright inconvenient to use the correct tool all the time, any blunt instrumment works as a hammer.
Java is elegent to program in, but its not easy for the end user, programmers are expected to understand what goes on under the hood of a computer, end users arent. Java and all these other languages that supposedly save programming time and just a cop out, programmers waste time learning multiple redundent languages.
Java is and always will be a cripled language that places limitations on what applications it is suited too. Java will never be a general purpose languange without proper hardware access.
Java will never be free, sun is just a microsoft wannabe, they are just dangling the carrot infront of our faces and watching us stretch. Does anyone really think sun is commited to open source ?
As an alternative to learning a new language for every programming task you undertake it would be much more efficient to learn one language and master it, if you know c well you can do anything with it, c places no limitations on what you can do.
Yea, i wish c really understood what a string is, but its easier to adapt and overcome c's inconveniences than it is to try and avoid them.
I used to be a java fan, but have turned my back on it for the above reasons.
Many people think Java is controlled by Sun. However, that is not entirely the case - for just about any area of Java you care to name, there are mailing lists and discussion forums where they discuss developments of various API's, and they really listen!
I know, I subscribed to the Java2D mailing list for a long time before they released the API. They asked the list many questions, and listened to everyone. Sometimes they shot ideas down if they thought they just were not a good idea (support for pallete cycling was one example here), but at least they listened to complaints about the way the API was going and did make changes based on input. One member even went so far as to code up the whole propsed Java2D API so people could try it out in practice and make comments.
Similarily, programmers have the opportuninty to voice thier opinion in code which is released under the SCSL (Sun Community Source Licence). Is it really "Open Source"? No. But then again, it does give you the opportunity to fix things and talk to the developers about how things are in Java in the clearest way possible - through code. Think of it as "free speech" where only one person showed up to hear you talk.
It is still true that Java is under Suns' control,
but never before (that I know of) has a company had a product with as much outside review and commentary in development.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
At work we used an oracle database with a charater based frontend in a Terminal Emulator on a Pentium 133 MHz and everyone was happy with it. Now we have a Pentium III 700 MHz with a JAVA based frontend and everything is at least 5 times slower ... That's why I HATE JAVE
Gah. Short sighted posts like this infuriate me.
It's an echo of what happened years ago: "Real Programmers don't use structured languages like C. Real Programmers use FORTRAN. If you can't do it in FORTRAN, do it in Assembly, if you can't do it in Assembly, it isn't worth doing. C is a cute toy language, but just no good for real world applications. The UNIX hackers who use it aren't sure wheter the print command is 'printf' or 'cout' this week, how is it ever going to manage to survive in the real world ??"Yeh. C forever. I don't know wheter or not Java will be the next-wave language, but saying that "C will never be replaced because there's nothing better" is just kind of moronic.
Cedric Balthazar Rotherwood
Sun Certified Programmer for the Java Platform +
System Admin. for Solaris
If you're actually running a simple chat server, then the results are okay, but Volano doesn't actually test Java optimisations very well as it spends most of it's time in pre-compiled static code, including the OS kernel.
Btw, when you say "There are some things a C compiler can't optimized because of aliasing", do you literally mean it would be impossible for any (legal/correct) C compiler?
If you have a nice FFT that can easily to 'converted' to another language, I'll be happy to try it out...
That's fine and all, but I think the point of the original poster is that since you don't know how fast the baseline is, then you don't know how fast any of the others are. Sure they are 10% faster, but faster than what? If it means that it takes 10 seconds to do one round of the Game of Life with GCC, and then HotSpot does *two* rounds in ten seconds, then sure it is 100% faster, but who cares! It is still unacceptable!
the language is irrelevant...
what is relevant is using the tool that will best get the results you want for the shortest design cycle / lowwest development cost / highest spec compatibility.
Borland's (InPrise) C/C-- Compiler is written in OOP Pascal (product name : Delphi). Actually the Borland OOP Pascal / Java objects models are almost identical. You want native Java code try Delphi (loose32) / Kylix (happy penguin and loose32 with qt ). Different language, same model..., faster (?) code.
TastesLikeHerringFlavoredChicken
TastesLikeHerringFlavoredChicken
Purpose built processors don't usually help. Sure they start off fast, but unless you have a huge development budget (and Intel has a huge budget!) you quickly get outdeveloped and then you are slower.
I love the crusoe tech though. Because it's smaller it might help keep development costs down.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Doing tests on numeric calculations is useless, because a JIT can generate the same code that the C/C++ application is using. I would like to see tests where the application had many threads, the computer had multiple processors and objects were continually being created/destroyed. I am pretty sure that Java would be 50% of the speed of a C/C++ application in this kind of test (which is certainly more real world than "life"). Chris Hafey
I can't say that Java is going to be the next big language, but I can certainly say that its design philosophy is excellent. In a world where operating systems want to make their APIs so convoluted and complex that no one would want to port them to another platform, Java is turning the tables. The idea behind Java is that if I choose I can write software for Windows and Linux and MacOS and any other machine that's running a JVM.
Granted, I know that Java isn't quite there yet. I personally experienced the pain of moving some of my Java programs that I had written under Windows and moving them to Linux, my new OS. And honestly Java seems to take a performance hit by compiling to byte codes and doing run-time optimization.
The strength of this article is that it points out (with some tentative evidence) that the performance hit doesn't seem to be nearly as bad as we (or at least I) thought. Perhaps the author is right. Maybe the problem isn't because of byte code compilation. Maybe it lies in the relative newness of Java as a language/platform.
Someday C will be superceded by another language. That language may or may not be Java. Honestly I'll probably keep programming in C, but I'll definitely keep an eye on Java as it matures.
"The further I get from the things that I care about, the less I care about how much further away I get." -Robert Smith