4 ms·

Why do you prefer native code ? What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). So maybe

Why do you prefer native code ? What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). So maybe you mean static compilation, but then, why is it better for the stuff you're doing ?

regularfry 14y ago
I can't answer for the GP, but native code is generally better for me because of the startup time.
batista 14y ago
>Why do you prefer native code ? For me, because I don't want to install the JVM, or force users of my stuff to install the JVM. I also don't care about JVM libs. >What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). I, for one, mean non-JIT, no virtual machine needed, native code. >So maybe you mean static compilation, but then, why is it better for the stuff you're doing ? Less startup overhead. Small binaries. Easily redistributable. No stuff I don't need.
- sanxiyn 14y ago
  Does GCJ qualify? No JIT, no VM, native code, less startup overhead, easily redistributable.
exDM69 14y ago
> Why do you prefer native code ? What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). By native code I mean binaries emitted by my compiler in a format that my operating system can link and load. I usually write the code in C with some CPU-specific assembly intrinsics for the critical stuff. I tend to write computer graphics and physics simulation stuff which has to be quite fast. A lot of stuff I deal with is moving blobs of binary data from buffer to another (disk, memory, dma, gpu). Or computing a SIMD fused multiply-and-add for a few hundred megabytes of floating point data. Or invert and transpose a hundred thousand 4x4 matrices. Everything the JVM does is acting against me, so better just write native. Sure there are games and physics and whatnot written with Java and other systems, but they are more commonly "low perf" stuff. 2d games and that kind of stuff. And even then they suffer from JIT & GC pauses and other undesirable effects. It always ruins my day when in the middle of a Minecraft session the GC kicks in while running away from a Creeper.
- jbooth 14y ago
  That's all well and good, but wouldn't any LISP be way insufficient for your needs then? I mean, Java's going to be closer to C's performance than any LISP dialect until we have a "sufficiently smart compiler", right?
- rayiner 14y ago
  > I tend to write computer graphics and physics simulation stuff which has to be quite fast. A lot of stuff I deal with is moving blobs of binary data from buffer to another (disk, memory, dma, gpu). Or computing a SIMD fused multiply-and-add for a few hundred megabytes of floating point data. Or invert and transpose a hundred thousand 4x4 matrices. Everything the JVM does is acting against me, so better just write native. The JVM is very fast for these things. There remaining delta is the result of more investment into optimizations in GCC/LLVM than any limitation of the JVM model itself.
- heretohelp 14y ago
  This is the sort of thing I'm talking about, when I talk about the insufficiency of Java and other VM languages for high performance programming. It'd be nice if somebody made a new systems language to succeed C or C++. Rust is looking less likely these days. Maybe Clay or Deca?
  - raphinou 14y ago
    Why is Rust less likely these days?
    - heretohelp 14y ago
      A thousand papercuts and a preoccupation with things that don't make it nicer to use. Supremely practical in a sense though. It's like the inverse of golang. golang is unimpressive, and totally impractical for systems programming, but is nice to use for general purpose programming. Rust is impressive and could'ish be used for systems programming (I'm not sure how much uphill fighting is involved with the current memory management model, it seems ARC is the default which makes me intensely uncomfortable about its prospects for 'hard' systems programming) but it's not very pleasant at all. The syntax and semantics make me nauseous. Rust can be fixed, golang cannot. Unlikely though. I'm not sure it's more realistic to make a practical implementation of region-based memory management than it is to ameliorate the pains of day-to-day systems programming in C. There is a lot of low-hanging fruit when it comes to systems programming if you're allowed to make a language from scratch and they've not really capitalized on much of that due to ambition.

regularfry 14y ago

I can't answer for the GP, but native code is generally better for me because of the startup time.

batista 14y ago

>Why do you prefer native code ? For me, because I don't want to install the JVM, or force users of my stuff to install the JVM. I also don't care about JVM libs. >What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). I, for one, mean non-JIT, no virtual machine needed, native code. >So maybe you mean static compilation, but then, why is it better for the stuff you're doing ? Less startup overhead. Small binaries. Easily redistributable. No stuff I don't need.

sanxiyn 14y ago
Does GCJ qualify? No JIT, no VM, native code, less startup overhead, easily redistributable.

exDM69 14y ago

> Why do you prefer native code ? What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). By native code I mean binaries emitted by my compiler in a format that my operating system can link and load. I usually write the code in C with some CPU-specific assembly intrinsics for the critical stuff. I tend to write computer graphics and physics simulation stuff which has to be quite fast. A lot of stuff I deal with is moving blobs of binary data from buffer to another (disk, memory, dma, gpu). Or computing a SIMD fused multiply-and-add for a few hundred megabytes of floating point data. Or invert and transpose a hundred thousand 4x4 matrices. Everything the JVM does is acting against me, so better just write native. Sure there are games and physics and whatnot written with Java and other systems, but they are more commonly "low perf" stuff. 2d games and that kind of stuff. And even then they suffer from JIT & GC pauses and other undesirable effects. It always ruins my day when in the middle of a Minecraft session the GC kicks in while running away from a Creeper.

jbooth 14y ago
That's all well and good, but wouldn't any LISP be way insufficient for your needs then? I mean, Java's going to be closer to C's performance than any LISP dialect until we have a "sufficiently smart compiler", right?
rayiner 14y ago
> I tend to write computer graphics and physics simulation stuff which has to be quite fast. A lot of stuff I deal with is moving blobs of binary data from buffer to another (disk, memory, dma, gpu). Or computing a SIMD fused multiply-and-add for a few hundred megabytes of floating point data. Or invert and transpose a hundred thousand 4x4 matrices. Everything the JVM does is acting against me, so better just write native. The JVM is very fast for these things. There remaining delta is the result of more investment into optimizations in GCC/LLVM than any limitation of the JVM model itself.
heretohelp 14y ago
This is the sort of thing I'm talking about, when I talk about the insufficiency of Java and other VM languages for high performance programming. It'd be nice if somebody made a new systems language to succeed C or C++. Rust is looking less likely these days. Maybe Clay or Deca?
- raphinou 14y ago
  Why is Rust less likely these days?
  - heretohelp 14y ago
    A thousand papercuts and a preoccupation with things that don't make it nicer to use. Supremely practical in a sense though. It's like the inverse of golang. golang is unimpressive, and totally impractical for systems programming, but is nice to use for general purpose programming. Rust is impressive and could'ish be used for systems programming (I'm not sure how much uphill fighting is involved with the current memory management model, it seems ARC is the default which makes me intensely uncomfortable about its prospects for 'hard' systems programming) but it's not very pleasant at all. The syntax and semantics make me nauseous. Rust can be fixed, golang cannot. Unlikely though. I'm not sure it's more realistic to make a practical implementation of region-based memory management than it is to ameliorate the pains of day-to-day systems programming in C. There is a lot of low-hanging fruit when it comes to systems programming if you're allowed to make a language from scratch and they've not really capitalized on much of that due to ambition.