On Friday, 20 September 2013 at 05:31:09 UTC, Dmitry Leskov wrote:
> Our AOT compiler does inline virtual calls of non-final methods that are not overloaded in any subclass known at compile time. Of course, there is a runtime check and a backup virtual call, but the check is cheap and code size increase in negligible.
>
> What we don't do (yet) is profile-guided optimizations, but that is on our to-do list.
>

So basically what you do is :

funptr = load from vtbl;
if (funptr == compile_time_known_value) {
    compile_time_known_value();
} else {
    funptr();
}

Which avoid the indirection if the function is actually called most of the time. Am I right ?

On 9/20/13, deadalnix <deadalnix@gmail.com> wrote:
> So basically what you do is :
>
> funptr = load from vtbl;
> if (funptr == compile_time_known_value) {
>      compile_time_known_value();
> } else {
>      funptr();
> }

OT: This reminds me of a small benchmark I did recently where using a signal implementation with two pointers (function and delegate, to allow connecting to both) is faster than using a single delegate and converting a function pointer to a delegate via toDelegate(). It boiled down to:

if (funcPtr !is null)
    funcPtr(...);
else
if (delegPtr !is null)
    delegPtr(...);

On 19/09/2013 19:44, Paulo Pinto wrote:
> Am 19.09.2013 19:44, schrieb Bruno Medeiros:
>> On 19/09/2013 11:06, deadalnix wrote:
>>>
>>>>> *Java's sluggish performance was what made me look for alternatives
>>>>> in the first place, and I found D.
>>>>
>>>> I accept this as true as it is a statement by you about your decision
>>>> making, but Java 8 is not Java 1. Early desktop Java was pure
>>>> interpretation, and hence slow. Modern Java, via the JIT, generally
>>>> executes native code. With Java 7 and method handles and invokedynamic,
>>>> the world changed even more and now computationally intensive codes can
>>>> run basically as fast using Java as using C, C++, Fortran, D, Rust, Go.
>>>> (After initial "warm up" of the JIT.)
>>>>
>>>
>>> Yes, the warm up is usually a severe drawback for user applications.
>>> Server app do not suffer from it that much. I guess that is why java is
>>> so much used server side, but not that much to create GUI apps.
>>
>> Yeah, tell me about it. :/
>> When I was writing the new parser for DDT I explored and tested a few
>> optimizations that the JVM does to ellide object allocations
>> (essentially escape analysis to see when an object can be treated as
>> value object, and deallocated automatically at the end of some scope).
>> I wanted to use a certain pervasive code idiom in the parser that would
>> make the code more elegant, but less performant if this optimization was
>> not made.
>> ( http://www.meetup.com/Londonjavacommunity/messages/52187462/ )
>> Fortunately the JVM is its later incarnations is quite smart in its
>> escape analysis, but unfortunately this is all done at runtime, whereas
>> a lot of it could be performed compile-time. :( But it seems the Java
>> folks (at least for OpenJDK) have a big aversion to performing any kind
>> of compile-time optimizations, even though a lot could be done here.
>>
>>
>
>
> I once read in a blog, an entry from an ex-JVM engineer from Sun,
> describing that anything that disputed Hotspot JIT capabilities was tabu
> and ideas about native compilation were frowned upon.
>
> Sadly I don't remember any longer where I read it.
>
> --
> Paulo

Even without seeing that article, I can well believe it. It seems they shun away completely from compile-time optimizations, and not much reasoning is given to that. It seems almost a purely political/marketing move: like if they want to push the mantra that JITing is the be all and end all of compiler optimization, and doing any kind of compile-time optimization would be admitting that compile-time is also important (and somehow making Java more prone to direct performance comparisons to other languages/platforms?)

-- 
Bruno Medeiros - Software Engineer

On Friday, 20 September 2013 at 10:41:39 UTC, Bruno Medeiros wrote:
> Even without seeing that article, I can well believe it. It seems they shun away completely from compile-time optimizations, and not much reasoning is given to that. It seems almost a purely political/marketing move: like if they want to push the mantra that JITing is the be all and end all of compiler optimization, and doing any kind of compile-time optimization would be admitting that compile-time is also important (and somehow making Java more prone to direct performance comparisons to other languages/platforms?)

Perhaps you're being a little paranoid. I think they don't want to do optimization in the compiler because this would remove the incentive/pressure to implement those optimizations in the JVM, which is bad for all other languages/compilers that target the JVM. For the JVM-ecosystem it is best if as many optimizations possible are implemented in the JVM.

If you look at existing benchmarks Java is comparable to many other languages/platforms with regard to performance.

On Thursday, 19 September 2013 at 23:37:05 UTC, Russel Winder wrote:
>
> I do note though that The Disruptor (by LMAX) is a seriously cool lock
> free ring buffer based system written entirely in Java.

The Apache Cassandra distributed database is using it in its latest incarnation, among other things.

On Thursday, 19 September 2013 at 09:48:15 UTC, Joakim wrote:
> On Thursday, 19 September 2013 at 08:26:03 UTC, Russel Winder wrote:
>> Java is no longer under-performant compared to C, C++, Fortran, D, Go, Rust. Check the benchmarks.
> Interesting.  Java people have been saying this for years and it's never been quite true, so I just looked up the benchmark shootout to see if you're right.  It shows Java 7 doing pretty well against C++ these days, roughly equivalent speed or at worst half as fast:
>
> http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&data=u64q
> [...]

It doesn't do that well when single core is selected (always slower, 4x worst case):

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=java&lang2=gpp&data=u64

It means that Java VM/libraries can explore multiple cores better that C++.

On Sunday, 22 September 2013 at 02:04:11 UTC, Paul Jurczak wrote:
> On Thursday, 19 September 2013 at 09:48:15 UTC, Joakim wrote:
>> On Thursday, 19 September 2013 at 08:26:03 UTC, Russel Winder wrote:
>>> Java is no longer under-performant compared to C, C++, Fortran, D, Go, Rust. Check the benchmarks.
>> Interesting.  Java people have been saying this for years and it's never been quite true, so I just looked up the benchmark shootout to see if you're right.  It shows Java 7 doing pretty well against C++ these days, roughly equivalent speed or at worst half as fast:
>>
>> http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&data=u64q
>> [...]
>
> It doesn't do that well when single core is selected (always slower, 4x worst case):
>
> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=java&lang2=gpp&data=u64
>
> It means that Java VM/libraries can explore multiple cores better that C++.

Which in a day and age that you can hardly buy single core machines, is a big advantage.


--
Paulo

On Friday, 20 September 2013 at 07:19:44 UTC, deadalnix wrote:
> On Friday, 20 September 2013 at 05:31:09 UTC, Dmitry Leskov wrote:
>> Our AOT compiler does inline virtual calls of non-final methods that are not overloaded in any subclass known at compile time. Of course, there is a runtime check and a backup virtual call, but the check is cheap and code size increase in negligible.
>>
>> What we don't do (yet) is profile-guided optimizations, but that is on our to-do list.
>>
>
> So basically what you do is :
>
> funptr = load from vtbl;
> if (funptr == compile_time_known_value) {
>     compile_time_known_value();
> } else {
>     funptr();
> }
>
> Which avoid the indirection if the function is actually called most of the time. Am I right ?

Almost:

funptr = load from vtbl;
if (funptr == compile_time_known_value) {
    // Inlined body of compile_time_known_value() goes here
} else {
    funptr();
}

On Friday, 20 September 2013 at 05:23:15 UTC, Dmitry Leskov wrote:
> On Thursday, 19 September 2013 at 09:44:30 UTC, Chris wrote:
>> Yes, the whole issue of decompilation was also an issue. Funnily enough, a few years ago I wrote an email to Excelsior asking if you guys offer a discount for academia. Our project would have qualified as "non-commercial use". But I never got an answer. So I started looking for alternatives, and here I am now :-)
>
> We respond to all requests that look legit. Sending from a university email address certainly helps, not least because our responses to free email users, especially Gmail, often end up in the Junk Mail folder, probably because they talk about "free", "download", and such...
>
> --
> Dmitry

I sent the email from my university email address and the spam filter is clever enough to know that it shouldn't filter answers from email addresses I have sent an email to, even if the words "free" etc appear. If in doubt, at least it asks me. Anyway, I switched to D and don't regret it. Also how do you define "legit"? If I send an email with a simple question "do you offer a discount for university projects?" or the like, why am I not entitled to an answer? Why is it not "legit"? Because I didn't include an elaborate description of the project? Why should I, if I don't even know that you offer a discount? Would be a waste of time, if the answer is a plain "No!". This said, I don't rule it out that you answered the email and that it got lost on the way. This happens sometimes.

On Tuesday, 24 September 2013 at 09:17:47 UTC, Chris wrote:
> On Friday, 20 September 2013 at 05:23:15 UTC, Dmitry Leskov wrote:
>> On Thursday, 19 September 2013 at 09:44:30 UTC, Chris wrote:
>>> Yes, the whole issue of decompilation was also an issue. Funnily enough, a few years ago I wrote an email to Excelsior asking if you guys offer a discount for academia. Our project would have qualified as "non-commercial use". But I never got an answer. So I started looking for alternatives, and here I am now :-)
>>
>> We respond to all requests that look legit. Sending from a university email address certainly helps, not least because our responses to free email users, especially Gmail, often end up in the Junk Mail folder, probably because they talk about "free", "download", and such...
>>
>> --
>> Dmitry
>
> I sent the email from my university email address and the spam filter is clever enough to know that it shouldn't filter answers from email addresses I have sent an email to, even if the words "free" etc appear. If in doubt, at least it asks me. Anyway, I switched to D and don't regret it. Also how do you define "legit"? If I send an email with a simple question "do you offer a discount for university projects?" or the like, why am I not entitled to an answer? Why is it not "legit"? Because I didn't include an elaborate description of the project? Why should I, if I don't even know that you offer a discount? Would be a waste of time, if the answer is a plain "No!". This said, I don't rule it out that you answered the email and that it got lost on the way. This happens sometimes.

If you asked a question like that, we most definitely responded. If you still have that email you sent us back in the day, would you please forward it to me?

My email address is on the Contact page of our Web site.