Dejan Jelovic: Why Java Will Always Be Slower than C++

We've covered this topic before, with Carol Schiraldi's article on why game developers tend to use C++ instead of Java, and in our interview with ID Software's Timothee Bessett.

Slow applications - especially if they are slow because they're "chatty" or if multiple instances of the program are run on a router or pass-through appliance - can lead to network delays. Although this article takes more of a programmer's point of view than that of a network engineer's, you might be interested in Dejan Jelovic's explaination of why Java will always be slower than C++.

People who claim that Java can be as fast as C++ or even faster often base their opinion on the idea that more disciplined languages give the compiler more room for optimization. So, unless you are going to hand-optimize the whole program, the compiler will do a better job overall.

This is true. Fortran still kicks C++'s ass in numeric computing because it is more disciplined. With no fear of pointer aliasing the compiler can optimize better. The only way that C++ can rival the speed of Fortran is with a cleverly designed active library like Blitz++.

However, in order to achieve overall results like that, the language must be designed to give the compiler room for optimization. Unfortunately, Java was not designed that way. So no matter how smart the compilers get, Java will never approach the speed of C++.

I would like to point out that there are some advantages to Java in enterprise environments. It's slightly easier to program, it's portable, and servers can usually handle Java's overhead. There are many advantages to using Java in an enterprise environment over C++ - it's just that there are also a number of drawbacks as well.

Besides, as anyone who has studied Special Relativity knows, nothing can travel at the the speed of C++ except light++.

The Register: Super-fast RDF Search Engine Developed

I'm skeptical that the Semantic Web will be as big a deal as it's made out to be - I believe that it will revolutionize commerce on the Web because computers will be able to hone in on the data much more quickly, but natural language is the carrier of ideas. The Internet is not a demanding social force because of its ability to connect with tons of computers, but because of its ability to connect people using those computers to the ideas of other people using computer. It is not about the transmission of ones and zeroes, but about the transmission of ideas.

That said, if you're interested in transmitting the ones and zeroes of commerce and business, RDF/Semantic Web innovations are indeed innovations which will enable you to do so quickly. And now there's a search engine for it.
Researchers at the National University of Ireland, Galway's (NUIG) Digital Enterprise Research Institute (DERI) have developed a search engine that can answer search queries with more than seven billion RDF statements in mere fractions of a second, which is the highest number recorded to date.

Using these semantic web tools, users should get more relevant results, with the computer filtering the information and allowing the transfer and sharing of information between systems, rather than leaving it up to users to filter it themselves. At present, this information is kept in separate "silos", for example in different software systems. The semantic web could help bridge that gap.

"The importance of this breakthrough cannot be overestimated," said Professor Stefan Decker, director of DERI. "These results enable us to create web search engines that really deliver answers instead of links. The technology also allows us to combine information from the web, for example the engine can list all partnerships of a company even if there is no single web page that lists all of them."

Never underestimate the power of overestimation. Yes, we'll find the prices of all 40" TVs within a 10 mile radius of a Denny's in states that begin with the letter A, but will a semantic web help people communicate ideas better?

The Retrospector: Top 10 Ways to Motivate Geeks

You probably already know most of this, but it never hurts to print it out and anonymously slip it under an executive officer's door…

By no means is this a rant, but for the last 10 years I've seen what motivates us and what doesn't. I've seen the managers that just don't get it. I've seen those that understand completely and react accordingly. So, I thought I'd share my observations and see what everyone has to add as well.

By far, the greatest motivation that works for me is knowing that what I do is important and interesting. The latter might not be helped - there's only so much interest one can feign for database maintenance or a routine server rollout - but too often there's a disconnect between IT and the business-side of business. Letting your IT department suggest solutions to problems that the business is having not only helps solve your problems quicker but it also underlines the value of the IT team to the organization as a whole.

TurbochargedCMS: Weathering Heavy Traffic with WordPress and Turbocharged

While most enterprises aren't running WordPress except for their corporate blogs, this tutorial is interesting because it talks about how serving up one dynamic Web page can make many calls to the MySQL server hosting it - and why sometimes performance problems caused by the "Slashdot effect" have nothing to do with your inbound link but everything to do with how much of a strain you're putting on a server. It also deals with some clever tricks to help reduce that load - one I particularly like is the fact that you can make your server produce an xdx auto-cache of your dynamically hosted content the first time you serve it - and subsequent visitors can get that version of the page.

The problem is that traffic storms aren't "average". When your site experiences a traffic storm, you can be sure it's going to be ten times (or perhaps even a hundred times) larger than the average traffic. Under a traffic surge, the Web server might be receiving ten WordPress (dynamic) requests per second, but it will be dispatching only one in that time - and the rest of the requests will be backlogged in a queue. The queue will grow and grow. Visitors will wait, and wait, only to never see the page they expected. Then they'll head somewhere else.