The Daily WTF: Curious Perversions in Information Technology

kipthegreat · 2005-11-02 Reply Admin

Anonymous:

Whats especially fun, the log with logging turned off would look like:

The current log level is not debug. The message will not be logged.
The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.

Have you never used software with logging? With logging turned off, there will be no log. Otherwise they would have just used System.out.println() instead of a logging framework.

OpBaI · 2005-11-02 Reply Admin

That's just another thing anonymous subroutines are good for:

Perl, for example:

sub Log(&) {
  return if not $logging_enabled;
  my ($sub) = @_;
  my $logline = $sub->();
  print STDERR "$logline\n";
}
Log {
  sleep 3;
  "This will only get executed if logging is enabled!";
};

Python can do about the same (untested):

def log(func):
  if logging_enabled:
    sys.stderr.write(func())
log(lambda: "This takes very long: %s" % (self.getXML(), ) )

Or Ruby:

def log(this_log_level, &func)
  if log_level > this_log_level
    $stderr.write(func[])
  end
end
log LOG_INFO {
  expensive()
  "hello world"
}
log LOG_ERROR do
  expensive2()
  "fsck, the file is broken now"
end

2005-11-02 Reply Admin

The WTF to me has been the attitudes and prejudices regarding performance. Qoute benchmarks, but if you really think worrying about perfromance starightaway rules out Java, you've not done enough lately to deserve staying in the software industry.

Anonymoose · 2005-11-02 Reply Admin

This reminds me of a project I was given, to figure out where it was taking so long.

One of the problems was in fact, a debug statement inside a loop, something innocuous like:

log("message" + object);

The problem was the object had a horribly long operation to convert itself into a string, and inside a tight loop, too!

2005-11-02 Reply Admin

frosty:
RevMike:
If anyone deploys a substantial java application without spending some time to choose the correct JVM parameters, they are the idiots, not the language.

I have a hunch I'm going to catch hell for this, but I'll ask it anyway. I did mainly C/C++ (no Java) in college, but picked up Java at my first job out and now work for another company doing Java (so there are a lot of java specific things I haven't picked up yet).

This bit on JVM parameters, what all can you change and such? It's something you do in the JVM itself, right (not in the program)?

The whole whack of HotSpot VM options for tuning are available at http://java.sun.com/docs/hotspot/VMOptions.html and they can all be specified on the command line when starting the VM.

kipthegreat · 2005-11-02 Reply Admin

Alex Papadimoulis:
Josh is the code reviewer on a fairly-large, Java-based message routing system. At one of his reviews, a coworker submitted some code that logged events like this:
logDebug("Account Number is '" + accNum + "', Transaction ID is '" + tranId + ""');
It's fairly standard Java code, but "wastes" a handful of clock cycles to concatenate strings that won't be logged in production. Since perforce is critical in the application, Josh requested that she check if debug logging is enabled first before logging the message. She agreed, and returned the next day with each and every logDebug() statement with the following pattern ...
if (isDebugEnabled())
{
  logDebug("Account Number is '" + accNum + "', Transaction ID is '" + tranId + ""');
} else {
  logInfo("The current log level is not debug. The message will not be logged.");
}

Why does everyone think this is a premature optimization?? We're just talking about good coding practice. Sure, building a string doesn't use that many clock cycles, but if he can convince his programmers to always do an if(DebugIsEnabled()) as a coding practice, there's no downside to that. Put a trace statement in a for-loop and we're talking a pretty big performance boost.

Where I work, these things are usually inlined something similar to this-

if (trace.isEnabled()) trace.println( ... );

And then for our C++ code the trace function is a macro that always checks if the trace is enabled first, so we don't have to worry about it....

RevMike · 2005-11-02 Reply Admin

Anonymous:
frosty:
RevMike:
If anyone deploys a substantial java application without spending some time to choose the correct JVM parameters, they are the idiots, not the language.

I have a hunch I'm going to catch hell for this, but I'll ask it anyway. I did mainly C/C++ (no Java) in college, but picked up Java at my first job out and now work for another company doing Java (so there are a lot of java specific things I haven't picked up yet).

This bit on JVM parameters, what all can you change and such? It's something you do in the JVM itself, right (not in the program)?

The whole whack of HotSpot VM options for tuning are available at http://java.sun.com/docs/hotspot/VMOptions.html and they can all be specified on the command line when starting the VM.

Here is some more info that I've found very useful: http://java.sun.com/docs/hotspot/gc1.4.2/ and http://www.petefreitag.com/articles/gctuning/

procyon112 · 2005-11-02 Reply Admin

While premature optimization is the root of all evil, it's premature pessimization that leads to flamewars about it :) Adding thousands of text maniipulations to every level of algorithm no matter how nested and throwing the results away is premature pessimization. The solution (check for trace flag) is obvious, but yea, it warts the code. That's the pain felt from java leaving us no mechanism for late binding of parameters, which can sometimes be done with the C++ preprocessor, but not always. IIRC it's impossible to implement operators &&, ||, and ?: correctly in C++ also because of this same issue.

I can think of a few ways to limit the warting, but they aren't obvious to future coders, eg..

isDebug() && debugLog("log message here");

2005-11-02 Reply Admin

Come on now! Any true programmer knows that if you want to keep your servers running fast you need to push everything over to the client side. Drop C/C++ and Java and try using JavaScript or VBScript. You'll be amazed at the reduced load on your core processors.

\Format this!

hoens · 2005-11-02 Reply Admin

The one thing that needs to be talked about in the Java vs C++ discussion when you are talking about the garbage collector, is the delete operator in C++. To delete objects in java it costs (from what I've heard) about 0 system calls since the JVM handles the memory, whereas deleting in C++ takes significantly more since you're married to the hardware. I haven't done any research into that area because premature optimization isn't really something that I care about, but I thought it was interesting, and if anyone else has any information on it that would be quasi interesting to read about.

antareus · 2005-11-02 Reply Admin

Java may have adequete performance, but anytime I use a Java desktop app I groan to myself. The UI insists on looking different and acting funny (not all access keys are implemented, whereas with native controls you get them for free) for no reason. Then there's the GC being lazy about releasing chunks of memory, to the point where people tell me I shouldn't leave Eclipse open after I go home from work because it takes longer to un-minimize the sucker than to simply launch it again the next day.

Mung Kee · 2005-11-02 Reply Admin

antareus:
Java may have adequete performance, but anytime I use a Java desktop app I groan to myself. The UI insists on looking different and acting funny (not all access keys are implemented, whereas with native controls you get them for free) for no reason. Then there's the GC being lazy about releasing chunks of memory, to the point where people tell me I shouldn't leave Eclipse open after I go home from work because it takes longer to un-minimize the sucker than to simply launch it again the next day.

Thought your comments on lazy GC are valid, Eclipse is written using SWT, not Swing.

Alexis de Torquemada · 2005-11-02 Reply Admin

Mung Kee:
cupofT:
If performance is critical why are they using java?[:S]

Until you can show me an extensive benchmark that isn't slanted, you can go f--- yourself with this comment.

I'm not sure what kind of benchmark you would accept, but I can show you a hundred thousand Java applets that suck in terms of performance and/or kill the browser.

Mung Kee · 2005-11-02 Reply Admin

Mung Kee:
antareus:
Java may have adequete performance, but anytime I use a Java desktop app I groan to myself. The UI insists on looking different and acting funny (not all access keys are implemented, whereas with native controls you get them for free) for no reason. Then there's the GC being lazy about releasing chunks of memory, to the point where people tell me I shouldn't leave Eclipse open after I go home from work because it takes longer to un-minimize the sucker than to simply launch it again the next day.

Though your comments on lazy GC are valid, Eclipse is written using SWT, not Swing.

Mung Kee · 2005-11-02 Reply Admin

Alexis de Torquemada:
Mung Kee:
cupofT:
If performance is critical why are they using java?[:S]

Until you can show me an extensive benchmark that isn't slanted, you can go f--- yourself with this comment.

I'm not sure what kind of benchmark you would accept, but I can show you a hundred thousand Java applets that suck in terms of performance and/or kill the browser.

Who the hell uses applets? :)

Alexis de Torquemada · 2005-11-02 Reply Admin

Anonymous:

You do realize of course that there are numerous benchmarks these days that are showing Java as FASTER than C/C++, right?

You do realize that they are either extremely narrow in scope or written by people who are absolutely clueless about C++ and who have a grudge to settle?

OneFactor · 2005-11-02 Reply Admin

procyon112:
While premature optimization is the root of all evil, it's premature pessimization that leads to flamewars about it :) Adding thousands of text maniipulations to every level of algorithm no matter how nested and throwing the results away is premature pessimization. The solution (check for trace flag) is obvious, but yea, it warts the code. That's the pain felt from java leaving us no mechanism for late binding of parameters, which can sometimes be done with the C++ preprocessor, but not always. IIRC it's impossible to implement operators &&, ||, and ?: correctly in C++ also because of this same issue.

I can think of a few ways to limit the warting, but they aren't obvious to future coders, eg..

isDebug() && debugLog("log message here");

Cute. I suppose you could also create a DebugMessage class and have the expensive stuff in the toString method (anonyouse inner class?) and pass the DebugMessage to the logging framework. Then the if check could be done before calling toString(). Though that brings in other warts though.

One technique that seems to work well is to put the most of the logging in the catch block of an exception. If you find this a problem because it gets called too much or not enough, then you often have a design problem with the code itself.

masklinn · 2005-11-02 Reply Admin

frosty:
Anonymous:

You do realize of course that there are numerous benchmarks these days that are showing Java as FASTER than C/C++, right?

I'm genuinly intrigued. With all that C/C++ has going for it, how could Java pull off being faster (I assume you mean after the jvm starts up, or is that included)?

After it starts up. Garbage collection is actually quite efficient, and if you add that to a JIT compiler (which the latest Sun JVM are) on a statically typed language (allows more easy optimisations than dynamically typed) and code that compiles well to native, you have performances that can reach at or beyond compiled C++ code level (usually not C level though, and there are languages that are faster than C, SML+the MLTon compiler often is for example).

The memory consumption, on the other hand, is a whole 'nother problem ;)

Mung Kee · 2005-11-02 Reply Admin

Alexis de Torquemada:
Mung Kee:
cupofT:
If performance is critical why are they using java?[:S]

Until you can show me an extensive benchmark that isn't slanted, you can go f--- yourself with this comment.

I'm not sure what kind of benchmark you would accept, but I can show you a hundred thousand Java applets that suck in terms of performance and/or kill the browser.

I'm not sure if there is a benchmark I would accept, since everyone that invests the time and $ into the research has some vested interest in the results.

I have said many times on this board that Swing/AWT sucks in terms of performance. I don't use them and have seen only 3 applets offered as a product/service in my 8+ year career.

Terrible performance of applets is always the case people make against Java but I assure you, not many companies on this side of the industry use them for any significant product or service offering.

Since this is a non-issue, care to complain about anything in Java with which you are knowledgable?

Alexis de Torquemada · 2005-11-02 Reply Admin

RevMike:
First, modern JVMs actively profile the code while it is running. Once the JVM decides what sections of code are important, they get compiled and run as native code rather than intrepreted. That gets us pretty close to C/C++ performance on a long running application like a server process.

Could you please refer me to the paragraph in the C++ standard that says that C++ is statically compiled to native code?

RevMike · 2005-11-02 Reply Admin

antareus:
Java may have adequete performance, but anytime I use a Java desktop app I groan to myself. The UI insists on looking different and acting funny (not all access keys are implemented, whereas with native controls you get them for free) for no reason. Then there's the GC being lazy about releasing chunks of memory, to the point where people tell me I shouldn't leave Eclipse open after I go home from work because it takes longer to un-minimize the sucker than to simply launch it again the next day.

I'm not a fan of Eclipse myself. And I have to admit that most Java GUIs aren't too hot. I develop middleware applications, so it isn't an issue for me. I ought to download Eclipse some day and see if I can tune the JVM to make the GUI perform respectably.

Anyway, real men don't use fancy schmancy IDEs. Real men use vim to code and to write their ant scripts, then run the whole thing from the command line.

Alexis de Torquemada · 2005-11-02 Reply Admin

Anonymous:
In my experience, Java code is only faster when there are a large number of iterations through a method. Unlike the C compiler, the Java runtime environment can create optimized native code based on the frequency with which code paths are being followed.

If dynamically compiled code is faster in this regard, it's typically because the statically compiling guys don't know what to do with a profiler.

frosty · 2005-11-02 Reply Admin

Alexis de Torquemada:

You do realize that they are either extremely narrow in scope or written by people who are absolutely clueless about C++ and who have a grudge to settle?

I pondered the same question.... Generally when I think of a high performance, hardware taxing application (not for servers) I think of 3D games. Maybe it has to do with the libraries available, but I don't hear much about the next hot first-person-shooter being developed in Java.

RevMike · 2005-11-02 Reply Admin

Alexis de Torquemada:
RevMike:
First, modern JVMs actively profile the code while it is running. Once the JVM decides what sections of code are important, they get compiled and run as native code rather than intrepreted. That gets us pretty close to C/C++ performance on a long running application like a server process.

Could you please refer me to the paragraph in the C++ standard that says that C++ is statically compiled to native code?

Could you please refer me to a C++ implementation in common use which is not?

Mung Kee · 2005-11-02 Reply Admin

Alexis de Torquemada:
Anonymous:

You do realize of course that there are numerous benchmarks these days that are showing Java as FASTER than C/C++, right?

You do realize that they are either extremely narrow in scope or written by people who are absolutely clueless about C++ and who have a grudge to settle?

Hmmm, Alexis, I never would have taken you for a conspiracy theorist. See my earlier post....I have yet to see a benchmark that wasn't slanted one way or the other. What's worse is the morons here, most of which likely have never read one, passing judgement regardless of whether they know anything about the "other language".

2005-11-02 Reply Admin

RevMike:

Anyway, real men don't use fancy schmancy IDEs. Real men use vim to code and to write their ant scripts, then run the whole thing from the command line.

Yeah I agree...I prefer to waste time doing all the things in VIM that an IDE can do for me. Like refactoring, automatic compilation as I type, automatic package importing...etc.

OneFactor · 2005-11-02 Reply Admin

OpBaI:

That's just another thing anonymous subroutines are good for:

Perl, for example:

sub Log(&) {
  return if not $logging_enabled;
  my ($sub) = @_;
  my $logline = $sub->();
  print STDERR "$logline\n";
}
Log {
  sleep 3;
  "This will only get executed if logging is enabled!";
};

Python can do about the same (untested):

def log(func):
  if logging_enabled:
    sys.stderr.write(func())
log(lambda: "This takes very long: %s" % (self.getXML(), ) )

Or Ruby:

def log(this_log_level, &func)
if log_level > this_log_level
$stderr.write(func[])
end
end
log LOG_INFO {
expensive()
"hello world"
}
log LOG_ERROR do
expensive2()
"fsck, the file is broken now"
end

Isn't that syntactic sugar for:

log(LogLevel.INFO, new Object() { public String toString() { return expensiveStringMakingCall();}

That being said, syntactic sugar is sometimes a good thing and this may be one of those times.

Alexis de Torquemada · 2005-11-02 Reply Admin

hoens:
The one thing that needs to be talked about in the Java vs C++ discussion when you are talking about the garbage collector, is the delete operator in C++. To delete objects in java it costs (from what I've heard) about 0 system calls since the JVM handles the memory, whereas deleting in C++ takes significantly more since you're married to the hardware. I haven't done any research into that area because premature optimization isn't really something that I care about, but I thought it was interesting, and if anyone else has any information on it that would be quasi interesting to read about.

Neither C++ nor Java issues a syscall for every deallocation. A thoroughly brain-dead implementation of either might, but I'm not aware of any.

2005-11-02 Reply Admin

<sarcasm>
You are all missing the point. The real WTF is that they are using a high level language at all. Everyone knows if an application is coded in assembly it will positively scream.
</sarcasm>

Alexis de Torquemada · 2005-11-02 Reply Admin

Mung Kee:

Since this is a non-issue, care to complain about anything in Java with which you are knowledgable?

Care to explain why application start-up times aren't relevant for performance? As a command-line freak I beg to differ.

PS: Ad hominems won't buy you much in this discussion.

2005-11-02 Reply Admin

RevMike:

I'm not a fan of Eclipse myself. And I have to admit that most Java GUIs aren't too hot. I develop middleware applications, so it isn't an issue for me. I ought to download Eclipse some day and see if I can tune the JVM to make the GUI perform respectably.

Let me put it like this - my work computer isn't the fastest one in the world, but besides taking it's time to start up, the GUI works perfectly, and as far as I'm concerned works even better than that Visual Studio .Net crap that I'm forced to use from time to time.

But that's just me...

JohnO · 2005-11-02 Reply Admin

Alexis de Torquemada:
Mung Kee:

Since this is a non-issue, care to complain about anything in Java with which you are knowledgable?

Care to explain why application start-up times aren't relevant for performance? As a command-line freak I beg to differ.

PS: Ad hominems won't buy you much in this discussion.

With the proper VM, you will have incredibly fast startup times, godly memory management, rock-solid stability, lightning fast performance rivaling the best hand-tuned ASM code. You just need to find the right VM.[:D]

RevMike · 2005-11-02 Reply Admin

Alexis de Torquemada:
Anonymous:
In my experience, Java code is only faster when there are a large number of iterations through a method. Unlike the C compiler, the Java runtime environment can create optimized native code based on the frequency with which code paths are being followed.

If dynamically compiled code is faster in this regard, it's typically because the statically compiling guys don't know what to do with a profiler.

There is more to it than that. The optimizations might be different for a Pentium, a Power, or a Sparc chip. Furthermore the optimizations may be different for, say, a Pentium 4, a Xeon, an Opteron, and an AthlonXP. And the optimizations can even be tweaked for each model in each family. The dynamically compiled code can take advantage of this. The guys with profilers typically won't tweak for every conceivable chip model. The dynamically compiled code can.

This is the same argument that was fought 15 years ago when optimizing compilers started coming out. A wizard could always write something a little faster than the compiler, but at what cost? There aren't that many wizards around and when you have one you usually want him working on something more that squeezing a few percent of performance out of something. Optimizing compilers allowed good competent programmers to write code that executed very nearly as well as a wizard's.

A real wizard using C or C++ will pretty much always be able to write something better than Java. But why, and at what cost? Realisticly, for a wide class of applications (typically long running server apps), a good competent team using Java will be able to develop better applications than a similarly talented team using C++. If performance is the final word then we'd all be writing assembly. We're not because programmer productivity and time to market is important too.

JohnO · 2005-11-02 Reply Admin

Anonymous:
Let me put it like this - my work computer isn't the fastest one in the world, but besides taking it's time to start up, the GUI works perfectly, and as far as I'm concerned works even better than that Visual Studio .Net crap that I'm forced to use from time to time.

But that's just me...

Eclipse isn't bad but VS .NET isn't bad either. You Java fan boys have to remember that some of us started using Java IDEs for serious projects way before Eclipse was around and it left a real bad taste in our mouths.

Mung Kee · 2005-11-02 Reply Admin

Alexis de Torquemada:

Care to explain why application start-up times aren't relevant for performance?

I didn't say it wasn't relevant. My problem with Java is that you're forced to take Swing, even if you don't use it. Slow classloading and start-up time is the result. They continue to add more sub-par apis (e.g. logging) to the core language and it becomes bloated. I'm a huge proponent of modularizing the language, as it used to be, so I can pick and choose what is loaded at start-up time.

Alexis de Torquemada:

As a command-line freak I beg to differ.

That's your problem, not Java's. If you're a Java developer, chances are you're not a command line freak, since most shops make use of widely available development tools.

Alexis de Torquemada:

PS: Ad hominems won't buy you much in this discussion.

It wasn't an ad hominem, and I gather that your argument is ad hominem for the language of your choice (C++?). Your initial argument about Java (applets) happens to be a seldom used feature/defect. If you have any legitimate issues with Java, let's hear them.

Alexis de Torquemada · 2005-11-02 Reply Admin

Mung Kee:
Hmmm, Alexis, I never would have taken you for a conspiracy theorist. See my earlier post....I have yet to see a benchmark that wasn't slanted one way or the other. What's worse is the morons here, most of which likely have never read one, passing judgement regardless of whether they know anything about the "other language".

I've read and performed some benchmarks comparing various C++ and Java implementations, and in most of them, C++ was slightly to dramatically faster (though D won some ahead of both others) even when taking JVM startup time into account. The others were typically biased against C++ by means of utter cluelessness (e.g. strdup'ing a string only to discard the result), whether malicious or not.

There are numerous theoretical reasons why C++ cannot be slower than Java in certain respects, not the least of which being that everything the JVM does can be done in C++ as well. Java implementations have become surprisingly fast given that at one time they executed many programs dozens of times slower than equivalent C++ programs, but Java still is almost never faster than a good C++ program run through a state of the art compiler, as some people like to claim (on this board and elsewhere). It's simply a myth. There are many good reasons to use Java for long-running applications, and even some short-running applications if you're smart enough to use GCJ for that purpose instead of that JVM bloatware. But, sorry, "because it's faster than C++" just isn't among.

BTW, I've used both languages extensively, in numerous implementations, so it must be someone else you are talking about in the last sentence.

2005-11-02 Reply Admin

christoofar:
Because Java programmers grow on trees and getting updates out the door would be faster than doing it in C/C++ and having to look for memory leaks.

We're using C++ with garbage collection, thank you. C++ certainly is not my first choice for a language, but with suitable libraries it can be fairly nice (nice, not safe).

Selecting software developers by the languages they know is like selecting mechanics by asking whether they use a 1/8" wrench or 3/8" wrench. One should choose the tools (i.e. the language) according to the problem.

Mung Kee · 2005-11-02 Reply Admin

Alexis de Torquemada:
Mung Kee:
Hmmm, Alexis, I never would have taken you for a conspiracy theorist. See my earlier post....I have yet to see a benchmark that wasn't slanted one way or the other. What's worse is the morons here, most of which likely have never read one, passing judgement regardless of whether they know anything about the "other language".

I've read and performed some benchmarks comparing various C++ and Java implementations, and in most of them, C++ was slightly to dramatically faster (though D won some ahead of both others) even when taking JVM startup time into account. The others were typically biased against C++ by means of utter cluelessness (e.g. strdup'ing a string only to discard the result), whether malicious or not. There are numerous theoretical reasons why C++ cannot be slower than Java in certain respects, not the least of which being that everything the JVM does can be done in C++ as well. Java implementations have become surprisingly fast given that at one time they executed many programs dozens of times slower than equivalent C++ programs, but Java still is almost never faster than a good C++ program run through a state of the art compiler, as some people like to claim (on this board and elsewhere). It's simply a myth. There are many good reasons to use Java for long-running applications, and even some short-running applications if you're smart enough to use GCJ for that purpose instead of that JVM bloatware. But, sorry, "because it's faster than C++" just isn't among. BTW, I've used both languages extensively, in numerous implementations, so it must be someone else you are talking about in the last sentence.

For the record, I wasn't grouping you with the morons. It was a general statement.

2005-11-02 Reply Admin

Anonymous:
My pet peeve is premature optimization. The biggest example of this is people barking about never using "abc" + "foo" + "bar" in Java. Sure its possible this is a big deal in your application, but come on. Unless this executed over 100k times per second, it probably not even close to being one of the critical performance issues.

Amen. If I told one of my developers not to concatenate strings because she's wasting clock cycles, I'd expect a knife in my belly. I'd rather work help desk than tap code for someone like Josh...

Mung Kee · 2005-11-02 Reply Admin

Anonymous:

Selecting software developers by the languages they know is like selecting mechanics by asking whether they use a 1/8" wrench or 3/8" wrench. One should choose the tools (i.e. the language) according to the problem.

That's not true at all. If you know how to use a specific type of wrench, you can learn how to use a different type within a split second. The same is not true for programming languages. You cannot make an immediate and/or sognificant contribution to a Perl application if you're expert only in C++. I'd venture a guess that you were denied a job at some point because you didn't know a specific language........but you know other languages and you're a "quick learner."

Alexis de Torquemada · 2005-11-02 Reply Admin

RevMike:

There is more to it than that. The optimizations might be different for a Pentium, a Power, or a Sparc chip. Furthermore the optimizations may be different for, say, a Pentium 4, a Xeon, an Opteron, and an AthlonXP. And the optimizations can even be tweaked for each model in each family. The dynamically compiled code can take advantage of this. The guys with profilers typically won't tweak for every conceivable chip model. The dynamically compiled code can.

Ok, they typically won't (most C++ programmers probably don't even use a profiler regularily). But they could. You can make an installation disc with different binaries depending on the processor model. Virtually nobody does, but it can be done. I was more interested in pointing out that the theoretical advantage of dynamic compilation over static compilation with profiling information is smaller than some assert. The practical advantage is much larger because almost no one wants to jump through these hoops just to get the last few percents of performance out of his/her statically compiled app. Gentoo users notwithstanding.

I strongly suspect that, if application start-up times are taken into account, dynamic compilation that occurs every time the program is run is inferior to properly performed static compilation with realistic profiling information, or dynamic compilation that includes a caching scheme. I don't quite buy the argument that dynamical compilation is by necessity superior since it can handle differences in execution behavior that occur per application run. This is because

a) Most often the execution behavior doesn't change a lot

and

b) If it does, it also changes per execution of a given function, which is too fine-grained even for dynamic compilers.

RevMike:

A real wizard using C or C++ will pretty much always be able to write something better than Java. But why, and at what cost? Realisticly, for a wide class of applications (typically long running server apps), a good competent team using Java will be able to develop better applications than a similarly talented team using C++. If performance is the final word then we'd all be writing assembly. We're not because programmer productivity and time to market is important too.

I agree 100%. A lot of relatively simple code takes too long to write in C++, mostly because of the source code model which is still based on translation units, and too long to debug because C++ not only offers many more ways to solve a problem, but also many more ways to shoot yourself in the foot.

makomk · 2005-11-02 Reply Admin

kipthegreat:

Have you never used software with logging? With logging turned off, there will be no log. Otherwise they would have just used System.out.println() instead of a logging framework.

Have you never used a program with log levels? The debug message is printed at level "debug", and the "debugging is disabled" message is printed at level "info". IIRC, "debug" is normally the more verbose of the two, so presumably if the maximum log level is set to "info" you'd get a load of messages saying that no message has been printed in the log...

WTFer · 2005-11-02 Reply Admin

RevMike:

Anyway, real men don't use fancy schmancy IDEs. Real men use vim to code and to write their ant scripts, then run the whole thing from the command line.

Real Men collect their own garbage. :) Anyway, real men code in binary.

2005-11-02 Reply Admin

WTFer:
RevMike:

Anyway, real men don't use fancy schmancy IDEs. Real men use vim to code and to write their ant scripts, then run the whole thing from the command line.

Real Men collect their own garbage. :) Anyway, real men code in binary.

Even more to the point: Real Men do:
copy con program.zip

'nuff said!

Richard Nixon · 2005-11-02 Reply Admin

Mung Kee:
Alexis de Torquemada:
Mung Kee:
Hmmm, Alexis, I never would have taken you for a conspiracy theorist. See my earlier post....I have yet to see a benchmark that wasn't slanted one way or the other. What's worse is the morons here, most of which likely have never read one, passing judgement regardless of whether they know anything about the "other language".

I've read and performed some benchmarks comparing various C++ and Java implementations, and in most of them, C++ was slightly to dramatically faster (though D won some ahead of both others) even when taking JVM startup time into account. The others were typically biased against C++ by means of utter cluelessness (e.g. strdup'ing a string only to discard the result), whether malicious or not. There are numerous theoretical reasons why C++ cannot be slower than Java in certain respects, not the least of which being that everything the JVM does can be done in C++ as well. Java implementations have become surprisingly fast given that at one time they executed many programs dozens of times slower than equivalent C++ programs, but Java still is almost never faster than a good C++ program run through a state of the art compiler, as some people like to claim (on this board and elsewhere). It's simply a myth. There are many good reasons to use Java for long-running applications, and even some short-running applications if you're smart enough to use GCJ for that purpose instead of that JVM bloatware. But, sorry, "because it's faster than C++" just isn't among. BTW, I've used both languages extensively, in numerous implementations, so it must be someone else you are talking about in the last sentence.

For the record, I wasn't grouping you with the morons. It was a general statement.

You're goddamned right you weren't. Otherwise he will bust your face in! He knows karater after all.

Sincerely,

Richard Nixon

zip · 2005-11-02 Reply Admin

Mung Kee:
I'd venture a guess that you were denied a job at some point because you didn't know a specific language........but you know other languages and you're a "quick learner."

Nice reach, asshole.

2005-11-02 Reply Admin

Anonymous:

copy con program.zip

Haha, that's f*ckin funny!

dpm · 2005-11-02 Reply Admin

kipthegreat:

Anonymous:

Whats especially fun, the log with logging turned off would look like:

The current log level is not debug. The message will not be logged.
The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.The current log level is not debug. The message will not be logged.

Have you never used software with logging? With logging turned off, there will be no log. Otherwise they would have just used System.out.println() instead of a logging framework.

He wasn't talking about software in general. He was talking about this particular WTF.
To be precise, he was pointing out that either logInfo() is going to fill up the disk
or it won't do anything . . . in either case, why call it?

ok
dpm

taryn · 2005-11-02 Reply Admin

RevMike:

There is more to it than that. The optimizations might be different for a Pentium, a Power, or a Sparc chip. Furthermore the optimizations may be different for, say, a Pentium 4, a Xeon, an Opteron, and an AthlonXP. And the optimizations can even be tweaked for each model in each family. The dynamically compiled code can take advantage of this. The guys with profilers typically won't tweak for every conceivable chip model. The dynamically compiled code can.

disclaimer: I'm not saying anything about the validity of other statements made here

I'm just adding the info that in the case of our workplace - our code only ever runs on our own server so we only ever have to optimise to our own chip. We run a combination of Java and C (they don't interact with one another) and I've already tried submitting some of the horrendous code to this site... but anyway.

OOC is there a code profiler available for C? I'd love to run some of our crud through it...

2005-11-02 Reply Admin

csecord:
sorry but I have to call shennanigans. There's no way that pushing everything onto the stack in order to run the function isDebugEnabled takes fewer cycles than catting a string. I think this one is made up.

I apologize for being late to the Java/C/C++ war, but I have to respond to that earliest of comments, as quoted above.

Push everything onto the stack in order to run the function ???? WTF? Just where do you think "everything" is sitting, that it's going to be pushed onto the stack when you make a function call? Are you talking about saving all the register contents?

Here's a hint: if your compiler doesn't "inform" calling applications what registers get modified in a procedure call (thereby limiting the list of registers that need to be saved before making the call), you need to get a better compiler.

And readjusting the stack pointer (once in each direction), loading a register from a memory location, and executing a branch isn't nearly as expensive as even looking up the length of a string to be concatenated.

As for the Java/C/C++ war, the question is this: how fast is the CPU that you're running on, that the performance difference between today's Java and today's alternative languages are making the difference between success and failure for you? How fast was the CPU when you started the project? How fast is your memory? Your I/O? Do you even know where your performance boundaries actually are?

Squishin' de Bugs

Leave a comment on “Squishin' de Bugs”