Slashdot Mirror

> ok, it got faster, but still not as fast as C++ too.
> I guess this will finally come but when ?

Errr...

Java 1.4 was comparable in speed to C++ (except obviously for Trig which got a huge overhaul in 1.4 and slowed down some)

It really depends how you write you code... Sloppy C++ code can be slow too.. ;-)

http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html/

http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html/

The writers of the this article have done the hard Work of "proving" that java's performance on numerical code Is at least comparable to C++.

Also, it seems to me that numerical programs (or at least a large class of numerical programs) are especially suited to dynamic compilation since a small piece of code is executed repeatedly (a hotspot). The compiler can focus on optimizing this hotspot once it's detected.

One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).

Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.

Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" compiler GCJ or the more mature but proprietary Excelsior JET). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.

One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.

(For the interested, IBM has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search I used to "refind" these articles.)

I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google or whatever. A word of warning though .. since older Java's were indeed slow, do note the version of the Java tested. It should be (at least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its faster or slower, but 1.4.x have a real nice enhanced garbage collecting subsystem. (Esp. 1.4.2 and above).

(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance".)

Here is a couple of quotes from an article that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.

Here are the quotes:

"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."

Or traditional compiler as opposed to JVM, as I pointed out. Neither is necessarily written in C++, BTW.

I am pretty sure it is implemented in C++,

Fine. However, the code that is running (machine code from the JIT, or natively compiled code from an ahead-of-time compiler) is not compiled C++ - it is compiled Java. Important distinction.

and as a simple consequence, also possible in C++.

In the sense that you could write stream of bytes to memory and then execute them from C++, true. In the sense of compiling C++ with an optimizing compiler to get the same performance, no.

That JAVA makes it easy to do is nice when you need this, but has zero to do with the performance argument.

Incorrect (and in fact you have yet to understand my point). Here are some references:

• COMPARISON OF FORTRAN AND C [note the parts about optimization]
• Performance of Java versus C++ [note 1) Pointers make optimization hard]

The HOPL is an "Interactive historical roster of computer languages". It has more languages, but also contain non-programming languages (like query-languages).

The editor of the site has made two color-coded posters: Version 1 and Version 2.

Other lists are here, here and here.

Ulrik

Well, look here and here.

bah, this mod first appeared 9 years ago with a Royal Typewriter

My experience with numerically-intensive algorithms is that Java is 2-4x slower than C. You can get it within 2x of the speed of C if you ignore object-oriented programming and you're really good at Java optimization, but that's it. And it will run much slower on some architecetures because Java guarantees certain floating-point operation semantics at the expense of speed.

The speed difference oft cited is about 20% on numerical apps. Check out http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html. He brings up " Benchmarking Java against C and Fortran for Scientific Applications as well.

You have to remember that Java's speed disadvantage is mainly in the JVM startup and GUI areas. Although a good Java dev team can make Swing fly ( checkout JBuilder for instance ).

Java being Just-In-Time compiled can even take advantage make runtime optimizations that your C/C++ application may not.

from the moment a Java program uses casts (that is, every Java program), it's by definition slower than the equivalent C/C++ program)

May be you mean that a cast in cast is slower that a cast in C??
Don't let reality disturb you but just with a little googling you can find some article with facts about Java speed and how could it be faster than C.

Imagine a C++ program full of dynamic casts!!!

I can't. I also can't imagine a Java program full of casts. Most I have seen or written have only a few casts.

I know many programmers who use C++ and QT who are as productive as the Java ones.

A programmer could be productive in any language. When talking about language productivity I usually assume it's refered to a general case, in some context. Example: I believe most programmers are more productive in Java for database enterprise apps than in Oracle PRO/C (Yuck!). Also the Java database programs are more portable and independent of the DB.

any competent C++ programmer will tell you C++ deficiencies right away

Not always. Some C++ programmer have their C++ hats down to the waist making them virtually (:-) blind to other languages features. By example take STL, which many believe is an end in itself when it should be a means.

Oh my god, you've got to be joking. C# and Java murder performance compared to C++.

According to his homepage he is a US citizen. But the German name Reiser would be pronounced like you suggested.

Were these pictures taken at different times or what? These don't even look like the same guy.

"but don't some BMW/Hummer/Lexus and some other luxury and european vehicles already use at least 24volt?"

I'm not sure about newer Cadillacs, but I used a '91 El Dorado Biarritz as the base for an art car. It had both 12 and 24 volt systems.

...changes to the design should be expected to set things back....

THIS IS EXACTLY what makes most large projects unestimatable! You can give all the dates you want but to completely implement a new system---you will always have requirement changes! Ask any of these companies that have SAP come in and replace their core accouting/planning/reports systems and why they end up scrapping the project because it takes three times as long as what they thought (costs 10x as much in lost opportunity) and they still can't customize it like when they had a local IT shop!

If you understand some basic mathematics, take a look at these two links and your eyes will be opened!!
Large Limits to Software Estimation

and for a background on randomness

A Century of Controversy Over the Foundations of Mathematics

This is good stuff!

When did FreeBSD get 100% compliance?

http://www.idiom.com/~bko/bsd/freebsd-threads.txt

And that's the point of a healthy pessimism in estimates; when the estimates are good, it's a matter of experience, not methodology. As you read through the comments on this article, you'll notice that everyone who has a method that sounds really sensible is relying on experience and the input of programmers, not on a pure methodology.

The reason I object to the term "software crisis" is because those who use it almost invariably go on to suggest "solutions" to this crisis which don't recognize basic realities of the underlying situation. You're doing exactly the same thing.

A paper was recently discussed here on Slashdot that gives an interesting take on the subject, and some excellent insights: Mathematical Limits to Software Estimation. One interesting observation quoted in the paper is "The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line". Many people, apparently including yourself, would like to deny this; but until it is acknowledged, those who refuse to acknowledge it will continue to perceive a "software crisis", and continue to pursue solutions which don't ever achieve what they want, because, as has also been famously observed in the software industry, there is no silver bullet. That seminal paper says, "Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any--no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware."

Before I go any further, I should qualify what I'm talking about. There are many classes of applications that are pretty much solved problems, because they have been developed over and over, and software frameworks have been developed which make it much easier to churn out variations on that particular kind of application. No-one is suggesting that no improvements in software productivity can be made - over time, the range of problems which are well-solved will certainly increase. However, the issue is that of dealing with new problems. And new problems arise more frequently than you might imagine. When it comes to simple business form-based applications, for example, the basics of such applications were essentially solved by the 1980's. However, any application written in the 1980s would have been written for environments which are now obsolete. Greater abstraction was nearly impossible back then, because the hardware simply didn't have the necessary resources. So the evolution of computers and software as a field itself creates new problems, as just one example.

The fields is still incredibly young and immature, there's no question of that. In just the last five years, things have fallen into place that were never possible or practical before, and that trend will continue for the forseeable future.

On its commercial side, plenty of "lying" takes place - it's called marketing. But there are millions of honest people, myself amongst them, who are doing our best to implement best practices and further the state of the art.

You're trying to do that too, which I applaud, but I don't applaud your attitude. Since I don't know you, I don't know what background has led you to be so antagonistic to the computer "industry". The industry is really an incredibly large and diverse ecosystem, which only superficially moves with one mind. The many languages you were complaining about earlier are a reflection of all the people who are trying hard to improve levels of abstraction and make computing a better place.

All of this has very little to do with the specific project you're apparently working on.

There is no rule of knowledge or of putting things together that says I need to study all written works ever existing in order to be smart enough to be able to put things together.

There is, in fact, a common-sense rule that's so widespread that it has a name: "reinventing the wheel". Another common sense rule is that it's dangerous to ignore a large body of work in the field in which you're attempting to innovate: can you really afford to dismiss the work of the large number of smart people that have gone before you? Are you saying that you don't need to know about prior art in order to advance the state of the art? There's another "rule of knowledge" that boils down to a single word: hubris.

I'm going to leave it at that. I wish you luck in your endeavours. If you're actually developing code, you will eventually learn some truths about software development, even if it has to be the hard way. Some reading and research could save you from a lot of dead ends.

It looks like several people (well, more than several) posted responses without reading beyond the lead-in. If you're one of them, yes, the argument here is in the general ballpark of "software estimation is hard or impossible", but it actually says something more specific than that.

The article does NOT say the following:

1. software estimation is impossible
2. objective software estimation is impossible therefore software estimation is impossible

The article DOES say

• Various software engineering authorities claim that objective software estimation is possible [paragraph 3, quotes on first page].
• objective software estimation is in fact not possible [body of article]

From this, it does NOT conclude either of the points 1,2 above. Instead, it concludes:

• Software construction is inherently creative and subjective, having more in common with physics than manufacturing; software estimation is inherently subjective [conclusion, Bollinger quote].
• Because software is used in the government, in vehicles, and other places where it can potentially have a negative on people's lives, we (software writers) have an ethical responsibility to not over-represent our ability to estimate (especially when it comes to estimation of software quality- r.e. correctness claim in the supplementary material).

Now some of the response posts, paraphrased:

• "The article says that estimation must be objective rather than subjective"
  No, it does not say this.

• "The article says that subjective software estimation is not useful"
  It also does not say this.

• "The article says that we are looking for exact answers, not estimates" or "the article doesn't understand what `estimate' means"
  No, the article distinguishes subjective and objective estimates, and specifically discusses the case of an objective estimate with bounds in detail.

• "People/organizations can make accurate estimates, I made one last week" or "Estimation is hard, I double my estimates and still miss them".
  Ok, but slightly off topic: the article is specifically talking about those who claim objective estimates.

• "You can do objective estimation, and I did it last week using COCOMO"
  And where did you get an objective estimate of the complexity of a new project? Read the article...

• "I think I'm the only person who has read this far".
  Yes, you are. Your boss is monitoring you, get back to work.

• "Software estimation needs common sense, not advanced mathematics."
  Certainly. The 'manufacturing' camp of software estimators (Humphrey quote in the supplementary material) say or hint that software construction can be made into a repeatable, fairly boring process where projects are always on time and programmers are like factory workers. This may or may not be true (I don't think it is), but regardless: to make this view seem more science than philosophy some of these people have fallen into the trap of cloaking their estimating process with formal notation and claiming or hinting objectivity. This part is wrong.

  On the contrary, [conclusions to the article and the supplementary material]:

  Good estimation therefore requires experience and judgment. The software industry should value human experience, intuition, and wisdom rather than claiming false objectivity and promoting entirely impersonal "processes".

Although I like to apply complexity theory to stuff as much as anyone, it doesn't really make sense here:

Quote, The article, Abtract, line 5:if it is accepted that algorithmic complexity is an appropriate
definition of the complexity of a programming project

This assumption set's focus in the wrong place. Most projects have low algorithmic complexity and many of those fail. so that's not the actual problem.

It might become a problem when people in the software world start solving hard (algorithmic complexity-hard) problems -- but I don't see that happening in commercial mainstream software within my lifetime ;)

and that's only on the application level. I have been hearing for over a year (1.2 release?) that servlets perform much better than cgi. Here's a couple links to evaluated benchmarks. Note the servlet link is from sun, so keep that in mind.
java and servlets

That must be one really fast vm!

-----
My karma is still less than my age.

European data privacy laws don't just control big annoying corporations in ways that
don't affect you - they also let governments into everybody's computers,
including yours and including corporations that have records on you.
In some countries, they make it illegal to keep databases of any kind of personal information online
unless you register them with the government.

• 
  Have you registered your online address book with them?
  
• 
  Or the email from your girlfriend with her phone number?
  
• 
  Or the mailing list for your anti-nuclear group
  
• 
  or your church
  
• 
  or your football team
  
• 
  or your anarchist literature-and-beer-drinking society?
  

In some countries, including Sweden and the US, it's safer if you're a journalist,
because there are press freedom laws protecting the privacy of journalists' work.
Of course, in Cyberspace, everybody can be a journalist.
You've probably got Journalistic Works In Progress, which have special legal protection, on your home computer, haven't you?
......... No? Well, then go write some!
However, it's not safe
to be a journalist everywhere.

On the bright side, if European Data Protection Laws don't let you keep personal records, your anonymous remailer really can't go keeping logs, can it?

(Most of this rant is on my web pages.)

David Brin has written a lot of stuff about privacy, particularly
The Transparent Society, about how the economics of surveillance, cheap cameras, and databases are unstoppable, so give up and focus on the important issue, which is making sure the public can watch the government so it behaves itself. I don't agree with it all, but he makes a lot of good points.

How about some real numbers? A java vs. C/C++ benchmark page is here

See this for a couple of small but real benchmarks on the IBM java; source included. Java speeds have improved considerably and are continuing to improve. Someday soon they'll be at the point where it's not an issue (e.g. 1.3x slower than C). Note that on one of the benchmarks the IBM jdk is *faster* than g++ -O. Huh? The processor was a celeron; I assume that the IBM jdk used PII instructions whereas g++ -O needs an additional flag. But still...

Sorry, perhaps I should have been more clear. I was talking solely of market share and mind share.

As for as technology goes, I think FreeBSD solves my problems the best. That said, I did my competative analysis nearly five years ago. I've been very happy with FreeBSD ever since and thus I have not done a detailed comparision since.

Nothing I've heard from other people in the interm has made me think I would get a different answer now. I run an ISP (Idiom) and my analysis reflects my requirements. Here's how I think things stack up now...

FreeBSD: focus on performance and stability (exactly what I want!). Note that stability requires security.

Linux: focus on features, too many players and too much energy to be really stable. Lots of fun and what I would reccomend for most new unix users.

NetBSD: focus on doing things right. Glad someone is, but I'll use something else until they finish :-)

OpenBSD: focus on security and integration of encryption. Mostly follows NetBSD development.

No matter how "strong" Carmack's "anti-cheat" device is, it will be circumvented. Some joker will build a workalike to this complex proxy system that "tells the server what it wants to hear."

A real solution would be to build an actual community.

Yes, this is absolutely right! The problem is that software can never be trusted: only people can be trusted. Take the problem back to the actual source.

The only way to really fix this problem, rather than simply layering more obscurity onto it, is to design a system where you actually know the people you are playing with (or at least know them pseudonymously), and trust them not to cheat.

You can cheat at cards, too. This is no different.

To the folks who think that simply hashing the binaries can solve this: who's to say that my client reports back the hashes from the binary that is actually running? This is the ``copy protection'' problem all over again, it simply doesn't work.

http://www.idiom.com/~brett/humor/ sex.space.html

It purports to be an actual NASA study performed above one of the space shuttles during one of their nearly 100 flights. It's an interesting and well-written read, even if it is a hoax.

---

I'm not a real anonymous coward, I just play one on TV.

ReiserFS was developed by a team led by (surprise!) Hans Reiser. Check out NAMESYS for more info.

Scott

mochaone wrote:

So let me get this straight. I'm supposed to gather evidence to support my suppositions, yet you are allowed to postulate as to what Judge Jackson is going to do?

No, you were postulating about what the appeals court would do, and I asked for some evidence for your postulations. I too was postulating, and in spite of your sarcastic tone, I will take your statements as a request for evidence on my part.

You seem to be questioning two points of mine: I expect the findings of fact will probably declare Microsoft to be a monopoly, and not suggest anything as to remidies, which is really two points: I expect the findings will declare monopoly, and I expect they won't suggest remedies at this point. The other point is A slap on the wrist would hasten the death of the proprietary software industry, because Microsoft would continue to kill it.

First, I expect the findings of fact to declare Microsoft a monopoly because that is far from controvertial. The rule of thumb is a company is a monopoly if it has more than a 70% market share, Microsoft has a 90% market share. The controversy is over whether or not Microsoft used its Monopoly powers illegally, and I did not speculate on what Jackson would find there.

I expect the findings of fact to suggest no remedies because there is no other reason for Judge Jackson to split the findings of fact from the Judgement. Microsoft asserted that they will appeal any negative judgement very early in the trial. The purpose of separating the judgement from the findings of fact is to shield the facts of the case (which are harder to appeal) from being dragged through the mud during the appeal of the judgement. Suggesting remedies during the findings of fact would defeat the purpose.

Lastly, as for Microsoft killing the proprietary software industry, here is some good material to support my opinion:
Caldera v Microsoft Complaint
Reiser v Microsoft on allegedly illegal product tying
A Rutgers University analysis of Microsoft's use of predatory pricing to destroy competitors
A Reuters Article describing Microsoft's pressure on Acer to not sell competitors applications

In all, Microsoft is clearly trying to encompass as much of the industry as they can get away with, and kill any competitors that stand in their way. If they're the only provider of proprietary software, it's no longer an industry, hence they would have killed the industry. Personally, I don't think it's a great loss, since Microsoft is a big fish, eating all the little fishes (other proprietary vendors), while the rest of us are learning to farm kelp (Free software).

Hmm...I guess since you're saying it, "evidence" isn't needed to prove your point?
No, I was saying evidence was needed to prove your point. As you can see above, there's lots of evidence to support my point.

PS: I was completely baffled by your talk of movies and heads. What were you trying to say there?

----

Oh yeah, sex in space should be great. If you're in to elastic harnesses and inflatable tubes. There's been a supposed NASA document about sex in zero g floating around the web for a while now - click here. It seems to be a reasonable discussion of the topic, but of course its unverified. True or not, its pretty damn funny.

Reiserfs doesn't have journalling *now*, but Chris Mason is working on it. Remember that reiserfs hasn't been released. Its feature set isn't set in stone.

By the way, Reiser has bigger ambitions than just producing a faster fileystem. He aims to change the way people use filesystems. See here for some insights.

PS. Hmm, interesting. The slashdot code seems to have removed the spaces in the anchor part of the url. Just jump to "Why Aggregate Small Objects at the File System Level?".
--

you might look at xfiles
- GPL'd, it shows a graphical file tree and compares/diffs/copies/deletes files between a client and a java server program. The client and server can be different processors or OS's.

No security at present. Editing would be trivial to add however - html display and text editing are both pre-provided widgets in the java JFC.

There is work in progress to develop a binary tree-based filesystem for Linux, which is currently on second beta. The paper and source files are located at http://idiom.com/~beverly/reiserfs.html . It is supposedly faster than ext2, and might be better suited for gigantic partitions, although I cannot attest to that, as I have no experience with it. Does anyone here know anything about this?