faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Native code FUD
by Tim Jansen on Sunday 08/Aug/2004, @15:39
|
>> - check whether code is secure / run it in a sandbox
>These are features that must be built in the OS, not in the
>programming language or the VM.
Java implements it in the VM without any help from the OS...
>> - run the same binary on multiple CPU architectures
> This is made possible by building multiple personalities
> in the CPU. Furthermore, if you can run a JIT compiler you
> can translate the code from a reference architecture to
> another on the fly.
As I said, it is possible (WinNT did this to run x86 software on Alphas), it is just less work to translate from an intermediate language like IL or Java's.
> - manipulate the code (optimize, analyze etc)
> This can be done with native code even better.
I doubt that. It's extremely hard to have any automatic optimizations on assembly code like x86. First of all, assembly has more instructions do deal with, and in x86 they are not exactly nice. With native code you have much more knowledge about the program's intentions. You know which method is virtual (and thus could be converted into a non-virtual), you can easily see where is mutex is acquired (all modifications without this knowledge can be pretty dangerous) and so on. In many cases you probably need to convert the assembly code back to an intermediate language anyway, because it's hard to modify code with a limited number of registers.
And then, even if you manage all this, you also have the problem that your code will be very platform specific and is useless on other architectures.
>>People should spend more time improving the OS instead of trying to reinvent an OS on top of the OS.<<
Basically I agree with that, but Linux in today's form is pretty useless in this respect. It just lacks infrastructure for too many things that would be needed. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Native code FUD
by tbscope on Sunday 08/Aug/2004, @16:49
|
Hmmm,
Every line of code, that is run on a system is native.
Otherwise, it would not run.
Or am I wrong here?
(I assume that if the cpu contains emulators that the emulated code is native too, as that's in the cpu, so I understand with native, something the cpu understands).
Your JIT compiler compiles the program to native code.
It might do it in a different way than a "static" compiler.
Quote:
"And then, even if you manage all this, you also have the problem that your code will be very platform specific and is useless on other architectures."
The same with JIT. When it's compiled, it's platform specific.
JIT compiling is good for small programs, not for large ones (in my opinion).
I don't think my PII 233MHz would like "office"-size JIT compiled programs.
And I've heard stories, although I can't confirm them, or know if they are true, that the garbage collector etc... sometimes delete the wrong objects, or think they can delete them.
I've always found that garbage collection is something for people who do not know how to program (personal opinion, although I understand it's faster to code with). I prefer using profiling and debugging tools to analyse my programs.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Tim Jansen on Sunday 08/Aug/2004, @17:43
|
"Every line of code, that is run on a system is native. Otherwise, it would not run."
The main difference is in which form the code is distributed, and which kind(s) of code are stored at disk.
With native code you distribute and store code that's optimized to run on the CPU with as few modifications as possible (usually you still need to link before actually running).
'Managed code', byte code, IL and whatever they are called are optimized for other purposes. For example for being easy to translate to a variety of CPU architectures, for being secure (programs can only access their own memory), for being easy to manipulate, for being small, and so on. Not necessary all of them at the same time, depending on the designer's goals.
"The same with JIT. When it's compiled, it's platform specific."
Yes, but you can rely on having the byte code available. This byte code is the same on every platform, so you can manipulate the program in a platform-independent way, even if the runtime later changes turns it into native code.
"JIT compiling is good for small programs, not for large ones (in my opinion).
I don't think my PII 233MHz would like "office"-size JIT compiled programs."
Compilation results can be cached though.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Leo Spalteholz on Monday 09/Aug/2004, @11:04
|
<i>Compilation results can be cached though.</i>
You've said this a few times, so if it can be cached, why isn't it? Apparently it's not as easy as you believe.
I think you can argue all you want about how managed code is/can be just as fast or faster than native code, but the fact is: it isn't. Perhaps it's possible to code a program in Java/C# that's just as fast as the same one in C++, but in practice, this doesn't happen. Off the top of my head, the non-trivial java apps that I use or have used:
Eclipse. Useable, but still very slow.
Azureus (java bittorrent client): Painfully slow
Freenet. (java) Huge memory hog, takes forever to start up.
Frost (java freenet client) Same as above, almost unuseable on a 256MB RAM machine.
I've had some better experiences with C# apps but still nothing close to native speed.
Theoretically, managed code may be just as fast, but realistically, with today's major platforms, it isn't. And you can't get around that reality with words.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Tim Jansen on Monday 09/Aug/2004, @11:59
|
"I think you can argue all you want about how managed code is/can be just as fast or faster than native code, but the fact is: it isn't."
Give it some time. C# is still very new. Java already made a lot of progress from it's early beginnings, but they started with an interpreter and Java is not exactly a language that has been designed with performance in mind.
I never claimed that managed code is faster today. I just complained about the statement that native code will be faster and whatnot for eternity.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Leo Spalteholz on Monday 09/Aug/2004, @12:06
|
True. I misread your original post a bit.
In any case, I think eventually it will become a moot point.
If I can implement features much faster in a mangaged language than in a static one then I can certainly live with the end result being a bit slower. Current average hardware isn't quite at the point where we can do this everywhere but it will be. Just like the transition from assembly to C to C++. The trend is towards languages that allow faster programming at the expense of some speed.
Maybe in 50 years I'll be coding in C##++ on a PIC :)
|
[
Reply To This | View ]
|
|
Re: Native code FUD
by Gian Filippo Pinzari on Sunday 08/Aug/2004, @17:12
|
> Java implements it in the VM without any help from the OS...
That's the problem. It's the wrong place.
> it is just less work to translate from an intermediate language
Every language is an intermediate language, to some
extent. It is the VM idea that is useless, not the idea that
the code produced by the compiler can be optimized on the
fly for the target architecture or the target CPU.
> Linux in today's form is pretty useless in this respect
I completely agree. That's sounds like a good reason for
improving it.
The main motivation for building VMs it to run code on a
wide-spread architecture and OS without writing that code
for the specific OS and, most importantly, its API. It is a
good motivation, I think, but is not going to last once you
have the same code running on that architecture and that
OS natively.
Soon we'll see Microsoft Windows running native Linux
programs and Linux running native Windows programs. The
platform that will win will be the platform that offers
the better facilities for running those programs securely,
with the best scalability and the best manageability.
There is an alternative, though. Somebody comes with a new
computing architecture that requires programs to be written
for a new API or a new programming language. Who controls
the API, again, controls the platform. It is not a matter
of having the best OS anymore. It becomes a matter of having
the vast user-base required to impose the API. The idea is
very good, it it works.
/Gian Filippo.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
