On Wednesday, 23 July 2014 at 08:46:32 UTC, Russel Winder via Digitalmars-d wrote:
> On Tue, 2014-07-22 at 10:55 +0000, 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.

>>> 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.

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 +0000, 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

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

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

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.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2014-07-23 at 09:11 +0000, 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.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2014-07-23 at 09:16 +0000, 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.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

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.