Slashdot Mirror

PHP for anything other than web stuff is a bad idea simply because PHP is just a horrendously bad language, it's truly awful. The only reason you'd use it on the web is because it's so well supported in terms of libraries and so forth, and generally available on cheap hosting options.

It doesn't have these advantages outside the web- the libraries aren't as common or well tested, and it's less available on say, desktop PCs than Java, .NET or native binary support is. Examples of problems with it are it's terrible hacked on OOP support, lack of proper namespaces, clunky syntax. Why would you put yourself through that when you can just use C, C++, Java, or one of the .NET languages? It's best to just leave PHP where it belongs.

C/C++ may be more than a little faster than Python certainly, but they're barely faster if at all than Java/JVM or C++,C#,VB,etc./CLR. See this site, which is now 6 years old (things have moved on even more since then) to better understand why C/C++ do not have much of an advantage in performance anymore, and have no advantage whatsoever when you factor in ease of development against performance:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

The idea that things that require high performance are written in C/C++ is a little bit of a straw man. Games are written in C++ because it's the only langauge that's portable across the Wii, the PS3, the Xbox 360, the PC, Mac, Linux and because it's what companies have been using for decades and as such have millions of lines of libraries written for and have developer teams skilled up in. It's certainly not about performance nowadays, head to java.com and look up their case studies list for high performance computing for example. The fundamental problem is that when you compile C/C++ code you're generally compiling for a generic chipset so that's the best that the compiler can optimise for, with VM based languages like Java and the .NET languages, they use JIT compilation so that the bytecode is compiled into natively executable code and optimised for the specific abilities of the system on which it is being run- this gives it an inherent advantage in terms of optimisation because it does not have that disadvantage of needing to be generic enough to run on any compatible system like compiled C/C++ generally does. You could get the same benefits with C/C++ and allow it to keep it's slight edge by distributing an executable optimised for each type of AMD processors with 1gb, 2gb, 3gb, 4gb RAM and so on and then the same for Intel and other factors, but you get a combinatorial explosion of the amount of executables you'd need to distribute and the user would probably struggle to know which one to use.

"Objective-C has advantages, such as that it is compiled."

Huh? Java is compiled too, but it's JIT compilation which is better in that it allows optimisation for the specific device on which it is being run, not the generic platform on which it is expected to be run. The claim that Objective-C being compiled is an advantage makes no sense at all. The rest of that paragraph seems to be based on the false premise that Java is inherently slower than Objective-C which just simply isn't true.

"X-Code is a purpose-built, clean-sheet IDE that may lack a few power features found in Eclipse, and Eclipse has numerous plug-ins, but Eclipse also has a pretty diabolical UI, especially compared to software from Apple."

I do agree, I'm not a fan of Eclipse, but then, Apple's software doesn't come close to beating Visual Studio, so in this respect it's really Windows Mobile that has the IDE advantage of any platform. It's a shame really there's no official support for NetBeans rather than Eclipse for Android, NetBeans is IMHO, much better.

"Java, Eclipse, and the other Android SDK tools are more than good enough, but they are not a big advantage, or, depending on your tastes, any advantage. There is a rough equivalence here that will probably extend to Android doing for client Java what iPhone did for Objective-C - making it popular. That is, Android apps will probably be the most common form of interactive client Java apps, if they have not already eclipsed AWT, Swing, SWT, and other Java UI libraries."

I'm not sure you know too much about Java, but it's far and away the most commonly used language across the globe and has been for many many years. Android is small fry in terms of overall Java development, even on the client side. When you go into a Doctor's surgery to book your appointment, use a system to pickup your prepaid Cinema or Airline tickets, get served by someone at checkout, the chances are these systems are all client side Java. Even on the desktop there are some prominent Java apps- Vuze (Azureus) is a popular BitTorrent client for example that has a pretty nice interface.

Regarding iPhone books as Amazon top sellers, it's also not really a meaningful metric (although I just had a look myself, and it doesn't even seem to be true- are you sure you weren't looking at your recommendations?). This could simply because Android has great online documentation for example.

Java certainly is an advantage, if not only because it's prominence as a language and portability between Windows, Linux, Mac, Android phones, Blackberrys, Unix and so forth means that even if you have to write the UI, you don't have to re-write the libraries. As pointed out above, it's not as if performance is an issue in Java either, see here, and keep in mind this page is now 6 years old:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

The only thing Java really does need is IDE improvements, if NetBeans or Eclipse were taken up to the quality and usefulness of Visual Studio then that'd be awesome.

"Most games aren't written in Java for the obvious performance reasons."

What obvious performance reasons would they be?

Java performs perfectly well for game development, the reason developers use C++ still is partly because it's the only language shared between all gaming platforms (PS3, Wii, 360, PC) and partly because it's historically what their developers were trained in because it was historically faster.

There are no performance issues with Java nowadays, it's a complete myth. See here, and keep in mind this page goes as far back as 2004:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

"It doesn't take a rocket scientist to work out that a GC-based, VM-based language that has layers of intermediate execution is going to be slower than is required for a trading system."

Actually, this is only true in an ever decreasing set of circumstances.

See here for an explanation of some of the common reasons why this is often not the case:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

...

A large scale trading system like this one is one of those circumstances. The latency has to be low, the throughput is high. They are spending enough on hardware that having a programmer optimize a few functions is very worthwhile. Certainly enough that they wouldn't think a 20% performance decrease was "very reasonable".

There are ways of optimizing .NET further, like writing chunks of the code in C. But one really has to consider how much of the application you want written in this way. Clearly in this case the optimizations weren't sufficient.

"It doesn't take a rocket scientist to work out that a GC-based, VM-based language that has layers of intermediate execution is going to be slower than is required for a trading system."

Actually, this is only true in an ever decreasing set of circumstances.

See here for an explanation of some of the common reasons why this is often not the case:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Also here are some benchmarks:

http://kano.net/javabench/

These sites are focussed on Java, but the points are applicable to .NET also as it's on par nowadays. In .NET you also get the option of using unmanaged code anyway so you can have areas that don't require the VM to underlie execution.

I'd imagine the real problem in this case was a combination of poor project management with poorly skilled developers in an attempt to make the profit margins for Microsoft and Accenture as big as possible. The net result though, as you can see, is quite bad. I do not believe for a second .NET was the problem as there is no reason it can't be used in a way that performs as well as or better than a C++ application. It would use a bit more memory to achieve that performance, but memory is cheap enough for this to not be an issue for most cases nowadays, particularly when you factor in the benefits of security and resilience you get from the managed parts of the codebase.

I have read the article in question, and it takes a specific "performance test" to task over bad methodology. I have not endorsed said methodology but referred to an article on the topic of performance that is more in depth.

If you have any information about the methodology applied in this article, please let me (and the author) know.

I also referred to this one, again not the one with the flawed methodology. If you feel there is anything wrong with either of these, please feel free to enlighten me.

am aware that Java 5 (aka 1.5.x) made some major speed improvements, but this is the first I have heard anybody claim that it "competes" with C++.

Well, I am glad that you say "first I have heard" since that explains it. You simply haven't been around that much to hear. Perhaps you do not work in the right industry. Perhaps you haven't been keeping up with Java at all. For one, Java is at 6, and it has been competitive for quite some time. As the benchmark here shows, java is very competitive with C++. This is for CPU intensive benchmarks. Once you add disk and database access into the mix, as you do in most applications, the speed difference between Java and C++ applications becomes negligible.

I think your opinion is highly colored by your prolonged lack of information about Java and benchmarks since Java performance parity with C++ for a large number of tasks was widely reported at least five or six years ago. Particularly the IBM Java VM gained a rep for being very fast, with subsequent inclusion of similar features in the Sun VM. You can read about it for example here.

Remember, a Java application can do something no (or most) C++ applications can not do, namely run-time performance tuning.

For a number of tasks C++ will probably always be faster than Java, but those tasks are fewer and further between every day, and for the tasks that so many people work on today, namely creating good web-based stuff, Java is probably the fastest language there is since C++ is not a widely used web-app development language.

So, given context, namely web-based applications, it is perfectly fine to use "high performance" about a Java solution since it is the best performer of them all. There are very few web-apps written in C++.

but never compared to C.

Here is a somewhat old comparison of Java and C/C++ performance, done by the University of Southern California. Note that the article was written in 2003 and updated in 2004. Javas performance has improved significantly since then, most noticeably in JDK 1.6. This is the conclusion:

Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks.

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

I won't argue that Java doesn't have its development problems - there are many things I hate about java development. However, in performance I'm afraid you're a little outdated: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

C is still faster, but not by an order of magnitude, which is what matters. On the other hand, you missed an element of "Powerful" - C is the only viable language if you need direct access to the hardware. That doesn't mean Java doesn't have its place, though.

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
statistics seem to contradict you. On startup Java is slow, but when you're running azureus for months, even years at a time, a minute or so of startup is nothing.

Please cite where Smalltalk is shown to be anywhere near the speed of Java. A quick Google search reveals this language comparison where Smalltalk gets its ass handed to it, and that was written in 2004. Say what you will about Smalltalk's elegance, but speed was never truly its forte.

So many problems, so little time..

The consumer JRE is ~4MB.

I can also write Java code that runs faster than C code on a 4 year old JVM!!

Now please, go back to your Visual Studio and let us adults get back to the convo.

Regards,

Here, read some. These are benchmarks comparing Java5 to C++
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Java has improved a lot since its early versions and now it's comparable to the best platform specific compiled languages out there.

That is, Compile it's own Compiler.

To Me, a Programming Language is 'Real' When it can fully bootstrap itself.

being an interpreted language, fails that test miserably.

I've once seen a student project, a java interpreter, written in Java.

But it's not faster, never!

Another link you might like to read (just done some search on google):
http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html

Of course you can create your own "dynamic" allocator in C++... but that doesn't make allocation/deallocation automatically faster.

Maybe you should search for some numbers to support your argument... just by stating "I don't buy it, C++ is still faster" it doesn't become reality.

Oh, and another thing:

I can compile java bytecode to run faster then optimized C++ apps.

It's been this way for years.


Please hurry with that patch! Also, it would be nice if you updated your script from VB4!!!! ;)

One of the better reads on this topic:

http://www.idiom.com/~zilla/Work/Softestim/softest im.html

Here's my view, based on my own life experiences as a one time software developer. Software development is partially an art form. No matter how well studied people are, writing awesome software requires passion and having some qualities that are like being an artisan. Just an artisan with great vision can turn a piece of stone into "David" it takes analagously speaking, similar qualities in creating a system of code that are resilient to change but at the same time extensible yet with maintainable.

The reality is, for many people, software development becomes a means to pay bills, nothing more. Which is fine, many people do this. However unlike the task of perhaps excavating a 10 foot by 100 trench for construction purposes, software is littered with intangibles including bad specs, unmotivated software developers, new paradigms (AJAX), etc., etc.

At least if you're working a construction crew, things are much clearer and you as a foreman can insist on people "stepping up" if needed. These measurements are simply not possible with software. Despite all the panaceas that has been given labels over the years, hard numbers just are not possible. And if you at least concoct a metric system that seems to work, you might have staff that quits and at that point, all those metrics are gone. All developers are *not* created equal. Fact.

There was a day when I used to follow the ANSI committee on C++ and knew the language incredibly well. I wrote some of my best code ten years ago including C++ frameworks that others had occasions to rely on. Sadly, I did *not* observe this attention to detail with my peers save for a couple of them. I had occasion to observe a couple of developers once wanting to rewrite my code since they had never used the Standard Template Library (STL) and had never encountered keywords such as "mutable" or my use of the "new" C++ (at the time) cast notation. Never mind that the code worked and did what it was supposed to and a peer review of this code (two seasoned and driven C++ developers) did not recommend changes.

The greatest "sin" I observed during my years of software development were individuals who programmed by rote, i.e. cut and past programming and simply did not have the motivation, inclination or passion(?) to learn the very programming language that constituted their "bread and butter." Expecting a largely unread person to suddenly write like Shakespeare (or columinist at a major newspaper) doesn't just magically happen. The most articulate people of the English language are always well read. They've at some level "paid their dues" engaging your mental faculties that many people never bother with. And just like with many things in life, practice, practice, practice.

Things perhaps have gotten better in the software development realm if only because there are less platforms to worry about now. By and large everyone is creating web applications and if you are not, then you are probably serving some vertical market (I doubt you are creating a WinAmp competitor) or work at large companies - Microsoft, Apple, IBM, Cisco, etc. Writing a Cocoa application (Mac OS X) means coding in Objective C but how many of you can make the claim you code in it regularly? Point made.

As my career advanced and I worked with web developers I saw many people not at all inclined to pick up new material. The one thing that web developers were incredibly bad at is induction - taking two principles or abstractions and creating a third. Most of them seemed to learn one way of doing things and applying this by rote over and over - cut and paste programming at its worst.

And since web apps are par for the course at many institutions now... well you can imagine the results.

-M

Also keep in mind that creating a C++ object in the stack is 25 times faster than creating a Java object (even with the server VM) according to my benchmarks...

If there's one thing we should all know by now, it's that benchmarking the performance of Java bytecode running on a JVM with a Just in Time compiler is very, very tricky. Modern JVMs may apply optimizations to your code while it's running, based on the way the code is actually being used.

Take a look at the slides from Dr. Clifford Click's presentation Java Technology Performance Myths Exposed (PDF) and at Performance Considerations for Run-Time Technologies in the .NET Framework by Emmanuel Schanzer to get an idea of how your code is manipulated at runtime to increase performance. Also, Performance of Java versus C++ by J.P.Lewis and Ulrich Neumann discusses some of the difficulties of benchmarking Java.

"Scouts also must choose one activity from a list that includes visiting a movie studio to see how many people can be harmed by film piracy. They also can create public service announcements urging others not to steal movies or music." And complete a lobotomy.

Do they also have merit badges for not thinking independently? Or one for having your IQ reduced to a single digit and being converted to a near-mindless automaton?

to put faces to names
hans reiser
nina reiser

This site shows an accurate single camera face motion capture program, requires only lipstick on the face: http://www.idiom.com/~zilla/Work/V/oct1TregP2Sor3. mov

C Source ==> gcc ==> Native Code
Java Source ==> javac ==> hotspot vm ==> Native Code

Java can be interpreted, just as C can be interpreted. Referring to Java as an interpreted language reveals the poster suffers from the widespread anti-Java prejudice that is based on complete and total ignorance of how modern Java VMs operate.

Just to add to this. Goto: http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html

Here is some evidence. Java recived a bad rep from the first couple iterations. Before say 1.3 the performance was crap. Now with the 1.5vm it is quite competitive with c/c++ compilers.

It has it's uses though you don't want to use it to do ls or other programs with a short run time. But with the runtime optimization it can be optimized in ways a a c++ compiler just can't which benefits longer running programs.

Rijk's results were incredible for their time. However, time has marched on and Java has gotten even faster. If you look at the second benchmark he posted (which is already 4 years old!) Java did even better than it did in Rijk's benchmarks.

There's further dicussion on the topic at this link.

Think about it: 20 years ago, computer science taught you to write good programs in relatively low-level languages; now they teach you to program in languages like Java with virtually no regard for efficiency. Programs could be written much, much more efficiently, and most of what we use today could easily be made to run on hardware over ten years old if more effort was put into optimizing it.

20 years ago we weren't doing what we do now with computers. Pull out a word processor from 20 years ago and tell me that it looks like a "good program" today.

More to the point, Java isn't slow! In many cases, it even beats C++.

My cellphone runs what is probably the closest thing to a production Java OS that exists today. The Danger Hiptop runs an entire OS on top of a Java VM, and while certain key functions are written in assembly (graphics functions, mostly), the OS manages to fare remarkably well considering that it's running on a 24MHz ARM with 4MB of memory. Neither Palm OS, nor Windows CE, nor embedded Linux would run as well on a system that is so limited.

the programmers take up every ounce of system resources they can now by being lazy

That's quite frankly crap. I remember a time when PCs struggled to play MP3s and run a word processor at the same time. Now I have no trouble playing a DVD while streaming media accross the network and recording two channels of TV.

None of the software on my system is "taking up every ounce of system resources". Right now, I'm using 4% of my CPU and have over 800MB of free physical memory (which is being used for disk cache at the moment). Is my PC high-end? Not in the least. I have an Athlon 64 2800+ system with 1GB of DDR400 running Windows XP.

and most of what we use today could easily be made to run on hardware over ten years old if more effort was put into optimizing it

A GPU from ten years ago wouldn't even be able to run today's games, let alone at a decent framerate. Forget about encoding XVID captures of DVDs, either - look at this chart (the bottom one) and note that a $150 2.4GHz Athlon 64 "Newcastle" does in 2 minutes what takes the fastest CPU from 10 years ago (the Pentium MMX 233, which is actually only 8.5 years old) 20 times as long.

Remember how problematic it used to be to print a large document? Remember how long PDF files took to open? Remember how long it used to take Flash animations to load? Remember how crappy video used to look?

The problem with people like you is that you forget what it was really like just 15 years ago. Mac OS was a dog on the computers of 1991, as was Windows. HP-UX took minutes to boot up. Even 10 years ago, the only reason that we didn't notice how slowly webpages rendered was because most of us were using modems. Pull out a copy of Netscape 2.0 and an old 68040 Mac to run it on, then tell me that we're not doing better. Fire up Word 7.0 on a 33MHz 486 with 16MB of memory and Windows 95, then tell me that applications aren't faster today.

Microsoft Word starts in 3 seconds on my system. Less if it's disk cached. I can resize it without a wireframe mode because the system is fast enough to redraw the application as I resize it.

Software uses more memory today because it does more. No one would think of working with 50MB photographs in 1996. No one would think about editing DV footage without expensive hardware.

Capsaicin
is an excellent topical analgesic also for neural problems, like Diabetic neuropathy.

There is a substance P which transmits the pain to the brain. Capsaicin destroys substance
P if you apply it for 4-5 days multiple times a day & hence for the next couple of weeks
you will not have pain, then you have to report it. Instead of the expensive Capsaicin
cream you can also use a paste made at home of red chilli powder etc. Or even McIlhenny's Tabasco

I have meralgia parasthetic condition & nothing provides relief like chilli paste.

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

Ahh...your typical uninformed slashdot poster...

You do realize that array bounds checking is eliminated by modern VM's? i.e. HotSpot. Suggest you read:

http://java.sun.com/products/hotspot/docs/whitepap er/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4 .html

The Java version of Quake performs faster than the C version:

http://www.bytonic.de/html/benchmarks.html

Here are some other benchmarks:

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

Java VM's such as HotSpot have the ability to de-optimize and re-optimize on the fly. C/C++ can not do that.

Stop repeating the lie that Java is slower than C/C++.

Take a look here for some objective information explaining how Java can (sometimes) be faster than statically compiled code. A fair criticism compared with fully compiled code is the JRE load time & basic memory requirement, as the bootstrap and the classes referenced in the classpath are loaded. For shared application "container" environments like a J2EE or Web server this cost is absorbed at startup.

Back on topic, I suppose this might be useful for companies with peak loads in various applications occurring at different times but it looks rather expensive. They must have done their market research though, so good luck to them.

"...What could possibly go wrong?..."

Well, memory leaks and array bounds probably won't go wrong ;-)

Looking at some benchmarks for numerical processing using Java, it appears to stack up quite well agains C++ at least.

Yeah I know, what exactly is being measured, are the benchmarks relevant, are any benchmarks relevant, blah blah blah. Just pointing out that the parent's postulated x60 slowdown is a trifle pessimistic.

T&K

Obligatory link to benchmark

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

Both have a reputation for being slow, insecure,

Maybe on Slashdot... Java has an excellent track record for security. Compare with the PHP worm that swept the net, or PHP based framworks like NukePHP that are hacked so regularly that sites are unusable. .Net I haven't kept up with, so I don't know how they do security in real life.

Server side java is REALLY fast. On artifical benchmarks, java can be as fast as C++, and these people wrote a high performance Linux cluster monitoring tool in Java.

If you need more proof, Java is now the preferred language for Boeing when doing mission critical and real time software. NASA used it during the Mars mission...

and proprietary.

You can join the Java Community Process for free as an individual and vote for how future versions of Java will look like, Sun has handed over control over just about everything but the Java trademark to this JCP. There are also plenty of open source implementations of compilers and JVMs. Sun keeps donating stuff to the open source community. DTrace, Solaris, 1600 patents, cryptography tech....

For years the Java wonks have been calling performance a strawman argument, usually followed with "get a faster machine".

Guess i'm not your typical java wonk since I've never claimed such a thing:

link

You know, I work with people like you, and you guys really piss people off.

Coding is about the best tool for the job.

In many cases that's C or Perl or C++ (shudder) or Python.

But sometimes it's Java, or C#, or something you would called "new age" or "gay" (yes, I've had co-workers who are 'professionals' call Java such names).

I call them powerful and simply use them when I need to. I also use other tools like C and can hack assembly code onto hardware controllers.

Your attitude is one of not recognizing that we're just like mechanics, we find a tool and a part and get to work until it's "fixed" aka the design and all requirements are met.

Don't knock others because they don't want to hand-code 100 GUI elements.

I can create software faster in Java than any other language. Java can do almost anything you need it to, and since the late 1990s it has been nearly as fast as C or C++:

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

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

There's literally tens of thousands of sources on the internet about java's execution speed and the myth of it all. Do some friggen research, what do I actually care if you believe it or not?

People wildly claim that Java is X amount slower than C++. I'm pointing out that it's not true. I guess the most mind boggling thing to me is that everyone is so skeptical about it, like if Java's execution speed approached the speed of C++ armageddon would happen.

Years ago, no one believed that the speed of C could ever approach the speed of assembly, but it has. It's come within about the same 10% margin that Java has come to C++.

I could see all the skepticism if someone was saying that Java was better. Fact is, it's no better or worse, it's just another language. Another language that happens to not be as slow as the majority think it is.

A quick web search turns up several surveys with lots of benchmarks,

http://java.sys-con.com/read/45250.htm
http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html

You could be the best programmer in the world in FORTRAN or C but don't think that because of that you understand Java. The vast majority of complainers and those who knock Java haven't written a line of code in Java ever in their life. Their experience may be with an applet or two in the browser, if that.

That being said, go read this article and then report back. I doubt you'll post because it's hard to dispute raw facts from an unbiased research team :)

---------------

Performance of Java versus C++
J.P.Lewis and Ulrich Neumann
Computer Graphics and Immersive Technology Lab
University of Southern California
Jan. 2003
updated 2004

This article surveys a number of benchmarks and finds that Java performance on numerical code is comparable to that of C++, with hints that Java's relative performance is continuing to improve. We then describe clear theoretical reasons why these benchmark results should be expected.

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

Then why are you wrong... Lets start.....

First of all, the cost of virtual memory. As we all know, it is not free. Google "virtual memory cost TLB percent" and hit "I feel lucky", you should come to this page...

http://developers.sun.com/solaris/articles/optimiz ing_apps.html

This is talking about a common case where an app causes a lot of TLB misses, using a substantial proportion of the execution time doing nothing but VM translation. Notice that the performance penalty is (in their example) roughly 30%, due to TLB misses causing floating point pipeline stalls. This is a commonly accepted figure. EVERY TLB miss will cause a few hundred clock cycles. A TLB miss rate of even 1% will have a SUBSTANTIAL effect on performance. Running without Virtual Memory (in system mode) completely eliminates the TLB and all of this performance is reclaimed. This is possible with any truly typesafe system, such as JAVA.

Secondly, compilers..... Yes, some of the compiler/verifier is on the client, however you could just as easily say that the hardware underneath is a compiler itself (translating CISC x86 instructions to RISK opcodes), so this terminology isn't particularly meaningful. It becomes totally misleading when you consider that there exist hardware platforms that can execute java bytecode directly. My meaning should have been clear from context to someone of your credentials. In any case, most of the checks are done within the compiler (Hotspot), though that compiler happens to reside on the client machine. If you dislike this being referred to as a compiler, then that is your business.

Third, you include some extremely bad examples of runtime checks. Modern Virtual Machines already eliminate a lot of array bounds checks with compiler passes (though granted, this particular compiler pass is performed on the client machine), and null pointer checks are handled by a hardware interrupt, just like an integer divide by zero. Both of the examples you gave are very unfortunate, as they are two checks that rarely actually must be performed by software.

As for your question of whether or not the software checks in java are more expensive than the hardware means, there is very little direct research available, but Java is commony accepted to be around 95% of the performance of straight C, and Virtual Memory is commonly accepted to be about 70% of the performance of System mode, so you tell me. For instance, see...
http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html

I wouldn't have assumed you were junior if you didn't make such classic mistakes.

Once again, it is very foolish to make claims about my chip designing skills. Everyone who has investigated the issue accepts that modern CPUs do the best they can GIVEN that they are running unsafe languages. It is also commonly accepted that dramatic efficiencies could be realized (I just gave one example, no TLBs needed, saving around 30%) if the software itself could be proven safe. It would be another mistake expected of a novice confuse this rather clear cut situation and claim that I was calling the Intel designers idiots.

Who knows, perhaps in your zeal to call me out as a fool you skimmed over some implications and said things that didn't sound particularly well founded.

However, since you asked... I'm a BA in Physics from an Ivy League institution. I currently work in computational finance. I spend a great deal of time working with java, and occasionally native code. We are largly performance bound, so I have studied this issue extensively.

That's what happens when you consolidate your energies rather than using a random collection. I'd be interested to know what these other languages were.

"It's much faster to write the application in php, then identify performance issues and code those functions as c++ extentions than it is to write the whole thing in java. This is Radwin's point, and I've seen it proven repeatedly in practice."

There's a problem with that. You now have to have developers know php and c++ which negates one of the benefits of PHP being easier to program. Whereas with Java you're starting off with better speed and if you need to go to native api's you can still do that through JNI and going from java to cpp is a lot easier than going from php to cpp from a coding perspective. (The languages are more alike).

"'Java's as fast as C++'. OMFG. LOL."

Ok, now I know you haven't used java or haven't touched it in years. On the server side JIT compilation really shows it's strengths. And things are going to only get better as cpu's continue to have greater threading capabilities which PHP can't usually take advantage of until more modules are made thread safe. JIT compilers can inline a method increasing performance and use other static calls. Intel worked on features of the P4 and Xeon processors to perform better with code with a lot of branching and inderection. They did this with JVM's in mind. The JIT compiler can reduce the number of branches and it's branch prediction is right most of the time. More than static compilers anyway. Delays on these processors for a correctly predicted branch are down to almost zero clock cycles.

Here are some links in case you don't believe me.

Java Pulling Ahead, Java faster than c++, Computer Language Shootout, http://www.tommti-systems.de/main-Dateien/reviews/ languages/benchmarks.html">This shows them mostly similar, this is an interesting read too

Academics looking at the question

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).

Pardon me for replying to my own post, but I found some references on what I'm talking about. One project is called visual IDs, where they generate random art for every icon in a filesystem, thereby making it easier to find files, based on their look rather than based on harder-to-remember filenames. Go here for more info.

Another one is a paper (reference 31 in TFA) that discusses hash visualization, i.e. generating random visual images based on unique strings/numbers/hashes.

I think there is alot of merit in these ideas. Humans are visual creatures, and can recognize images very quickly. I would like to see filesystems and authentication schemes that take advantage of this fact.

This reminds me of a paper I read several years ago that gave a mathematical proof showing that objective estimation of software complexity is impossible. The same author has since provided some supplementary notes as well that are a good read, and even a PDF of some slides from a talk he gave.

Being a math weenie myself, I gave a short presentation of the results to my development. Afterwards, my manager pulled me aside & told me to stop wasting valuable development time since we were already behind our schedule.

Sigh.

This reminds me of a paper I read several years ago that gave a mathematical proof showing that objective estimation of software complexity is impossible. The same author has since provided some supplementary notes as well that are a good read, and even a PDF of some slides from a talk he gave.

Being a math weenie myself, I gave a short presentation of the results to my development. Afterwards, my manager pulled me aside & told me to stop wasting valuable development time since we were already behind our schedule.

Sigh.

This reminds me of a paper I read several years ago that gave a mathematical proof showing that objective estimation of software complexity is impossible. The same author has since provided some supplementary notes as well that are a good read, and even a PDF of some slides from a talk he gave.

Being a math weenie myself, I gave a short presentation of the results to my development. Afterwards, my manager pulled me aside & told me to stop wasting valuable development time since we were already behind our schedule.

Sigh.

Of the six reasons adduced for project failure, these cannot be accurately applied post facto:

Use of an inappropriate methodology: Had they used a different methodology, they might have simply stumbled on different "gotcha's".

Lack of formal project management practices: This reason means they know a number of issues got out of control. They do not know how much more those issues would have been controlled, nor how much additional control might have slowed progress.

In addition, the "Requirements volatility" category begs a big question: requirements DO change over time; how is this category different from "Lack of formal project management practices" that would have planned for requirements changes?

It is interesting that "Project complexity" falls low on this list, because it is the most clearly proven reason why project plans fail. See this website for a fairly formal proof that project complexity cannot be estimated in advance: http://www.idiom.com/~zilla/Work/Softestim/kcsest. pdf/
This proof has been discussed at slashdot here: http://developers.slashdot.org/article.pl?sid=02/0 1/10/1844255&tid=156&tid=9/.

• One
• Two
• Three
• Four
• Five
• Six
• Seven
• Eight
• Nine
• Ten
• Eleven
• Twelve