4 ms·

It's an implementation problem of Java. I never understood why the JVM folks didn't get along to develop a JIT cache. That means the first time I start a Java

It's an implementation problem of Java. I never understood why the JVM folks didn't get along to develop a JIT cache. That means the first time I start a Java program it would run normally slow. But from the second run on it would use the native cache and run immediately fast with native performance. That would eliminate many performance problems of Java. I know that there already is a solution which uses a Java server to serve the application as client which reduces the startup time but this is not very convenient to use. The slowness of Clojure is a typical problem of all languages which are based on JVM. Racket Scheme, for instance, which is a Lisp like language but NOT based on JVM, needs just 0.062s to print "Hello World" (compiled) on my system.

bad_user 14y ago
For dynamic languages such as Clojure or JRuby, a "JIT cache" would do no good.
- brlewis 14y ago
  Don't assume that an interactive language is necessarily interpreted. Clojure compiles to JVM bytecodes: http://clojure.org/compilation http://clojure.org/compilation
CountHackulus 14y ago
That "JIT cache" you're talking about already exists. It's known as AOT, or "Ahead of Time" compilation. I forget how you enable it, but it's there.
- ithkuil 14y ago
  if you mean clojure AOT, it precompiles clojure to jvm bytecode. Usually the term JIT in this context is used to describe the native code generated by the VM on the flight, not the on the flight VM bytecode generation performed by a higher level language like clojure. EDIT: sorry, probably your referred to http://publib.boulder.ibm.com/infocenter/java7sdk/v7r0/topic/com.ibm.java.win.70.doc/diag/understanding/aot.html http://publib.boulder.ibm.com/infocenter/java7sdk/v7r0/topic...
  - bitcracker 14y ago
    According to this link precompilation with AOT produces worse results than normal JIT execution. If so, what is AOT useful for? "Da AOT-Code über verschiedene Programmausführungen hinweg bestehen bleiben muss, ist die Leistung von mit AOT generiertem Code nicht so gut wie die von mit JIT generiertem Code."
    - CountHackulus 14y ago
      It helps with startup time. It's not that it produces worse code, it's that there's multiple levels of compilation. It stores the equivalent of -O1 on disk, and eventually some of the code can ramp up to -O3+. This is almost entirely to help startup time so that you don't have a bunch of code trying to compile during startup.
ww520 14y ago
Did you read the article? The majority of the Clojure startup time is spent on initializing the Clojure runtime. "spends 95% of the startup-time loading the clojure.core namespace (the clojure.lang.RT class in particular) and filling out all the metadata/docstrings etc for the methods. This process stresses the GC quite a bit, some 130k objects are allocated and 90k free-d during multiple invokes of the GC (3-6 times), the building up of meta data is one big source of this massive object churn."
- bitcracker 14y ago
  > The majority of the Clojure startup time is spent on initializing the Clojure runtime. That's correct but even without this startup time Clojure is significantly slower than other functional languages. Look at SBCL and Racket in http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... That doesn't mean that I don't like Clojure. I am even considering it for a business project. But Clojure is definitely unsuitable for small apps (shell scripts etc.) Btw the benchmark listing doesn't take LuaJIT into account. This JIT is the fastest I have ever encountered, way ahead of JVM regarding startup time.

bad_user 14y ago

For dynamic languages such as Clojure or JRuby, a "JIT cache" would do no good.

brlewis 14y ago
Don't assume that an interactive language is necessarily interpreted. Clojure compiles to JVM bytecodes: http://clojure.org/compilation http://clojure.org/compilation

CountHackulus 14y ago

That "JIT cache" you're talking about already exists. It's known as AOT, or "Ahead of Time" compilation. I forget how you enable it, but it's there.

ithkuil 14y ago
if you mean clojure AOT, it precompiles clojure to jvm bytecode. Usually the term JIT in this context is used to describe the native code generated by the VM on the flight, not the on the flight VM bytecode generation performed by a higher level language like clojure. EDIT: sorry, probably your referred to http://publib.boulder.ibm.com/infocenter/java7sdk/v7r0/topic/com.ibm.java.win.70.doc/diag/understanding/aot.html http://publib.boulder.ibm.com/infocenter/java7sdk/v7r0/topic...
- bitcracker 14y ago
  According to this link precompilation with AOT produces worse results than normal JIT execution. If so, what is AOT useful for? "Da AOT-Code über verschiedene Programmausführungen hinweg bestehen bleiben muss, ist die Leistung von mit AOT generiertem Code nicht so gut wie die von mit JIT generiertem Code."
  - CountHackulus 14y ago
    It helps with startup time. It's not that it produces worse code, it's that there's multiple levels of compilation. It stores the equivalent of -O1 on disk, and eventually some of the code can ramp up to -O3+. This is almost entirely to help startup time so that you don't have a bunch of code trying to compile during startup.

ww520 14y ago

Did you read the article? The majority of the Clojure startup time is spent on initializing the Clojure runtime. "spends 95% of the startup-time loading the clojure.core namespace (the clojure.lang.RT class in particular) and filling out all the metadata/docstrings etc for the methods. This process stresses the GC quite a bit, some 130k objects are allocated and 90k free-d during multiple invokes of the GC (3-6 times), the building up of meta data is one big source of this massive object churn."

bitcracker 14y ago
> The majority of the Clojure startup time is spent on initializing the Clojure runtime. That's correct but even without this startup time Clojure is significantly slower than other functional languages. Look at SBCL and Racket in http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... That doesn't mean that I don't like Clojure. I am even considering it for a business project. But Clojure is definitely unsuitable for small apps (shell scripts etc.) Btw the benchmark listing doesn't take LuaJIT into account. This JIT is the fastest I have ever encountered, way ahead of JVM regarding startup time.