One of the things you do when teaching object-oriented programming (especially when you learned to program in the structured programming era) is spend time thinking about how programming paradigms come and go and how much of the impetus to change has been restricting what programmers can easily do so that they have less leeway to get into trouble (hopefully meaning fewer bugs). Then my colleague Daniel Lemire goes and questions the utility of debuggers, and I wonder if all of these linguistic and developmental tools merely serve to make software developers lazy. Why bother to really understand your code (for instance, trace it by hand) when you can scan through it while it runs? Who cares how inefficient language X is; machines are fast!
This is my pet peeve: software manufacturers are burning my machine cycles, which I paid for with my hard-earned money, to reduce their effort in producing quality code. If you don't believe it, go to The Computer Shootout Benchmarks and compare the trendiest, most "modern" languages' performance with C. The best you'll find is C++, which looks to be about 30% slower than C in general. C#/Mono? C is 2-70 times faster. Java? C is 2-66 times faster. And C is hundreds of times faster than Ruby et al.
What do I get for all these extra cycles? The only thing I can see that is of value to me is platform independence. Is it worth buying a machine twice as fast as I might otherwise need? Maybe. Four times as fast? I'm not so sure. Seventy times as fast? I'm sorry. Where are all those extra cycles going? To absolving companies from the need to discipline their development processes. In other words, I'm paying more money for a computer so companies don't need to pay as much attention to the fine details of product quality.
Disclaimer: The above doesn't apply to computation-intensive
applications, for which the more cycles the merrier. I don't play
video games, but I do write simulation code. But should you really
need a multi-gigahertz machine to write a letter? I wrote a 200-page
dissertation, with drawings, graphs, and all sorts of typeset math, on
a Mac SE (using LATEX).
Topics: programming
languages,
object-oriented programming, computer performance.
But you do pay for those cycles! Last time I checked, faster computers cost more than slower ones. And older computers, perfectly usable otherwise, can't run newer applications, even if those newer apps are merely "updated" versions of older ones (think Word). So, you must trade in those older computers for newer ones, which costs money.
ReplyDeleteOur 6+ year-old minivan runs fine (since we replaced the transmission a year ago) and does the job as well as when it was new. Can you say the same for a six-year-old computer with the latest versions of the OS or applications?
"slower than C in general"
ReplyDeleteOn the Computer Language Shootout website we go to great lengths to say these measurements are measurements of particular programs on particular machines with particular language implementations - these are particular truths not general truths.
Did you notice benchmarks where the java program was faster than the gcc program? See nbody or spectral-norm.
Did you notice benchmarks where some other jvm based program was faster than both the gcc program and the java program? See mandelbrot (looks like that Java program could be improved...)
Did you notice the tcl program that was so much faster than the gcc program? See regex-dna
Isaac, that's what I intended by "in general". There are specific benchmarks in which those other languages are faster, but, overall, across the broad range of tests, C is faster. I think this conforms to most people's subjective experiences. I'm not a C bigot; in fact, I do most of my programming in MATLAB, so I understand the productivity and performance gains for other languages, particularly for problems where there are built-in optimizations (which is certainly the case for MATLAB). But, then there's the "arbitrary code" (for MATLAB, it would be the stuff that is inherently sequential), where a language like C, in the hands of a programmer knowledgeable about performance issues, can shine.
ReplyDeleteIn fact, though I didn't go into this above, the biggest disparity (for Java) is startup time, I imagine because of the JVM initialization and JIT compilation that must happen. So, a language like Java is especially poorly suited to situations in which small programs are frequently started up and shut down, where users spend noticeable time waiting. Daniel Lemire pointed out to me that this is exactly what Java is used for frequently: little applets on web pages.
So, the right tools for the right job, benchmarking is an art, not a science, so please, no wagering.
"overall, across the broad range of tests, C is faster"
ReplyDeleteThere isn't an overall just a set of very different particular situations.
"most people's subjective experiences"
I don't believe you're in a position to speak for most people ;-)
"a language like Java is especially poorly suited"
Remember, we can only talk about the performance of a language implementation, not the performance of a language.
You're assumptions about Java startup time are invalidated as soon as we choose to use ahead-of-time compilation.
"exactly what Java is used for frequently: little applets on web pages"
Really? Check it out. (I think you'll find that Java is mostly used for long running server applications.)
"no wagering"
No idea what you mean by that.
Back to January 06 compare the trendiest, most "modern" languages' performance with C
C++ Java and C# are rather old mainstream languages. Trendy and modern might include Haskell, D, Scala.
Isaac Gouy said...
ReplyDeleteThere isn't an overall just a set of very different particular situations.
By "overall", I meant over all of the benchmarks cited. There's no such thing as a "final word" benchmark; it all depends on what you're interested in. In fact, that was the motivation behind my later statement about Java applets.
Remember, we can only talk about the performance of a language implementation, not the performance of a language...
Of course; I assumed it was clear that I was talking about implementations and not fundamental language differences. However, if we assume that managed memory (i.e., garbage collection) and byte code (cross-platform "binaries" running on a virtual machine, perhaps compiled at load time) are integral features of certain languages, then I believe my statements are more general. In particular, compiling Java directly into machine code is not what most people think of when they think of a "Java program".
(I think you'll find that Java is mostly used for long running server applications.)
I didn't say Java was mostly used for applets, just frequently used that way. Certainly, it's the way that most impinges on a user's experiences, since users don't care how servers are implemented -- server programs don't run on my computer.
"no wagering"
No idea what you mean by that.
Old-timer "Late Night with David Letterman" reference.
C++ Java and C# are rather old mainstream languages. Trendy and modern might include Haskell, D, Scala.
Depends on your point of view; anything after PL/I seems new to me. :^)
What a relief, finally we can agree a little ;-)
ReplyDelete"I assumed it was clear..."
Others assume differently so it's never clear.
'what most people think of when they think of a "Java program"'
There you go again! You know that isn't necessarily the case, I know that isn't necessarily the case, and neither of us have any evidence for what "most people think".
"applets, just frequently used that way"
Do you have evidence for how many websites use applets?
(Seems most I visit work fine with Java blocked, they use JavaScript & CSS)
Isaac Gouy said...
ReplyDeleteWhat a relief, finally we can agree a little ;-)
I think we agree a lot, and you're just being perverse here. :^)
Others assume differently so it's never clear.
Here is the quote from the original post: "There are specific benchmarks in which those other languages are faster, but, overall, across the broad range of tests, C is faster." The context was a discussion of the computer shootout benchmarks; I don't think that it is reasonable to interpret "the broad range of tests" as being anything other than the tests presented on that web site. Additionally, my point was that languages like Java are burning my CPU cycles in benefit of software developers, not me. Unless you're going to insist that memory management isn't an integral feature of languages like Java, or that most client-side Java usage doesn't use the JVM, I'll stand by that statement.
There you go again! You know that isn't necessarily the case...
Isaac, do you really think that many people think of Java as a language compiled into machine code, like C or C++? The three major "selling points" of Java are: 1. memory management, 2. a large set of classes "built in", and 3. machine-independent binaries via a virtual machine. Do you seriously want to assert that most client-side usages of Java are via direct compilation to machine code?
Do you have evidence for how many websites use applets?
No, nor did I assert that. I asserted that most users' experiences with Java are via applets. This is not the result of any rigorous study, true, but I think it's about as reasonable as saying that most users don't have the foggiest idea what Java is.
"just being perverse" "really think that many people think of Java as..."
ReplyDeleteMichael, I don't think many people think of Java, period.
You may be thinking of a particular group of people (people who've downloaded and installed a JVM because a website asked them to, or some other group of people) but you don't say so - so how would I know.
It isn't perverse to say that these are your personal assumptions, and other people will have their own assumptions.
'The three major "selling points" of Java are...'
Why do you think "ahead of time compilation" changes 1 & 2?
We have memory management for C/C++, and we have large libraries for C/C++ - so why would "ahead of time compilation" break those Java "selling points"?
"most client-side usages of Java"
I have no information on that subject, and no embarrassment in saying that I don't know.
"languages like Java are burning my CPU cycles in benefit of software developers, not me"
Does using the software benefit you?
Why do you think "ahead of time compilation" changes 1 & 2?
ReplyDeleteIt doesn't, nor did I say that it did. However, the JVM is really the only user-centered reason justifying why I might want to spend cycles running a Java program. The other reasons are developer-centered, i.e., them spending my cycles (which I bought) to reduce their development effort.
We have memory management for C/C++, and we have large libraries for C/C++ - so why would "ahead of time compilation" break those Java "selling points"?
Again, I didn't say that it would; I merely said that the JVM is the only Java advantage for the user. And standard C/C++ are not managed languages, nor do the standards include large function/class libraries (you can't compare the STL to the much larger breadth and completeness of the Java class libraries). As a user, I couldn't care less about these features. As a developer, I still use C (and, less often, C++) because I write numeric code and even a 50% difference in speed is important to me (and, frankly, you don't need O-O programming to integrate sets of ordinary differential equations). I've learned well to free my dynamically allocated memory, so a managed language doesn't do much for me (nor should it for any fully competent developer, IMHO). I can see the attraction of the Java class libraries for a number of applications: they're very rich.
"languages like Java are burning my CPU cycles in benefit of software developers, not me"
Does using the software benefit you?
It would benefit me even more if it used fewer cycles, thus not requiring the purchase of a faster machine. This is exactly (and pretty much entirely) the point of my post: software manufacturers are using my cycles to reduce their development costs and to reduce their need for well-educated programmers (which reduces their development costs even further).
"software manufacturers are using my cycles to reduce their development costs"
ReplyDeleteAre you willing to pay more for identical functionality, if the software uses less CPU cycles?
How much more? 2x?
I would pay at least as much as those extra cycles cost me (i.e., the extra expense of buying a new, faster machine earlier than I might have needed). I say, "at least as much" in consideration of the value of the time it takes to shop around for a new machine and do all the initial setup.
ReplyDelete