On Thursday, 19 September 2013 at 13:55:34 UTC, Olivier Pisano wrote:
> On Wednesday, 18 September 2013 at 23:53:35 UTC, Iain Buclaw wrote:
>>
>> Java itelf is a very basic language to allow this to be possible.  But
>> the library implementation denies this, and I don't see native support
>> beyond JNI.
>
> Native Java won't be a problem for D if they keep JNI for talking to the system. I wish I never had to work with JNI in multithreaded environment. All the type information goes away and their global reference system is impossible to use with RAII correctly.
>
> D's ability of using a C function just by declaring it and linking with C code is a bless.

That I fully agree.

On Thursday, 19 September 2013 at 13:05:17 UTC, PauloPinto wrote:
> Wrong. The Java AOT compilers that target embedded systems produce static binaries.
>

I don't think that address anything. As long as you CAN dynamically load override, then you can't optimize AOT, and if you can't then, it isn't java, but some kind of java like dialect that is amputed of some of its capabilities.

On Thursday, 19 September 2013 at 14:28:04 UTC, deadalnix wrote:
> On Thursday, 19 September 2013 at 13:05:17 UTC, PauloPinto wrote:
>> Wrong. The Java AOT compilers that target embedded systems produce static binaries.
>>
>
> I don't think that address anything. As long as you CAN dynamically load override, then you can't optimize AOT, and if you can't then, it isn't java, but some kind of java like dialect that is amputed of some of its capabilities.

Why would you dynamically load firmware during code execution?

This is for embedded systems.

--
Paulo

On Thursday, 19 September 2013 at 13:55:34 UTC, Olivier Pisano wrote:
> D's ability of using a C function just by declaring it and linking with C code is a bless.

Amen!

On Thursday, 19 September 2013 at 14:28:04 UTC, deadalnix wrote:
> On Thursday, 19 September 2013 at 13:05:17 UTC, PauloPinto wrote:
>> Wrong. The Java AOT compilers that target embedded systems produce static binaries.
>>
>
> I don't think that address anything. As long as you CAN dynamically load override, then you can't optimize AOT, and if you can't then, it isn't java, but some kind of java like dialect that is amputed of some of its capabilities.

Just to provide a bit more of detail what I am talking about, here you can read about how AOT works in Websphere Realtime VM case.

http://www.ibm.com/developerworks/library/j-rtj5/index.html

--
Paulo

On Thursday, 19 September 2013 at 14:52:03 UTC, Chris wrote:
> On Thursday, 19 September 2013 at 13:55:34 UTC, Olivier Pisano wrote:
>> D's ability of using a C function just by declaring it and linking with C code is a bless.
>
> Amen!

This was one of the design decisions that the Go guys did wrong, by requiring a C compiler to work with CGO.

--
Paulo

On 9/19/13 1:25 AM, Russel Winder wrote:
> Java is no longer under-performant compared to C, C++, Fortran, D, Go,
> Rust. Check the benchmarks.

Hmmm, this is not established wisdom and the glib "check the benchmarks" doesn't quite help.

Java has gotten on par with C and C++ for raw performance of "straight" code (numerics, I/O etc). I've seen such. Java seems to have issues involving layout control, which is an important influencer of performance in computing nowadays.

Clearly the Java community has amassed a nice bag of tricks regarding performance optimization (parallel arrays, hoisting allocations, etc) but systems compilers and techniques have also made solid progress. When it comes to getting "all" performance, the C model is where it's at.


Andrei

On 9/19/13 4:05 AM, PauloPinto wrote:
> Java might eventually gain value types. The IBM J9 VM already has them.
>
> http://duimovich.blogspot.ca/2012/11/packed-objects-in-java.html
>
> http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120

I think I've heard of at least one more similar endeavor. The funny part is, this is acquiescence of the fact they're needed, which invalidates the former claim that Java was as fast as C before it had them...


Andrei

On 9/19/13 6:05 AM, PauloPinto wrote:
>> In java, all classes are dynamically loadable, and most functions are
>> virtual. This is a deal breaker for the AOT.
>
> Wrong. The Java AOT compilers that target embedded systems produce
> static binaries.

That's not wrong. Java AOT compilers usually (or at least last time I looked) make it clear they support no dynamic loading/invocation etc. so in a sense they don't support 100% of Java.

Andrei

On 19/09/2013 17:58, Andrei Alexandrescu wrote:
> On 9/19/13 1:25 AM, Russel Winder wrote:
>> Java is no longer under-performant compared to C, C++, Fortran, D, Go,
>> Rust. Check the benchmarks.
>
> Hmmm, this is not established wisdom and the glib "check the benchmarks"
> doesn't quite help.
>
> Java has gotten on par with C and C++ for raw performance of "straight"
> code (numerics, I/O etc). I've seen such. Java seems to have issues
> involving layout control, which is an important influencer of
> performance in computing nowadays.
>
> Clearly the Java community has amassed a nice bag of tricks regarding
> performance optimization (parallel arrays, hoisting allocations, etc)
> but systems compilers and techniques have also made solid progress. When
> it comes to getting "all" performance, the C model is where it's at.
>
>
> Andrei
>

I was about to say something similar. Java is no longer under-performant to C/C++, etc., for a *certain* class of applications only. Applications that mainly do data manipulation, I/O, etc., because the JIT will (eventually) compile the Java bytecode to native code.
So Java really is not behind because of being VM-based instead of fully native-based.

Generally though, I would still say Java is under-performant compared to C/C++, etc., although I would say it's mainly due to lack of optional manual memory management. Or lack of value-types (which in a way, are a form of memory management).
I didn't think layout control would be a major issue, except for a very specific type of applications, no? That seems like a very low level optimization.

-- 
Bruno Medeiros - Software Engineer