Slashdot Mirror
The End of Native Code?
psycln asks: "An average PC nowadays holds enough power to run complex software programmed in an interpreted language which is handled by runtime virtual machines, or just-in-time compiled. Particular to Windows programmers, the announcement of MS-Windows Vista's system requirements means that future Windows boxes will laugh at the memory/processor requirements of current interpreted/JIT compiled languages (e.g. .NET, Java , Python, and others). Regardless of the negligible performance hit compared to native code, major software houses, as well as a lot of open-source developers, prefer native code for major projects even though interpreted languages are easier to port cross-platform, often have a shorter development time, and are just as powerful as languages that generate native code. What does the Slashdot community think of the current state of interpreted/JIT compiled languages? Is it time to jump in the boat of interpreted/JIT compiled languages? Do programmers feel that they are losing - an arguably needed low-level - control when they do interpreted languages? What would we be losing besides more gray hair?"
BASIC had its problems, warping a generation of programmers (including me), but it was small and light and didn't take long to learn unless you wanted to enough find tricks to get real work done.
FORTH was smaller, lighter, and faster. It was overly self-important, considering its reinvention of the subroutine to something new and radical, but if you wanted to program toasters or telescopes it was the language to use. Postscript was somewhat of a Forth derivative.
P-Code was a nice portable little VM you could implement other things on.
And then there was Java, which grew out of Gosling's experiences with NeWS, a Postscript-based windowing system. If you wonder why you're not using Netscape and maybe not using Java, and why you've probably got Windows underneath your Mozilla, it's because it became obvious to lots of people that Netscape+Java was a sufficiently powerful and easily ported environment that the operating system underneath could become nearly irrelevant - so Microsoft had to go build a non-standards-compliant browser and wonky Java implementation and start working on .NET to kill off the threat. It wasn't that conquering the market for free browsers was a big moneymaker - it was self-defense to make sure that free browsers didn't conquer the OS market, allowing Windows+Intel to be replaced by Linux/BSD/QNX/MacOS/OS9/SunOS/etc.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
One of the neat things was te 4k graphics demo contests - try to write the most impressive graphics demo with only 4k of assembler. There was a LOT of code writing code in memory, code using other code that had already run as raw data for designing the next iteration, then using it again as code ... a 4k program that could take you through a 3-dimensional roller coster ride for 20 minutes, never repeating, all done in real time, on hardware that you wouldn't deign to pick out of the scrap heap.
Well, that sort of compiler is sort of the holy grail of pure functional languages. The idea goes something like this:
..., and has no side effects (print statements, assignment to mutable state, etc.).
Forget your C/C++/Java/whatever. Side effects and multiple assignment are bad. Program in a pure functional language, such that all functions are referentially transparent---that is, f(x1,x2,...) always returns the same value given the same x1, x2,
Now, since most of your code is made up of referentially transparent functions, the compiler can automatically split independent pieces of code up, and perform them in parallel without fear that a call to b(x) somehow effects the results of c(y).
When you absolutely need side effects (for IO, for example), you use something (uniqueness types, monads; I'm guessing) that explicitly orders the code and in this case, would presumably prevent the compiler from parallelizing it.
Compilers aren't there yet. The things I'm (vaguely) familiar with require specific annotation of potentially parallel paths. Try Occam, for instance. Another example I've read only slightly more about is parallel Haskell, which includes similar annotation primitives (par and seq). However, just because you annotate something as parallel doesn't mean it will be performed in parallel. The compiler/runtime/I'm-not-sure-which decides what to run in parallel from among the massive potential of parallelism in such a program.
If you're asking how it's possible in Java: it isn't. But then, Java already sucks when it comes to concurrency compared to systems designed for it like, say, Erlang (which, incidentally, is VM interpreted, but still blows the pants off most conventional C/whatever programs within its application domain (massively concurrent/fault-tolerant systems), lending some credence to the point of this article, not that the same things necessarily couldn't be done with native code).
I've come for the woman, and your head.
I am a Pascal programmer from ancient days and have been pretty much a Delphi person on account of my Pascal affinity and other requirements, but I have implemented GUI apps in C++, C#, Java, Matlab, and VB. I am seriously looking at Java/Swing as the next wave of what started as DOS/Turbo Pascal and got reimplemented in Windows/Delphi. Java simply couldn't do in 1997 what I was doing even at that time in Windows, just plain couldn't from the standpoint of features and performances. Java is not-quite-there-yet with the features I use in Windows, but it is much farther along in 2006 than in 1997 and is closing the gap with graphics acceleration and other features. It may surpass Delphi for what I do if it proves to be easier to do multi-threaded apps to take advantage of multi-core.
While my complex data visualization stuff is a long way off from being done in Java, the sort of simple data visualization stuff that I was doing in 1997 under Windows works quite well under Java, and it works equally well under Linux. If anything will get me to switch to Linux it will be that I have a collection of graphical data visualiztion programs for the work I do written in Java that will work equally well under Linux. While I can write a faster program with more features in Windows, the Java implementation is proving good enough for a lot of stuff that I am doing and it breaks me loose from Windows as well.
SUN seems to be in this Java business for the long haul, seemingly spinning their wheels making it available for free and always being a step behind Windows in features. But at some point Java/Swing programs will have accumulated enough performance and features that they are good enough for what people want to do, and they have the added advantage of not being tied to Windows. This idea that something like Java could transcend the OS may yet happen for client GUI apps.
Hmm.. as well. I worked on a team that developed a DB app that was nine PETABYTES and growing constantly. (Our little test database was 60 terabytes.) It will soon be one of the five largest databases in the world, and could extend into the exabyte range (you can guess who it's for.) We use Java and ASP.NET on the server and Java and an AJAX solution on the client. We throw shitloads of big boxes at it and we don't give a damn, because it works. Do not get me started on how analytically complex the algorthms are that use that data...
I don't trust atoms -- they make up stuff.
If your native code is running as slow as interpreted, I would really recommend getting that looked at.
The question you have to ask, of course, is where is the bottleneck. And the answer is fairly obvious if you analyse the performance of modern applications on a variety of different hardware: IO is the bottleneck in almost every case. There's no other explanation for why my 400MHz desktop (with a nice, fast hard disk) performs as well as or better than my 1.7GHz laptop (with a slow, energy saving hard disk but otherwise similar specs) for many applications (including Firefox, OpenOffice, etc... the kind of things that the average user runs daily) while the laptop wipes the floor with it for others (media players, SketchUp).
The point is, if you're going to be waiting 50ms for disk access, why bother shaving 2ms of processing time by running in a native compiled language? Nobody will ever notice. And you may find the more modern and high-level design of the interpreted language's library allows you to write faster performing IO code more easily than the simple & low level libraries that are supplied with most compiled languages, at which point you may get better results for the same programming effort for using that language.
In the end, fast programs are about good design, not language choice. Higher level languages often allow you to spend more time on design and less on implementation. All real-world projects have a limited time scale; ISVs just try to do the best they can with the time they have available, which isn't usually producing something miraculous.