4 ms·

Well, I would agree if we are talking Java vs C# but platform in general im not quite sure. Rich Hickey for example said he had much more problems with the CLR

by nickik 12y ago

Well, I would agree if we are talking Java vs C# but platform in general im not quite sure. Rich Hickey for example said he had much more problems with the CLR and ended up mostly dropping it (could be diffrent knowdays). Competition can only be good, seams to me they are pretty much a wash at the moment. For me the JVM is much better because thats the prefered Clojure platform.

pjmlp 12y ago
- Ahead of time compilation since day 1. On JVM side you need to rely on commercial JVMs - Always JITs, there is no interpretation. Some JVMs do this as well. On the reference implementation, you need to set interpretation threshold to zero. - Tail Call Optimization. Eventually it will come to the JVM, after the bytecode verifier gets updated. - Reiffied generics. JVM 9 or maybe 10, depending on project evolution. - Value types. JVM 9 or maybe 10, depending on project evolution. - Better interop story. Oracle is now working on a JNI replacement for Java 9, maybe 10. - support for pointers in unsafe code - support for stack allocation - control over memory layouts > Rich Hickey for example said he had much more problems with the CLR and ended up mostly dropping it (could be diffrent knowdays). http://clojure.org/clojureclr http://clojure.org/clojureclr Quite up to date.
- vardump 12y ago
  Amen. Control over memory layouts. That would be truly useful for getting reasonable performance. And dropping memory required by the reference hell. Java doesn't support arrays for anything but basic types. Just boolean, byte, char, double, float, int, long. And (object|array) reference. Arrays in Java can have up to 2^31 entries. An array of 2^31 Objects takes 4 * 2^31 (8 GB), with compressed references. Plus of course 8 * 2^31 (8+16 GB) for java.lang.Objects that don't do anything. Smallest usable objects with at least one member would take 16 * 2^31 (8+32 GB) RAM. But this would prevent you from using compressed references (max 32GB heap), which would increase consumed memory to 16+32 GB. Like for example for 2 billion Integers. I realize you wouldn't store integer values this way, the point is integers are about the smallest useful objects imaginable. Java should have true object arrays (like C structs). And how do you align objects to say a cache line? You don't! It's hard to even avoid false sharing in Java. Practically impossible, because you can even get cross-object false sharing due to object memory alignment! Always JITs can be also a bad thing, why bother with code that is very rarely executed? If time it takes to compile + execute compiled version exceeds time it takes to interpret, why bother?

by nickik 12y ago

pjmlp 12y ago

- Ahead of time compilation since day 1. On JVM side you need to rely on commercial JVMs - Always JITs, there is no interpretation. Some JVMs do this as well. On the reference implementation, you need to set interpretation threshold to zero. - Tail Call Optimization. Eventually it will come to the JVM, after the bytecode verifier gets updated. - Reiffied generics. JVM 9 or maybe 10, depending on project evolution. - Value types. JVM 9 or maybe 10, depending on project evolution. - Better interop story. Oracle is now working on a JNI replacement for Java 9, maybe 10. - support for pointers in unsafe code - support for stack allocation - control over memory layouts > Rich Hickey for example said he had much more problems with the CLR and ended up mostly dropping it (could be diffrent knowdays). http://clojure.org/clojureclr http://clojure.org/clojureclr Quite up to date.

vardump 12y ago
Amen. Control over memory layouts. That would be truly useful for getting reasonable performance. And dropping memory required by the reference hell. Java doesn't support arrays for anything but basic types. Just boolean, byte, char, double, float, int, long. And (object|array) reference. Arrays in Java can have up to 2^31 entries. An array of 2^31 Objects takes 4 * 2^31 (8 GB), with compressed references. Plus of course 8 * 2^31 (8+16 GB) for java.lang.Objects that don't do anything. Smallest usable objects with at least one member would take 16 * 2^31 (8+32 GB) RAM. But this would prevent you from using compressed references (max 32GB heap), which would increase consumed memory to 16+32 GB. Like for example for 2 billion Integers. I realize you wouldn't store integer values this way, the point is integers are about the smallest useful objects imaginable. Java should have true object arrays (like C structs). And how do you align objects to say a cache line? You don't! It's hard to even avoid false sharing in Java. Practically impossible, because you can even get cross-object false sharing due to object memory alignment! Always JITs can be also a bad thing, why bother with code that is very rarely executed? If time it takes to compile + execute compiled version exceeds time it takes to interpret, why bother?