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;


    Hmm... (4.50 / 2) (#14)
    by ucblockhead on Tue Jun 25, 2002 at 12:53:19 PM EST

    That doesn't seem to work for me...
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    Maybe... (5.00 / 3) (#30)
    by bhouston on Tue Jun 25, 2002 at 01:18:31 PM EST

    Supposidely the short types 'int', 'long', 'short', 'double', 'float', etc... are defined by this style of "typedef" thus maybe you can not use them as targets.  Try this with a fully defined type instead:

      using WORDHDL = System.Int32;


    [ Parent ]

    That worked (nt) (3.50 / 2) (#31)
    by ucblockhead on Tue Jun 25, 2002 at 01:20:21 PM EST


    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    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


    what are "value-types" (3.00 / 1) (#15)
    by speek on Tue Jun 25, 2002 at 12:57:34 PM EST

    ?

    --
    God needs money from you
    [ Parent ]

    Value-Types vs. Reference-Types in C# (5.00 / 3) (#38)
    by bhouston on Tue Jun 25, 2002 at 01:31:24 PM EST

    I could write up somethin crappy or you could check out this fairly well written page on it... ;-)
    http://www.albahari.com/value%20vs%20reference%20types.html


    [ Parent ]
    ok (4.00 / 3) (#70)
    by speek on Tue Jun 25, 2002 at 03:44:12 PM EST

    That's what I guessed. However, Java does have the final keyword, which does some of what "value-type" in C# does (ie, prevents inheritance). Also, Java has many objects set up as immutable, which supposedly helps performance in some of the same ways "value-type" is supposed to. The only real difference is the way parameters are passed to methods - in Java, it's always by reference, essentially, since any object is a pointer in reality (well, this doesn't hold for primitives). But, I fail to see any advantage to by-value passing except to encourage side-effects (not that Java prevents side-effects).

    --
    He who can copy, can do - Da Vinci
    [ Parent ]

    final = sealed, immutable != value-type (5.00 / 3) (#76)
    by bhouston on Tue Jun 25, 2002 at 03:59:00 PM EST

    The point of value-types doesn't really have to do with preventing inheritance (i.e. the purpose of Java's 'final' keyword.)  In C# the keyword 'sealed' is equivalent to Java's keyword 'final' in this regard.

    Immutable objects are also not really at the core of value-types.  [Immutable objects in Java are things like strings that (usually) create modified copies of themselves rather than actually modifying the own data.]

    In Java there are value-types but they are limited to those built in types 'int',
    'uint', 'float', 'double', etc....  They are very fast to use since they are allocated quickly on the stack and not in the GC'ed heap.  These Java value-types also have no overhead for class-type stuff that normal objects have.  Java added these to the language (instead of everything being objects) because of the big difference they make in performance.

    C# allows for user defined value-types using the 'struct' keyword.  C# thus allows for the unification of primative types 'int', 'double', etc... and their class-like representations 'System.Int32', 'System.Double', etc... (or in Java 'Integer', 'Double', etc...)

    [ Parent ]

    ok (4.00 / 2) (#78)
    by speek on Tue Jun 25, 2002 at 04:03:44 PM EST

    The page you gave me started out by saying value-type prevents inheritance, thus improving performance. Obviously that's not the whole story, but it's there.

    Also, are these "structs" allocated on the stack? I didn't get an indication one way or the other on that page (though I admit, I skimmed much of it). That would be a big difference if true.

    --
    He who can copy, can do - Da Vinci
    [ Parent ]

    structs (5.00 / 3) (#79)
    by ucblockhead on Tue Jun 25, 2002 at 04:05:34 PM EST

    The way I understand it, structs are on the stack, classes are on the heap.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    preventing inheritance --> no vtable --> fas (5.00 / 2) (#80)
    by bhouston on Tue Jun 25, 2002 at 04:22:44 PM EST

    speek wrote:
    "The page you gave me started out by saying value-type prevents inheritance, thus improving performance. Obviously that's not the whole story, but it's there."

    Basically struct's don't have a vtable and thus OO-things such as virtual functions, inheritance, etc... are not possible.  But on the other hand the non-existence of a vtable (and its associated double pointer deference when calling functions) is a boost on performance. :-)

    [But strangely structs can still support interfaces which do require a vtable when boxed.  Things unfortunately can get really weird in some areas of C#]

    speek wrote:
    "Also, are these "structs" allocated on the stack? I didn't get an indication one way or the other on that page (though I admit, I skimmed much of it). That would be a big difference if true."

    Yes.  The article does mention this although initial not in a direct fashion.

    [ Parent ]

    The reimplementation is often better (none / 0) (#109)
    by RandomPeon on Wed Jun 26, 2002 at 01:49:18 AM EST

    I orginally thought of C# as a Java clone, but now it appears that C# has a lot of interesting features that Java lacks. This appears to be one of them, along with operator overloading and a better compilation/VM architecture.

    As is often the case in this business, the reimplementation is often better than the original. GNU tools, Apple/MS windowing systems, Linux, C#. "They're just copies!!!" people often say of all the above, but they seem to be damn good copies. Screw the "first mover" advantage, the "second mover" seems to have a lot of luck....

    [ Parent ]
    Call-Bys (Slightly OT) (5.00 / 2) (#101)
    by Bear Cub on Tue Jun 25, 2002 at 07:55:23 PM EST

    This is a nitpick, but you seem a little fuzzy on what "Call by Reference" and "Call by Value" mean. I wouldn't have mentioned this, except that I thought it might clarify a few of the things you're thinking about.

    There's a good write up here that should point you in the right direction.

    Be careful not to confuse what you're passing with how you're passing it. In Java, for instance, you may be passing references, but you're passing them by value.

    Cheers!

    ------------------------------------- Bear Cub now posts as Christopher.
    [ Parent ]

    You mean "compound value-types", right? (none / 0) (#131)
    by dachshund on Wed Jun 26, 2002 at 12:57:52 PM EST

    One of the major advantages that I have found in C# as compared to Java is its support of value-types

    What you mean to say is that C# supports compound value-types, like structs for instance. It took me a minute to understand what the heck you were saying, because Java certainly simple value-types (int, float, etc.)

    [ Parent ]

    sure. (none / 0) (#134)
    by bhouston on Wed Jun 26, 2002 at 02:29:45 PM EST

    Yeah compound value-types or user definable value-types.  I guess I wasn't as clear as I could have been.

    [ Parent ]
    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!

    OT: validation (none / 0) (#16)
    by jacob on Tue Jun 25, 2002 at 12:57:52 PM EST

    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.

    Could you elaborate on this? I'm very interested in the ways forms get validated these days because I'm writing a new way of doing it.

    --
    "it's not rocket science" right right insofar as rocket science is boring

    --Iced_Up

    [ Parent ]

    Hrm. (none / 0) (#19)
    by tombuck on Tue Jun 25, 2002 at 01:00:09 PM EST

    The quickstart guides here can explain (quickly) much better than I every could do.

    Oh, and make sure you set the samples language as "C#" in the right-hand corner box :-)

    --
    Give me yer cash!
    [ Parent ]

    Damn damn damn (none / 0) (#20)
    by tombuck on Tue Jun 25, 2002 at 01:00:55 PM EST

    It's the "Server Control Form Validation" section you're after.

    It's all very quick 'n' small and gets to the point pretty quickly.

    --
    Give me yer cash!
    [ Parent ]

    very nice. (5.00 / 1) (#33)
    by jacob on Tue Jun 25, 2002 at 01:24:27 PM EST

    I wrote a library about a year ago for my (sadly yet-to-be-released) research web language that did something very similar to this. Mine was slightly more transparent — in fact if you've written your page in XHTML you don't even have to do anything custom to the page at all, it just works automatically, the idea being you can get straight-up HTML monkeys to write pure web pages and then have all the code off the HTML pages in a single program. That library has been sitting on my hard-drive, fully built and tested and everything, for a year, but in order to actually use it on a web site you need the full suite which isn't ready for release.

    Anyway, cool stuff. Thanks for the info.

    --
    "it's not rocket science" right right insofar as rocket science is boring

    --Iced_Up

    [ Parent ]

    Eh... (none / 0) (#85)
    by TunkeyMicket on Tue Jun 25, 2002 at 04:51:45 PM EST

    Client-Side form validation with JavaScript 1.3 does just as good a job as Server-Side will. With PHP you can insert a couple of special HTML-alike tags which check for it. Fantastic. I've spent alot of time at GE programming in ASP/ASPX and I've started writing PHP and PERL scripts to OUTPUT ASP/ASPX CODE FOR ME. Why? Because PHP/PERL does a wonderfull job of reading in an XML file and outputting data needed. Besides, ASP is the most ill-designed language I have ever seen, besides being based on VB. ASPX/ASP.NET is actually not that bad, reminiscient of JSP imo. However ASP has scarred me for life and I have serious doubts of me ever using it for anything other than things I ask for rediculous amounts of money for.
    --
    Chris "TunkeyMicket" Watford
    [ Parent ]
    umm, javascript validation (none / 0) (#86)
    by jacob on Tue Jun 25, 2002 at 04:57:00 PM EST

    is nice and all, but it's not a substitute for server-side validation. When you put javascript on a web page, you're just asking politely for someone to execute it. They don't have to.

    --
    "it's not rocket science" right right insofar as rocket science is boring

    --Iced_Up

    [ Parent ]
    Client side validation is an invitation for abuse (none / 0) (#123)
    by abdera on Wed Jun 26, 2002 at 11:00:04 AM EST

    If someone is trying to circumvent the validation in order to break your site, and see client-side validation, then you better be prepared for that validation to be consciously avoided. _Never_ trust the client.

    Use of client-side validation is only useful for taking a load off of your server if your form is confusing, or your users are stupid.

    #224 [deft-:deft@98A9C369.ipt.aol.com] at least i don't go on aol
    [ Parent ]

    Ha. (none / 0) (#124)
    by i on Wed Jun 26, 2002 at 11:28:03 AM EST

    Wait until trusted PC arrives.

    and we have a contradicton according to our assumptions and the factor theorem

    [ Parent ]
    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.

    RE: C# Performance Still Requires Thought (4.00 / 3) (#23)
    by bhouston on Tue Jun 25, 2002 at 01:06:12 PM EST

    Ahh, case in point.  In the C# version of the app unblockhead is using two hashtables, "myWordsLookup" and "myNeighborSets", which use (string, int) pairs.  Unfortunately because he is using a value type (int) in a generic collection he is going to incur a fairly heafty penalty every time he inserts or retrieves that value because of implicit boxing/unboxing.

    If one gave me 30 minutes I am sure that I could beat the C++ example's performance using C#. ;-)

    [ Parent ]

    alternative (3.00 / 2) (#29)
    by ucblockhead on Tue Jun 25, 2002 at 01:18:00 PM EST

    How do you avoid the boxing?
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    typed collections (5.00 / 4) (#36)
    by bhouston on Tue Jun 25, 2002 at 01:29:23 PM EST

    The answer is typed collections.  Unfortunately they are sort of a pain to create since C# does yet allow for 'templates' like C++ does.  There are some tricks to creating them using that 'typedef' stuff I was talking about before.  For some examples check out the classes Vector3DCollection and Plane3DCollection in the Geometry3D library:
      http://www.exocortex.org/3dengine

    There is also a tool now available for VisualStudio.NET that automates the creation of such typed collections:
      http://www.sellsbrothers.com/tools/#collectionGen

    [ Parent ]

    complications. (3.66 / 3) (#24)
    by ucblockhead on Tue Jun 25, 2002 at 01:06:16 PM EST

    I'm not saying that you can ignore performance in C#. What I was getting at is that you don't have quite the level of bizareness that even a simple C++ app can have. For example, in the C++ version of this program, I had to know that const string& performed substantially better than string when used as a parameter. Obviously that is similar to boxing, but if you do any STL work, it is an entire order more complicated.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    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.

    Curious... (3.66 / 3) (#47)
    by pb on Tue Jun 25, 2002 at 01:47:19 PM EST

    I would wonder this as well, if it were true...

    g++ C++: 17.28
    g++ C++ + SGI STL: 14.93
    g++ C++ + SGI STL and hash_map: 7.29
    [...]
    Java: 65.57

    Lower is better; perhaps you missed a decimal point?
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    do not feed the troll (nt) (5.00 / 2) (#48)
    by jacob on Tue Jun 25, 2002 at 01:49:56 PM EST



    --
    "it's not rocket science" right right insofar as rocket science is boring

    --Iced_Up

    [ Parent ]
    perhaps, but... (1.00 / 1) (#54)
    by pb on Tue Jun 25, 2002 at 02:09:48 PM EST

    Never attribute to malice that which can be explained by ignorance?

    Besides, medham is usually more entertaining when he's trolling, so I'm willing to give him the benefit of the doubt here.  What's really annoying are the trollbusters...  :)
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    If (1.00 / 5) (#53)
    by medham on Tue Jun 25, 2002 at 02:09:44 PM EST

    You accept the results listed there. Consider the biased source, I'd say. Try to reproduce them yourself and see what happens.

    Running cygwin on my machine, I got significantly higher numbers for the g++ implementations.

    And calling inconvenient facts "trolls" isn't going to make you any wealthier.

    The real 'medham' has userid 6831.
    [ Parent ]

    even if I don't... (2.50 / 2) (#59)
    by pb on Tue Jun 25, 2002 at 02:26:03 PM EST

    Testing on Cygwin, on a PIII of some sort that surely isn't as beefy as ucblockhead's...

    pbaylies@PB ~
    $ g++ -O9 -s pfc4.cc -o pfc4

    pbaylies@PB ~
    $ time ./pfc4.exe < linkdata > log 2> err

    real    0m11.601s
    user    0m11.437s
    sys     0m0.046s

    Also, note that the word "troll" or "trolls" appears nowhere in my previous post.  I assumed that if you were trolling, you'd do a better job than this...
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    Whatever (1.00 / 3) (#60)
    by medham on Tue Jun 25, 2002 at 02:33:52 PM EST

    Jacob.

    And I don't much care for results on insignificant operating systems.

    The real 'medham' has userid 6831.
    [ Parent ]

    Is Solaris significant? (n/t) (none / 0) (#61)
    by i on Tue Jun 25, 2002 at 02:37:48 PM EST



    and we have a contradicton according to our assumptions and the factor theorem

    [ Parent ]
    okaay... (3.33 / 3) (#62)
    by pb on Tue Jun 25, 2002 at 02:44:31 PM EST

    Testing on Cygwin, man, Cygwin; the same thing that you were theoretically testing on.

    Therefore, the insignificant operating system in question is Windows.

    Get it together, man, you're cracking up!
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    Well, mr. troll... (none / 0) (#107)
    by a life in hell on Tue Jun 25, 2002 at 11:50:57 PM EST

    If you read the articile, you'd see the the g++ code actully performed quite compedetivly(sp?), as it often does, particularly in the more recent versions. Also, I should point out that equating "speed" with "buggy" ("so much slower on average than the equivalent code in even the buggiest java") is completly incorrect, as bugfixes often reduce speed, not increase it.

    [ Parent ]
    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.

    so says the author (3.00 / 1) (#103)
    by tps12 on Tue Jun 25, 2002 at 08:46:06 PM EST

    The author admits as much throughout the article, and in the intro. Rather than making the article less useful, it probably makes it more useful, as many potential C# and Managed C++ users will be coming from a similar background of C++ experience.

    [ Parent ]
    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.

    Yes (5.00 / 4) (#69)
    by ucblockhead on Tue Jun 25, 2002 at 03:41:56 PM EST

    I should have probably talked about this a bit more...I am aware of this, however, the number of binary functions is not as high as you'd think. Most of the C++ libraries are template code and they compiling down to IL, not x86. In particular, all of the container code is template code, so none of it is x86 code. (I verified this with ILdasm.) Basically the only native code I could find was in new, delete, stream IO, and in the string class.

    I played a bit with larger and larger datasets to try to wash out the effect of JIT, but I never could find any effect. Increasing the input data by a factor of four increases the runtime for both the C# and C++ (and Java) versions by approximately the same factor. This is probably because the way the algorithm works, most methods will get hit a huge number of times using just the data set I did use, so any initial runtime effects wash out.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    wicked. (none / 0) (#98)
    by bhouston on Tue Jun 25, 2002 at 06:22:35 PM EST

    That's cool.  Your article is well researched and your knowledge of Managed C++, Java, C#, etc... is impressive. :-)

    [ Parent ]
    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

    The reason for handles (4.00 / 1) (#72)
    by ucblockhead on Tue Jun 25, 2002 at 03:45:01 PM EST

    Performance, pure and simple. That whole purpose of the "WordHdl" class is performance. Without it, the program (any version, C++, Java, whatever) runs twice as slowly.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    I appreciate your attempts at ... (3.00 / 1) (#75)
    by Space Monkey on Tue Jun 25, 2002 at 03:53:51 PM EST

    Making Java look fast, but I should point out that the most traditional way in Java is to make source have clean interfaces and clean code. If you have to muck things up to make it faster, then something's wrong.

    Sometimes it is necessary to sacrifice freedom for safety," as Benjamin Franklin once said.
    [ Parent ]
    Please explain (2.00 / 1) (#82)
    by Simon Kinahan on Tue Jun 25, 2002 at 04:39:48 PM EST

    Admittedly I haven't read your code in detail, but I really don't see why that should be the case.

    Simon

    If you disagree, post, don't moderate
    [ Parent ]
    Let me try to be clearer ... (4.50 / 2) (#88)
    by Simon Kinahan on Tue Jun 25, 2002 at 05:15:05 PM EST

    As far as I can tell, the only thing WorldHdls does is allow you to refer to a world by an integer handle. It contains a variety of operations that are, in essence, operations on words (even though there is no word class), and a methods for converting back and forth from integer to string form.

    This approach is one I would be reluctant to use, because it exposes the implementation of words as integers. You can rewrite that part of the code, in a much cleaner form that is just as fast (barring instantiation cost, which in this case will pale into insignificance), by having a Word and WordGraph classes (I would call the latter Dictionary, but you're using that for something else that possibly ought to be combined with it). They would look something like this (I've not included the implementation code, as it is trivial to infer given your original).

    class WordGraph
    {
        public Word addWord(String word);

        public Word getWord(String word);

        public String getPath(Word[] words);

        public void clear();
    }

    class Word
    {
        public Set/*Word*/ getNeighbours();

        public int distance(Word word);

        public String getText();
    }

    Is that not a lot cleaner ? and looking at it, quite possibly faster too, actually, since you no longer have to maintain that wretched collection in strings. I'm not terribly happy with getPath(), but I suspect that is because there really ought to be a proper abstraction for paths, too.

    Simon

    If you disagree, post, don't moderate
    [ Parent ]

    maintaining strings (4.00 / 1) (#89)
    by ucblockhead on Tue Jun 25, 2002 at 05:46:54 PM EST

    You are still going to have to maintain some sort of mapping between strings and integers, or you are going to lose the performance benefit. Or am I not understanding what you mean by "wretched collection of strings"?
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    References? (4.00 / 1) (#91)
    by mattbelcher on Tue Jun 25, 2002 at 05:50:47 PM EST

    Perhaps I'm missing something, but isn't a reference to a string simply an integer as well? Granted, in Java you can't do arithmetic with your references, but its not like you are actually passing Strings around, just the address of them.

    [ Parent ]
    Sorry (4.00 / 1) (#92)
    by ucblockhead on Tue Jun 25, 2002 at 06:05:40 PM EST

    I think I'm not being clear here. The performance hit is not in string passing. It is in using strings as a key in a container. If you use strings as keys, you end up doing lots of string compares. If you use integers as keys, you change these string compares to integer compares. Integer compares perform much better than string compares.

    In this particular case, there's no real reason to need strings. The only time you need to worry the string nature of the words is when you get the neighbors. At all other points in the algorithm, words are simply atomic things. By using integers to represent those things through most of the algorithm, it runs two or three times faster. (And you get the same benefit on all platforms, Java, C# and C++.)
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    Yes, but .. (5.00 / 1) (#95)
    by Simon Kinahan on Tue Jun 25, 2002 at 06:17:52 PM EST

    If you call ident() on your strings, you can then compare the returned Strings using ==, which is equally fast for all datatypes. ident() gives you the VM's version of the string from its string tables, so there's only ever one ident()'d string for any given value. That probably gives you what you want.

    Event disregarding that, comparisons on a Word object have the same cost as comparisons on 32-bit ints, unless you care about ordering, or using them as indexes. If you do care about that, see my reply to your comment above.

    Simon

    If you disagree, post, don't moderate
    [ Parent ]

    Ident() (3.00 / 1) (#96)
    by ucblockhead on Tue Jun 25, 2002 at 06:21:13 PM EST

    Ah...this is the kind of info I wish I'd had before I'd written the story...
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    Details (none / 0) (#133)
    by ucblockhead on Wed Jun 26, 2002 at 02:21:33 PM EST

    I can't seem to find any info about "ident()" in the java documentation I have...
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    I got it slightly wrong ... (none / 0) (#137)
    by Simon Kinahan on Wed Jun 26, 2002 at 04:06:31 PM EST

    The method you want is actually called String.intern().

    Simon

    If you disagree, post, don't moderate
    [ Parent ]
    bullshit, read the documentation dammit (4.00 / 1) (#112)
    by boxed on Wed Jun 26, 2002 at 03:36:42 AM EST

    Using String as keys in a container uses the hash value of the String. The amount of string comparisons should be extremely low. If you've set up the hash map correctly there would be NONE. Not a single one. Read the documentation dude.

    [ Parent ]
    Well then (none / 0) (#125)
    by ucblockhead on Wed Jun 26, 2002 at 11:56:39 AM EST

    Please explain to me why changing the key from an int to a string caused the program to run twice as fast.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    oh? (none / 0) (#141)
    by boxed on Wed Jun 26, 2002 at 06:41:06 PM EST

    Please explain to me why changing the key from an int to a string caused the program to run twice as fast.
    Wow, that surprises me. I would think that Strings should at least be as quick as int, not twice as fast. I was more right than I thought then!

    [ Parent ]
    Why ? (3.00 / 1) (#93)
    by Simon Kinahan on Tue Jun 25, 2002 at 06:11:25 PM EST

    You've now got a word object, a reference to which can point to as much data as you like, including the corresponding string. There's no need to keep a collection to map from strings to ints and back again.

    If there's some other place where having an integer key to stand in for the string would be useful, and which I have not noticed, each word can be assigned a monotonically increasing interger value by the WordGraph when you do addWord().

    Simon

    If you disagree, post, don't moderate
    [ Parent ]

    performance (5.00 / 1) (#94)
    by ucblockhead on Tue Jun 25, 2002 at 06:17:21 PM EST

    Having integer keys makes the program run between two and three times faster.

    That's the entire point of the class. The original C++ version written for PFC4 didn't have that class...it's entire purpose was to make the entry faster. When I wrote the C# version, I discovered that the same optimization (unsurprisingly) had the same effect. And it, indeed, had the same effect in Java.

    String compares are slow. There's no reason to use them when the things you are comparing are essentially atomic.

    It probably would be better to bury this all in a Word class and do the integer comparison in the Compare function... But doing the integer compare is critical, performance wise.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    No, look... (5.00 / 2) (#97)
    by Simon Kinahan on Tue Jun 25, 2002 at 06:22:18 PM EST

    If you've got a Word class, you can compare two instances of Word for reference equality in just the same time as two integers. Its exactly the same operation. You can do the same for Strings if you call ident() on them first.

    There's no need - that I can see - to have the integer handles at all, if all you're interested in is a fast comparison operation.  

    Simon

    If you disagree, post, don't moderate
    [ Parent ]

    string atomicity in Java (none / 0) (#142)
    by astatine on Wed Jun 26, 2002 at 07:25:32 PM EST

    Java supports the use of strings as atoms. The intern() method returns a canonical string reference, such that if s1.equals(s2), then s1.intern() == s2.intern(). By interning all strings, you could then simply do reference comparisons to determine equality.

    Society, they say, exists to safeguard the rights of the individual. If this is so, the primary right of a human being is evidently to live unrealistically.Celia Green
    [ Parent ]
    Methodology (3.00 / 1) (#73)
    by ucblockhead on Tue Jun 25, 2002 at 03:47:11 PM EST

    I do agree that the methodology is dubious, but frankly, I've never seen a language comparison that didn't have a dubious methodolgy. Such comparisons are not trivial.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    Yes (3.00 / 1) (#84)
    by Simon Kinahan on Tue Jun 25, 2002 at 04:47:27 PM EST

    So fundamentally, I think its a misguided thing to try to do. Programming languages represent different views that can be taken of the process of computation. As such, some are better suited to some problems, and others to others.

    Admittedly there are some features that are always desirable, and others that are mistaken, but a comparison using a single problem or a single checklist, or even a large group of problems, is going to miss important features.

    Simon

    If you disagree, post, don't moderate
    [ Parent ]

    Need to start somewhere... (none / 0) (#115)
    by codemonkey_uk on Wed Jun 26, 2002 at 05:08:51 AM EST

    Without language comparisons, how do you suggest programmers select the most appropriate language for any given task?
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    Re: Starting Somewhere (none / 0) (#121)
    by Matrix on Wed Jun 26, 2002 at 08:54:18 AM EST

    I'm tempted to say personal knowledge of the ins and outs of various languages. Not by reading things that compare the languages, which, as pointed out, almost always use a flawed methodology. A better approach would be to learn the languages in question, or read articles specifically about them.


    Matrix
    "...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
    - Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
    [ Parent ]

    Compare among similars (none / 0) (#150)
    by bodrius on Fri Jun 28, 2002 at 07:02:21 AM EST

    Languages should indeed be compared, but only among those that share similar paradigms and core qualities, and only with a particular goal in mind.

    When comparing languages with as different qualities as C and Java, for example, the programmer would be best served with a comparison of paradigms, then let him/her choose among the remaining options. Once more, having a particular goal in mind.

    Without a goal that defines the features that are relevant and how, any comparison is meaningless. The goal may be quite abstract ("GUI application development"), but a general comparison to see which language is "the best" is as effective as arguing about which movie is "the best ever": only the monumentally mediocre will be discarded.

    That said, I would argue that the hard part is figuring out what the "core qualities" of a programming language is and what it is best suited for.

    Syntax definitely doesn't help to make the decision, because it can easily lure programmers into thinking they are dealing with similar beasts when they are not: Java is not in the same family as C++, IMO (neither is C# or the whole .NET thing).

    Java and all of .NET are meant to provide high-level programming languages with a rich set of standard libraries, sure. But that's only part of the package. They run in a VM system that provides a bit more than platform independence: a security structure for running trusted and untrusted code, for example. The VM, properly used, could and should be a feature, not an implementation compromise.

    The point is: if performance is the issue, evaluate on performance with code that depends on performance. If it's readability, evaluate on that with code that demands it (multiple programmers in a mid-size app). If it's rapid development, evaluate different sets of tools and languages and see how quickly you can make a nice little App, how readable and modular it is, and then how fast.

    Whatever mix is chosen, the conclusion will only be valid for that mix, and will be completely useless and invalid for someone with different priorities and a different goal in mind.
    Freedom is the freedom to say 2+2=4, everything else follows...
    [ Parent ]

    Oh, come on... (4.33 / 3) (#77)
    by trhurler on Tue Jun 25, 2002 at 04:01:42 PM EST

    Granted, his code isn't what a Java programmer would call beautiful, but your suggestions for fixing it would make it even slower! If the purpose is a performance test, ucblockhead was a lot kinder to Java than he really ought to have been, given the way it is typically written!

    --
    'God dammit, your posts make me hard.' --LilDebbie

    [ Parent ]
    Why ? (3.00 / 1) (#83)
    by Simon Kinahan on Tue Jun 25, 2002 at 04:42:02 PM EST

    Given I didn't give a very concrete suggestion, I really don't see why getting rid of the nasty integer handles should make the code slower.

    The purpose in this case wasn't a performance test. It seems to have been a comparison of language "feel". If thats the goal, the languages should have been written as they normally would be, not like deformed C++.

    Simon

    If you disagree, post, don't moderate
    [ Parent ]

    Good point, but hard to do. (4.00 / 1) (#104)
    by ghjm on Tue Jun 25, 2002 at 09:01:15 PM EST

    If you're a C++ programmer, how would you know what the "community standard" ways of doing things are in Java? If you're trying to decide what to do next, then your evaluation projects are obviously going to look as much like C++ as possible, regardless of which language you're working in.

    Besides which, if you know a better way to write it, post the code.

    -Graham

    [ Parent ]

    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.

    Which Java (4.00 / 1) (#87)
    by ucblockhead on Tue Jun 25, 2002 at 05:12:27 PM EST

    It was the latest Sun JVM, downloaded a couple weeks ago.

    I hope no one things this article proves anything. It is, indeed, just a data point.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    Not all that surprising (none / 0) (#90)
    by mattbelcher on Tue Jun 25, 2002 at 05:46:55 PM EST

    As the author noted, Java has a lot of overhead tied up in doing console I/O. A large proportion of the running time may have been spent there.

    [ Parent ]
    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?

    Wild-assed python comparison (4.00 / 2) (#106)
    by MK77 on Tue Jun 25, 2002 at 11:25:29 PM EST

    I wrote a Python solution to this problem, but I didn't use the same algorithm as ucblockhead. My algorithm is probably less efficient.

    This is an even poorer comparison to his programs, because I wasn't attempting to solve the problem in the same way. But, what can we learn?

    First, it's a lot shorter. About one fourth the size of his shortest solution. And it's also a lot slower. The question is how fast is "fast enough"?

    If you optimized it, maybe you could get it faster, but I'm skeptical that pure Python will ever be as fast as even Java. Deducing types from arbitrary python code is a hard problem, and I don't think it will be solved satisfactorily for as long as people are actively using Python. However, if you want to speed up Python, you've got a few options.

    There's Psyco. This is a JIT compiler for Python which deduces variable types from runtime behavior. It's a clever solution to the problem, but writing a good JITter for Python is much harder than writing a good JITter for Java or C#. And that's already pretty hard. I admire the hack value of the project, but I don't think it will be production ready for a long, long time.

    Then there's Pyrex. You can annotate your python variables with C-style type declarations, and Pyrex will compile your code to C. It will be efficient where you use type declarations, and inefficient where you don't. This is a nice comprimise between the abstract purity of Python and practical performance needs, but Pyrex is still very immature. I've been using Pyrex lately, and it can certainly give me the performance I need, but once you get down to the level of C data types, it doesn't feel like Python any longer. You lose much of the programmer efficiency Pythin is famous for, and I feel like I might as well be writing C# code.

    Another option is Weave. You can easily embed C++ code in your Python code. The upside is the performance. The downside is that you are writing C++ code.

    So, what's my opinion after all this? I like Python a lot. I'd rather code in Python than C, C++, Java or C#. I think Python is an extremely well designed language, and useful for many things -- as long as performance isn't high on your list of project risks. If it is, but you can clearly isolate the performance critical section of code from the rest of the code, then maybe you should still use Python and use one of the performance solutions I discuss above. However, if you can't tolerate most of your program running one-hundred times slower than the equivalent C application, Python probably isn't the right tool for the job.


    --
    Mmm... rageahol
    [ Parent ]

    jython (3.00 / 1) (#110)
    by f00b4r on Wed Jun 26, 2002 at 02:16:12 AM EST

    Or you could use a tool called Jython and program parts of your program in Java and other parts in python and have them intermingle as you like. Its a great tool and very useful.

    [ Parent ]
    Type inference (4.50 / 2) (#114)
    by han on Wed Jun 26, 2002 at 04:48:31 AM EST

    Is there something about Python that makes type inferencing unworkable? As far as I understand it, type inferencing in dynamic languages is pretty much a solved problem. I only have experience of this in Common Lisp, where the compilers work well enough that you don't need much type declarations, unless the compiler gives inefficiency warnings about your inner loops.

    [ Parent ]
    amen (none / 0) (#116)
    by kubalaa on Wed Jun 26, 2002 at 05:22:54 AM EST

    It baffles me why modern statically-typed languages would not support type inference. There's everything to gain, nothing to lose, and even people used to dynamically-typed languages don't mind it much.

    [ Parent ]
    Here goes subject line. (none / 0) (#118)
    by i on Wed Jun 26, 2002 at 08:12:30 AM EST

    Modern statically-typed languages do support type inference. It's somewhat harder for OO languages because of subtyping and/or ad-hoc overloading though.

    and we have a contradicton according to our assumptions and the factor theorem

    [ Parent ]
    yeah, okay (none / 0) (#120)
    by kubalaa on Wed Jun 26, 2002 at 08:28:20 AM EST

    Seems like all the modern, mainstream, statically-typed languages are OO, which I'm not sure is so great. Anyways, O'Haskell has a good section on the limitations of inference with subtyping.

    [ Parent ]
    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.

    not so important with newer JVMs (5.00 / 1) (#108)
    by bhouston on Wed Jun 26, 2002 at 12:18:52 AM EST

    Although what you say was very true it is not so important with newer JVMs starting with (I believe) v1.3.

    Here is a quote from www.onjava.com:
      "For some of the latest JVMs the difference in speed between the two classes is negligible: strictly speaking, for these JVMs the difference in speed between the two classes is less than the variation in times obtained from tests comparing the performance of these classes."

    http://www.onjava.com/pub/a/onjava/2001/05/30/optimization.html


    [ Parent ]

    depends on the application (4.00 / 1) (#111)
    by boxed on Wed Jun 26, 2002 at 03:32:08 AM EST

    in this case, the algorithm is specifically heavy on the dynamic array, so using a Vector instead of ArrayList will hurt performance. This is not only a case of synchronization though, it's about the flawed growing algorithm of Vector. A synchronized ArrayList is always measurably faster than Vector.

    [ Parent ]
    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.

    Vapourware is not relevant to benchmarks (1.33 / 3) (#117)
    by walwyn on Wed Jun 26, 2002 at 08:00:24 AM EST

    How many times does some code need to execute before runtime optimization kicks in? I'll take an interest in JAVA when this simple benchmark runs in a comparable time in C++ and Java.
    ----
    Professor Moriarty - Bugs, Sculpture, Tombs, and Stained Glass
    [ Parent ]
    get a grip dude (3.00 / 1) (#122)
    by boxed on Wed Jun 26, 2002 at 10:50:49 AM EST

    JIT isn't vaporware. It's standard in suns and ibms JRE's on windows, linux and solaris. Get a grip on yourself.
    How many times does some code need to execute before runtime optimization kicks in? I'll take an interest in JAVA when this simple benchmark runs in a comparable time in C++ and Java.
    1) I don't know how many times, I didn't write the JIT. Go ask Sun. 2) It's "java" not "JAVA". Stop screaming. 3) It will only run in comparable time after the warmup period. Read a book about VM design or something.

    [ Parent ]
    Right (none / 0) (#135)
    by walwyn on Wed Jun 26, 2002 at 03:03:17 PM EST

    your claim is that Java can avail itself of runtime optimization and thus run faster than statically compiled code. The claim is vapourware as the benchmark clearly shows that runtime optimization does not exist. The benchmark code runs in 6 secs as compiled C++ and 13 secs as Java on my machine. No optimization tweaks, or inlining of the C++ code.

    The code is executed 10,000,000 times which ought to be a sufficient number of times, for a runtime optimizer to work out whats going on, that the each loop iteration returns a constant value

    If this time difference is due to a "warmup period" then heaven help us if it ever has to deal with complex code. The code is doing simple comparisions of doubles, which is extremely common in CAD programs. Heck we aren't even doing anything 'complex' like vector cross products, or 'difficult' like surface evaluations. Nevertheless feel free to up the number of loop iterations by a factor of 100.
    ----
    Professor Moriarty - Bugs, Sculpture, Tombs, and Stained Glass
    [ Parent ]

    look up the word 'vaporware' (none / 0) (#140)
    by boxed on Wed Jun 26, 2002 at 06:37:00 PM EST

    It means "software that has been advirtised but does not exist". You claim JITs to be vaporware, obviously you either don't even know the meaning of the word, or you're ignorant. Furthermore, you have still not taken the startup time into consideration. Not that it matters really, because the dynamic performance optimizations I'm talking about are present in real code, but not in your example. Your test is biased heavily on the side of C++. Hell, not to mention that java kills C++ in a bunch of memory allocation/deallocation intense ares, due to the centralized garbage collection.

    [ Parent ]
    Reading comprehension problems? (none / 0) (#143)
    by walwyn on Wed Jun 26, 2002 at 08:40:38 PM EST

    If you believe that Java has effective runtime optimization that will outperform static compilation, then I've got this seafront property just outside of Las Vegas you might be interested in.

    What could be simpler than comparing two doubles? But Java is slower by almost 50%. Run the java benchmark with 10 iterations and the execution time is in ms, so the JIT compilation is not a factor, or do you think it is continually recompiling the code on every iteration?

    Can you provide a Java application and dataset where runtime optimization outperforms a statically compiled C++ equivalent? No you can't. All you can do is promise it next week, next year - vapourware, and well you know it.

    ----
    Professor Moriarty - Bugs, Sculpture, Tombs, and Stained Glass
    [ Parent ]

    I just ran your little benchmark (none / 0) (#144)
    by Space Monkey on Wed Jun 26, 2002 at 08:51:26 PM EST

    C - 5 (000?)

    Java - 5110

    Looks like Java tied C. Which means that it isn't terrible.



    Sometimes it is necessary to sacrifice freedom for safety," as Benjamin Franklin once said.
    [ Parent ]
    Really? (none / 0) (#146)
    by walwyn on Thu Jun 27, 2002 at 08:00:22 AM EST

    I've just downloaded j2sdk1.4.0_01 onto the throb beast at work. Changed the number of iterations, in both the C++ and Java sources, by a factor of 10 and I get C++ 5(000), Java 11453.
    ----
    Professor Moriarty - Bugs, Sculpture, Tombs, and Stained Glass
    [ Parent ]
    Java version seems faster for me.. (none / 0) (#149)
    by icklemichael on Fri Jun 28, 2002 at 06:15:02 AM EST

    The java version seems to go faster (albeit still slow compared to both of yours) on my machine:

    mstephen@sokoki:~/benchmark$ a.out
    24
    mstephen@sokoki:~/benchmark$ java Point
    21515
    mstephen@sokoki:~/benchmark$ g++ --version
    egcs-2.91.66
    mstephen@sokoki:~/benchmark$ java -version
    java version "1.4.0-rc"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
    Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)


    [ Parent ]
    Startup (none / 0) (#126)
    by ucblockhead on Wed Jun 26, 2002 at 11:58:49 AM EST

    As I explained elsewhere, changing the dataset size by a factor of four caused all versions to take four times as long to run. That includes C++ and Java. So plainly JIT was having no effect on runtime.

    This is not surprising given the size of the dataset. and the small size of the program.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    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

    Pascal? (4.00 / 1) (#127)
    by ucblockhead on Wed Jun 26, 2002 at 11:59:50 AM EST

    C# is nothing like Pascal. It is clearly based on Java.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    I believe the message was about Anders Hejlsberg (none / 0) (#128)
    by lotzmana on Wed Jun 26, 2002 at 12:21:37 PM EST

    Anders Hejlsberg is the main designer behind C# and the .NET framework. He used to work for Borland where he creating Delphi. Delphi was based on ObjectPascal and is an excellent programming framework. The rumor is that Microsoft were then stunned by the qualities of Delphi and did their best to make him leave Borland and join Microsoft. Hejlsberg, as far as I remember, is the leading designer of the Windows classes libraries for Java. This was one of the contention points with Sun later. As the Java enterprise in Redmond sunk, Microsoft shifted its attention in creating something new that can be under the control of the company.

    Anders Hejlsberg won the Dr. Dobb's Execellence In Programming Award for 2001. You can see him on the cover of the journal, may 2001.


    [ Parent ]

    Yes (none / 0) (#130)
    by ucblockhead on Wed Jun 26, 2002 at 12:55:11 PM EST

    Yes, that is all very true...but the language C# has very little relation to ObjectPascal other than that they are both compiled Object Oriented languages.

    It may well be true that the .NET Framework is very similar to Delphi.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    actually it is similar to Delphi Pascal (4.00 / 1) (#136)
    by bhouston on Wed Jun 26, 2002 at 03:05:57 PM EST

    Although I don't know all the features that C# has in common with Delphi that are not also shared by Java I can list a few:

    C#'s delegates <--> Delphi's procedural types
    C#'s override keyword <--> Delphi's override keyword
    C#'s params keyword <--> Delphi's variant open-array parameters
    C#'s ref keyword <--> Delphi's var keyword

    This is in addition to the many features that C# has in common with both Java and Delphi.  If you were to use one of Borland's recent versions of Delphi you would why people say there are similarities.

    [ Parent ]

    Yeah, right (4.00 / 1) (#129)
    by Jevesus on Wed Jun 26, 2002 at 12:29:10 PM EST

    It's true that Anders Hejlsberg also developed the Turbo Pascal compiler and had a lot to do with the development of Delphi.

    However, your complete and utter lack of experience with Pascal and/or C# shines perfectly well through your claim that C# is supposedly a "copy of" Pascal. If C# is a copy of any language, which I beg to differ, that language is Java or C++.

    - Jevesus
    [ Parent ]

    You haven't used MS C++ recently, eh? (none / 0) (#145)
    by DodgyGeezer on Wed Jun 26, 2002 at 11:10:22 PM EST

    Ahh, come on.  The MSFT C++ implementation is much better than it used to be.  It's fairly easy to write ANSI C++ anyway.  It's definitely better than some of those UNIX vendor C++ compilers.  Even with *ageing* MSVC6, the only problems I had writing cross-platform code to be shared on the Mac were with:

    1) "throws" function decorator - MSVC6 C++ doesn't call abort() when an unrelated class is thrown.
    2) Implicit scoping within a class implementation of things defined in the class definition.
    3) Scoping of variables declared in a "for" statement.

    I was even able to include TCHAR.H and have the Win32 version use Unicode (wchar_t) whilst the Mac version compiled under Code Warrior to ordinary single or multibyte (char), although which, I don't recall.

    I wrote *all* the code under Win32.  The Mac guy would periodically grab a copy from source control, and come back with the small number of comiler errors and warnings.  I was actually impressed at how easy it all was.  Finally, when it comes to library functions, the MSDN documentation is pretty good at declaring compability, e.g. whether the function is ANSI or Win9x, or WinNT, etc.

    [ Parent ]

    "actually visual?" (none / 0) (#153)
    by NFW on Fri Jun 28, 2002 at 02:44:28 PM EST

    What does "actually visual" mean for Borland's C++ Builder?

    When I think of visual programming, I think of languages with source code that isn't text, e.g. things like Prograph and Max and my own two projects.

    What is it about C++ Builder that makes it "actually visual?"


    --
    Got birds?


    [ Parent ]

    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 :(

    Inner classes (none / 0) (#163)
    by mattam on Thu Jul 18, 2002 at 06:32:15 AM EST

    You can do it in both languages so why :( ?

    [ Parent ]
    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

    still has the Distance bug (none / 0) (#147)
    by zzzeek on Thu Jun 27, 2002 at 11:36:13 AM EST

    its still doing this to calculate distance:

    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;
    }

    this will always return zero.

    [ Parent ]
    Doh! (none / 0) (#148)
    by ucblockhead on Thu Jun 27, 2002 at 12:21:21 PM EST

    That's fixed now...Check here.

    It now runs in 20.751 seconds...significantly faster than the C# versions but still a bit slower than the C++ versions. This runtime is closer to what I'd expected originally.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    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.



    yeah (nt) (none / 0) (#152)
    by ucblockhead on Fri Jun 28, 2002 at 01:35:04 PM EST


    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    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.

    You are right (none / 0) (#155)
    by ucblockhead on Mon Jul 01, 2002 at 12:15:05 PM EST

    You are correct, of course, though in my defense I have to say that there is currently only on C# platform available, and very few java platforms available. In fact, I tried to download the gcc "gcj" java compiler, but they seem to have removed the download page...

    So you are correct, in theory, but in practices, we working programmers have to compare the obtainable implementations...right or wrong, "java" is mostly associated with Sun's byte-code implementation.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    gcj (none / 0) (#159)
    by greenrd on Tue Jul 02, 2002 at 04:34:51 PM EST

    gcj is part of the gcc suite. You can also get it as an rpm from your local redhat mirror.


    "Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
    [ Parent ]

    3.0 (none / 0) (#160)
    by ucblockhead on Tue Jul 02, 2002 at 05:29:16 PM EST

    Isn't it 3.0 only?
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    Nope (none / 0) (#161)
    by greenrd on Tue Jul 02, 2002 at 10:17:56 PM EST

    It's been around for aaaaaaaages.


    "Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
    [ Parent ]

    Hrm.... (none / 0) (#162)
    by ucblockhead on Tue Jul 02, 2002 at 11:12:36 PM EST

    I should have all the dev tools on my box...I can't find it...

    It's probably this stupid Mandrake install...I really should rebuild my box.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    Not quite. (none / 0) (#156)
    by jacob on Mon Jul 01, 2002 at 01:57:21 PM EST

    A PL's semantics can have necessary performance implications. For instance, C's semantics say that when you add two integers using the + operator, the result is undefined if the integers are out of a particular range. That semantic decision allows compiler writers to turn a + into an actual CPU addi instruction directly. In Scheme, though, there is no equivalent; + is always defined even over numbers that are larger than a machine register; as a result, Scheme + has to somehow check at runtime that the sum will not be too large, and if it will be perform some extra action: addi doesn't do that, so Scheme + can't compile straight down to that. Furthermore, Scheme allows any value to flow into +, while C only allows ints (well, the + over ints only allows ints, anyway). That means that Scheme + has to check what kinds of values it has (are these integers? Inexact floating-point numbers? Exact fractions? Some other kind of value, like a list?) and then do the appropriate thing based on what kind of value it receives at runtime. That has a necessary performance penalty, and that performance penalty really does come as a result of the language itself rather than a particular implementation of it.

    So even in a theoretical sense it is possible to meaningfully discuss the speed of relative languages. In a practical sense it's much more important. Standard libraries, standard implementations, et cetera all have performance characteristics that are important to know.


    --
    "it's not rocket science" right right insofar as rocket science is boring

    --Iced_Up

    [ Parent ]

    Good point (none / 0) (#157)
    by localusr on Mon Jul 01, 2002 at 02:55:13 PM EST

    Thank you for your comment, you have a good point. I agree with you on that some semantic constructs are more conducive to faster implementations and some are less. However, we can't help speaking of faster implementations rather than faster languages in this case also.

    I know I am getting circumstantial here and for many practical purposes saying that C++ is faster than Java is very meaningful. I was trying to emphasize the importance of evaluating a language on the basis of the expressiveness and richness of its abstraction set as opposed to the speed of its implementations though.

    [ Parent ]

    That depends (none / 0) (#158)
    by ucblockhead on Mon Jul 01, 2002 at 03:29:05 PM EST

    What is important depends a lot on the project. An expressive language is useless if the project is canceled because the resulting program is too slow.

    It is important to evaluate a language on all metrics, both things like expressiveness and also things like performance.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    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!