The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Native code FUD
by David on Sunday 08/Aug/2004, @14:06
|
"That's FUD. First of all, in theory there is no difference in performance between native code and managed code."
Please tell me that's some sort of joke. First of all, a managed environment has not been proven simply because major things have not been re-written in one. Once a whole desktop is re-written with a managed environment and it performs acceptably then we'll know. As it is, that hasn't happened and not even Microsoft is going to re-write Windows for the CLR - although of course, there will be 'seamless' interfaces so no one notices :).
As we have seen with various benchmarks, managed code can be fast. However, once you start running everything through it and have six or seven applications open at the same time, all targetted for managed code, that is somewhat different. That's where Java has been found wanting over the years. Because of garbage collection, and the overhead of the managed environment itself, it is always going to consume more resources than native code.
For providing an environment for desktop applications that are easier to develop for, easier to debug (potentially) and work with, managed code is certainly a plus. However, in terms of a system as a whole you're just never going to get managed code everywhere (and Microsoft will certainly never achieve it). Managed code will not win, but it will be useful for some tasks.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Tim Jansen on Sunday 08/Aug/2004, @14:47
|
"First of all, a managed environment has not been proven simply because major things have not been re-written in one. Once a whole desktop is re-written with a managed environment and it performs acceptably then we'll know."
You don't have to. There's simply not a single optimization that native code can do and managed code can't. (I didn't doubt that implementing a managed code runtime is more work)
"Because of garbage collection, and the overhead of the managed environment itself, it is always going to consume more resources than native code."
Gargage collection has nothing to do with managed/native code, you can have managed code without (There are C compilers for IL). GC a language issue.
"For providing an environment for desktop applications that are easier to develop for, easier to debug (potentially) and work with, managed code is certainly a plus."
No, these are no advantages of managed code. I would even doubt that the programmer has to notice the difference. The reason why developing with Java or .Net is nicer than with gcc is just the age and history of make, gcc and the whole unix build system. Advantages of managed code are that it is usually much easier to
- check whether code is secure / run it in a sandbox
- run the same binary on multiple CPU architectures
- manipulate the code (optimize, analyze etc)
Note that all this is possible with native code, it's just more difficult for the developer of the system.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Gian Filippo Pinzari on Sunday 08/Aug/2004, @15:15
|
> - 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.
> - 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.
> - manipulate the code (optimize, analyze etc)
This can be done with native code even better.
There is no need for virtual machines and 'managed code'
when you have the OS and the computing architecture handling
all this stuff.
People should spend more time improving the OS instead of
trying to reinvent an OS on top of the OS.
/Gian Filippo.
|
[
Reply To This | View ]
|
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.
|
[
Reply To This | View ]
|
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 ]
|
|
Re: Native code FUD
by Rayiner Hashem on Sunday 08/Aug/2004, @15:30
|
<i>Dynamic compilers do not have such boundaries for optimization. All code is equal for them, because all code is stored in the prefered way for optimization.</i>
Good static compilers have no such boundries either --- LLVM will do inter-library optimization at link time. Also, java or CLR bytecodes are a terrible representation for optimization. Before doing any optimzation on CLR code, Mono first converts it from the stack-oriented CLR model to a virtual-register oriented SSA form.
<i>For example the JavaVM checks whether a virtual method is actually overridden by a class.</i>
Static compilers do this too. For high-performance native compilers for Lisp or Smalltalk, such optimzations are standard operating procedure.
<i>A static compiler can't do optimizations like this, it always has to optimize for the worst case.</i>
No it doesn't. The capability to do optimization in the precense of dynamic code has nothing to do with native code and everything to do with having a compiler available at runtime. Static compilers for Lisp can do these sorts of optimizations, even though they generate native code.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Tim Jansen on Sunday 08/Aug/2004, @15:46
|
"Good static compilers have no such boundries either --- LLVM will do inter-library optimization at link time."
Hmm? I don't know LLVM very well, but I'd call LLVM a dynamic compiler with managed code (their virtual instruction set).
"<i>A static compiler can't do optimizations like this, it always has to optimize for the worst case.</i>
No it doesn't. The capability to do optimization in the precense of dynamic code has nothing to do with native code and everything to do with having a compiler available at runtime."
If they can compile at runtime, I would call them dynamic compilers with managed code. The only difference may be that they don't use an intermediate language, but work directly on the source code.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Rayiner Hashem on Sunday 08/Aug/2004, @18:19
|
"Managed code" and "native code" have rather precise definitions. Managed code is stored as an abstract bytecode, and compiled *on-the-fly* to machine code. Native code is stored as machine code, and executed directly. JIT's and compilers available at runtime blur the lines, but the fundemental distinction is still that JIT's compile on the fly by default, and cache native code as an optimization, while native compilers use native code by default, but make it possible to regenerate that code. Certainly, using the accepted definitions of "native code compiler" and "managed code compiler," Java/C# are managed code platforms, while LLVM/CMUCL/etc are native code platforms.
|
[
Reply To This | View ]
|
|
Re: Native code FUD
by Matthias Ettrich on Sunday 08/Aug/2004, @17:46
|
Performance and memory consumption is not only a matter of the instruction set and how the runtime system executes it, but depends largely on data structures, the object model itself and on what kind of APIs and programming style the programming languages in use imply or encourage. This is not about static versus dynamic compiler optimizations techniques or the benefits of having another layer on top of the CPU's instruction set. This is about comparing how developers today write native applications on both Microsoft Windows and Linux, and how they write Java or .NET applications. So I could have said "C/C++" instead of "native code".
C++ does not necessarily mean speed, even if the language makes it harder to write slow programs. Just imagine a C++ programming style where all functions and inheritances are virtual, all classes inherit from a common base class that does central object registration, all objects are always allocated on the heap and every single pointer or array access is checked beforehand. If you then create an API that encourages the creation of massive amounts of small objects that call into each other through listener interfaces, and requires dynamically checked type casts to narrow objects, then you would not end up with the speed we see with Qt and KDE today, and for that matter any other well written C/C++ software.
What makes C++ code so fast is not only that the CPU understands the assembly directly, at least not exclusively. Most of its speed stems from the powerful language. It's good when a JIT compiler can optimize function calls, but it's better if you don't even need a function call. It's good when an allocator is really fast when allocating small objects, but it's better if you don't have to allocate anything at all. And so on.
This is why C++ is here to stay, on both Microsoft Windows and on Linux.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Richard Dale on Sunday 08/Aug/2004, @21:33
|
"Just imagine a C++ programming style where all functions and inheritances are virtual, all classes inherit from a common base class that does central object registration, all objects are always allocated on the heap and every single pointer or array access is checked beforehand"
Well I've used Objective-C/OpenStep (ie Apple Cocoa) a lot. It was easily fast enough 10 years ago, and it certainly is now. In Objective-C every method is effectively virtual, including the equivalent of 'static' methods. All classes inherit from NSObject, and the NSArray class doesn't allow you to drop off the end and crash. All Objective-C instances are allocated on the heap.
"If you then create an API that encourages the creation of massive amounts of small objects that call into each other through listener interfaces, and requires dynamically checked type casts to narrow objects, then you would not end up with the speed we see with Qt and KDE today"
This is where Objective-C diverges from the java approach. In Cocoa there are many fewer instances required to do something, and the inheritance heirachies are flatter. You can use delegation or categories (ie dynamically adding/changing methods to running instances) where you would need to subclass in java. Listener interfaces are a design disaster as they ignore the dynamic reflection possibilities in java. Qt takes a static language and makes it more dynamic via the moc and signals/slots, while Swing java takes a dynamic language and implements a clunky api based entirely on static typing.
I'm fussy and I don't like a lot of software, but I really think Qt/KDE is the best application framework since NeXTStep (especially with the KDE 3.3 ruby bindings).
|
[
Reply To This | View ]
|
Re: Native code FUD
by Tim Jansen on Monday 09/Aug/2004, @00:38
|
"All Objective-C instances are allocated on the heap."
BTW this is not strictly necessary in Objective-C, and neither in Java or C#. They could use stack-allocation for many short-lived objects. It would require more/better analysis of the code though, to determine for which objects it is possible.
(Similarly all the other performance problems listed by Matthias can be solved by more intelligent compilers - we're just not there yet)
|
[
Reply To This | View ]
|
Re: Native code FUD
by Richard Dale on Monday 09/Aug/2004, @00:50
|
"BTW this is not strictly necessary in Objective-C,"
It isn't possible in Objective-C - you create an instance by messaging a class object, and then sending an initialization message to the new instance. Only string literals of the form @"mystring" can be statically allocated
Instances are allocated in 'autorelease pools'. You can create you're own autorelease pools, and you would do that if you have a lot of short lived objects.
C# already allows to allocate short lived objects on the stack.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Rayiner Hashem on Monday 09/Aug/2004, @08:09
|
Lot's of compilers are already at that point. Stalin, CMUCL, d2c, Bigoo, etc, all do these sorts of optimizations. It's just something that hasn't come to C# and Java compilers yet (and will never come to C/C++ compilers, because of their semantics).
|
[
Reply To This | View ]
|
Re: Native code FUD
by lypanov on Thursday 12/Aug/2004, @07:53
|
umm i very much doubt this...
c is here to stay. but c++ i doubt.
dynamic optimisation is not possible
without a jitting mechanism and a
language that doesn't overspecify.
good jit compiler do inlines of
the methods based on execution
profiling. the best c++ compiler
can only guess. and slowly at
that. sure with profile feedback
it can do much better. but still
nowhere near perfect.
also its because of the
overspecification of interfaces
in c++ that we don't see automatic
removal of virtual keywords based
on profiling / path analysis
same goes for the need to
explicitly use zone allocators
rather than have the runtime
figure it out at er.. yeah
runtime :)
Alex
|
[
Reply To This | View ]
|
Re: Native code FUD
by Richard Dale on Thursday 12/Aug/2004, @17:06
|
"c is here to stay. but c++ i doubt.
dynamic optimisation is not possible
without a jitting mechanism and a
language that doesn't overspecify.
good jit compiler do inlines of
the methods based on execution
profiling. the best c++ compiler
can only guess. and slowly at
that. sure with profile feedback
it can do much better. but still
nowhere near perfect."
I think you've lost the plot here. Which is most important - a gui framework based on a more expressive dynamic language such as ruby, or a statically compiled language which is a bit faster at runtime because of jit compilation? And should a toolkit be written in the same language that end users will program it in?
Which gui toolkits are so awesome that they just need a bit of jit'ing to make them perfect? MFC, Swing, WinForms, Delphi, Taligent, WxWidgets, GTK+, GTK#. To me they're all just a bunch of dogs compared with Cocoa or Qt/KDE.
C# is a complex systems programming language (as a systems programmer I find it fun), but it is most certainly not a RAD language that everyday programmers will feel comfortable with. Ruby doesn't have jit'ing, but does anyone care, it's just much easier to get stuff done with ruby (or python) than C# or java or C++. Why can't we talk about the programming language usability vs. efficiency tradeoff? The Qt toolkit will never be as popular as it should be while it is C++ specific - a jit'ed C# version wouldn't solve that problem at all.
|
[
Reply To This | View ]
|
|
Re: Native code FUD
by Mike Hearn on Monday 09/Aug/2004, @02:11
|
The other problem with JITing runtimes tends to be memory pressure, which impacts desktop performance far more than CPU overhead these days.
I think most of the advantages of JIT compiled code are bogus. Security is not to me a convincing argument as the only security you gain is via type-checking, which is not fine grained enough for real world security. For instance you can prove the code does not use the File object, but you cannot restrict which files it can access and when (at least, not without seriously hacking the class library sources itself). A worse-is-better approach seems to be an SELinux style one, where security is applied at the process level rather than the type level, but policy is easier to specify and more flexible.
CPU independence - please. The CPU is already abstracted by the compiler, no need to do it twice given the dominance of x86 (on the desktop, it may be more useful on the server).
Easier to examine the code: well, there is no rule that says you cannot have reflective native code, and indeed gcj/java does exactly this.
I don't have a strong opinion on Java vs Mono, but right now it seems they are evenly matched. Mono has the community momentum and nicer APIs (at least for GTK developers) but GCJ has a more traditional toolchain and produces native code that is easily integrated with existing systems. It also seems to have easier integration with native code via the CNI and the upcoming GDirect thing (similar to P/Invoke). I do not know which will "win", but I suspect they will both be strong. Right now Mono seems to be in the lead if only because there aren't any "real" desktop Java apps outside Eclipse that are in wide use on Linux.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Philippe Fremy on Monday 09/Aug/2004, @03:04
|
I don't have an opinion on this Java vs Mono but somehow, seing the debate reminds me a bit of the java momentum, when java was supposed to replace everything and of the orbit vs dcop/kpart debate too.
We sure like to have heated discussion with technical arguments...
|
[
Reply To This | View ]
|
Re: Native code FUD
by Tim Jansen on Monday 09/Aug/2004, @09:37
|
"The other problem with JITing runtimes tends to be memory pressure, which
impacts desktop performance far more than CPU overhead these days."
These problems can easily eliminated by caching the results. The advantage is
that you can do best-case optimizations that a static compiler can't afford, - if the worst-case happens a dynamic compiler can still recompile at runtime. But that doesnt mean that it needs to happen frequently.
"I think most of the advantages of JIT compiled code are bogus. Security is not to me a convincing argument as the only security you gain is via type-checking, which is not fine grained enough for real world security. "
There are two things that you need for Java-like sandboxing:
1. you need to integrate security checks in all libraries that communicate with the world outside of the process/VM and should be used by the sandbox'd code
2. you need to make sure that the only way to access any part of the system is using the public APIs
With native code, number 2 becomes very hard.
"For instance you can prove the code does not use the File object, but you cannot restrict which files it can access and when (at least, not without seriously hacking the class library sources itself)."
Java allows this:
http://java.sun.com/j2se/1.4.2/docs/api/java/io/FilePermission.html
"A worse-is-better approach seems to be an SELinux style one, where security is applied at the process level rather than the type level, but policy is easier to specify and more flexible."
This allows only very low-level security. For example Java allows that applets in a sandbox can create windows, but only if the window has a large warning sign. Try enforcing that with SELinux.
"CPU independence - please. The CPU is already abstracted by the compiler, no
need to do it twice given the dominance of x86 (on the desktop, it may be
more useful on the server)."
Even if there would be only x86, there are already more than enough variants through extensions. 32-bit and 64-bit, MMX, 3DNow, SSE, SSE2...
Managed code also has the advantage that it will give x86 CPU vendors more room for improvement. Right now they have the problem that even if they come up with a good (low-level) extension, there will hardly any software that makes use of it.
"Easier to examine the code: well, there is no rule that says you cannot have reflective native code, and indeed gcj/java does exactly this."
That's examining at runtime and not what I meant. I was talking about analysing and modifying programs that are stored on the disk in their distribution format.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Mike Hearn on Wednesday 11/Aug/2004, @05:16
|
Yes, you can enforce such windowing policies with SELinux (or more accurately the in-development SE-X). SELinux policy can be propogated up into userspace object managers.
As to the other points, well maybe but I've not seen much software that would benefit from such on the fly optimization. Algorithmic optimization usually matters far more.
|
[
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)
