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?"
> When your web-based-datastore gets 50,000 inserts per second, hovers between 15 and 20 billion rows and endures a sustained query rate
> of 43,000 queries per hour, tell me which part of it you want to coded in PHP.
hmm, the warehouse I work on has multiple databases with billions of rows in them, can hit insert rates of 100,000 rows a second, can experience 60,000 queries/hour - many of which are trending data over 13 months, has hundreds of users. Many of these users are allowed to directly hit some of the databases with whatever query tool they want. Scans of a hundred million rows at a time aren't uncommon (though seldom happen more than a few dozen times a day).
This app is completely written in korn shell, python, php and sql (db2). Looks like Ruby is also coming into the picture now, will probably supplant much of the php in order to improve manageablity.
Oh yeah, and the frequency of releases is quick and it's defect rate is low. And we're planning to begin adding over 400 million events a day soon. I've done similar projects in C and java. Never anywhere near as successfully as in python and php.
We might consider rewriting a few select python classes in c. Maybe, if we port the ETL over to the Power5 architecture with psycho doesn't run. Otherwise, it's cheaper to just buy more hardware at this point - since each ETL server can handle about 3 billion rows of data/day with our python programs.
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.
Your argument actually points out how much *more* valuable interpreted and JIT languages will get. Are you going to compile new binaries for every architecture and combination of cores? Or, are you going to encode the logic of the application and have your JIT figure out how to optimize for the specific platform. Before you say that JITs cannot hack this, remember that they use exactly the same technology as your 'standard' compilers.
Secondly, if it is a question of taking too long to compile, realize that you can always ship optimized binaries from high-level languages (e.g. GCJ), but you cannot readily make your optimized native code work on a new platform.
You forgot high performance computing (ie supercomputing) environments, where electrical costs are measured in dollars per minute (and the job takes weeks).
.Net. Nor will Ruby on Rails. It's the same old song, covered by some fresh new 'hip' band.
There are plenty of cases where it is far more cost effective to pay somebody $10k/week to optimize the hell out of a piece of code, because a 1% optimization will save thousands of dollars over the course of a year. The market for supercomputing applications is growing substantially. It's quite frequently cheaper to prototype in a supercomputer than it is to do something 'in the real world.'
I always laugh when I see people point out benchmarks where Java is compared to C in terms of the Linpack benchmark -- entirely ignoring the fact that in both cases, the actual 'work' is being done in neither Java nor C, but in a BLAS library that is written in Fortran. It's hardly suprising they have similar speeds -- they're running the exact same routines, from the exact same Fortran library.
The thing I see is this: The market for interpreted languages is fairly static -- I remember playing simple games written in BASIC on my parent's Apple II. I recall word processors, education software, etc -- all written in interpreted languages.
The region of 'corner cases' where native-compiled code is substantially faster than interpreted languages hasn't changed significantly over my lifetime. High performance games were, are, and will remain native-compiled code for the forseeable future. The same applies to supercomputing. Embedded machines are also a bastion of native code -- simply because they are produced on a scale that favors code written natively-- the tradeoff being more expensive hardware, and the economics never work out such that software (including its one-time development cost) is cheaper than hardware.
There's nothing wrong with either; they are tools, to be used appropriately. Being a rabid fanboy (or hater) of either only proves one is willfully ignorant of reality. Fifteen years ago, an interpreted language kept many of the world's largest mainframes running -- it wasn't Java, it was BASIC (or one of quite a few other interpreted languages).
The languages used may have changed, but the amount of (and use cases for) interpreted vs. native code hasn't changed that much over the decades. Shiny-new Java didn't change it, neither did
Don't think for a second that interpreted languages are taking over; or that they're losing ground. The more things change, the more they stay the same.
-- Sometimes you have to turn the lights off in order to see.
The problem isn't native-code vs interpretive code. It's that our native code languages are terribly flawed.
Programming backed itself into a corner with C and C++. They're useful languages, but they're not safe. Now this has nothing to do with performance; you can have safety in a hard-compiled language. Ada, the Modula family, and the Pascal/Delphi family did it. The problem is that, because of some bad design decisions in C (the equivalence of arrays and pointers being the big one), you have to lie to the language to get anything done. This makes safety hopeless. The basic problem of C is that you have to obsess on "who owns what" for memory allocation purposes, and the language gives you no help with this. The language doesn't even adequately address "how big is this". With those two design defects, we're doomed to have memory safety problems. Which we do.
C++ at first seemed like an improvement, but as it turned out, C++ adds hiding to C without improving safety. Note that this seems to be unique to C++; no prior language did that, and no language since has taken that route. Attempts have been made to work around the problem within the structure of C++, but with limited success. The "auto_ptr" debacle and the endless problems of trying to make sound reference-counted allocation work reliably indicate the fundamental limitations of the language. You just can't fix those problems in C++ without breaking backwards compatibility. (See my postings in comp.std.c++ over the last decade for more details on this.)
Java was invented mostly to get around the memory safety problems of C and C++. The fact that Java is usually semi-interpretive has nothing to do with the language design; that's a consequence of Sun's original focus on applets. There are native-code compilers for Java; GCC contains one. There are competitive advantages of locking the user into a giant environment (J2EE in the Java world, .NET in the Microsoft world), which is part of why we're seeing so much of that. But it's not a language design issue.
Microsoft came up with C# as their answer to Java, and most of the same issues as with Java apply.
What's so embarassing about all this is that it's quite fixable. The solutions were known twenty years ago. If you have a language where the language knows how big everything is, and the subscript checks are hoisted out of loops at compile time, you get safety with high performance. There were Pascal compilers that got this right in the 1980s.
On the allocation front, you can use either garbage collection or reference counting to automate that process. Java and C# are garbage-collected; Perl and Python are reference-counted, and in practice, programmers in those languages seldom have to think about memory allocation issues. Allocation overhead can also be hoisted out of loops. Java compilers are starting to do this, allocating temporary variables on the stack. Reference count updates can be optimized similarly. There's nothing to prevent using these techniques in a native-code compiler.
And that's how we got to where we are today, with buffer overflows, zombies, and blue screens of death, papered over with a layer of inefficient interpreters. Fortunately the hardware people have held up their end and made it possible to live with this, but we on the software side should have the understanding and grace to be embarassed by it.
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.
One guess where 99% of the ccycles arae in that
I'll take a guess! And it's even the one you want me to guess. The db2 instance. That's the fucking *point*. The fast C code that's executing has already been written.. some of it is in the python interpreter, some it is in the ksh and php interpreters, most of it is in the db2 interpreter. Very fast algorithms doing what they do best: optimized, super fast loops operating on static types.
That is WHY python and other interpreted languages achieve the speed they achieve.. because what they do is allow you to glue together C code written by other people. And, because the Python code is much simpler, you can understand the interactions between the fast code more easily, and see where your code fails to perform well. It's always because you're putting loops together inefficiently and making poor design choices, not because of the speed of the interpreter--and now that your code is short enough for you to see that, you can fix it.
Your application logic doesn't need to be super fast. It needs to be super agile, so you can refactor and accommodate changing requirements and make smart decisions about which pieces you are going to use and how you are going to use them together.
C won't die, at least, not for a long, long time*, and that doesn't bother me, a hardcore Python programmer, in the least. Somebody has to do the dirty job of writing those fast loops. Meanwhile I'll be here zipping through the application implementation.
*It will eventually be replaced by Pyrex, of course.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
The European Commission has just announced an agreement
whereby English will be the official language of the EU rather than
German which was the other possibility. As part of the negotiations,
Her Majesty's Government conceded that English spelling had some
room for improvement and has accepted a 5 year phase-in plan that
would be known as "Euro-English".
In the first year, "s" will replace the soft "c". Sertainly, this will make the
sivil servants jump with joy. The hard "c" will be dropped in favour of
the"k". This should klear up konfusion and keyboards kan have 1 less
letter.
There will be growing publik enthusiasm in the sekond year, when the
troublesome "ph" will be replaced with "f". This will make words like
"fotograf" 20% shorter.
In the 3rd year, publik akseptanse of the new spelling kan be
ekspekted to reach the stage where more komplikated changes are
possible. Governments will enkorage the removal of double letters,
which have always ben a deterent to akurate speling. Also, al wil agre
that the horible mes of the silent "e"s in the language is disgraseful,
and they should go away.
By the fourth year, peopl wil be reseptiv to steps such as replasing "th"
with "z" and "w" with "v". During ze fifz year, ze unesesary "o" kan be
dropd from vords kontaining "ou" and similar changes vud of kors be
aplid to ozer kombinations of leters.
After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no mor
trubl or difikultis and evrivun vil find it ezi to understand ech ozer. Ze
drem vil finali kum tru!
617B3B7F7E7C7D7F00EOF