faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
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. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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 ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
