VB Compiled or Interpreted?

[Pangloss]

VB has perfectly serviceable IF statements.

 

I think Klaynos has the best answer here so far.

[Pangloss]

You guys are such language snobs, picking on VB. Oh no, it doesn't do multi-line comments! Heaven forfend!

 

I doubt most people even know what partial interfaces or iterators are, much less have ever used them in code, but those are just about the ONLY differences between VB and C#. Both languages compile to the same Intermediary Language, then JIT-compile again at execution time, so all your high-fallutin' C# code looks *exactly* like that low-brow VB code after you smack the Build command.

 

Posers.

[doG]

Who are "you guys" and who even brought up C# except for you? BTW, Kant/Kash and TTCalc are not languages but ready made solutions for doing math.

[Pangloss]

Hey, I'm not the one who answered a question about VB with "use a different language cuz VB sucks". I'm just pointing out that there seem to be a lot of misconceptions about VB, how it works, and what it's capable of -- it's a perfectly valid language that's every bit as capable as any other modern OOP language.

 

Misconceptions get straightened out here; it's what we do.

[doG]

Who said VB sucks? VB is perfectly capable but in the end it is an interpreted language and will never run as fast as code that compiles directly to machine code. For many business apps and database stuff VB works fine but for most math stuff it does suck terribly when it comes to execution time.

[Pangloss]

VB is perfectly capable but in the end it is an interpreted language

 

No, it isn't.

 

 

and will never run as fast as code that compiles directly to machine code.

 

That's true of all OS-managed languages, and VB runs as fast as any of those (see below).

 

 

For many business apps and database stuff VB works fine but for most math stuff it does suck terribly when it comes to execution time.

 

No more so than any other managed language, such as C# or Java.

[doG]

By default VB compiles as p-code which is interpreted by the VB runtime dll. It has an option to compile to native code which does give some performance boost in some applications. This option does create a large executable since the functions in the runtime interpreter are compiled directly into the native code exe.

 

BTW, I've used VB since VB3 in the Windows 3.1 era. It has its uses, computational mathematics is not one of them. Not that it can't do it. It just can't do it as fast. VB's big advantage is very short application development time, particularly for enterprise database applications. It's not an optimal language for cpu intensive operations. Try doing some high speed graphics with VB and then compare it with compiled c code and you'll really see the difference.

[Pangloss]

That was VB6 -- ten years ago. Modern VB is compiled into intermediary language (right alongside C#), which is then JIT-compiled at runtime and executed.

 

Walk away from the keyboard, doG. Just walk away.

[doG]

JIT-compiled at runtime and executed.

 

...is not native code, it's interpreted. Tell me. How many times have you actually written code in VB and then rewritten it in C to get it to run faster? I've dome so many times. Believe me, there are times I'd rather use VB because it codes faster but I've written both and there are tasks where VB just doesn't cut it. If VB's just as good as everything else why is anything else still around. No one language is just as good or even "the best" at everything, they all have their niches and anyone that argues differently doesn't really understand why different languages exist. VB is not the grand just-as-good-as-everything-else you claim it to be.

[Pangloss]

...is not native code, it's interpreted.

 

No sir, it's a compiled language. The live interpretation execution model you referred to was phased out when it was replaced with the .NET Framework model and the Common Language Runtime approach, generally known as "managed code execution". It is a compiled approach, consisting ultimately of a machine code executable.

 

References:

http://msdn.microsoft.com/en-us/library/w95cx9k1(VS.80).aspx

http://msdn.microsoft.com/en-us/library/s4kbxexc(VS.80).aspx

http://en.wikipedia.org/wiki/Visual_Basic

http://en.wikipedia.org/wiki/Compiled_language

 

 

VB is not the grand just-as-good-as-everything-else you claim it to be.

 

I made no such claim.

[doG]

No sir, it's a compiled language....

http://en.wikipedia.org/wiki/Visual_Basic[/url]

 

From your link....

 

....as well as the ability to compile to native Windows executable code,

 

Native Windows executable code is not native machine code. It's latest iteration requires the .net framework to interpret and execute the code. Native machine code needs no runtime or any external references to run it, no .net framework. If you had ever actually written the same code in both VB and C and run them for comparison your would know the difference. At this point I must assume you've never actually written any C, assembly or machine code and have never actually experienced the difference in execution time.

[Pangloss]

Native Windows executable code is not native machine code. It's latest iteration requires the .net framework to interpret and execute the code.

 

Yes, I never said it didn't require the .NET Framework, but it's not interpretation, it's compilation. It uses a compiler, therefore it is compiled, not interpreted. The difference is that there is no run-time interpretation taking place -- all the determinations are done in advance. By a compiler. In this case there are two -- one that compiles to intermediary language, and a second one that compiles just in time for execution, creating the final executable code.

 

I understand that's different from how compilers work for C++ and other systemic programming models, but I'm not going to sit here and let you cast aspersions that are ten years out of date just because you don't like a language. I just am not.

---

Merged post follows:

Consecutive posts merged

Posts moved to separate thread.

[doG]

Yes, I never said it didn't require the .NET Framework, but it's not interpretation, it's compilation. It uses a compiler, therefore it is compiled, not interpreted. The difference is that there is no run-time interpretation taking place -- all the determinations are done in advance. By a compiler. In this case there are two -- one that compiles to intermediary language, and a second one that compiles just in time for execution, creating the final executable code.

 

Not exactly. You have two options when you compile, P-Code and native code. Both are compiled into an executable but p-code is still interpreted by the VB runtime or VB Virtual machine (vbvmrtNN.dll) at runtime. P-Code is not native machine code and is the default option in the compiler.

 

The native code option is effectively a standalone executable in that the VB runtime is actually compiled into the resulting executable so that calls do not need to be made to vbvmrtNN.dll at execution time. This is effectively non-interpreted code because the resulting executable is native machine code once it is compiled. All references to the VB virtual machine are resolved at the time the code is compiled, not when it is run. This option is not the default because it results in large executables since dependencies are compiled into them.

 

Just because a particular language is compiled does not mean it is not interpreted. If it is compiled to native executable machine code it is non-interpreted. If it is compiled to an intermediate code that is converted to executable machine code on the fly at execution time then it is interpreted.

---

Merged post follows:

Consecutive posts merged

I understand that's different from how compilers work for C++ and other systemic programming models, but I'm not going to sit here and let you cast aspersions that are ten years out of date just because you don't like a language.

 

Who said anything about me not liking the language? I use VB a lot. For many business applications it's a good language. For CPU intensive math operations it sucks. I've written them both ways and CPU intensive math operations can always be optimized by writing them in C instead of VB. Again, have you written any such code in both VB and C and compared the execution time?

---

Merged post follows:

Consecutive posts merged

Kant/Kash and Fortran come to mind when I imagine the logistics of implementing such a math procedure. Even C offers much more functionality than VB.

 

This post was on topic in the original thread and shouldn't have been moved. The OP asked about how to approach a programming problem in evaluating math expressions for various values of x. He posted that he had searched for hours on how to do it with VB and couldn't find any answers so I suggested some alternatives.

[Pangloss]

Sure, I'll copy it back to the other thread.

 

Fine, produce a source that shows some interpretation is still going on at the DLL level in VB8 and I'll acknowledge that point. Otherwise knock it off. Note that even if you do that, it's still a compiled language (see source below).

 

I never said VB was faster than C, I was never concerned with that point at all, and you really should stop saying that.

 

 

http://en.wikipedia.org/wiki/JIT_compilation

 

The performance improvement over interpreters originates from caching the results of translating blocks of code, and not simply reevaluating each line or operand each time it is met (see Interpreted language).

[doG]

Interpreted language

 

Languages usually compiled to a virtual machine code

 

Many interpreted languages are first compiled to some form of virtual machine code' date=' which is then either interpreted or compiled at runtime to native code.

 

* Java (frequently translated to bytecode, but can also be compiled to a native binary using an AOT compiler)

o Groovy

o Join Java

o ColdFusion

* Lua

* .NET Framework languages (translated to CIL code)

o C#

o Visual Basic .NET

* Perl

* Pike

* Python

 

* Visual FoxPro

[/quote']

 

Compiled language

 

A compiled language is a programming language whose implementations are typically compilers (translators which generate machine code from source code)' date=' and not interpreters (step-by-step executors of source code, [b']where no translation takes place[/b]).

 

The term is somewhat vague; in principle any language can be implemented with a compiler or with an interpreter. A combination of both solutions is also increasingly common: a compiler can translate the source code into some intermediate form (often called bytecode), which is then passed to an interpreter which executes it.

 

VB.net code, as well as previous VB versions, is compiled to an intermediate form by default, pcode or CIL, that is then interpreted, or translated, by the VB virtual machine (interpreter, translator) at execution time. By definition that is interpreted. Sorry, I didn't write the definition but a JIT compiler is a translator, previously known as an interpreter.

[Pangloss]

You missed part of your own quote:

 

which is then either interpreted or compiled at runtime to native code.

 

In the case of VB, it's compiled, per my previous links, as I've been telling you all along. So by your own links, VB is a compiled language. Thanks for acknowledging that point. I've also shown how VB is vastly different from the ten-year-old version you cited earlier, so that's been dealt with as well.

 

If you do find some evidence that there is interpretation taking place within the .NET Framework, please feel free to pass it along -- it sounds like an interesting point, it's just unfortunate that you haven't found a link to back it up, but I agree that these things are complex and not easily defined by entirely traditional definitions. In fact according to MSDN when you install the .NET Framework is compiles all the DLLs immediately anyway, so I think you're going to lose that argument any way you phrase it. But feel free to keep looking.

 

Thanks for a lively discussion.

[doG]

You missed part of your own quote:

which is then either interpreted or compiled at runtime to native code.

 

No, I didn't miss it at all. I specifically quoted that portion of the article on interpreted languages on purpose because it points out that any language that is compiled or interpreted AT RUNTIME is an interpreted language. If you don't agree with that then take it up with the maintainer of that article at Wikipedia. If that's the case you'll also need to take it up with Citizendium since their article on programming languages states:

 

Compiled vs. interpreted

 

One way in which various programming languages have traditionally been categorized is as compiled vs. interpreted languages. The traditional view was that compiled languages were first translated' date=' by a compiler program, from human-readable source code into binary machine code. Some widely used early languages such as Fortran and C use pure compilation.

 

Conversely, interpreted languages rely, at run time, on a special runtime application, called the interpreter, to translate source code into machine code during program execution. An example of an early purely interpreted language is Snobol. Purely interpreted programs tend to execute more slowly due to the necessary intervention of the interpreter while the program is "executing". HTML is a special-purpose language that is interpreted; the interpreter for HTML is called a web browser, and it reads the HTML line-by-line and renders a web page for display to a user based on the HTML code.

 

The division between compiled languages and interpreted languages has blurred since the 1990's with the advent of hybrid platforms such as Java and the .NET Framework (C# and VB.NET). These hybrid languages are compiled down to an intermediate language at the time a program is written. When the program is later run, the intermediate code is loaded into a sophisticated, optimized runtime engine for "execution". Such runtime engines could be implemented as interpreters (early ones were), but nowadays they typically use Just-In-Time compilers to generate native machine code from the intermediate language on an as-needed basis. So multiple compilers are involved, one used by programmers to create programs that contain intermediate code, [b']and another used at runtime to "interpret" the intermediate language (or in actuality, to just-in-time compile portions of intermediate code to native code on the fly as needed)[/b].

 

If you do find some evidence that there is interpretation taking place within the .NET Framework, please feel free to pass it along

 

Already have. A JIT compiler is an interpreter, a translator because it translates code into machine executable code at runtime. That's why VB.net is listed as an interpreted language just like Java, C#, Perl and a host of others. The part you don't seem to get is that any language that is translated to machine executable code at runtime is an interpreted language by definition. I've quoted both Wiki and Citizendium to point this out. A JIT compiler, or a runtime virtual machine like older versions of VB used, is a translator or an interpreter by another name. Just because VB compiles to a Compiled Intermediate Language does not mean that it is not an interpreted language. It means that it is an interpreted language because that compiled intermediate language is not one that the processor understands but one that must be translated at runtime to executable code that the processor does understand.

 

Why does it bother you that VB is an interpreted language anyhow? So is Java, C#, Perl and other hybrid languages. For many applications the fact that they are interpreted gives them an advantage over languages like C, mainly cross platform portability. They have their niche, it just isn't applications or functions that require CPU intensive operations like some math algorithms that run for billions or trillions of machine cycles. I've actually written applications with a VB frontend that called functions in the backend I wrote in C and compiled as DLLs to enjoy the benefits of both.

[Pangloss]

That quote seems to support what I'm saying -- that it's compiled, not interpreted.

 

and another used at runtime to "interpret" the intermediate language (or in actuality, to just-in-time compile portions of intermediate code to native code on the fly as needed).

 

And this quote before that point also supports what I said:

 

Such runtime engines could be implemented as interpreters (early ones were), but nowadays they typically use Just-In-Time compilers to generate native machine code from the intermediate language on an as-needed basis.

 

 

As for whether it "bothers" me, why do you feel the need to redefine the .NET languages as interpreted? The question goes both ways. Personally I could care less, I simply want accurate information posted on this forum.

 

If you can back it up, please feel free to do so. Until then these languages appear to remain firmly compiled. Thanks.

Edited March 16, 2009 by Pangloss

[bascule]

Pangloss is right, the .NET CLR compiles to native code. In fact, the CLR is much more like a standard run-of-the-mill ahead of time (AOT) native code compiler than it is to a JIT compiler ala Java's HotSpot. I think this was an intentional design decision by the creators of the CLR so they didn't need to go through years and years of adding runtime optimizations and dynamic compilation like Java HotSpot did to get decent performance. Note that this is a similar design decision to two Google VMs: Dalvik (Java implementation for Android) and V8 (JavaScript engine) However, that said, HotSpot has better overall performance.

 

An interpreted language means one of two things: the execution happens on a "virtual CPU", either in the form of a stack machine or a register machine, or the abstract syntax tree is evaluated directly, a method popular in scripting languages.

 

JIT means many things... a JIT can dynamically recompile bytecode to new forms, such as Java's HotSpot. This is how it inlines methods... and it can also "deoptimize" these sections to the original form so it can attempt different optimization strategies as the requirements change. However, JIT typically means compiling from some sort of intermediate form to native code at runtime. Native code is native code... the instructions are expressed in the instruction set architecture of a native CPU. Just because they defer control back to the runtime is meaningless... so does C++.

 

The C++ runtime handles method dispatch and must maintain vptr tables to handle virtual method invocation. In Java (and I believe with the CLR languages) all method dispatch is virtual, but inlining can be performed at runtime by a JIT. This is a distinct advantage offered by languages like Java over C++.

[doG]

Neat how you completely ignored the "interpret" there that was clearly explained by the part in parentheses you emphasized. I never said it wasn't compiled, only that just in time compilation is considered interpreted. Both articles on interpreted languages clearly and plainly list Java, C# and VB.net as examples. They are hybrid languages that use a compiler at runtime to interpret the intermediate code. If you can't understand what is plainly said there I don't know what more to tell you.

[bascule]

Neat how you completely ignored the "interpret" there that was clearly explained by the part in parentheses you emphasized.

 

Interpretation means that programs are compiled to an intermediate representation which is evaluated by a runtime, as opposed to being compiled directly to native code. This immediate representation may be an abstract syntax tree (in the case of truly "evaluated" languages) or it may be bytecode targeting a stack machine or a register machine.

 

I never said it wasn't compiled, only that just in time compilation is considered interpreted.

 

Just-In-Time compilation in and of itself implies nothing about the execution strategy. In fact the execution strategy used alongside the JIT compiler of one of my favorite languages, Erlang, is effectively the same as an AOT compiler but the final compilation stage happens at runtime (as is more or less the case with the CLR, V8, and Dalvik, although they support dynamic recompilation to native code). JIT really just means you have a compiler functioning as part of the runtime. This compiler may output native code, which can be the only execution strategy, or it can dynamically recompile to bytecode, possibly in addition to recompiling to native code as in the case of HotSpot.

 

Both articles on interpreted languages clearly and plainly list Java, C# and VB.net as examples.

 

Well, to put it bluntly, in the case of C# and VB.net they're wrong.

 

They are hybrid languages that use a compiler at runtime to interpret the intermediate code.

 

As stated in my previous post, Java does use a hybrid strategy of interpretation and native code execution. Java also started out as a fully interpreted language, with HotSpot being added later.

 

However, using the "compiler at runtime" to generate native code isn't interpretation. The native code coming out of a JIT compiler is executed directly by the CPU. The native code coming out of those compilers is the same type of native code that would come out of a standard AOT compiler for C. There is no interpretation... because they're making native code. What isn't clear about that?

 

Here's a Wikipedia article that explains the situation better:

 

http://en.wikipedia.org/wiki/Comparison_of_Application_Virtual_Machines

 

The bytecode used by the .NET CLR provides a stack machine, much like the JVM. However unlike the JVM there is no interpreter for that bytecode (see the box in red under "interpreter"). The only way the CLR can execute bytecode is to compile it to native code. The JVM is instead a true "virtual machine" meaning it has a program which can understand JVM bytecode directly and execute it on a "virtual" stack machine written in software. The JVM is in effect an "emulator" for JVM bytecode.

 

The CLR also lets you AOT compile to native code (in addition to CLR bytecode), which is in effect what you want, except the resulting files are packaged differently than a .EXE file and still need the .NET CLR to run. All this really saves you is the initial compilation stage which would otherwise take place when the program is executed, provided the original files were AOT compiled to your native machine architecture. However, .NET lets you ship files containing native code (Erlang does more or less the same thing as the only option available).

 

The thing is, the JVM's hybrid approach of using interpreted and natively compiled code is faster than the CLR's approach of compiling directly to native code. This is because HotSpot can perform whole classes of optimizations on JVM bytecode, which is far easier to work with than native code. HotSpot can try to rearrange things and back out if it's discovered they don't improve performance, and is constantly reorganizing your code to run faster, so if your program starts doing something different than when it originally made its optimizations it can back out of them and reoptimize for the new situation. When it "hot" sections of code (ones which get executed many many times over) it converts these to native code.

 

Contrast this to C++, where you are given the choice of self-imposing design constraints for performance (by not declaring methods virtual) or going dog slow. Virtual methods let you take advantage of inheritance and polymorphism which are some of the most important features in object oriented design, but come with a high performance penalty.

 

If your C++ code makes extensive use of virtual methods, the equivalent Java or C# code will probably be faster due to their automatic method inlining. This is why it pays to have a smart runtime. On the other hand, if your C++ code looks a lot like C then, yes, it will probably be faster than equivalent Java or C# code. However unless you're writing performance critical numerical transforms chances are your code isn't going to look a lot like C, because C provides a poor model for solving most types of problems outside the spaces of systems programming or purely numerical computing (e.g. video codecs, image processing, scientific computing, mathematical transforms, etc)

[Pangloss]

Well doG I agree that they're hybrid languages and I do take your point there -- they're different from traditional approaches, more complex and intricate and not as rigidly defined, perhaps. And since you now agree that it can be called a compiled language I guess we can move on. Thanks.

 

------------

 

Bascule that was an interesting post, but my ignorance caused me to lose you in this last paragraph:

 

The C++ runtime handles method dispatch and must maintain vptr tables to handle virtual method invocation. In Java (and I believe with the CLR languages) all method dispatch is virtual, but inlining can be performed at runtime by a JIT. This is a distinct advantage offered by languages like Java over C++.

 

Does "method dispatch" mean the handling of method calls by the compiler or interpreter? So for example if I say something like "myObject.turnblue" (where "turnblue" is a method that turns the object blue), the process of "method dispatch" is what the compiler does with that command, i.e. what native code it writes? Or am I way out in the wrong field there?

 

Also, what is "inlining"?

[bascule]

Does "method dispatch" mean the handling of method calls by the compiler or interpreter?

 

Pretty much any object oriented language is going to have method dispatch, from C++ to Java to Python.

 

In the case of C++, method dispatch handles inheritance/polymorphism. It looks up where the native code to execute a particular method lives depending on the class of a given object in something called the vptr table. This allows you to pass an object to a method which accepts an ancestor of a given object as a parameter, among other things.

 

The method you passed it to has no idea you gave it a subclass, and the subclass may have behavior that's different from the ancestor. But the method you gave it to can still talk to the object as if it were the ancestor being none the wiser it has different behavior.

 

Also, what is "inlining"?

 

When the JVM inlines methods it effectively takes the code in the body of one method and writes it into where another method would ordinarily call it. Inlining happens whenever the runtime sees a particular sequence of functions are a "hot spot" in a given program, i.e. they're being called repeatedly. Inlining allows the compiler to treat a given sequence of functions as if it were one big function, which allows for much more optimization potential.

 

It also reduces the lookup time for virtual method dispatch. As I described above when C++ executes a virtual method it has to look it up in the vptr table. This is an O(log n) operation, since the vptr table is effectively a hash table. With method inlining the most common case becomes O(1), because the first thing the runtime does when dispatching a given method is ask "are you the most common case?" which is an O(1) operation. If it's not, it proceeds with normal O(log n) method dispatch. C++ cannot do this because its execution strategy is completely static.

 

In the end C++ foists the majority of optimization complexity onto the language's user, where Java or C# attempt to handle more of it at runtime. This allows users of Java and C# to focus on designing their systems better, as opposed to compromising their designs for optimum performance.

[Pangloss]

Fascinating, thanks. I've read many times about how this is supposed to be an advantage, but I've never read exactly why.

[doG]

However, using the "compiler at runtime" to generate native code isn't interpretation. The native code coming out of a JIT compiler is executed directly by the CPU. The native code coming out of those compilers is the same type of native code that would come out of a standard AOT compiler for C. There is no interpretation... because they're making native code. What isn't clear about that?

 

It's perfectly clear. There is still a distinction between them though. Languages that have been traditionally classified as compiled languages like C, Fortran and Pascal produce executables that are stored in native code and begin executing as native code as soon as they are called. Languages that use a just in time compiler do not. They use processor clock cycles to produce native machine code that is then executed when they are called. While these languages do not fall under the traditional meaning of interpretation they do not fall under the traditional meaning of compiled either. One executable uses processor clock cycles to convert the code to native executable code and the other does not. Those languages using clock cycles to convert code to run instead of running it from the get go do not fit the traditional category of compiled languages because they are not compiled to native code once and stored, ready to run as native code, but compiled to native code each and every time they are run just as languages traditionally classified as interpreted are translated each and every time they are run.