81–90 of 373 posts
Well, I sure wish I knew how to make our Clojure dev server (`lein ring server`) take less than 2 minutes to start up on a 4 core i7 16GB MacBook Pro. Fortunately I typically only need to restart it when switching branches.
Earlier quoted context omitted.
If you investigate what they actually do to achieve those numbers, it's much less simple than just rewriting Cassandra in C++. For example, they use their own TCP stack and make use of vector intrinsics.
Hey.. "vector intrinsics" looks very cool. Thanks for mentioning that! so what you mean is that, even after throwing facebook scale resources at java.. it is possible for a That's a huge loss of face for java IMHO
Because the JVM JIT, like every other compiler, sucks at developing vectorized algorithms ad-hoc; a task usually carried out by human experts in that?
Earlier quoted context omitted.
In my mind, 1½ seconds is huge; that essentially rules out any interactive usage. It's even annoying for rapid development cycles. Only low expectations or heavy orchestration can overcome such a startling disadvantage.
That's completely false in the context of a Lisp. I boot the JVM once and iterate endlessly in the same process. Same for ClojureScript in the browser or node.js. Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK). 1.5 seconds would be huge if you had to constantly restart your application like you do everywhere outside Lisp. Iterating in Clojure is literally instant. I wro…
That's Forth. Lisp comes next.
Earlier quoted context omitted.
> 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs Where do you get these numbers from? On my five year old MacBook Pro with default JVM options parsing a 20 MB file: real 0m0.248s user 0m0.325s sys 0m0.043s > 2. Memory usage of Java objects is quite heavy. That's IBMs enterprise VM that uses three word headers. HotSpot is actually better. If you compare that with other "lightweight" prog…
> real 0m0.248s A quarter of a second to start up the VM, run some code, and exit again is actually pretty steep compared to typical interpreted and compiled languages. Among other things, this means that you can't really call Java executables from a loop in a shell script. For comparison purposes, both Ruby and Rust will show between "0.00 elapsed" and "0.02 elapsed" for a simple "Hello, world" program on my laptop.
To do a fair comparison, with your example, I just compiled and ran Hello World in Java on my machine and got this:
real 0.06 user 0.06 sys 0.01
Is this cognitive dissonance? Dishonesty? I don't understand.
Earlier quoted context omitted.
> 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs Where do you get these numbers from? On my five year old MacBook Pro with default JVM options parsing a 20 MB file: real 0m0.248s user 0m0.325s sys 0m0.043s > 2. Memory usage of Java objects is quite heavy. That's IBMs enterprise VM that uses three word headers. HotSpot is actually better. If you compare that with other "lightweight" prog…
> real 0m0.248s A quarter of a second to start up the VM, run some code, and exit again is actually pretty steep compared to typical interpreted and compiled languages. Among other things, this means that you can't really call Java executables from a loop in a shell script. For comparison purposes, both Ruby and Rust will show between "0.00 elapsed" and "0.02 elapsed" for a simple "Hello, world" program on my laptop.
Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…
> I wrote a simple tool that allows you to filter out what you don't need It'd be a short hop from here to a tool that basically does for JDK-platform apps what Erlang's releases do for the ERTS platform: builds a new JRE (as a portable executable, not an installer) that actually contains the app and its deps in the JRE's stdlib, such that you just end up with a dir containing "a JRE", plus a runtime "boot config" fi…
Earlier quoted context omitted.
And there are alternative JVMs that are specifically designed for that use case that don't behave the same way.
For examples: • the JVM on smart cards, e.g. EMV (chip) credit cards, or GSM cellular SIM cards • the JVM embedded into the Intel Management Engine coprocessor
First time I've heard that one. Got a source?
I agree with many points in this article. That being said, there are dimensions of heaviness not captured in the article as far as I can see: 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs, but the startup time of your application gets higher if you have a lot of classes on the classpath. I guess it's the classpath scanning that takes a lot of time (?). 2. Memory usage of Java objects i…
$ time java -jar target/uberjar/clojure.jar
Hello, World!
1.29s user 0.08s system 181% cpu 0.755 total
$ /usr/sbin/system_profiler -detailLevel full
Model Name: MacBook Pro
Model Identifier: MacBookPro11,3
Processor Name: Intel Core i7
Processor Speed: 2.3 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Memory: 16 GB