Clojure on Azul Zing JVM
317 views
Skip to first unread message
Piyush Katariya
May 17, 2018, 2:52:53 AM5/17/18
to Clojure
Is anybody using Clojure app on Azul Zing JVM ? It ships with LLVM based JIT and pauseless garbage collector.
How was the experience compared to Standard Oracle HotSpots JVM ?
Piyush Katariya
May 21, 2018, 10:45:24 AM5/21/18
to Clojure
Strange ! nobody using it ?
I saw the Rich Hickey's testimony on their site
Matching Socks
May 21, 2018, 8:00:28 PM5/21/18
to Clojure
IBM Java likewise has not excited very much conversation here. Perhaps because Java is "write once, run anywhere"! The various implementations of Java have their strong and weak points, but they will run Clojure in any case.
Timothy Baldridge
May 21, 2018, 11:28:23 PM5/21/18
to clo...@googlegroups.com
I've worked on several projects where Zing was considered as a solution to a few problems (normally GC pauses due to really large heaps). But in the end we never trailed it, due to a few factors:
1) Zing isn't super cheap, it's not that expensive in the grand scheme of things, but it's an additional cost that had to be added to a project, normally towards the end when heap sizes or other such things become a problem. So it's hard to go to management and ask for an increase in budget.
2) There really isn't a lot of documentation freely available as to how much Zing helps in a Clojure app. Chicken-and-egg problem here, need more experience reports to justify the cost, but it's hard to justify the cost of doing tests with such limited information.
3) Servers and ram are cheap in comparison. So often it was simply cheaper to create split services up, or partition data in a way that heap sizes could be reduced. Even something as simple as reducing the JVM heap size and using memecached on the same box was a cheaper way to solve the problem.
4) Algorithm changes were also cheaper. In a few cases we moved from using Clojure's persistent structures to off-heap structures like ChronicleMap or LevelDB. Or simply walk over the code in question and find ways of storing less in memory, or caching aggregates instead of whole collections.
In the end there's a theme here. At about 2/3rds of the way through the project we'd hit an issue with HotSpot and say (hey Zing would help here). But switching JVMs would require an additional investment. But we already had a team, so it was simpler to spin off a few developers and have them solve the worst of the issues and perhaps let a feature slip. In the end, a small feature not getting in is easier to justify than the purchase of a new JVM.
So I wish I could work with Zing someday, but each time I've gotten close, a cheaper solution has presented itself.
Timothy
1) Zing isn't super cheap, it's not that expensive in the grand scheme of things, but it's an additional cost that had to be added to a project, normally towards the end when heap sizes or other such things become a problem. So it's hard to go to management and ask for an increase in budget.
2) There really isn't a lot of documentation freely available as to how much Zing helps in a Clojure app. Chicken-and-egg problem here, need more experience reports to justify the cost, but it's hard to justify the cost of doing tests with such limited information.
3) Servers and ram are cheap in comparison. So often it was simply cheaper to create split services up, or partition data in a way that heap sizes could be reduced. Even something as simple as reducing the JVM heap size and using memecached on the same box was a cheaper way to solve the problem.
4) Algorithm changes were also cheaper. In a few cases we moved from using Clojure's persistent structures to off-heap structures like ChronicleMap or LevelDB. Or simply walk over the code in question and find ways of storing less in memory, or caching aggregates instead of whole collections.
In the end there's a theme here. At about 2/3rds of the way through the project we'd hit an issue with HotSpot and say (hey Zing would help here). But switching JVMs would require an additional investment. But we already had a team, so it was simpler to spin off a few developers and have them solve the worst of the issues and perhaps let a feature slip. In the end, a small feature not getting in is easier to justify than the purchase of a new JVM.
So I wish I could work with Zing someday, but each time I've gotten close, a cheaper solution has presented itself.
Timothy
On Mon, May 21, 2018 at 6:00 PM, Matching Socks <phill...@gmail.com> wrote:
IBM Java likewise has not excited very much conversation here. Perhaps because Java is "write once, run anywhere"! The various implementations of Java have their strong and weak points, but they will run Clojure in any case.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)
(Robert Firth)
Piyush Katariya
May 22, 2018, 2:26:18 AM5/22/18
to Clojure
Thanks Timothy for detailed insight, especially point #4.
In my case I usually use AWS for deployment.
AWS marketplace allows Azul Zing on Ubuntu at $0.2/hr ( $144 /month/ec2 instance + $10 flat fees = $1738 annually) for instances like i3.xlarge (30GB RAM, 4 CPU core), which is workable for me.It's actually half the annual price as mentioned on their site.
https://aws.amazon.com/marketplace/pp/B014KRTOOQ?qid=1526967549964&sr=0-8&ref_=srh_res_product_title
Don't get me wrong. By no means, I am associated with Azul company :). I believe in Buy option before considering Build option.
But I am tempted to the idea of changing your default JVM choice to Zing(or any other similar product if exists) for better performance instead of trying to make my stack complex and have more moving parts for maintenance in my architecture. They have really good success stories to share.
Also in many cases when we use Big Data or Distributed computation tools like Cascalog, Onyx, Datomic etc. or perhaps just plain simple CLJ Web app which uses NoSQL databases like Cassandra as primary database and ends up doing medium complex computation and custom aggregation would be greatly benefited. Azul Zing's C4 Garbage Collector can take care of fast garbage disposal across the giant JVM heap.
For caching we can use Hazelcast or Apache Ignite as an embedded library rather than using Memcached or Redis or LevelDB which need separate deployment and maintenance efforts.
Reply all
Reply to author
Forward
0 new messages