Interpreted code? No thank you...
-
Hi, I am just thinking now, and wondering what are the advantages and disadvantages of the interpreted code (e.g. Java, .NET etc). Because if you will talk about platform transparency, I think it is some issue, but mostly it looks like to me like these 'offroad' cars, which are not good even for roads neither for country. Also I think, that if you design your system as a multiplatform, you cannot use the benefits of the platforms you are focusing - you can use only the smallest subset of functions available on all platforms. And I cannot find another reason for using interpreted code than for this multiplatforming. So maybe you know some.
-
Hi, I am just thinking now, and wondering what are the advantages and disadvantages of the interpreted code (e.g. Java, .NET etc). Because if you will talk about platform transparency, I think it is some issue, but mostly it looks like to me like these 'offroad' cars, which are not good even for roads neither for country. Also I think, that if you design your system as a multiplatform, you cannot use the benefits of the platforms you are focusing - you can use only the smallest subset of functions available on all platforms. And I cannot find another reason for using interpreted code than for this multiplatforming. So maybe you know some.
geo_m wrote: I am just thinking now, and wondering what are the advantages and disadvantages of the interpreted code (e.g. Java, .NET etc). You are making a mistake here. Contraty to Java bytecodes, .NET IL is NEVER run interpreted. The .NET introduces a concept where the final steps of compilation and optimization are run in the user machine, not in the developer's one. It's similar to a JIT, but the JIT is run when the program ("assembly" in .NET terminology) is loaded. So, your C# executable code is NEVER interpreted, it's always run in native code. I see dumb people
-
Hi, I am just thinking now, and wondering what are the advantages and disadvantages of the interpreted code (e.g. Java, .NET etc). Because if you will talk about platform transparency, I think it is some issue, but mostly it looks like to me like these 'offroad' cars, which are not good even for roads neither for country. Also I think, that if you design your system as a multiplatform, you cannot use the benefits of the platforms you are focusing - you can use only the smallest subset of functions available on all platforms. And I cannot find another reason for using interpreted code than for this multiplatforming. So maybe you know some.
geo_m wrote: So maybe you know some. Because we can? :rolleyes: I like your SUV soft-roader anology though.
Paul Watson
Bluegrass
Cape Town, South AfricaChristopher Duncan wrote: Which explains why when Santa asked, "And what do you want for Christmas, little boy?" I said, "A life." (Accesories sold separately)
-
geo_m wrote: I am just thinking now, and wondering what are the advantages and disadvantages of the interpreted code (e.g. Java, .NET etc). You are making a mistake here. Contraty to Java bytecodes, .NET IL is NEVER run interpreted. The .NET introduces a concept where the final steps of compilation and optimization are run in the user machine, not in the developer's one. It's similar to a JIT, but the JIT is run when the program ("assembly" in .NET terminology) is loaded. So, your C# executable code is NEVER interpreted, it's always run in native code. I see dumb people
Daniel Turini wrote: It's similar to a JIT, but the JIT is run when the program ("assembly" in .NET terminology) is loaded. How is this different from Java JITs? I thought the difference was that C# (I should probably say .NET) saved the compiled code for coming executions.. -- This space for rent.
-
Hi, I am just thinking now, and wondering what are the advantages and disadvantages of the interpreted code (e.g. Java, .NET etc). Because if you will talk about platform transparency, I think it is some issue, but mostly it looks like to me like these 'offroad' cars, which are not good even for roads neither for country. Also I think, that if you design your system as a multiplatform, you cannot use the benefits of the platforms you are focusing - you can use only the smallest subset of functions available on all platforms. And I cannot find another reason for using interpreted code than for this multiplatforming. So maybe you know some.
interpreted code advantages: "self-awareness", i.e. you can build a string containing code, and run it; the code brings it's own interface description, etc. Technically, this is possible with compiled code, too, but easier said than done. target platform specific optimizations (processor features, number of processors, size of cache and main memory, etc.) and, within limits, optimization goals (speed, workload, memory footprint) - especially when JIT'ed Debug, Reverse Engineer, and Code inject get technically easier. This is not always an advantage, but can be.
If I could find a souvenir / just to prove the world was here [sighist]
-
Hi, I am just thinking now, and wondering what are the advantages and disadvantages of the interpreted code (e.g. Java, .NET etc). Because if you will talk about platform transparency, I think it is some issue, but mostly it looks like to me like these 'offroad' cars, which are not good even for roads neither for country. Also I think, that if you design your system as a multiplatform, you cannot use the benefits of the platforms you are focusing - you can use only the smallest subset of functions available on all platforms. And I cannot find another reason for using interpreted code than for this multiplatforming. So maybe you know some.
If you develop your interpreted language around a feature set then any system that supports a feature directly will be used directly. Any system that does not implement a feature just needs that functionality provided by the interpreter. Smaller distribution size is another benefit of interpreted code. I was never a big fan of IL in the early VB days, but todays IL with JIT compiling provides more benefits with fewer drawbacks. I can tolerate it now. -- If it starts to make sense, you're in a cult.
-
Daniel Turini wrote: It's similar to a JIT, but the JIT is run when the program ("assembly" in .NET terminology) is loaded. How is this different from Java JITs? I thought the difference was that C# (I should probably say .NET) saved the compiled code for coming executions.. -- This space for rent.
Jörgen Sigvardsson wrote: How is this different from Java JITs? I thought the difference was that C# (I should probably say .NET) saved the compiled code for coming executions.. You're talking about the ngen.exe, which saves a JITted snapshot of the EXE or DLL (assembly). Contrary to Java, a .NET interpreter does not even exist on the .NET framework! The JIT is a VM specific optimization, you can never be sure if your code will run interpreted or native. Most Java JITters do not JIT a function until it has run a pre-determined number of times. This means you may never run your program at full speed. Under .NET (and assuming you never run ngen), your program will have a slower startup, but it will always run compiled and at full speed. I see dumb people
-
geo_m wrote: I am just thinking now, and wondering what are the advantages and disadvantages of the interpreted code (e.g. Java, .NET etc). You are making a mistake here. Contraty to Java bytecodes, .NET IL is NEVER run interpreted. The .NET introduces a concept where the final steps of compilation and optimization are run in the user machine, not in the developer's one. It's similar to a JIT, but the JIT is run when the program ("assembly" in .NET terminology) is loaded. So, your C# executable code is NEVER interpreted, it's always run in native code. I see dumb people
-
Jörgen Sigvardsson wrote: How is this different from Java JITs? I thought the difference was that C# (I should probably say .NET) saved the compiled code for coming executions.. You're talking about the ngen.exe, which saves a JITted snapshot of the EXE or DLL (assembly). Contrary to Java, a .NET interpreter does not even exist on the .NET framework! The JIT is a VM specific optimization, you can never be sure if your code will run interpreted or native. Most Java JITters do not JIT a function until it has run a pre-determined number of times. This means you may never run your program at full speed. Under .NET (and assuming you never run ngen), your program will have a slower startup, but it will always run compiled and at full speed. I see dumb people
So basically what you're saying is that .NET apps being JITed are compiled onload, as opposed to java which are JITed on the fly whenever it's gained enough statistics? Does ngen.exe work on all assemblies? Can I instruct the system to ngen assemblies automatically for me? Excure my ignorance, but I haven't really had the time to bury myself in the grotty details .NET just yet. So far I've just played with C# language a little. There might be an opportunity to do ASP.NET a bit later on though... Then I'll have all the excuses in the world to buy some .NET books (at the company's expense of course ;)) Daniel Turini wrote: I see dumb people I not only see them, I hear them too. I don't know which is worse; evil or dumb people. -- This space for rent.
-
So basically what you're saying is that .NET apps being JITed are compiled onload, as opposed to java which are JITed on the fly whenever it's gained enough statistics? Does ngen.exe work on all assemblies? Can I instruct the system to ngen assemblies automatically for me? Excure my ignorance, but I haven't really had the time to bury myself in the grotty details .NET just yet. So far I've just played with C# language a little. There might be an opportunity to do ASP.NET a bit later on though... Then I'll have all the excuses in the world to buy some .NET books (at the company's expense of course ;)) Daniel Turini wrote: I see dumb people I not only see them, I hear them too. I don't know which is worse; evil or dumb people. -- This space for rent.
Jörgen Sigvardsson wrote: So basically what you're saying is that .NET apps being JITed are compiled onload, as opposed to java which are JITed on the fly whenever it's gained enough statistics? Exactly. And I'm yet to see a so good JITter as the .NET's one. Even the Rotor's one is a very good one. If you don't know yet, Rotor is an open source .NET CLR made by Microsoft running on Windows, FreeBSD and Mac OS X. Some people hacked it so it compiles under Linux, too. When the first Java JITters started to be written, some people saw some design mistakes that were made when defining some Java bytecodes. So, since Java was not designed from the start with JIT in mind, some bytecodes are hard to be tightly optimized. The main design goal in Java bytecodes was small bytecode size (so applets loaded faster; this was a really important issue in the 14.4K modem days), small interpreter size (so it could be embedded) and fast interpretation (not fast JIT, do you see?) The inverse is not true with the .NET JIT. It's a much more modern design. If a assembly is 2K or 3K, it doesn't matter so much; the MS IL is actually very similar and fast to translate into a graph often made in the optimizing phase of a compiler; so, loading an assembly and optimizing it is very fast. And it was designed with Pentium 4, Athlon in mind. Processor scheduling and memory caches were taken account when designing the JIT and the GC. IMHO, the Java JVM design is starting to become obsolete, and it would be healthy if Sun made a review in some design decisions. Jörgen Sigvardsson wrote: Does ngen.exe work on all assemblies? Can I instruct the system to ngen assemblies automatically for me? Yes, it works. No, and often, it's not necessary nor efficient NGEN assemblies. Only in some cases, like the System.* namespaces, some heavily used libraries and command line utilities which potentially could be called several times in a row it would make a difference. As I've said, loading and optimizing an assembly is a extremely fast process. Actually, there are some poorly and some undocumented ways of timing this and, in Desktop Bob, a moderate size application, it is taking only 150ms. I see dumb people