Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Language Comparison, C#, C++ and Java

By ucblockhead in Technology
Tue Jun 25, 2002 at 04:12:48 PM EST
Tags: Software (all tags)
Software

With Visual Studio .NET, Microsoft has put forth a new application development language with elements of C++ and Java. I spent some time looking at how these three languages compare as Windows development languages and these are the results.


Three new languages, not one

Visual Studio.NET actually includes three new languages rather than one. C# was built from the ground up as a new language. The two existing Visual Studio languages, C++ and Visual Basic, have been given extensive makeovers. (This is the last you'll hear about Visual BASIC in this article.)

In theory, the idea behind these extensions is that all of the languages in Visual Studio will use the "Common Language Runtime" (CLR). There are two components to this, the IL ("Intruction Language") bytecode (akin to the JVM) and the ".NET Framework". The first is a bytecode language akin to the JVM. The second is an API for controlling the Windows operating system and user interface. The goal is to give programmers in any supported language access to the same APIs. These two things are essentially independent, or at least you can use the IL bytecode without using the .NET framework.

Getting a C++ program to use the IL bytecode is fairly easy. Most C++ programs can simply be compiled to use it with the /clr option. Getting C++ to use the .NET Framework is a bit more difficult in that it requires that you use "Managed C++". "Managed C++" is a garbage collected, safety checked version of C++ that is not backward compatible with standard ("unmanaged") C++. Managed C++ code cannot use many standard C++ features, the most important of which are templates or any of the standard libraries. Making it all a bit confusing is the fact that you can mix unmanaged and managed C++ code. You can call managed code from unmanaged code, but not vice-versa.

In order to compare these various languages I took a program written for the old "Programming Fun Challenge 4" contest that I had written in C++, and rewrote it three times. First, in C#, then in Java (because C# is also supposed to be a "Java killer") and finally in "Managed C++". My goal was to get a sense of both the syntax and the performance differences of the four languages. (I say four, because as you'll see, "managed C++" ends up being practically an entire new language in its own.)

The program

Here is a Description of the PFC4.

The PFC4 program is not a perfect test, but I think it is a decent one. It ignores the GUI entirely, which is good as the differences between the different UI APIs would make a comparison near impossible. It does, however, use the collection classes extensively, so it isn't just a test of the raw language, but of the APIs as well.

All of these programs use an identical algorithm, differing only as much as the language required. The four programs can be found here:

The C++ version The C# version The Java version The Managed C++ version

I have attempted to use all of the same method and property names in order to simplify comparisons. Also, my naming conventions are all taken from the original C++ version and therefore may not match the normal conventions for C# or Java. This is intentional as it also simplifies comparison.

Caveat: My experience in both Java and C# is light. It is very possible that my implementations in either of those languages is substandard. Also, this program does not hit every portion of the language, so this article is only a view of the languages used to attack a particular sort of problem.

The Implementations

Here is the implementation of one of the simpler methods in each of the languages:

// c++
WORDHDL AddHandle(const string& aWord)
{
    int rc = GetHandle(aWord);
    if( rc != -1 )
        return rc;

    myWordsLookup[aWord] = myWords.size();
    myWords.push_back(aWord);
    return myWords.size()-1;
}

// Java
public int AddHandle(String aWord)
{
    int rc = GetHandle(aWord);
    if( rc != -1 )
        return rc;

    myWordsLookup.put(aWord,new Integer(myWords.size()));
    myWords.add(aWord);
    return myWords.size()-1;
}

// C#
public int AddHandle(string aWord)
{
    int rc = GetHandle(aWord);
    if( rc != -1 )
        return rc;

    myWordsLookup[aWord] = myWords.Count;
    myWords.Add(aWord);
    return myWords.Count - 1;
}

// Managed C++
WORDHDL AddHandle(String *aWord)
{
    WORDHDL rc = GetHandle(aWord);
    if( rc != -1 )
        return rc;

    myWordsLookup->set_Item(aWord, __box(myWords->get_Count()));
    myWords->Add(aWord);
    return myWords->get_Count()-1;
}

Some things to notice:

  • Java doesn't have anything like typedef, ie, something to make a quick-and-dirty alias for a type. This is a shame, because as you can see here, this feature can be used for code clarity. For the Java version, I have to remember that certain methods that return int are returning a handle to a word string.
  • Java requires you to explicitly wrap base types when you put them in a container. Managed C++ requires you to "box" a base type when putting it in a container. (This is essentially the same thing). C# implicitly does these for you. C++'s containers are not object-based, so no casting or wrapping is needed.
  • Both C++ and C# make use of operator overloading to simplify the syntax of container inserts and fetches. Note that while you can in theory do this in Managed C++, the .NET framework does not do this, making inserts and features a bit uglier. Foo[key] = data; becomes Foo->set_Item(Key, __box(Data));.
  • Note the way C# muddies the difference between a property and a method. The Count property in the C# version is the same as the Count() method in the Java version. In other words, it could involve executing arbitrary amounts of code.

    Thoughts about C#

    Despite its name, C# is much more of an extended Java than an extended C++. The similarities are extensive, going as far is using identical names for identical methods. Comparing the two languages themselves, I'd have to say that C# is just slightly easier to work with in that where it doesn't mimic Java exactly, it extends it in a useful way. The two major extensions that I ran into were the ability to define properties with code (which I found useful syntactic sugar though I know others object to the idea) and the simpler syntax due to more implicit casting.

    Thoughts about Managed C++.

    It should be clear from anyone looking at the managed C++ version that it is not a viable option for new development. It is by far the longest of the programs, and also, in my opinion, the most syntactically ugly of the four. And indeed, Microsoft explicitly discourages its use for new development, promoting it mainly as a way to pull in old C++ code. And as you'll see below, you don't even get the performance benefits you'd expect using C++, so there seems to be little reason to ever use as anything other than an upgrade path.

    Collection containers

    The C++ containers are different from the containers in both Java and in the .NET Framework in that they are generic containers rather than object oriented containers. In other words, for C++, you say "I want a container to put things of type Foo" in whereas in the other language you say "I want a container to put things in".

    None of the languages provided all of the containers I wanted for this application. C++ is missing a good hashtable type. (std::map is a b-tree.) C# is missing any concept of a set (i.e. a container where the key and the data are the same). Neither C# nor Java have containers with non-unique keys. (Though they are pretty easy to fake with containers of containers.)

    The SGI implementation of the C++ STL has a nonstandard "hash_map" extension. This version is very common in the C++ community and is rumored to be slated for inclusion of the next C++ standard. It has an interesting effect on performance, so I included support for it in the C++ version.

    Objective comparisons

    The lengths of the different programs is interesting:

    Table One

    C++: 375 lines
    C#: 425 lines
    Java: 431 lines
    Managed C++: 512 lines

    I was a bit taken aback by the fact that the C++ version came in shorther give that C# and Java are supposedly "higher level" languages. Part of this is due to the STL and the fact that it has a quick-and-dirty tuple class (std::pair) that I could use in containers to avoid having to create a special class for the same purpose. Also influencing this is that neither Java nor C# are as good at console IO as C++ is. This is not surprising given their GUI orientation and C++'s console heritage.

    The timing differences are more interesting. a note on the many C++ versions. C++ can be compiled to use the CLR or not to use the CLR even if it is not managed. This has timing implications. There are also different versions using the various STL implementations, and, for kicks, versions compiled with gcc rather than Microsoft Visual Studio.NET.

    All timings were obtained on a 800 Mhz Pentium IV using this input data. All times in seconds.

    Table Two

    Standard C++: 27.99
    Standard C++ + SGI STL 11.15
    Standard C++ + SGI STL and hash_map 6.04
    g++ C++: 17.28
    g++ C++ + SGI STL: 14.93
    g++ C++ + SGI STL and hash_map: 7.29
    Standard C++ compiled /clr: 34.36
    Standard C++ + SGI STL compiled /clr: 25.09
    Standard C++ + SGI STL and hash_map compiled /clr: 12.98
    Managed C++: 111.59
    C#: 93.08
    Java: 65.57

    As you can see, the differences can be substantial. The fastest and the slowest systems differed from each other by more than a factor of fifteen. In general, the C++ versions outperformed the others, with one very important exception; the very slowest of the systems was the managed C++ version.

    Why? There are lots of possibilities. The most obvious would be the bytecode, but it is clear from the C++ versions compiled to use bytecode that the performance hit here is about a factor of two. This alone does not explain the performance differences between C++ and the other three languages.

    An obvious culprit is the .NET Framework itself, as the two differences between the Managed C++ version and the standard C++ version are the .NET Framework and garbage collection. And indeed, after doing a little bit of profiling, it appeared that the .NET Framework classes performed very differently then the STL collection classes. In particular, the C++ classes were actually slower on inserts than the .NET Framework collection classes, but were far, far faster on fetches. (The C++ version that runs in six seconds spends almost a second and a half of its time loading the dictionary, something the managed C++ version does in less than a second.)

    It is interesting that the Java version, while significantly faster than those using the .NET Framework, is still significantly slower than the C++ versions. This could, in theory, be the garbage collection, but I suspect not, as playing around with other aspects of C# programming, most notably, UI development, I've found it generally only to be only about half as slow as C++. I suspect the big difference is that the C# collections need to store full objects whereas the C++ collections can store base types.

    Final Thoughts

    One thing I've found when comparing C# to C++, both with this program and others, is that the biggest differences in the ease of programming come not from the languages themselves but from the APIs. The collection classes in C# (and Java) are substantially easier to use than the STL. The new .NET Framework is substantially easier to use then the older Win32 API for Windows programming. (And also quite a bit easier to use than Gtk.) These differences seem to swamp out a lot of differences in ease of use in the languages themselves. But it still must be said that programming in C# is certainly easier than programming in C++. There's a lot of fairly arcane stuff you must think about if you are going to get the most out of C++ whereas most of these decisions are made for you under the covers with C# (or, indeed, most languages).

    It is also important to see that the performance differences between the various systems are very application dependent. The timings here make C# (and also Java) look very slow compared to C++, and while I chose the task essentially at random, in retrospect I think it was a bit unfair in that I suspect other tasks might not show such a performance gap. Certainly a benchmark that did something like calculate Fibonacci numbers, and that avoided the collection classes, would make C# look much better. It is also interesting to note the impact that simply using the SGI hash_map had on the C++ versions. It shows how important choosing the right data structure for the task is.

  • Sponsors

    Voxel dot net
    o Managed Hosting
    o VoxCAST Content Delivery
    o Raw Infrastructure

    Login

    Related Links
    o Descriptio n of the PFC4
    o The C++ version
    o The C# version
    o The Java version
    o The Managed C++ version
    o Table One
    o input data
    o Table Two
    o Also by ucblockhead


    Display: Sort:
    Language Comparison, C#, C++ and Java | 163 comments (124 topical, 39 editorial, 0 hidden)
    typedef in C# (4.40 / 5) (#7)
    by bhouston on Tue Jun 25, 2002 at 12:44:00 PM EST

    ucblockhead wrote:
    "Neither Java nor C# has anything like typedef, ie, something to make a quick-and-dirty alias for a type."

    Actually in C# there is an equivalent to typedef -- although its syntax is strange:

       using WORDHDL = int;


    Thoughts about C# : you forgot value types (4.50 / 4) (#11)
    by bhouston on Tue Jun 25, 2002 at 12:49:30 PM EST

    One of the major advantages that I have found in C# as compared to Java is its support of value-types.  Because of this feature I was able to write a lot of performance critical code in C# ([1], [2]) that would not have been feasible had I gone with Java.

    [1] Open Source C# OpenGL 3D Engine
    http://www.exocortex.org/3dengine

    [2] Open Source Complex Number and FFT Library
    http://www.exocortex.org/dsp


    nice article (3.00 / 2) (#12)
    by eurasian on Tue Jun 25, 2002 at 12:49:53 PM EST

    clear, concise. thanks.


    C# (4.00 / 1) (#13)
    by tombuck on Tue Jun 25, 2002 at 12:51:18 PM EST

    I've recently been throw in at the deep end whilst at work and am having to learn C# as I help write a new project.

    Now, this is for web development (i.e. asp.net) which your article doesn't address much. Note, however, that just because it's called asp.net doesn't mean it has anything to do with the asp language.

    No! I write my web applications in C#.

    Things are so easy.

    For example, form validation. Before, using PHP, I'd manually have to check the values of the forms are what I want them to be. With asp.net I can simply insert a couple of special HTML-alike tags which check for it. Fantastic.

    C# is good indeed. It's java but actually good.

    --
    Give me yer cash!

    C# Performance Still Requires Thought (4.71 / 7) (#18)
    by bhouston on Tue Jun 25, 2002 at 12:59:38 PM EST

    ucblockhead wrote:
    "There's a lot of fairly arcane stuff you must thing about if you are going to get the most out of C++ whereas most of these decisions are made for you under the covers with C# (or, indeed, most languages)."

    Because of the countless hours I've spend optimizing C# code I must disagree. ;-)  The major things that kill C# code performance in critical sections are: (1) implicit boxing/unboxing, (2) use of abstract or virtual functions (as opposed to static functions) and (3) use of generic collections insread of typed collections.

    What I wonder (1.00 / 13) (#35)
    by medham on Tue Jun 25, 2002 at 01:29:06 PM EST

    Is why code compiled with g++ is so much slower on average than the equivalent code in even the buggiest java implementations? It seems to me that the lackluster performance of gcc, the flagship GNU application, says quite a bit about the ultimate quality of "free" software.

    The real 'medham' has userid 6831.

    this is why.. (2.00 / 3) (#52)
    by richxcasto on Tue Jun 25, 2002 at 02:02:46 PM EST

    I stopped doing s/w development and went into networking and security!

    -1, poor research methods (2.42 / 7) (#65)
    by mattbelcher on Tue Jun 25, 2002 at 03:14:21 PM EST

    One program, written in a style best suited towards c++, does not make much of a meaningful comparison. Were the author to make a suite of comparison programs as well as give more information regarding the tests (which JVM and java compiler were used, etc), then I would give it a +1. However, this study ends up worse than useless, as it appears to give real data, when in fact means almost nothing.

    Thankfully, the author acknowledges some of the shortcomings of his study in the final thoughts. While commendable, acknowledgment of fault doesn't suddenly make a poor study more worthy of publication.

    Don't know how you do things (4.37 / 8) (#66)
    by ennui on Tue Jun 25, 2002 at 03:17:19 PM EST

    But how I do things for projects I'm serious about: I always subclass things like vectors and hash(tables)maps if I expect them to only contain references to objects of a particular class (and try to avoid hash(tables)maps altogether whereever possible, as they generally don't lead to good OO design.) You can then treat them as their superclass for things that require it, and add and override methods so that the container is more aware of what you're putting in it, specifically, throwing an exception if you're violating the contract of the container class and giving design-time hints to people who might be using it.

    You're also making your life more difficult than it needs to be with the primitives/primitive wrapper classes. Subclassing containers use is a decent solution to the gyrations in your code.

    Some of the complaints you're bringing up (lack of typedef and the problems you're having with primitives) are more related to the way you've chosen to do things (a fairly procedural approach, not taking advantage of OO concepts or design, particularly in the Java example) than any merits of any particular language you've chosen to compare, reminds me of when Java became Java (not "Green") and C(++) programmers complained that there weren't pointers, you couldn't micromanage array memory, and bemoaned the lack of precompiler directives. If that's important to you, you don't want Java, nor OO languages in general.

    "You can get a lot more done with a kind word and a gun, than with a kind word alone." -- Al Capone

    Compiling C++ with the "/clr" Parameter (4.00 / 3) (#67)
    by bhouston on Tue Jun 25, 2002 at 03:28:10 PM EST

    ucblockhead timed two versions of C++ code, one without the /clr param and one with it:
      "Standard C++: 27.99"
      "Standard C++ compiled /clr: 34.36"

    To explain the difference ucblockhead wrote:
    "The most obvious would be the bytecode, but it is clear from the C++ versions compiled to use bytecode that the performance hit here is about a factor of two."

    Unfortunately using the /clr parameter does not mean that the whole program was compiled into bytecode.  In fact the compiler with the /clr param will only compile individual *functions* into bytecode if it is possible otherwise it will still using raw x86 instructions.  Because of this not-quite-all-bytecode compilation it is difficult to compare the overhead that results from bytecode.

    Also it should be mentioned that when executed the bytecode is converted to x86 code which is then cached -- i.e. just-in-time (JIT) compilation.  JITing is done on a function by function and a need basis.  I have found that .NET programs tend to start slowly (probably because of the JITing) but once running they are very comparable to C++ code performance.

    Dubious Methodology (3.60 / 5) (#68)
    by Simon Kinahan on Tue Jun 25, 2002 at 03:35:17 PM EST

    I guess you're more experience in C++ than the other languages, right ? Certainly the code looks like it, and your Java isn't written in "good" style. Most especially, in response to:

    Java doesn't have anything like typedef, ie, something to make a quick-and-dirty alias for a type. This is a shame, because as you can see here, this feature can be used for code clarity. For the Java version, I have to remember that certain methods that return int are returning a handle to a word string.

    I say "don't do that, then". This an object oriented language. If you want to refer to something, you maintain a reference to it. If you want it to look different, create a class to wrap it up in. Looking at your code, why not have a "Word" class ? This is just elementary OO design: the fact you've got classes with plural names ought to be a giveaway that something is wrong. I can't think of a credible case for using interger "handles" anywhere in Java.

    In general programming languages are vehicles of expression, and each one is accompanied by cultural baggage of accepted ways of doing things. The actual value of taking a program in C++ and mapping it line-by-line to Java is very limmited, because usual practice in the two languages is quite different.

    Simon

    If you disagree, post, don't moderate

    Which Java? (4.00 / 2) (#81)
    by p3d0 on Tue Jun 25, 2002 at 04:30:27 PM EST

    Nice job on tackling something so thorny. No doubt you will be criticized on your benchmarking and your programming style (and rightly so). This one article in itself doesn't prove anything, but the more of these we see, from different viewpoints, the better. It's a data point.

    What I wonder is, which Java did you use? Was it a recent Sun or IBM JDK with a highly-tuned JIT compiler? If so, I would find the order-of-magnitude performance difference between Java and C++ to be surprising indeed.
    --
    Patrick Doyle
    My comments do not reflect the opinions of my employer.

    Where is Python and Clisp? (3.50 / 2) (#99)
    by axxackall on Tue Jun 25, 2002 at 07:21:19 PM EST

    While the comparison is interesting and useful, it's certainly is not complete. It could be very useful to include Python and Common Lisp. Otherwise, it's more like an argueing between M$ and Sun.

    Both Python and Common Lisp have strong positions in Obeject Oriented Programming. Both are fast enough, being optimized. And both have good byte-compilation. What they do not have - hype-support of big software monsters, like Sun and M$.

    May be IBM and HP in future will start pushing Python and/or Clisp, like IBM is pushing Linux today. Who knows?

    Spelling and Accuracy (4.33 / 3) (#102)
    by icastel on Tue Jun 25, 2002 at 08:21:49 PM EST

    There are two components to this, the IL ("Intruction Language") bytecode (akin to the JVM) ...

    Did you mean "Instruction Language?" Not that it would be accurate if you did. IL actually stands for "Intermediate Language."

    Also, IL is NOT akin to JVM. Rather, CLR is akin to JVM and IL is akin to Bytecode.






    -- I like my land flat --
    vectors in java (3.00 / 2) (#105)
    by brewster on Tue Jun 25, 2002 at 11:20:27 PM EST

    Vectors are synchronized and much slower than ArrayLists. I'm too lazy to split your code into the seperate files for recompiling (a zip would have been nice), but if someone wants to change everything to arraylists and see what the difference is, I'd guess it to be quite noticable.

    Benchmark methology (3.50 / 2) (#113)
    by boxed on Wed Jun 26, 2002 at 03:41:54 AM EST

    Did you include warm-up time as a factor or did you ignore that completely? This warm-up thing is what can make java in some cases faster than C++ due to runtime optimization that just can't happen in C++ because the language hasn't got access to that kind of information. JVMs with JIT are actually slower than non-JIT JVMs in this startup phase, but after that phase the speed drastically increases. You should have a curve with the speed of the program over time.

    What you forgot to say about c# (3.00 / 1) (#119)
    by Sopwith Pup on Wed Jun 26, 2002 at 08:17:41 AM EST

    Is that its basically a copy of Borland's Pascal written IIRC by the same guy (except of course without several years of intensive use)

    You also forgot to mention that the C++ you use with VStudio is a completely bastard MS version of the language which will ruin you for ANSI C++. God knows what abortions 'managed' C++ will bring to the table.

    I discovered Borland's C++ Builder a few years back, it is actually visual (as opposed to MS's efforts) allows actual ANSI c++, will do all of MS's latest shit. Didn't mean to be a plug here but think a more useful language comparison (for the windows world) would take in the (IMHO) superior alternatives


    Be realistic, demand the impossible

    issues with the java implementation (5.00 / 5) (#132)
    by zzzeek on Wed Jun 26, 2002 at 01:59:33 PM EST

    I am going thru the java implementation and reworking it the way Java applications are usually written, to take advantage of its architectural features as well as common speed improvements. As I am going thru to understand the algorithm, some quick observations:

    the first strange thing was that you have "import" statements that are importing the name of classes, with no package names. I am not sure why you did this, since all these classes are in the same package anyway, and additionally the syntax is invalid without a package name of some sort and would not compile with Sun's javac compiler. What Java compiler/interpreter were you using ?

    next weird thing, theres a bug in the WordHdls class. Yet the program still works. you have this loop:



    private int Distance(String str1, String str2)
    {
    int Diffs = 0;
    for(int i=0;i>str1.length();i++)
    if( str1.charAt(i) != str2.charAt(i) )
    ++Diffs;

    return Diffs;
    }

    The loop does nothing, as 'i' will never match the loop condition and it will not be executed. So the distance between any two words will always be caluclated as zero, i.e. they are the same word. Im not sure how the program works yet, so since the complied app returns the correct results, so I must assume that either this function's usage is completely superfluous (and it is used in the main algorithm), or that it is part of an optimization that is not taking place.

    Another optimization that is completely unused, WordHdls contains the hashmap myNeighborSets, used to store neighbors after an extremely brute-force approach has been taken to find those neighbors. The code that searches for neighbor sets looks in this hash, and if it finds nothing, sets out to assemble the list of neighbors manually. But the result is never cached! Meaning the myNeighborSets cache is never used in the application.



    public int[] GetNeighbors(int aWordHdl)
    {
    // look for neighbor set in the cache
    if( myNeighborSets.containsKey(new Integer(aWordHdl)) )
    return (int[]) myNeighborSets.get(new Integer(aWordHdl));

    // do it by brute force
    String aWordStr = GetWord(aWordHdl);

    Vector neighbors = new Vector();
    for(int i=0;i<aWordStr.length();i++) {
    for(char ch='a';ch<='z';ch++) {
    if( aWordStr.charAt(i) != ch )
    {
    char[] str = aWordStr.toCharArray();
    str[i] = ch;
    if(myWordsLookup.containsKey(new String(str)) )
    neighbors.add(new String(str));
    }
    } }

    int[] someNeighbors = new int[neighbors.size()];
    for(int i=0;i<neighbors.size();i++)
    someNeighbors[i] = GetHandle( (String)neighbors.get(i) );

    // profit !!!! wheres the storage ??
    return someNeighbors;
    }

    Was just wondering if I am missing something here or if these are actually mistakes. I will attempt to work in these improvements into my version.



    Code length (4.75 / 4) (#138)
    by DodgyGeezer on Wed Jun 26, 2002 at 04:43:21 PM EST

    Great article.  It's good to see these kinds of comparisons.  I really like the comparisons with the various STLs, compilers and compiler options.  Which in itself is a suggestion of why C++ isn't always the best language choice: one spends too much time worrying about language/environment issues instead of concentrating on rapidly producing a reliable solution.

    However, I really don't think you can compare source code size.  You admitted yourself that you were a C++ guy coming at it armed with a C++ app.  I didn't look through your sources, but I speak from my own experiences.  As an experienced C++ guy, I found when I first started looking at Java that I would write Java in a C++ syle.  This is only natural.  I found that as I became more fluent in Java that the C++ style was actually often quite unnatural, and perhaps considerably more verbose.

    It's funny, since going back to C++, I've taken some of my Java style back with me, such as with global constants and "interfaces".  No inner classes though :(

    New Java version (5.00 / 3) (#139)
    by ucblockhead on Wed Jun 26, 2002 at 05:50:49 PM EST

    I've incorporated some of the changes suggested here into the java version. The new version can be found here.

    The new version is substantially shorter (because I dumped the "WordHdls" class) and a bit faster. It now runs in 33.69 seconds on my box.
    -----------------------
    This is k5. We're all tools - duxup

    Pentium IV? (none / 0) (#151)
    by Ambient on Fri Jun 28, 2002 at 01:10:34 PM EST

    All timings were obtained on a 800 Mhz Pentium IV using this input data. All times in seconds.

    Did they even make an 800Mhz Pentium IV??? I'll assume you meant a Pentium III.



    Comparing language "performance" (none / 0) (#154)
    by localusr on Mon Jul 01, 2002 at 12:04:05 PM EST

    It seems inappropriate to me to compare languages by measuring performance or speed of binary code. Theoretically, the language per se does not affect the speed of the binary's execution because the language is merely a set of lexical abstractions of computer hardware. For example, a program written in Java can be translated in C# implicitly and then compiled into a binary. In that case, the resulting binary's  performance will surely not be affected by the difference between Java and C#.

    Saying that C++ programs are faster than Java programs is like saying that native English speakers are better communicators than native Russian speakers. It's the person in question (the compiler) who affects the effectiveness of the communication (the binary performance).

    Some languages' abstraction sets are more expressive or richer than others or some language compilers always produce machine code while some, always "intermediate bytecode", which can skew the public opinion of the language's "performance". However, IMHO, it is non-sensical to speak of faster or slower languages. One should rather speak of faster or slower platform implementations or mere binaries.

    Language Comparison, C#, C++ and Java | 163 comments (124 topical, 39 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!