Interpreted vs compiled languages


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 6 123 ... LastLast
Results 1 to 15 of 78

Thread: Interpreted vs compiled languages

  1. #1
    Larry Serflaten Guest

    Re: Interpreted vs compiled languages

    "Paul" <1@1.com> wrote
    > I read alot about .Net NOT being an interpreted language- in that the, for
    > example, VB.Net code is compiled down in to the MSIL which is then compiled
    > into native machine code by the JIT compiler.


    Where do you read that? ALL of the languages, AFAIK are parsed to MSIL and
    shipped that way. After they get placed on the client, THEN the JIT compiler does
    its thing to give the client a better chance at optimizations targeted for the client
    machine.

    In my mind, an interpreted language was one where the interpreter resides in memory
    while the program runs. It would attack the program a line at a time, interpreting and
    executing the commands from P-code to executable code.

    LFS




  2. #2
    Larry Serflaten Guest

    Re: Interpreted vs compiled languages

    "Larry Serflaten" <serflaten@usinternet.com> wrote
    > "Paul" <1@1.com> wrote
    > > I read alot about .Net NOT being an interpreted language-


    My mistake, I read that too fast. I read it as VB.NOT being... instead of
    ..Net NOT...

    Sorry!
    ;-)
    LFS



  3. #3
    Daniel Pratt Guest

    Re: Interpreted vs compiled languages

    Hi Paul,

    "Paul" <1@1.com> wrote in message news:3ca8c2fb@10.1.10.29...
    > I read alot about .Net NOT being an interpreted language- in that the, for
    > example, VB.Net code is compiled down in to the MSIL which is then

    compiled
    > into native machine code by the JIT compiler.
    > Whilst my definition of a compiled language would be
    > "The program is compiled to native machine language, which is then
    > executed."
    >
    > I'm slightly confused by what exactly we mean by the term interpreted
    > language- which I would describe as
    > "The program is parsed/compiled into an intermediary non-machine language
    > format which is executed (such as bytecode, parse trees, etc)."


    More or less correct, I think. My definition of an interpreted language
    is one that is interactively executed by an interpreter and is never
    converted to machine language.

    > Am I safe in describing Java as an interpreted language in that Java code

    is
    > compiled into bytecode which then requires the JVM to interpret it


    Many JVMs actually do pre-compile the bytecode into native machine code
    just as the CLR does. The difference, according to Microsoft, is that MSIL
    was _designed_ to run compiled, whereas Java bytecode was designed to run
    interpreted. Theoretically this allows the .NET CLR to do greater
    optimizations depending on the target machine.

    if this
    > is so then the problem I have getting my head around is how does the JVM

    run
    > this bytecode without turning this bytecode into native machine code?


    Everything that executes on a machine is machine code native to the
    processor. The difference is whether the bytecode is converted "up front" or
    "line by line". If you call a function five times in an interpreted
    language, the interpreter "converts" the code all five times. Compilation
    converts the code only once.

    > Also I take it if Java is interpreted then it must run slower than a .Net
    > application (although the first time a particular .Net assembly is

    compiled
    > by the JIT a small initial performance hit will be experienced).


    To reiterate, many JVMs pre-compile bytecode. Any performance benefits
    accorded to .NET would be the result of MSIL code that is optimized for
    on-site compilation or just a better-designed CLR.

    > I'm not trying to bash Java- as I use it heavily and love it (along with
    > VB)- but I'm merely trying to get my head around the concept of an
    > interpreted language- and what it actually means under the bonnet.


    It gets confusing, for sure. I hope I was helpful.

    Regards,
    Dan



  4. #4
    David Bayley Guest

    Re: Interpreted vs compiled languages

    "Paul" <1@1.com> wrote in message news:3ca8c2fb@10.1.10.29...

    > I read alot about .Net NOT being an interpreted language- in that the, for
    > example, VB.Net code is compiled down in to the MSIL which is then

    compiled
    > into native machine code by the JIT compiler.
    > Whilst my definition of a compiled language would be
    > "The program is compiled to native machine language, which is then
    > executed."


    That's what a JIT compiler does. The difference with traditional compilers
    is that the final stage happens Just In Time on the end-users' system rather
    than Ahead Of Time on the developer's system. "Dynamic compilation" vs.
    "Static compilation", but compilation nevertheless.

    > I'm slightly confused by what exactly we mean by the term interpreted
    > language- which I would describe as
    > "The program is parsed/compiled into an intermediary non-machine language
    > format which is executed (such as bytecode, parse trees, etc)."


    It's a grey area... I think the crucial difference is that an interpreter
    interprets pseudo-code (bytecode) at run-time /continuously/. The .NET
    JIT-compiler takes a whole method, and compiles that to native code only on
    the /first time/ it is called. Thereafter, the cached native code is
    executed immediately. In this sense the architecture is closer to a
    "compiler" that is delayed until the last minute, rather than an
    "interpreter" that might be optimised to interpret groups of bytecodes.

    Note: .NET also has a Pre-JIT compiler that compiles when the program is
    installed, and stores the cached native on disk. I think most, if not all,
    of the .NET frameworks are Pre-JIT'ed at install-time to improve start up
    time.

    > Am I safe in describing Java as an interpreted language in that Java code

    is
    > compiled into bytecode which then requires the JVM to interpret it- if

    this
    > is so then the problem I have getting my head around is how does the JVM

    run
    > this bytecode without turning this bytecode into native machine code?


    Older JVMs were interpreted, but modern JVMs provide _both_ interpretation
    and JIT-compilation. The majority of code is interpreted bytecode by
    bytecode, but performance is monitored to identify "HotSpots". Found
    hotspots are then JIT-compiled to native code just like .NET. In .NET
    however, *every* method is JIT-compiled, nothing is monitored, and nothing
    is interpreted.

    > Also I take it if Java is interpreted then it must run slower than a .Net
    > application (although the first time a particular .Net assembly is

    compiled
    > by the JIT a small initial performance hit will be experienced).


    I don't think it is as simple as that. I think there is a complex trade-off
    to be made between how agressively the compiler optimizes the code (long
    term benefits), and the length of time it takes to perform that optimization
    (short term benefits). I'm certainly no expert on this though, and have
    never written a compiler, this is just what I understand from previous
    discussions.

    --
    David.



  5. #5
    Rob Teixeira Guest

    Re: Interpreted vs compiled languages


    "Paul" <1@1.com> wrote:
    >I read alot about .Net NOT being an interpreted language- in that the, for
    >example, VB.Net code is compiled down in to the MSIL which is then compiled
    >into native machine code by the JIT compiler.
    > Whilst my definition of a compiled language would be
    >"The program is compiled to native machine language, which is then
    >executed."
    >
    >I'm slightly confused by what exactly we mean by the term interpreted
    >language- which I would describe as
    >"The program is parsed/compiled into an intermediary non-machine language
    >format which is executed (such as bytecode, parse trees, etc)."


    Correct. An interpreted instruction set is non-native byte codes that are
    run through a "virtual execution machine" (the interpreter) at runtime. The
    CPU does not run the code directly, the interpreter runs the code.

    With .NET and MSIL, the situation is a little different. MSIL embodies the
    essence of the code in a platform-agnostic fashion. A Just-In-Time compiler
    then converts the MSIL to platform-native code (and can even cache the results).
    This native code is ultimately run directly by the CPU. The MSIL is never
    interpreted by any kind of software as it runs. Using this technique, you
    get the benifits of a virtual system (platform neutrality and platform-specific
    optimization) without the performance hit of a virtual execution system.
    For example, on a single-processor x86, the native code could be different
    than from a multi-processor x86 so that each takes advantage of the host
    system. Also, you can theoretically take the same executable, and JIT/run
    it on a 64-bit system.

    >Am I safe in describing Java as an interpreted language in that Java code

    is
    >compiled into bytecode which then requires the JVM to interpret it- if this
    >is so then the problem I have getting my head around is how does the JVM

    run
    >this bytecode without turning this bytecode into native machine code?


    Let me explain this in EXTREMELY simplistic terms
    If you look at native code, for each instruction, you load a bunch of registers
    with data, and then the instruction code toggles some branch of circuit in
    the CPU to perform a task.
    In Java's case, the software does pretty much the same thing as the CPU,
    except in software form. The data for each instruction is loaded up in memory
    somewhere, and the virtual machine looks at the instruction part of the byte
    code and then asks, "according to this code, what runtime function do I call?".

    However, also note that there are Just-In-Time compilers for Java out there
    that will compile Java bytecode to native code and run that, similar to what
    .NET does with MSIL. But, MSIL is based on an instruction stack machine,
    which in theory can compile and execute certain instructions faster than
    the way Java bytecode is structured.

    >Also I take it if Java is interpreted then it must run slower than a .Net
    >application


    Yes.

    >(although the first time a particular .Net assembly is compiled
    >by the JIT a small initial performance hit will be experienced).


    Yes. However, MSIL can be compiled at install-time (rather than runtime),
    and the results cached, if this is a problem for your application.

    >I'm not trying to bash Java- as I use it heavily and love it (along with
    >VB)- but I'm merely trying to get my head around the concept of an
    >interpreted language- and what it actually means under the bonnet.


    Yep, lots of new stuff in there to get used to

    -Rob

  6. #6
    Mike Mitchell Guest

    Re: Interpreted vs compiled languages

    On Mon, 1 Apr 2002 15:38:06 -0600, "Larry Serflaten"
    <serflaten@usinternet.com> wrote:

    >Where do you read that? ALL of the languages, AFAIK are parsed to MSIL and
    >shipped that way. After they get placed on the client, THEN the JIT compiler does
    >its thing to give the client a better chance at optimizations targeted for the client
    >machine.


    Thus, effectively, removing any predictability about the actual
    machine cycles your application will execute on machine X compared to
    machine Y. Try selling this idea to safety-conscious design teams:
    "Here's the code to stop the planes colliding with each other, but we
    cannot tell you what the CPU may actually be executing. Oh, sorry,
    we've just heard that a plane has been optimized."

    MM

  7. #7
    Mike Mitchell Guest

    Re: Interpreted vs compiled languages

    On Mon, 1 Apr 2002 15:41:33 -0600, "Larry Serflaten"
    <serflaten@usinternet.com> wrote:

    >"Larry Serflaten" <serflaten@usinternet.com> wrote
    >> "Paul" <1@1.com> wrote
    >> > I read alot about .Net NOT being an interpreted language-

    >
    >My mistake, I read that too fast. I read it as VB.NOT being... instead of
    >.Net NOT...
    >
    >Sorry!
    >;-)


    Yes, Microsoft may rue the day their marketing team came up with the
    .Net moniker! Whoever thought of starting a word with a period?
    Unless, of course, they have plans for that word...!

    MM

  8. #8
    Mike Mitchell Guest

    Re: Interpreted vs compiled languages

    On 1 Apr 2002 14:54:05 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    wrote:

    >Yep, lots of new stuff in there to get used to


    And if it's new, it has to be beneficial, doesn't it?

    MM

  9. #9
    Rob Teixeira Guest

    Re: Interpreted vs compiled languages



    And if one has so much to say, it should have meaning, shouldn't it?

    -Rob

    kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
    >
    >And if it's new, it has to be beneficial, doesn't it?
    >
    >MM



  10. #10
    Mike Mitchell Guest

    Re: Interpreted vs compiled languages

    On 2 Apr 2002 09:18:56 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    wrote:

    >And if one has so much to say, it should have meaning, shouldn't it?


    No, don't try to duck the question: How is all this new stuff so
    beneficial? Is new stuff *always* beneficial? What benefits do you
    envisage when .Net is eventually replaced with even *NEWER* new stuff?
    Like, is this now *it*? Or do you see a point down the road when .Net
    will be "discontinued" and a brand new paradigm put in its place? It
    happened to VB after all.

    MM

  11. #11
    Robert Lantry Guest

    Re: Interpreted vs compiled languages

    "The point is, we are not rocks. Who wants to be one anyway, impermeable,
    unchanging, our history already played out..."
    - John Rosenthal


    --

    -Robert

    Have a cow, man:
    http://www.riddleme.com/html/cow.html


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:3ca9fdfa.11655274@news.devx.com...
    > On 2 Apr 2002 09:18:56 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    > wrote:
    >
    > >And if one has so much to say, it should have meaning, shouldn't it?

    >
    > No, don't try to duck the question: How is all this new stuff so
    > beneficial? Is new stuff *always* beneficial? What benefits do you
    > envisage when .Net is eventually replaced with even *NEWER* new stuff?
    > Like, is this now *it*? Or do you see a point down the road when .Net
    > will be "discontinued" and a brand new paradigm put in its place? It
    > happened to VB after all.
    >
    > MM




  12. #12
    Paul Guest

    Interpreted vs compiled languages

    I read alot about .Net NOT being an interpreted language- in that the, for
    example, VB.Net code is compiled down in to the MSIL which is then compiled
    into native machine code by the JIT compiler.
    Whilst my definition of a compiled language would be
    "The program is compiled to native machine language, which is then
    executed."

    I'm slightly confused by what exactly we mean by the term interpreted
    language- which I would describe as
    "The program is parsed/compiled into an intermediary non-machine language
    format which is executed (such as bytecode, parse trees, etc)."

    Am I safe in describing Java as an interpreted language in that Java code is
    compiled into bytecode which then requires the JVM to interpret it- if this
    is so then the problem I have getting my head around is how does the JVM run
    this bytecode without turning this bytecode into native machine code?

    Also I take it if Java is interpreted then it must run slower than a .Net
    application (although the first time a particular .Net assembly is compiled
    by the JIT a small initial performance hit will be experienced).

    I'm not trying to bash Java- as I use it heavily and love it (along with
    VB)- but I'm merely trying to get my head around the concept of an
    interpreted language- and what it actually means under the bonnet.


    thanks

    Paul.



  13. #13
    Larry Serflaten Guest

    Re: Interpreted vs compiled languages

    > Yes, Microsoft may rue the day their marketing team came up with the
    > Net moniker! Whoever thought of starting a word with a period?
    > Unless, of course, they have plans for that word...!
    >
    > MM


    I kinda thought they planned to put all their new webservices in the
    ..net domain....

    LFS




  14. #14
    Larry Serflaten Guest

    Re: Interpreted vs compiled languages

    For talk about not having a leg to stand on...

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
    > On 2 Apr 2002 09:18:56 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    > wrote:
    >
    > >And if one has so much to say, it should have meaning, shouldn't it?

    >
    > No, don't try to duck the question: How is all this new stuff so
    > beneficial?


    How? Because it increases productivity, and for VB in particular, it opens
    many new doors previously reserved to the hardcore enthusiasts.

    > Is new stuff *always* beneficial?


    Yes, some moreso than others. Even if the only benefit of some new implementation
    shows that such a solution is not viable, that too, is a benefit.


    > What benefits do you envisage when .Net is eventually replaced with even *NEWER* new stuff?


    > Like, is this now *it*? Or do you see a point down the road when .Net
    > will be "discontinued" and a brand new paradigm put in its place?


    Can I borrow your crystal ball? It seems you talk as if yours actually works....





  15. #15
    Tom Bennet Guest

    Re: Interpreted vs compiled languages


    .Net is a major advancement for VB, but .Net as a whole doesn't seem to bring
    anything all that revolutionary to the table. I see .Net as a victory for
    Sun not a defeat. As far as being more productive, I have yet to see it.
    I would put it on par with Java and Java is not as productive a tool as
    VB6 was. Most of quick and dirty things that can be done in 6 are gone in
    .Net. It's great that you can spin threads, but there is nothing revolutionary
    about it.

    That being said, I have to use it and I really don't mind all that much.
    I just hate the fact that I have sooooooo much code that cannot be compiled
    because a "revolutionary" tool had to be brought to market so MS could continue
    to compete with Sun.

    "Larry Serflaten" <serflaten@usinternet.com> wrote:
    >For talk about not having a leg to stand on...



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center