On Sunday, September 8, 2002, at 07:49 AM, Anthony DeRobertis wrote:
> > On Saturday, Sep 7, 2002, at 10:23 US/Eastern, Adrian Sutton wrote: >> >> Oh ye of little faith (and Java knowledge :). Java for non-gui is as >> fast or faster than C (particularly C compiled with gcc since it is >> very bad at optimisation). > > I challenge thy assertion, oh one of great faith! > > Compiling commands were: > javac -O test.java > g++ -O3 test.cpp -o test > g++ -O3 -mcpu=7400 test.cpp -o test7400 You should do a little more research into benchmarking before you start issuing such challenges. :) 1. You're Java code is not written to take advantage of hotspot. 2. You didn't use hotspot anyway. java -hotspot would have turned it on. :) 3. You timed the start up of the JVM as well as the execution of the code. The start up of the JVM is a once-off event and is depreciated over the lifetime of the application, so you can knock off about 3 or 4 seconds from your Java times. :) Which makes Java roughly as fast a C++. :) and the big one: 4. While I'll be running code like you posted, you'll be running an interpreter and having to work out what to do, then execute it. However, I gave up fighting over benchmarks a while back and left it to the pros. http://www.aceshardware.com/Spades/read.php?article_id=153 That article is a few years old now and Java has improved significantly even on top of those results. :) >> Hotspot, SWT, Cocoa and good Java coding all combine to produce >> very good speeds for Java. > > Well, I guess 1/2 of C++ speed is pretty good. You failed to use any of the above technologies in your tests. >> and that's with the VB version using great swabs of C code from the >> operating system (like the entire HTML editor pane which handles 90% >> of the functionality). > > You know, of course, that a lot of your Java engine is probably > written in C as well. However, this doesn't speak of the speed of the > languages; I think we'll both agree that the wrong choice of > algorithms will make even the quickest language, machine, etc., crawl. That's simply because if the JVM were written in Java it would have to run itself - an impossible task. The Java libraries are written in Java (I have the source code to prove it). >> Welcome to the year 2000, we've worked out how to make Java go fast. >> :) > > gcj, or its equivalents? [didn't test this since Mac OS X does not > have it] No, hotspot, good coding and picking the right GUI libraries. > I certainly agree they are miles apart. When I was using it, I had a > bunch of complaints about it; unfortunately (or, maybe, fortunately) I > forget most of them now. I remember that templates would of been nice. > So would of multiple inheritance (yeah, it makes writing the compiler > harder. Deal with it!) In other words, you wanted to write C++ code in Java. Java does have a form of multiple inheritance, it's called interfaces and it will provide you with everything you'll ever need in a well designed Java application. Templates may be nice but are certainly no big deal for a well designed application. > With the stuff we were doing in Java, I ran into a bunch of things > that were much more elegantly solved in C++. Even the other Java > developers on the project had to agree with me on some of them. I'm > sorry I can't remember exactly what they are. Horses for courses. Right now I'm trying to create a web-enabled, cross platform development tool, which sounds right up Java's alley. > >> Spend a few years working with Java and you'll never go back though. >> :) > > Well, after one year, you're quite right --- I will never go back ;-) Then I know of a heck of a lot of fortune 500 companies who won't employ you. >>> Anyway, I bet I can get a C++-based interpreter running on more >>> platforms than you can get your java one running on, and first.. >> >> I'm not a betting man, but I'm more than prepared to take that >> challenge. To kick things off, I'll raise you fields (including >> rendering HTML and RTF), buttons and menus. :) > > Java does have a serious advantage in the graphical area as far as > portability is concerned. X11 can't quite match it. You can't use X11 for your GUI. You need to use native widgets on each platform. This is exceptionally important. On OS X, you will need to use Carbon or Cocoa, on Windows MFC or win32 api and on most UNIX you can use X11. > Yep, that is a can 'o worms! GTK does run on at least 12 linux > platforms, several bsd ones, windows, and mac os x, though... Ah, but does it have the correct look and feel or are you going to throw yourself to the wolves, er HC list. :) I told the OpenOffice people and the Mozilla people, your product will not take off on Mac unless you use native widgets - emulating them is never going to cut it. I was right about Mozilla and apparently OpenOffice though there hasn't been a full port yet anyway so it's probably too early to gloat. :) BTW, the Chimera project is Mozilla for Mac done right with native Widgets and it's coming along very nicely. Either way, it is futile to argue the language issue based on whether or not you like the language or even on speed really because in reality in both cases there is run time optimization of code, in Java because it always happens that way, in C because you're writing an interpreter. Java has Sun, Apple, IBM and a whole bunch of others working to make it run faster whereas a C interpreter has our little development team. I know which I prefer. The key thing to be discussed is which architecture we get more benefits from. I think that's Java because it enables us to get easy cross platform support, automatic web based deployment and a massive amount of features that come about purely from using the Java libraries (like HTML rendering in fields - and buttons btw). The other big issue is how long will it take to develop, I'm rocketing along on the Java project because all I have to do is map FreeCard on to Java, I basically don't have to write any features myself. The big concern I have with Java is when the JRE isn't available on a platform (such as BeOS and the clones). I'm not sure how to tackle that issue yet, perhaps GCJ can be used - I don't know. Perhaps we need a C version for those platforms. The key thing is to do something and move forward, so be it if we wind up with a Java version and a C version, two choices are better than none. Lets get back to coding... Adrian Sutton. ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Freecard-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freecard-general
