Re: Java compilation [was GCs in the news]
On Thu, 2014-07-24 at 11:39 +, Paulo Pinto via Digitalmars-d wrote: […] In this specific case yes, but as I mentioned there are lots of uses cases being reported. It turns out to be a known fact even in Gradleware. Hans mentions it specifically inhis vision for the future document of a month ago. He also mentions that the C/C++ build aspects of Gradle are to be used by the Android NDK folk. I already asked them about including D in the package, but the response was nobody uses D. So maybe we (I guess this mean I) should do a user contributed patch to add D to the whole thing. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Sunday, 27 July 2014 at 08:24:44 UTC, Russel Winder via Digitalmars-d wrote: On Thu, 2014-07-24 at 11:39 +, Paulo Pinto via Digitalmars-d wrote: […] In this specific case yes, but as I mentioned there are lots of uses cases being reported. It turns out to be a known fact even in Gradleware. Hans mentions it specifically inhis vision for the future document of a month ago. He also mentions that the C/C++ build aspects of Gradle are to be used by the Android NDK folk. I already asked them about including D in the package, but the response was nobody uses D. I am nobody. So maybe we (I guess this mean I) should do a user contributed patch to add D to the whole thing.
Re: Java compilation [was GCs in the news]
On Sun, 2014-07-27 at 12:51 +, Chris via Digitalmars-d wrote: On Sunday, 27 July 2014 at 08:24:44 UTC, Russel Winder via Digitalmars-d wrote: […] He also mentions that the C/C++ build aspects of Gradle are to be used by the Android NDK folk. I already asked them about including D in the package, but the response was nobody uses D. I am nobody. I was fairly appalled at the response so I have requested ability to clone the C/C++ stuff so as to add D and send in pull requests. Whatever anyone things of Gradle (or SCons) for D, it is looking more and more like Gradle is the route to build on Android. So if we want D on Android ensuring buildable with Gradle is a way of removing a hurdle. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On 7/23/2014 1:46 AM, Russel Winder via Digitalmars-d wrote: I think you'll find HotSpot evolved from a Smalltalk JIT originally. Borland and Semantec had JVM JITs as well, Sun even licenced the Semantec one for a while. Fun fact: the guy who wrote Symantec's JVM JIT, Steve Russell, is the very guy who wrote Optlink!
Re: Java compilation [was GCs in the news]
On Wed, 2014-07-23 at 22:58 +0200, Paulo Pinto via Digitalmars-d wrote: […] So far I could only find Looking into the JVM Crystal Ball http://www.parleys.com/play/524f6b5be4b0a43ac12123a9/about Between 00:40:00 and 00:45:50, compilation gets discussed, including AOT. Not the ones about Graal, though. I am pretty sure I saw a slide with it as part of the Java 9+ wishlist, now just have to remember if it was actually at JavaONE, Devoxx, FOSDEM or Jax. :\ I'll check this out. I am also getting the folk from the LJC who represent the LJC on the JCP EC (LJC is an elected members) to get a definitive statement on the road map. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Wed, 2014-07-23 at 21:32 +0200, Paulo Pinto via Digitalmars-d wrote: […] I only tried Graddle because of Android Studio, it makes so bad use of hardware resources, pegging my i7 and core duo processors, that I returned to Eclipse + ADT on the same day. I have not tried Android Studio for anything as yet. It is based on IntelliJ IDEA though (as is PyCharm) and IntelliJ IDEA beats Eclipse hands down for Java and Groovy working (as PyCharm beats Eclipse/PyDev hands down for Python). For me, YMMV. The situation is so bad it was even mentioned at this Google IO Android developer tools talk. I think this will be a JetBrains problem rather than a Gradle problem. This aborted my attempt to try to use Kotlin instead of C++ on my hobby Android projects. Kotlin is great fun, but I only use IntelliJ IDEA for that. As for our Fortune 500 customers portfolio, the ones using Java are still 100% in a mix of Ant and Maven. shudder/ I gave up Ant when I wrote Gant (*), and avoided Maven until Gradle arrived. Humans should not have to hand write XML ever. (*) Someone forked this to create the Groovy front end to Ant, which must beat the XML one any and every day of the week. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Wed, 2014-07-23 at 14:37 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 7/23/14, 12:23 PM, Russel Winder via Digitalmars-d wrote: BTW what's with the rabbit and the monkey? He promised his kid they'll go on an adventure with daddy. A really nice touch. I might steal it for my own talks. -- Andrei Excellent. Perhaps we should make the a thing. Every speaker must have their cuddly toy companion on stage. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Thursday, 24 July 2014 at 08:34:30 UTC, Russel Winder via Digitalmars-d wrote: On Wed, 2014-07-23 at 21:32 +0200, Paulo Pinto via Digitalmars-d wrote: […] The situation is so bad it was even mentioned at this Google IO Android developer tools talk. I think this will be a JetBrains problem rather than a Gradle problem. Nope, Gradle, as shown by the CPU usage on the task manager. -- Paulo
Re: Java compilation [was GCs in the news]
On Thu, 2014-07-24 at 09:38 +, Paulo Pinto via Digitalmars-d wrote: […] Nope, Gradle, as shown by the CPU usage on the task manager. I am surprised, but data always trumps opinion. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via Digitalmars-d wrote: On Thu, 2014-07-24 at 09:38 +, Paulo Pinto via Digitalmars-d wrote: […] Nope, Gradle, as shown by the CPU usage on the task manager. I am surprised, but data always trumps opinion. One of the first Google results, http://askubuntu.com/questions/469709/gradle-compiling-slows-down-my-computer You can find many more out there, in many combinations use cases.
Re: Java compilation [was GCs in the news]
On Thu, 2014-07-24 at 11:09 +, Paulo Pinto via Digitalmars-d wrote: On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via Digitalmars-d wrote: On Thu, 2014-07-24 at 09:38 +, Paulo Pinto via Digitalmars-d wrote: […] Nope, Gradle, as shown by the CPU usage on the task manager. I am surprised, but data always trumps opinion. One of the first Google results, http://askubuntu.com/questions/469709/gradle-compiling-slows-down-my-computer You can find many more out there, in many combinations use cases. Looks like Android Studio tells Gradle to use the number of threads that there are cores, so this is an Android Studio problem, not a Gradle problem per se. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Thursday, 24 July 2014 at 11:35:09 UTC, Russel Winder via Digitalmars-d wrote: On Thu, 2014-07-24 at 11:09 +, Paulo Pinto via Digitalmars-d wrote: On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via Digitalmars-d wrote: On Thu, 2014-07-24 at 09:38 +, Paulo Pinto via Digitalmars-d wrote: […] Nope, Gradle, as shown by the CPU usage on the task manager. I am surprised, but data always trumps opinion. One of the first Google results, http://askubuntu.com/questions/469709/gradle-compiling-slows-down-my-computer You can find many more out there, in many combinations use cases. Looks like Android Studio tells Gradle to use the number of threads that there are cores, so this is an Android Studio problem, not a Gradle problem per se. In this specific case yes, but as I mentioned there are lots of uses cases being reported. -- Paulo
Re: Java compilation [was GCs in the news]
On Tue, 2014-07-22 at 10:55 +, Paulo Pinto via Digitalmars-d wrote: […] The JVM JIT was originally targeted to SELF, not Java. I think you'll find HotSpot evolved from a Smalltalk JIT originally. Borland and Semantec had JVM JITs as well, Sun even licenced the Semantec one for a while. […] Functional programming languages have AOT compilers and they perform quite well, almost to C level in many use case cases. True. Java/JVM/JIT also performs very well surpassing C in many cases. Indeed C++ surpasses C in many cases as well. As for Groovy, I always felt the implementation was always lacking in performance. True. Groovy is a dynamic language not intended for performance computation. However it now has static compilation to JVM bytcodes as well which leads to it being as fast or sometimes faster than Java. I avoid touching Gradle. Your loss! For others: Gradle is becoming the de facto standard build framework for JVM-based things and also Android. […] I was discussing JIT vs AOT in abstract. The trouble is that this isn't a good way of discussing what is a performance issue that can only be decided by comparative benchmarks. To be able to perform such a tests you need: - A programming language X In the case at hand X = Java. - The state of the art JIT compiler implementation for the given language I guess HotSpot is the default here, unless anyone has access to the IBM VM. - The state of the art AOT compiler implementation for the given language I know a few commercial AOT compilers for Java, not sure which one would be the best one to choose. I am not sure which I would go with here as I have little experience of the high cost products. We'd have to get some sponsorship for the benchmarks. I will ask around the folks in the JVM performance community. But the proof is Microsoft adding .NET Native to their toolchain, Google replacing Dalvik with AOT and Oracle has added AOT compilation (Substract) to Graal, the candidate to Hotspot replacement. Graal isn't a replacement for HotSpot but a dynamic compilation technology to work with HotSpot. It is actually a very promising technology, I am looking forward to trying it out. So apparently they all agree AOT still wins in many scenarios. Why is it one or the other? Having both AOT and JIT will likely do even better. Hence Graal on HotSpot. Certainly AOT putting the burden on compilation, ensures there is no start-up overhead, so is a benefit for short running systems. JIT has an initial (often large) overhead but once triggered produces highly performant (localized) code. Java is going to have to find the balance to stay up with the performance needed these days. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Wednesday, 23 July 2014 at 08:46:32 UTC, Russel Winder via Digitalmars-d wrote: On Tue, 2014-07-22 at 10:55 +, Paulo Pinto via Digitalmars-d wrote: […] I avoid touching Gradle. Your loss! For others: Gradle is becoming the de facto standard build framework for JVM-based things and also Android. I will happily use it when it gets to the same execution speed and hardware resources than Eclipse + ADT is currently using. […] But the proof is Microsoft adding .NET Native to their toolchain, Google replacing Dalvik with AOT and Oracle has added AOT compilation (Substract) to Graal, the candidate to Hotspot replacement. Graal isn't a replacement for HotSpot but a dynamic compilation technology to work with HotSpot. It is actually a very promising technology, I am looking forward to trying it out. Yes it is. It was presented as such at JavaONE for possible future Java 9+ improvements. I can try to dig out the presentation, if you wish. [...] Why is it one or the other? Having both AOT and JIT will likely do even better. Hence Graal on HotSpot. I agree in the cases the toolchain offers both possibilities out of the box and does not force developers to choose among different vendors toolchains. -- Paulo
Re: Java compilation [was GCs in the news]
On Wednesday, 23 July 2014 at 08:46:32 UTC, Russel Winder via Digitalmars-d wrote: On Tue, 2014-07-22 at 10:55 +, Paulo Pinto via Digitalmars-d wrote: […] The JVM JIT was originally targeted to SELF, not Java. I think you'll find HotSpot evolved from a Smalltalk JIT originally. Borland and Semantec had JVM JITs as well, Sun even licenced the Semantec one for a while. […] Functional programming languages have AOT compilers and they perform quite well, almost to C level in many use case cases. True. Java/JVM/JIT also performs very well surpassing C in many cases. Indeed C++ surpasses C in many cases as well. I am suspicious. I understand that a situation can be contrived such that C will lose, but in normal, sensible code the only language I've ever seen reliably beat C is FORTRAN.
Re: Java compilation [was GCs in the news]
The JVM JIT was originally targeted to SELF, not Java. Yes, that's right. The guys that developed Self (David Ungar et al.) then set out to develop a high-performance typed Smalltalk using the optimization techniques they developed for Self. The Smalltalk system never hit the market as the development team was acquired by Sun before that could happen. The Smalltalk system they were working on was released to the public: http://www.strongtalk.org/ I think you'll find HotSpot evolved from a Smalltalk JIT originally. The reason I replied to this is that the original technology developed for Self was not a JIT. It was a runtime byte code optimizer that was put into Java named HotSpot. Since HotSpot operates at runtime it can optimize things an optimizing compiler could not find at compile time. This is why Java sometimes catches up very good performance and in isolated cases can compete with C.
Re: Java compilation [was GCs in the news]
On Wednesday, 23 July 2014 at 09:16:57 UTC, John Colvin wrote: On Wednesday, 23 July 2014 at 08:46:32 UTC, Russel Winder via Digitalmars-d wrote: On Tue, 2014-07-22 at 10:55 +, Paulo Pinto via Digitalmars-d wrote: […] The JVM JIT was originally targeted to SELF, not Java. I think you'll find HotSpot evolved from a Smalltalk JIT originally. Borland and Semantec had JVM JITs as well, Sun even licenced the Semantec one for a while. […] Functional programming languages have AOT compilers and they perform quite well, almost to C level in many use case cases. True. Java/JVM/JIT also performs very well surpassing C in many cases. Indeed C++ surpasses C in many cases as well. I am suspicious. I understand that a situation can be contrived such that C will lose, but in normal, sensible code the only language I've ever seen reliably beat C is FORTRAN. http://benchmarksgame.alioth.debian.org/ There's no good reason for C to beat C++. Even if there were, it would be simple to rewrite the C++ bottleneck in C style. Likewise, there's no good reason for C to beat D either. I was surprised by the Java results once they started beating C at certain benchmarks years ago. But the fact is it does. Atila
Re: Java compilation [was GCs in the news]
On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote: For others: Gradle is becoming the de facto standard build framework for JVM-based things and also Android. Uhm, I'm literally right now in a talk on Buck (https://github.com/facebook/buck) at OSCON. -- Andrei
Re: Java compilation [was GCs in the news]
On 7/23/14, 11:40 AM, Andrei Alexandrescu wrote: On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote: For others: Gradle is becoming the de facto standard build framework for JVM-based things and also Android. Uhm, I'm literally right now in a talk on Buck (https://github.com/facebook/buck) at OSCON. -- Andrei Fresh photo comparing buck with gradle: http://i.imgur.com/uGHdfyq.jpg -- Andrei
Re: Java compilation [was GCs in the news]
On Wed, 2014-07-23 at 11:45 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 7/23/14, 11:40 AM, Andrei Alexandrescu wrote: On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote: For others: Gradle is becoming the de facto standard build framework for JVM-based things and also Android. Uhm, I'm literally right now in a talk on Buck (https://github.com/facebook/buck) at OSCON. -- Andrei Fresh photo comparing buck with gradle: http://i.imgur.com/uGHdfyq.jpg -- Andrei Were any of the Gradleware folk there, that should really scare them. BTW what's with the rabbit and the monkey? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Wed, 2014-07-23 at 09:11 +, Paulo Pinto via Digitalmars-d wrote: […] I will happily use it when it gets to the same execution speed and hardware resources than Eclipse + ADT is currently using. The way I work with Gradle is to generate Eclipse or IntelliJ IDEA projects if I am going to use Eclipse or IntelliJ IDEA. […] Graal isn't a replacement for HotSpot but a dynamic compilation technology to work with HotSpot. It is actually a very promising technology, I am looking forward to trying it out. Yes it is. It was presented as such at JavaONE for possible future Java 9+ improvements. I can try to dig out the presentation, if you wish. Clearly I need to update my knowledge! […] I agree in the cases the toolchain offers both possibilities out of the box and does not force developers to choose among different vendors toolchains. I am trying to get folk in the JVM benchmarking trade to tell me what the latest SP is on things. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Wed, 2014-07-23 at 09:16 +, John Colvin via Digitalmars-d wrote: […] I am suspicious. I understand that a situation can be contrived such that C will lose, but in normal, sensible code the only language I've ever seen reliably beat C is FORTRAN. For my data parallel computations, I find C++ with TBB tends to be the winner. C, C++ and Fortran (not FORTRAN!) with OpenMP do fairly well. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
Am 23.07.2014 21:23, schrieb Russel Winder via Digitalmars-d: On Wed, 2014-07-23 at 11:45 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 7/23/14, 11:40 AM, Andrei Alexandrescu wrote: On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote: For others: Gradle is becoming the de facto standard build framework for JVM-based things and also Android. Uhm, I'm literally right now in a talk on Buck (https://github.com/facebook/buck) at OSCON. -- Andrei Fresh photo comparing buck with gradle: http://i.imgur.com/uGHdfyq.jpg -- Andrei Were any of the Gradleware folk there, that should really scare them. BTW what's with the rabbit and the monkey? I only tried Graddle because of Android Studio, it makes so bad use of hardware resources, pegging my i7 and core duo processors, that I returned to Eclipse + ADT on the same day. The situation is so bad it was even mentioned at this Google IO Android developer tools talk. This aborted my attempt to try to use Kotlin instead of C++ on my hobby Android projects. As for our Fortune 500 customers portfolio, the ones using Java are still 100% in a mix of Ant and Maven. -- Paulo
Re: Java compilation [was GCs in the news]
On Wednesday, 23 July 2014 at 09:16:57 UTC, John Colvin wrote: I am suspicious. I understand that a situation can be contrived such that C will lose, but in normal, sensible code the only language I've ever seen reliably beat C is FORTRAN. I'm reminded of when headlines came out saying PyPy was now faster than C in some cases. I got pretty excited (that's an impressive feat of engineering) but upon looking into it, it turned out it was just inlining better than C because the C code was making a function call into another library. LTCG/LTO wasn't even uncommon at the time and would have easily handled that case had it been enabled.
Re: Java compilation [was GCs in the news]
Am 23.07.2014 21:27, schrieb Russel Winder via Digitalmars-d: On Wed, 2014-07-23 at 09:11 +, Paulo Pinto via Digitalmars-d wrote: […] It was presented as such at JavaONE for possible future Java 9+ improvements. I can try to dig out the presentation, if you wish. Clearly I need to update my knowledge! So far I could only find Looking into the JVM Crystal Ball http://www.parleys.com/play/524f6b5be4b0a43ac12123a9/about Between 00:40:00 and 00:45:50, compilation gets discussed, including AOT. Not the ones about Graal, though. I am pretty sure I saw a slide with it as part of the Java 9+ wishlist, now just have to remember if it was actually at JavaONE, Devoxx, FOSDEM or Jax. :\ -- Paulo
Re: Java compilation [was GCs in the news]
On 7/23/14, 12:23 PM, Russel Winder via Digitalmars-d wrote: BTW what's with the rabbit and the monkey? He promised his kid they'll go on an adventure with daddy. A really nice touch. I might steal it for my own talks. -- Andrei
Re: Java compilation [was GCs in the news]
On Wednesday, 23 July 2014 at 11:54:19 UTC, Atila Neves wrote: http://benchmarksgame.alioth.debian.org/ There's no good reason for C to beat C++. Even if there were, it would be simple to rewrite the C++ bottleneck in C style. Likewise, there's no good reason for C to beat D either. I was surprised by the Java results once they started beating C at certain benchmarks years ago. But the fact is it does. Atila It usually does in memory intensive benchmark that aren't multithreaded. Java's GC is a free shot of concurrency that C won't get.
Re: Java compilation [was GCs in the news]
On Wednesday, 23 July 2014 at 18:45:23 UTC, Andrei Alexandrescu wrote: On 7/23/14, 11:40 AM, Andrei Alexandrescu wrote: On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote: For others: Gradle is becoming the de facto standard build framework for JVM-based things and also Android. Uhm, I'm literally right now in a talk on Buck (https://github.com/facebook/buck) at OSCON. -- Andrei Fresh photo comparing buck with gradle: http://i.imgur.com/uGHdfyq.jpg -- Andrei Say hi to Simon :)
Re: Java compilation [was GCs in the news]
On Tue, 2014-07-22 at 06:35 +, Paulo Pinto via Digitalmars-d wrote: […] Yes it can, if developers bother to do PGO + AOT instead and learn the compiler flags. I used to have a stronger opinion on JIT, but given how many JITs perform and do not actually use the hardware as they, in theory could, JIT tend to only be an advantage for dynamic languages not strong typed ones. With JIT, writing the code in a way that makes the JIT compiler happy is a lost battle, as it depends on the exact same JIT implementation being available on the deployment system. I think you have to make good on this claim since the JVM JIT is intended for Java which is supposedly a static, strongly typed language. Moreover, evidence from Groovy is the JVM JIT provides only patchy benefit. The biggest benefit all round is invokedynamic for both static and dynamic languages. Java 8 would be nothing without invokedynamic. But maybe we should take this off this list as it is way off topic. Clearly we can use JMH for benchmarking. I have a couple of codes I could use to try things out. So: 1. How to compile and execute to get full AOT *and* switch off the JIT. 2. How to compile and execute to get no AOT and have JIT on full. then we can begin to compare. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Java compilation [was GCs in the news]
On Tuesday, 22 July 2014 at 08:10:31 UTC, Russel Winder via Digitalmars-d wrote: On Tue, 2014-07-22 at 06:35 +, Paulo Pinto via Digitalmars-d wrote: […] Yes it can, if developers bother to do PGO + AOT instead and learn the compiler flags. I used to have a stronger opinion on JIT, but given how many JITs perform and do not actually use the hardware as they, in theory could, JIT tend to only be an advantage for dynamic languages not strong typed ones. With JIT, writing the code in a way that makes the JIT compiler happy is a lost battle, as it depends on the exact same JIT implementation being available on the deployment system. I think you have to make good on this claim since the JVM JIT is intended for Java which is supposedly a static, strongly typed language. The JVM JIT was originally targeted to SELF, not Java. Moreover, evidence from Groovy is the JVM JIT provides only patchy benefit. The biggest benefit all round is invokedynamic for both static and dynamic languages. Java 8 would be nothing without invokedynamic. Functional programming languages have AOT compilers and they perform quite well, almost to C level in many use case cases. As for Groovy, I always felt the implementation was always lacking in performance. I avoid touching Gradle. But maybe we should take this off this list as it is way off topic. Clearly we can use JMH for benchmarking. I have a couple of codes I could use to try things out. So: 1. How to compile and execute to get full AOT *and* switch off the JIT. 2. How to compile and execute to get no AOT and have JIT on full. then we can begin to compare. I was discussing JIT vs AOT in abstract. To be able to perform such a tests you need: - A programming language X - The state of the art JIT compiler implementation for the given language - The state of the art AOT compiler implementation for the given language I know a few commercial AOT compilers for Java, not sure which one would be the best one to choose. But the proof is Microsoft adding .NET Native to their toolchain, Google replacing Dalvik with AOT and Oracle has added AOT compilation (Substract) to Graal, the candidate to Hotspot replacement. So apparently they all agree AOT still wins in many scenarios. -- Paulo
