4 ms·

Between D, Nimrod and Julia it looks like there's a resurgence of fun in (JIT) compiled languages.

deleted 13y ago
[deleted]
pjmlp 13y ago
All available D compilers generate native code directly, there is no JIT involved. Sometimes I wonder how computing would look like if the default implementations of Java and C#[1] were available from the start as native compilers, instead of VM environments. [1] Funny enough, the precursor of .NET was native and COM based, similar to what is now WinRT, more info here, http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-10-32-72-38/Ext_2D00_VOS.pdf http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-co...
- rbehrends 13y ago
  All available D compilers generate native code directly, there is no JIT involved. I think that's why the GP has the JIT in parentheses (to account for Julia's implementation, which does use a JIT-compiler, as opposed to D and Nimrod)
  - pjmlp 13y ago
    Fair enough, it wasn't clear to me.
- Jtsummers 13y ago
  Sometimes I wonder how computing would look like if the default implementations of Java and C#[1] were available from the start as native compilers, instead of VM environments. At least with Java that would defeat one of the main intents of its development. What would you think would be gained by having non-VM based implementations of these by default?
  - rbehrends 13y ago
    What would you think would be gained by having non-VM based implementations of these by default? For the JVM, considerably lower startup/JIT warm-up times. You can really observe this nicely if you're using Zinc (the incremental Scala compiler), where you not only cut the startup overhead down to pretty much zero, but compilation really speeds up once the JIT has warmed up a bit. (Hence why Nailgun exists.)
    - Jtsummers 13y ago
      I only have a passing familiarity with Scala so I had to look up Zinc, and my hobby languages are erlang/lisp and work is C# so Nailgun is also new to me. Nailgun seems to be a way to keep the JVM running so you don't incur the startup overhead. Straightforward enough, and makes sense when your execution time is dominated by the JVM init. Zinc seems to be a compiler based on Nailgun so that performance improves over time (particularly useful for long compiles or frequent compilation). Neither of those though, move Java off a VM/JIT basis. However, as someone who hasn't seen them before, it was interesting reading and neat to see what's going on in the rest of the world.
      - rbehrends 13y ago
        Neither of those though, move Java off a VM/JIT basis. That's the thing; the Nailgun workaround to an extent avoids the startup overhead, but can create other problems. E.g., when you're starting multiple builds on the same server (because the Nailgun server listens on a port, so you may have to sort out conflicts), if you have multiple users on the same machine (because anybody can connect to the socket, so you have a potential security problem), etc. With a native option, this can be avoided (note that IBM offers an AOT compiler for Java).
        Jtsummers 13y ago
        Note: I'm not saying a native option doesn't make sense, my original question is what would be the benefit for Java/C# (though we've focused on Java) of native first. Re: Nailgun - that seems like an implementation issue, but yes, if native compilation were present then Nailgun wouldn't exist (or need to) so the technical issues causing those problems wouldn't exist.
rbehrends 13y ago
The crucial combination appears to be static typing + automatic memory management + imperative programming. This is a niche that has not been served well by languages outside the JVM/.NET families; and the JVM has the problem of having pretty high per-process overheads while the problem with .NET languages has always been portability/deployment outside the Windows ecosystem.

deleted 13y ago

[deleted]

pjmlp 13y ago

All available D compilers generate native code directly, there is no JIT involved. Sometimes I wonder how computing would look like if the default implementations of Java and C#[1] were available from the start as native compilers, instead of VM environments. [1] Funny enough, the precursor of .NET was native and COM based, similar to what is now WinRT, more info here, http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-10-32-72-38/Ext_2D00_VOS.pdf http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-co...

rbehrends 13y ago
All available D compilers generate native code directly, there is no JIT involved. I think that's why the GP has the JIT in parentheses (to account for Julia's implementation, which does use a JIT-compiler, as opposed to D and Nimrod)
- pjmlp 13y ago
  Fair enough, it wasn't clear to me.
Jtsummers 13y ago
Sometimes I wonder how computing would look like if the default implementations of Java and C#[1] were available from the start as native compilers, instead of VM environments. At least with Java that would defeat one of the main intents of its development. What would you think would be gained by having non-VM based implementations of these by default?
- rbehrends 13y ago
  What would you think would be gained by having non-VM based implementations of these by default? For the JVM, considerably lower startup/JIT warm-up times. You can really observe this nicely if you're using Zinc (the incremental Scala compiler), where you not only cut the startup overhead down to pretty much zero, but compilation really speeds up once the JIT has warmed up a bit. (Hence why Nailgun exists.)
  - Jtsummers 13y ago
    I only have a passing familiarity with Scala so I had to look up Zinc, and my hobby languages are erlang/lisp and work is C# so Nailgun is also new to me. Nailgun seems to be a way to keep the JVM running so you don't incur the startup overhead. Straightforward enough, and makes sense when your execution time is dominated by the JVM init. Zinc seems to be a compiler based on Nailgun so that performance improves over time (particularly useful for long compiles or frequent compilation). Neither of those though, move Java off a VM/JIT basis. However, as someone who hasn't seen them before, it was interesting reading and neat to see what's going on in the rest of the world.
    - rbehrends 13y ago
      Neither of those though, move Java off a VM/JIT basis. That's the thing; the Nailgun workaround to an extent avoids the startup overhead, but can create other problems. E.g., when you're starting multiple builds on the same server (because the Nailgun server listens on a port, so you may have to sort out conflicts), if you have multiple users on the same machine (because anybody can connect to the socket, so you have a potential security problem), etc. With a native option, this can be avoided (note that IBM offers an AOT compiler for Java).
      - Jtsummers 13y ago
        Note: I'm not saying a native option doesn't make sense, my original question is what would be the benefit for Java/C# (though we've focused on Java) of native first. Re: Nailgun - that seems like an implementation issue, but yes, if native compilation were present then Nailgun wouldn't exist (or need to) so the technical issues causing those problems wouldn't exist.

rbehrends 13y ago

The crucial combination appears to be static typing + automatic memory management + imperative programming. This is a niche that has not been served well by languages outside the JVM/.NET families; and the JVM has the problem of having pretty high per-process overheads while the problem with .NET languages has always been portability/deployment outside the Windows ecosystem.