Slashdot Mirror
Does C# Measure Up?
An anonymous reader queries: "Windows::Developer is offering a detailed, quantitative examination [free login required] of C#'s performance versus Java, C, C++ and D. 'Overall the results were surprising, although perhaps unexciting, in showing that C# (and to a less extent Java) is, to a good degree, on a par in efficiency terms with its older and (presumed to be) more efficient counterparts C and C++ at least as far as the basic language features compared in this analysis are concerned,' writes the author, Matthew Wilson. I'm only an amateur coder, and confess to not understanding most of the two-part article. I'd love to hear how true programmers view his results, which are too wide-ranging to summarize easily here. How about it Slashdot, as this special edition asks, 'Can C# keep up with compiled languages like C, C++, and D or byte-code based Java?'"
While we're on the topic of C#, rnd() queries: "It's been a while now, since Mono and DotGnu have begun eroding the market power of Microsoft by creating open source implementations of C# and the Common Language Runtime. Over the weekend I loaded Mono and did some informal benchmarking of object creation, intensive message passing, massive iteration, etc., and the results show that Mono is about 90% as fast as Microsoft's implementation after a very short time. I now want to switch my .NET development over to Linux/Mono exclusively, but I want to first settle on a free alternative to Visual Studio .NET 2003. Any suggestions?"
C# is higher pitch than C but less so than D.
--
Hotspot is really good about compiling bytecodes down to the native machine language. That code is real honest to goodness native code, and will execute at approximately C++ speed.
Why use anything else?
- David
How about Eclipse?
Actually VB apps tend to run just fine through Wine, or at least a few little projects I've done in VB have worked for me...
(a) That's not the only problem;
(b) VB isn't the topic; and
(c) That isn't even true.
Wow, none out of three!
Raed it. Ingroe it. Bncehmrak aynawy.
This really makes sense if you understand how JITs work, and understand the nature of the benchmarks. These benchmarks are mostly microbenchmarks that test a particular operation in a tight loop. JITs can compile this loop once and run it directly on the CPU afterwords. This doesn't extrapolate well to situations where the JIT gets involved more often in the benchmark.
A deep unwavering belief is a sure sign you're missing something...
I now want to switch my .NET development over to Linux/Mono exclusively, but I want to first settle on a free alternative to Visual Studio .NET 2003. Any suggestions?
:-D
VI.
C,D, I feel bad for the F Programmer.
Mono is a bit faster than Java, for some benchmark?
Well, why didn't you say so before?!
That way we could have avoided all that tedious discussion about IP infringements, functionality etc. in yesterday's Mono debate. Clearly some dude's performance figure should override all other considerations when choosing a platform.
> Overall the results were surprising, although perhaps unexciting, in showing that C# (and to a less extent Java) is, to a good degree, on a par in efficiency terms with its older and (presumed to be) more efficient counterparts C and C++ at least as far as the basic language features compared in this analysis are concerned
Could we have a few more weasel-words in that sentence, please?
Sheesh, evil *and* a jerk. -- Jade
Java has received alot of attention over the last 7 or 8 years or so. It's a great idea in theory, but it falls way short in practice. It does remain viable for a few select uses, though: small widgets, servlets and web app servers. Pretty much other than that, using Java will mean excessive memory usage and slow performance.
Garbage collection in Java is not guranteed. It's what I call Union. It'll clean up when it god damn well feels like it. In the meantime, the system slows to a crawl.
Graphics in Java are abysmally slow. Even basic UIs lack the speed and responsiveness of GUIs written in C, C++ or similar languages.
Java was supposed to be: Write once, run anywhere, but what it is in reality is: Write once, debug everywhere... over and over and over. Or perhaps more appropriately it is" Write once, run screaming.
I've worked in a variety of Java development projects in the past and not once has it ever risen to the task to show itself as a worthy choice and/or a mature language. Instead it has invariably wasted companies time and money. Primarily because they failed to realize that Java is a small task tool, not suitable for major applications or those requiring performance.
I know a lot of engineers like Java because it makes life easier for them by doing things for them, but those things it does it does very poorly.
I'm sure I'll be marked as flamebait or troll by some Java loving mod, but what I've stated are facts and experiences from real life Java development. The results are in and frankly... Java sucks! Stick with C and C++ for most development, there's a reason they are the standard: they work.
This is just one way to slice the pie.
Languages are appropriate for different uses. I use C while kernel hacking. I use C++ for its template abstractions. I use PHP for web pages, Perl for command-line scripting. I use bash/tcsh for boot-scripts. I respect VB as an accessible language, but I have no use for a single-platform language.
What language you use depends on your application. Comparing C, C++, and C# is like comparing a wrench and a screw driver. And concluding they can both be used as a hammer.
C# was Delphi b (best flat sign I could do)
My other sig is extremely clever...
- C# fares rather well.
- ... but almost never as well as native C and C++ implementations done "smartly".
- Java suffers from runtime-based overhead, with the advantage of a well-tested set of runtimes for various platforms. Unfortunately, due to the Java implementation of client-side runtime libraries, programming in Java is still "write once, test everywhere. curse. port everywhere" for real applications.
And most importantly, as a game programmer, I'm going to pay attention to the relative performance the author received from the Intel-branded compiler, written to the metal of the Pentium IV with streaming SIMD instructions. -andyRemember though, C# and Db aren't the same note outside of the well tempered world!
OK lets get a few things settled.
Given: two identical applications; A, written in low level language like machine assembly, C, or C++; B, written in high level language like Java, Python, VB, hgluahalguha.
If the application is high in CPU burn (lets call it X), like oh, for (i = 0; i
If the application is copying a very large file using basic read/write system calls and large enough buffers (lets call this Y), A and B will have very similar performance.
If the application is printing hello world, they will have similar performance, although the startup costs for B may be higher, and A will probably finish executing faster.
MOST applications written today are written to solve for Y. The code that most programmers write today is NOT the CPU intensive portion. Usually the CPU intensive portion is in the library called by the programmer: rendering a box, moving things around on a storage device, making something appear on a network.
In these cases, a high or low level language makes no freaking difference on execution speed. However, your choice WILL make a huge difference on time to develop, maintainability, resultant bugginess, SECURITY, etc.
OF COURSE THERE ARE EXCEPTIONS. Maybe you're writing a routine that needs to draw lines fast, or move bytes through a network filter at 100MB/sec, or you're compressing a file, whatever. In these cases you tend to write the performance critical code in a more low level language so you have greater control over the physical machine. Sometimes you write the entire application in the low level language.
Many high level languages provide mechanisms for calling low-level code when it's necessary for performance. It's often pretty easy.
The performance argument is a red herring.
...my life. It's been mostly C/C++ but also a good amount of assember and VB. Maybe someone here can answer one of the questions that keeps poping up when I write anything. My question is, why do we always end up creating libraries/classes that contain other code we will never use? What I would like is a compile environment where each function or object that I use is individually addressable, without having to pull in other "stuff" I don't need in my specific app. Is that so hard? Why doesn't the OS manage code better than pulling in a whole library? If I use only strcat() for example, why do I need to load in the entire C string library?
.NET and Suns Java take the cake by making you load an entire "run-time" engine. This consists of vast numbers of "ready-to-go" objects that make your simple "Hello World!" app into an 11 Meg progam. Java can't even share the "run-time" between apps very well!
The problem gets even worse with C++ and objects. Huge numbers of member functions and public variables that will never be used. Microsoft's
Is there a program out there that can tell the efficiency of the operating system environment, apps and OS, by how many functions "aren't" getting used in a normal day by a user? I'm going to go out on a limb here and suggest that most RAM isn't being utilized by apps.
What I would like is an extremely efficient programming environment that compiles my six line x++ program down to a few hundred bytes total...that's in-memory while running. I want to use my RAM for data and number crunching, not unusable code.
+1-1
So, with that line of thinking, C++ should have been "P" (insert favorite "P Object-Oriented Programming" acronym joke here), and C# (although it shouldn't have been created at all, but was) should have been "L".
I don't know if anyone has done any formal study on the complexity of development tools over time - but the fact is that programming tools are getting "lower" over time.
When I started out in this business, a language like C was a high level programming language. It did a lot for the programmer, especially compared to assembler and FORTRAN.
Everything we did every day was to save memory and CPU cycles. Can we squeeze a date field into 8 bits? You bet we'd try! And we did! Heck, we could ignore weekends and holidays. Phew!
At the same time, databases were heirarchical. The databases were very close to the machine, so they were darn fast. As long as you didn't do any unexpected queries (like "sort by first name"), everything was blazing fast and tight.
Then came the higher level systems. Ouch, they sucked! We were the very first customer to run DB2 in production (quiz- you know which one?) Anyhow, it sucked rocks compared to the heirarchical databases - they were just optimized for speed! Why would anyone ever want a relational database?
But over years we came to see the light. With faster and faster machines, the number of cycles was less important. With bigger memory and disk, storage was less important. And it was butt-easy to use these tools. Easier and MUCH more maintainable.
So yeah, Java and C# are going to use more memory and more cycles than plain old C (if using the languages as expected). But for most tasks, that isn't the whole story.
The whole story is that Java and C# result in less expensive programs. And those programs should run fast enough. Yeah, not in EVERY case. But in most cases.
Performance comparisons be damned.
I recommend that any programmers out there try using it before discounting it. It might be especially interesting for those C++ programmers out there who don't like Java for one reason or another.
...be smart enough to "know" what sub-functions each function you are using needs to be loaded. If strcat() only uses 3 sub-functions, then those should only be loaded for "it". And, if those functions are already loaded "somewhere in memory", the OS shouldn't load them again, and again, and again, as so often happens these days.
I'm saying that the compiler/OS should be smart enough to "itemize" your entire application in terms of absolute functions/variables needed at compile and run-time.
Where is that capability? Why aren't compilers smarter?
-1+1
No matter what you say, C is *always* faster. You *cannot* write a loop in C#, and claim that it will run faster than a comprable loop in C. For one, the interpreter for Java or C# is very likely written in C itself.
Does the speed matter? Does anyone care? No. Well, not for a vast majority of applications. Most of the time the I/O speed is the bottle-neck, not the "code" speed. So if you write a word processor, or some database app in C#, or C++, or C, or Java, more often than not, their 'apparent speed' will be comprable to each other.
A better question to ask is: Would you do numerical analysis, or number crunching/factoring algorithms in Java or C#? Would you even do them in C? (or would you go for Fortran or distributed Haskell?)
"If anything can go wrong, it will." - Murphy
And, if those functions are already loaded "somewhere in memory", the OS shouldn't load them again, and again, and again, as so often happens these days.
If the functions are in a shared library, they shouldn't be. Each library (including, for example, the C runtime) is loaded once into memory and every process uses the same code. If you modify that code in memory, Windows makes an individual copy of the page for the modifying process. I couldn't tell you exactly what the overhead is used for, but the OS isn't loading 20 copies of strcpy or whatever as long as each executable is dynamically linked.
Too bad Limbo is too deeply tied to Inferno. It's unfortunate. From looking at how it's been designed it seems that Dennis Ritchie still hasn't lost his touch as an exceptional language designer. The Dis virtual machine that goes with it is supposedly designed to make a JIT simpler and more efficient, and well, according to Vita Nuova it gets something like 50% to 75% of the performance of compiled C/C++ code, which, if the article and Vita Nuova's benchmarks are accurate, totally blows C# and Java out of the water performance-wise. Now if only Vita Nuova would care to make it half as platform-neutral as Java... But hey, who cares, I'm already trying to do that. :)
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
You're right. But with ever-increasing CPU horsepower, memory bandwidth, memory size, etc., there simply is no incentive for optimizing the things you're talking about. Moore's 'Law' has attenuated the advancement of software technology, by eliminating the need for efficient software.
There are plenty of dinosaurian programmers like myself who remember hacking away on small machines. Save a byte by referencing a constant stored as an opcode in the instruction stream? Excellent! SLR R1,R1 is 60ns faster than SL R1,R1? Excellent! Decrease the size of the PDP-8 bootstrap loader by one word? Excellent! (Flipping those toggle switches took a lot of time.)
In 'the old days' hardware was expensive and programmers were cheap. Hard problems were solved by incredible brainpower from great engineers. As a result, by the early 70's software had made huge advances over the punchcard/paper-tape era, and we had learned a lot about how to build quality systems.
But there was a magic moment when the curves crossed between the cost of programming time versus the cost of hardware. Suddenly, it became easier to solve a problem by adding iron rather than by thinking harder. And so we slid backwards down the slope.
As far as I'm concerned, hardly anything significant has happened in software architecture or praxis for a few decades. Sure, we have a bunch of fancy new widgets, and the common man's programming paradigm has changed. And the Open Source movement finally has given substance and a PHB-understandable framework to what Unix, LISP, Smalltalk, and other hacker communities used to do behind the scenes.
But most of today's 'new' language, compiler, data management, operating system, and other computer science paradigms had their fundamental elements invented back in the 60's and 70's. We're finally RE-discovering many great concepts of the past. But it seems we've totally forgotten the importance of efficient, defect-free code, and the methods that might be used to create it.
This is not to say that only great systems were built in 'the good old days' -- those days weren't that good, and there was plenty of crap. But the really bright folks figured out how to do things RIGHT; and yet they wound up being ignored, because 'doing it right' became less important than 'letting Bruce the part-time lifeguard do it over the weekend in Visual Basic.'
So while I totally agree with your rant, and I've made a hundred similar rants of my own, the fact is we probably won't see fundamental improvements in software platforms until subatomic physics finally provides a wall against which hardware advances can bounce. As long as the answer to every performance/capacity complaint is "wait six months" there's no incentive to invest the man-centuries it will take to revamp our software environments. We probably need to build intelligent software that can optimize itself, because WE NEVER WILL.
</rant>
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post by Bruce Eckel on artima.com.
Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).
I do a lot of ASP3.0/SQL2k and some utility development on Win32, taking a stab at .NET. It would be nice to move over to Mono.
Anyway, I've done a bit of poking around and ran across SharpDevelop - AKA #develop . It's open source a la GPL and looks a lot like Visual Studio, and compiles C# and VB.NET; has C# => VB.NET code conversion; does projects or files; has syntaxing for the whole MS shebang. It's a .97 - this build was released Friday 9/12/2K3, officially in beta, and you can get the binaries here, go snag the source here, and get the MS.NET1.1SDK here.
To those folks who hiss and moan about the whole GNOME/.NET/Mono thing, take a gander at the rationale before playing jump to conclusions (mp3).
SharpWT - AKA #WT is a .NET port of Java SWT on both Windows/.NET and Linux/Mono platforms. So...you can develop your .NET apps to run on both Win32 and Linux with pretty much the same GUI. Neat, eh?
Anyway, intrepid Windows Developer, if you can pry yourself away from the MSDN Library for a few minutes, you might find there's something to this Mono business.
I've been coding for a million years: 6502 machine code all the way up to a recent foray into C#, and almost everything in between. Here's my take, for what it's worth. And, it's your chance to mod me down for pontificating!
.NET, to which C# is bolted, is pretty good as well. And the IDE is very nice. So, all-in-all, I think that C# is a good choice for Windows development. The web forms stuff seems interesting, but I have a feeling that using it would be something that I'd end up regretting - there's bound to be nasty gotchas that won't show up until late in the project.
Delphi is the best all-around language ever for producing Windows apps. The Delphi programmer has control over everything if they want it, but they don't need to muck around with nasty details unless they need to. It encourages clean coding. Performance is superb. And the IDE is excellent. The Delphi package (language plus IDE) has been the path of least resistance to getting an app done for the past six or seven years.
Prior to Delphi, the way to go was VB with C DLLs. Do the UI in VB, do the internals as C DLLs. VB was great for abstracting nasty stuff, but it often overabstracted, and performance was ungood. Writing companion DLLs in C boosted flexibility and performance.
Generally speaking, C is basically not much beyond portable assembly language. If a reasonable alternative is available, and it usually is, using C for anything beyond embedded systems or super resource-critical applications is probably not a good idea, as the code tends to be dangerous and obsfuscated. And keeping track of pointers is just nutty.
C++ is a nightmare. In theory it's object oriented, but all of the code that I've seen is a total mess, more like C using the C++ libraries. Ugh.
Java is almost good: it is pretty safe, and encourages good habits. But I find it clumsy - like it was designed by academics rather than practical developers. Lack of enumerated types, for example, is insane, and encourages unsafe programming. It's also a pig, which doesn't matter so much for a lot of things these days - we usually have lots of CPU cycles to spare. For doing GUI apps, Swing is a weird joke - a pig's pig - which should be forgotten immediately. And the Java IDEs have only recently become usable for command-line stuff, but they suck as bad as Swing for GUI development.
Now C#. Having toyed with C# for an app recently, I'm quite impressed. It's sort of like the best of Java with some of Delphi's goodness added. It's ALMOST as good as Delphi - which makes sense, since the same fellow (Anders Hejlsbeg) was key in developing both of these languages. And
I am in the process of coding a data collection server application in Java which collects data from remote devices that dail up over a phone line. The application must interface with the serial port at a low level, send email, generate XLS files, send faxes, create charts, and, of course, communicate with a DBMS. It also has a significant GUI component as well. Oh yes, this application must be able to run both on Linux and Windows (2000 or XP).
I have been developing on Linux. All in all, to date I've coded around 30,000 lines of code. Because of the high level of portability of the APIs, I had to change all of about a dozen lines of code to get it up and running on Windows. That's one dozen out of 30,000. There's now way you could even come close to that using C or C++, regardless of how cross-platform the library developers say their libraries are.
As far as performance, Java may have been slow three of four years ago, but the last several versions of the JDK and the HotSpot JVM have seen a steady and rapid improvement in performance and stability. SWING, although it has improved, may still be a bit slow, but computational code written in Java is only slightly slower than in C++. Even current versions of SWING, although arbuably slower than native GUIs like GTK+ or QT, are fast enough so as to not be noticable on any machine faster than 800MHz or so.
Most people who say Java is unstable or slow are remembering their experience from the JDK 1.1 days. The current JDK 1.4 bears little resemblance to that in terms of performance and maturity.
And this is where the .NET Framework shines, because the CLR is a generic virtual machine to which any number of languages can be compiled. Currently there are C#, C++, VB, and even Java (under the moniker J#). There has been talk of writing a Python compiler and even possibly a Perl compiler. So you can choose your language of choice, and your resulting binaries or objects will fully interoperate with the other .NET languages and class libraries.
And as far as this article is concerned, I think the interesting point is not that they're comparing apples to oranges, but just that the performance numbers for CLR-compiled C# aren't so horrible that they should scare off the majority of developers.
Possibly true for pure VB, but major VB apps aren't. In order to do a lot of things that aren't intrinsic to the language, you end up calling C/C++ or Windows API functions to get the job done. That tends to blow compatibility with non-Windows runtime environments (hell, it tends to blow compatibility with Windows environments.)
The higher the technology, the sharper that two-edged sword.
I really can't believe this thread. Why do people always come up with this worn out line whenever someone suggests that C++ templates are an advantage? And how come so many people have done so in replying to the same post? All but the first are (-1, Redundant), and the first is (-1, Ill-informed).
OK, please, read this carefully, for I shall write it only once (in this thread):
Java's generics are not even close to the power of C++ templates. They are glorified macros to fix a bug in the type system that should never have been there.
C++ templates were at that level around a decade ago. Today, they're used not only to create generic containers (for which they are, no doubt, very useful) but also, via metaprogramming techniques, as the tool underlying most of the really powerful developments in C++ for the past few years: expression templates, high performance maths libraries, etc.
If you didn't already know that, please read it again and understand it before proceeding.
Java's generics don't even come close to the same power. They're a cheap knock-off, aimed at just one of the uses of C++ templates, which fixes a glaring flaw in the previous Java language. For that, they serve their purpose well, but please don't pretend they're anything more.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
... compared to the code-generating power of lisp macros.
To a Lisp hacker, XML is S-expressions in drag.
Microsoft have had a .Net version of Quake II mentioned on their developer pages for some time now. It's a port to Visual C++ .Net 2003, using the CLR.
Has anyone tried this? It's presumably managed C++ rather than C#, but it should give a fair indication of the performance you'd get from C# if it's using the same run-time framework. If they can get comparable performance in a FPS using the .NET run-time, it might be worth looking at for games development after all...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
share portability in common. I can write an app in C, and run it on my server, laptop, palmtop, ancient SunServer, or even a Windows machine. The same goes for Java and C++.
.NET. Mono is a good start, but not enough to make my code reliably portable.
.NET is to make the platform compatibility promised by NT 4 available without opening the source.
If I use C#, I'm effectively locked into
C# has all the speed of Java with all the portability of X86 assembly linked to Windows libraries. Microsoft's BS patents will help ensure that the portability problems aren't corrected.
The real purpose behind
You can't judge a book by the way it wears its hair.
Actually, in practice, no it's not and yes you can.
What you're ignoring is the "late optimisation" effect of virtual-machine and intermediate language execution models. The installer or run-time can take intermediate code and convert it to native code, just as a C compiler would, but with full knowledge of the environment in which that code is going to run. That allows for specific optimisations based on the execution environment that are rarely, if ever, practical for C-based programs. (How many C programs ship with different optimised executables for each Pentium and Athlon series processor, for example?)
You seem to be writing as someone who knows how things are supposed to work, who has a certain mindset and isn't prepared to look outside it. So-called just-in-time compilers actually have a lot of potential. They aren't, in general, as fast as something like C or C++ yet. However, in theory they could actually be faster once they've matured and caught up, because they can do all the same low-level optimisation tricks as a C or C++ compiler, with more knowledge of the target environment to get the best out of them.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I know the article is about C#, but every time I read something about C# I think to myself "I can do that in Python". Python is cross-platform, interpreted, object-oriented, fast, easy to extend with C or C++ and even more exciting for some people, usable transparently with Java as Jython.
I've found that almost all the programs I've written I could've written smaller and better and more obvious (and therefore easier to debug and maintain) with Python. None of those that I have rewritten show any noticeable performance penalty for having done so either.
Just wondering if you've dealt with it at all yet.
- Michael T. Babcock (Yes, I blog)
You mean all the way back 1994-95 era computing? sheesh. You work in a museum.
Translation: Today they are used to butcher a perfectly fine language and add new impediments to understanding.
Show me on the doll where his noodly appendage touched you.
But what if app A doesn't use but 1 function in library A? And, app B only uses 1 other function from library A?
This is why Linux pages things in on demand. It doesn't read the whole library and load it into physical memory. The library is conceptually mapped into your address space, when you try to access a function foo(), if foo() is in a page that isn't currently loaded in physical RAM, the OS gets a page fault, and that page will be loaded.
Just because you're linked against libc, that doesn't mean you're physically loading every string function into RAM when your program runs. The granularity you're talking about probably isn't worth the gain in extra complexity.
Try this:
Write a backend app in Java, and one with the same functionality in C or C++. Make sure they both read and write data to an Oracle database. Now, with stopwatch in hand, make them both run on Win2K, Cygwin, Solaris, and Linux.
Guess which language will allow you to finish first.
Correction: generics are unglorified macros. Templates are glorified macros. Templates can add type safety at compile time with no runtime penalty. Generics macro expand their type safety into java casts, which incur a decent runtime penalty (especially for large container intensive algorithms).
Additionally, I once saw someone (saurik from saurik.com) use templates to do dynamic programming at compile time. He wrote an exponentially increasing algorithm to have an exponentially increasing compile time but constant run time when an arbitrary limiting value n was increased. Not actually useful, but still really damn clever and it illustrates the versatility of templates for meta-programming. And more importantly, I am pretty sure the same program is illegal for generics.
I would suspect that brininging a "managed environment" to system level programming would be a good step.
C/C++ have served us all well. However, I suspect that something a bit more portable and simpler may be relevant, especially with the byzantine complexity of C++ behavior.
On the application end, I would suspect aspect-oriented programming is next on the horizon. More structures to ensure quality (pre/post conditions). More programming by definition and constraint with glue (built in quality control).
-------- -------- Support Wesley Clark for president!!!
I posted this already... go see how blitz++ works.
It doesn't make the language butchered in the least, quite the opposite, the end result is very clear to use and the confusing part is hidden inside the classes, where it cannot cause trouble.
the thing about C++ is, sometimes things are hard, but the reason you do them anyway is because they are worth it, and you can get high levels of abstraction (arbitrarilly high) without taking runtime hits. You have the ability to control your overhead, templates are a great example, especially the examples the parent poster mentions, expression templates, and high performance math libraries.
Blitz++ uses templates in an elegant, mind blowingly cool way. It might not be clear how it works to many, but that doesn't change how it works. Truly beautiful. And it makes the code easier to read, not harder.
-pyrrho
The multiple language angle is
;-)
.net environment.
1) to allow anyone accessibility with there skillset.
2) allow the integration and migration of legacy codebases.
3) Not piss of VB customers who are perfectly happy with their ugly piglatin language
Serious, there are large Fortran libraries out their. Microsft's approach allows easy integration.
A cobol implementation exists. Though, COBOL is almost always spagetti code riddled with non-modular entry points. But I suppose well written COBOL code can be migrated into a mixed
Ultimately, distilling it all into cross-platform IL is a thing of beauty. Managed code that can be accessed from any language and run on virtually any platform.
-------- -------- Support Wesley Clark for president!!!
Currently there are C#, C++, VB, and even Java
.NET framework correctly, there is no way to support either multiple inheritance or templates--in which case C++ cannot be accurately modeled in .NET. Nor will Java be .NETtable after 1.5, which will introduce pale imitations of templates (but imitation enough to give the CLR a hissyfit).
.NET CLR does not support multiple languages. It supports one language--C#. Its "multiple language support" comes from being able to compile down many functionally-identical languages with different syntaxes down to the same bytecodes.
.NET supports are those which are subsets of C#. And once you realize that, .NET becomes much less interesting.
.NET much in the last few months. Last I checked these things were true, but after being very unimpressed with .NET I haven't kept up with things.)
If I understand the
The
But truly different languages are not representable in the CLR. Show me how to do a Scheme continuation in the CLR, please, or export a C++ template, or a LISP macro.
The only languages
(Warning: haven't used
There is an open source alternative IDE for .NET called SharpDevelop, which you get at http://www.icsharpcode.net.
It is not as good as VS2003, but quite near :)
Intelligence shared is intelligence squared.
There's a D?
D Programming Language Reference
Beware: In C++, your friends can see your privates!
I've done significant work in benchmarking Java programs versus equivalent C/C++ programs. I've found that garbage collection is the sole reason that Java is slower than C++; having a "virtual machine" imposes no performance penalty whatsoever. This is unsurprising, when you think about it; a JIT compiler simply moves the latter phases of compilation ("byte code->assembly") to runtime.
Contary to what many people think, even most traditional C compilers work by compiling source to byte code, optimizing the byte code, then compiling byte code to assembly. There's no reason to expect that the resultant assembly will be any slower just because the final phase is done at run time by a JIT.
Programs compiled using IBM's Java compiler routinely outperform equivalent programs compiled using "gcc -02", if garbage collection is not used in the Java program being compiled.
Since registration is required to read the article, I have not read it. But given the title of the publication I was alert to the possibility of bias, and I think it's quite strongly present in the introduction. Java is the platform against which .Net will be measured for the forseable time and I think that the choice of benchmarks in Part 1 strongly favour .Net.
.Net libraries can't do better than the Java libraries then I'm appalled.
.Net
application invocation (time to load and execute)
It seems likely to me that the CLR will be be preloaded/vigorously cached by a Microsoft OS whereas the JVM is treated like any other application. Startup times will be skewed appropriately
algorithms and recursion (calculating Pi and Eratosthenes's sieve)
One of the small number of additional features of the CLR over the JVM is support for tail-end-recursive algorithms. This test will favour the CLR for the reason.
conversions (int to float, float to int, int to string, string to int)
A valid test but half useless. How much time is spent in an application casting from float to int or vice versa? Conversion between ints and strings is a valuable benchmark (XML based applications have to that often).
string comparison, string concatenation, string tokenization
Java has a weakness (actually it has had many) with its treatment of String handling. They are slow to manipulate and memory heavy. Further changes are being made in 1.5 (introduction of non-synchronized StringBuilder class). If the
From the outside, this article just looks like another opportunity has been taken to falsely bash Java with
Programmers of the world unite, you have nothing to lose but your strings.
First of all -- what's the deal with this whole "WARMUPS" thing? This is just the most explicit way possible of training the JIT mechanisms without measuring its overhead. That might be fine if you believe that the overhead asymptotically costs nothing, however, I don't know what evidence there is of this. The test should use other mechanisms other than this explicit mechanism to allow the language itself to demonstrate that the overhead is of low cost.
The way this test is set up, the JIT people could spend hours or days optimizing the code without it showing up in the tests. This is the wrong approach and will do nothing other than to encourage the JIT developers to cheat in a way such as this just to try to win these benchmarks.
Ok as to the specific tests:
1. FloatInteger conversion on x86 are notoriously slow and CPU micro-architecturally dependent. It also depends on your rounding standard -- the C standard dictates a rounding mode that forces the x86s into their slowest mode. However using the new "Prescott New Instructions", Intel has found a way around this issue that should eventually show up in the Intel C/C++ compiler.
This does not demonstrate anything about a language other than to ask the question of whether or not the overhead outside of the fi rises to the level of not overshadowing the slowness of the conversion itself.
(That said, obviously Intel's compiler knows something here that the other guys don't -- notice how it *RAPES* the competition.)
2. Integer to string conversion is just a question of the quality of the library implementation. A naive implement will just use divides in the inner loop, instead of one of the numerous "constant divide" tricks. Also, string to integer will use multiplies and still just be a limited to the quality of implementation as its most major factor determining performance.
3. The Pi calculation via iteration has two integer->floating point conversions and a divide in the inner loop. Again, this will make it limited to CPU speed, not language speed.
4. The Calculation of Pi via recursion is still dominated by the integer divide calculation. It will be CPU limited not language limited.
5. The Sieve of Erastothenes (sp?) is a fair test. However, if SLOTS is initialized to millions, and the comparable C implementation uses true bits, instead of integers, then I think the C implementation should beat the pants off of C#, Java, or anything else.
6. The string concatenation test, of course, is going to severely ding C for its pathetic string library implemenation (strcat, has an implicit strlen calculation in it, thus making it dramatically slower than it needs to be.) Using something like bstrlib would negate the advantage of C#, Java, or any other language.
7. The string comparison with switch is a fair test, and gives each language the opportunity to use whatever high level "insight" that the compiler is capable of delivering on. It should be noted that a sufficiently powerful C compiler should be capable of killing its competition on this test, however, I don't believe any C compiler currently in existence is capable of demonstrating this for this case. I.e., this *could* be a legitimate case to demonstrate that C# or Java's high level abstractions give it an advantage over where the state of the art is in C compilers today.
8. Of course the tokenization is another serious ding on the rather pathetic implementation of the C library. None of strtok, strspn, etc are up to the task of doing serious high performance string tokenization. If you use an alternative library (such as bstrlib or even just PCRE) you would find that C would be impossible to beat.
-----
Ok, while the results here are interesting, I don't think there were enough tests here to truly test the language, especially in more real world (and less laboratory-like) conditions. Please refer to The Great Win32 Computer Language Shootout for a more serious set of tests.
When are people going to learn that languages that target the Common Language Runtime (CLR, only part of the .NET Framework) compile to the same thing (Intermediate Language - IL)? C# is not being tested here. The C# compiler optionally optimized and compiles source code into IL which is later JIT'd and executed. Because of this, it's the CLR and the base class library (BCL) that are being tested.
This could just as easily been done with VB.NET (not that I condone anything resembling VB) or J#, although MC++ is a different monster because it can (but doesn't have to) use native code in mixed mode and, thus, is not verifiable).
The only differences besides language syntax is the specific language compiler and the optimizations it makes. The C# compiler does - as far as I've tested - a better job of optimizing. The VB.NET compiler, for instance, automatically adds an extra local var to support the syntax FunctionName = ReturnValue whether or not you use it!
So, let's get the facts straight. C# is not being tested here. The .NET CLR and BCL are.
First, I'll ask you to please see my comments in the other response to you...
.NET claims it will support all programming languages. It doesn't. It doesn't even come close. Once you realize .NET is just another VM that can be more easily targeted by compilers, you realize that "hey, this is ... really ... not all that interesting or useful," as I said in the post which kicked all this off.
.NET or am I talking about Java? In this case, Java. (I can't confirm the 60+ languages bit, but that's the number I see. Last I heard, Java supported more languages than .NET, but this gap was rapidly closing and the numbers are a couple of months old.)
.NET interesting? It was interesting the first time Sun did it with Java. (Or, for us dinosaurs, it was interesting the first time I saw UCSD Pascal do it with their VM.) It's not interesting this second time around.
.NET useful? If you're married to the Microsoft platform, then I guess it's useful. But really, where's the huge win for .NET over Java? There isn't one. It's an alternative to Java, not really something new and innovative, not something which allows you to solve more problems than Java or even allows you to solve them all that much differently.
Done.
In fact, even his "brilliant" graph algorithms may have been top-class during his time.
As far as I can see, remember, or am concerned, Dijkstra's contributions to computational graph theory are fundamental to the field. If you think they're brilliant-in-quotation-marks, all I can ask is what you've discovered that's comparable.
That's not meant as an insult or a challenge, incidentally. It's meant to say that in hindsight many things become obvious which required real genius to see them in the first place. Dijkstra's graph algorithms are simple and straightforward, and in hindsight they're obvious--but let's not forget that the only reason they're obvious to us is because Dijkstra had the insight to see, in foresight, what's obvious in hindsight.
If in your academic mind you truly believe this,
You keep on calling me that, an "academic". The reality is I'm nothing of the sort except in the sense that I'm a graduate student. I'm a hacker, not an ivory-tower academic. I believe in solving problems and sharing those solutions with the world.
It's axiomatic that if you're faced with a problem, one of the worst things you can do is stubbornly insist that it be solved with X technique. You have to show some flexibility. You have to be able to approach the problem from different angles. For GUIs, I've found object orientation is almost always best. For scientific programming, I've found template metaprogramming best. For using computers in math theory courses, I use LISP or ML. For writing system-level software, I use C++. Etcetera.
My insistence on multiple paradigms is unequivocally not born out of "academia", a word which it seems you're using as an insult. My insistence on multiple paradigms is born out of my demand that I use the right tool for the job.
Why is it not all that interesting or useful? Because we already have that with Java. We've got a virtual machine which provides managed services and is targeted by over 60 different languages, all of which can use all the facilities of the other languages once their code has been reduced down to bytecodes. We've got a VM which allows you to interface with the native hardware to get a massive speed boost.
Am I talking about
So where is
Where is
That said, is it useful for Company A, which prefers VB, and Company B, which uses Java, to be able to collaborate on software, each using their preferred language, with their results able to be executed on a shared VM?
Sure it is. That's not what I mean when I say ".NET is neither useful nor intere
if you have some kind of auto-email thing turned on let me know, because I'm a relative /. newbie and have no idea how to set that up if it exists...
:)
Check your User Page.
You'll see a dropdown box saying "Comment Reply". Select "Email", then save your changes and you're done.
That said, I hope you enjoyed that act of friendliness, because I see nothing but disagreements in the near future.
What I really wanted to point out was the fallacy of the "language worth learning" quote, in that it only uses "worth" in once sense of value, when in fact the majority of people in the world who deal with technology use a completely different set of criteria on which to place the "value" of learning a language - and this usually comes down to $ in the end.
I'm utterly unconvinced that the software industry has any sensible valuation of worth, particularly in the management field. Paul Graham has a great essay on why this is--what it boils down to is management's knowledge of the field and languages is primarily imparted by marketing glossies and marketing departments (either Sun's or Microsoft's, it appears). Hackers' knowledge of the field is primarily imparted by catastrophic disasters.
As an example of this, Java is being used in a lot of places today where it really shouldn't be. In 2000 during the height of the Java hype, a friend of mine who worked for a major United States bank was driven up the wall by a management decision to migrate all their COBOL apps to Java. "After all," Management said, "COBOL is a dead language and these are fifty-year-old legacy programs."
To a hacker, COBOL may well be a dead language, but a program that has a fifty-year record of reliability basically swaggers around the RAID array menacing newer programs with <DenisLeary>"yeah, I may be written in COBOL, but I haven't crashed in fifty fucking years, guy, okay?"</DenisLeary>
So was this major U.S. bank wise in their decision to migrate all their legacy COBOL apps to Java? By your logic, yes, because industry knows the value of software and can properly evaluate things in a dollars-and-cents manner. I'm certain there was a great business case made for this mass migration. I can't imagine what else could make a bank decide to undertake something that risky.
And after about 150 man-years of work--optimistically, about $15 million of development--the program was abruptly cancelled due to the fabled dollars and cents failing to materialize.
Wherever you look in the industry there are all sorts of examples like this. In the commercial software industry, I've seen far more projects fail than succeed. How does the industry respond to this? By declaring any software project that comes in at under 500% cost overrun and a year late to be a "qualified success".
The thing is, we all know this. We've all read The Mythical Man-Month. Most of us--I imagine you do, I know I do--have horror stories about death marches and the Project That Would Not Die And Yet Never Truly Lived, Either.
Given the spectacularly poor state of software management nowadays, I'm deeply skeptical of any claims that the software industry is in a position to make accurate estimations of value, whether that value be in a financial or a technical sense.
I'm a hacker. I don't know about how to value software in a financial sense. (I'm heartened by the fact that nobody else does, either.) On the other hand, I do know how to value software in a technical and artistic sense. My estimations will differ from the next hacker's, but in general we can make certain agreements--that COBOL is crufty but COBOL legacy apps that run for fifty years rock, that LISP is woefully underused, that people keep on using C when they really want to be using something else, etc.
if they had the same skillset level and also the same level of mathema