On Thu, 2013-09-19 at 12:11 +0200, John Colvin wrote:
[…]
> Did you ever get around to making a wiki page etc. as discussed in the last thread about D GPGPU? I've been working on a fork of cl4d that's shaping up ok (I'm thinking of publishing to code.dlang.org once I've written a test-suite), but i'm relatively inexperienced with openCL.

I have been up to my neck in Python activity over the last 4 months, I had to put responding to your email in that thread and doing the "leg work" to keep things bubbling, on the back burner. Sorry. Things settle down after end of October.
-- 
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 Thursday, 19 September 2013 at 10:06:54 UTC, deadalnix wrote:
> On Thursday, 19 September 2013 at 08:26:03 UTC, Russel Winder wrote:
>> And Windows native code applications don't ship with a version of all
>> the Windows DLLs for every application?
>>
>> Java is no longer under-performant compared to C, C++, Fortran, D, Go,
>> Rust. Check the benchmarks.
>>
>
> Benchmarks in Java are often misleading. The language promote a style with a lot of indirections, in the code and in datas. Once your application reach a certain size, cache effect makes it slowdown dramatically. But most benchmark applications aren't big enough to exhibit that behavior.
>
> That being said, if you code in D like in java, you'll have the same trouble (in fact, it is likely to be worse in D). Compile time polymorphism and value types are here a major benefit of C/C++/C#/D (pick whatever you like).
>
> Obviously, you'll find some pathologic cases where java is faster (usually mono-threaded memory allocation intensive benchmark exhibit that, as the JVM is able to add concurrency to the equation via the GC). But that doesn't represent the typical way most a program works (and when they do, you want to fix that as this is a performance killer, in every language, even if java suffers less from it).
>
> The main problem of java isn't the VM, it is its addiction to indirections.
>
>>> *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.

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

--
Paulo

On Thursday, 19 September 2013 at 09:52:40 UTC, deadalnix wrote:
> On Wednesday, 18 September 2013 at 21:33:50 UTC, Chris wrote:
>> Seeing that more and more developers and companies look for or actively develop native languages, I wonder will Java go native one day? (Cf. http://docs.oracle.com/cd/A97336_01/buslog.102/a83727/jtools5.htm)
>>
>
> Java as some design decision that will make it perform worse natively than in a VM.
>
> Dynamic code loading + virtual by default is one example.
>
>> Is this Java's only chance to keep up with Go and Rust (and D)?
>
> It certainly isn't unless the language is modified and a large amount of code is thrown away.

Well, nothing that cannot be cured with PGO, just like in C++'s case.

--
Paulo

On Thursday, 19 September 2013 at 11:23:10 UTC, PauloPinto wrote:
> On Thursday, 19 September 2013 at 09:52:40 UTC, deadalnix wrote:
>> On Wednesday, 18 September 2013 at 21:33:50 UTC, Chris wrote:
>>> Seeing that more and more developers and companies look for or actively develop native languages, I wonder will Java go native one day? (Cf. http://docs.oracle.com/cd/A97336_01/buslog.102/a83727/jtools5.htm)
>>>
>>
>> Java as some design decision that will make it perform worse natively than in a VM.
>>
>> Dynamic code loading + virtual by default is one example.
>>
>>> Is this Java's only chance to keep up with Go and Rust (and D)?
>>
>> It certainly isn't unless the language is modified and a large amount of code is thrown away.
>
> Well, nothing that cannot be cured with PGO, just like in C++'s case.
>

PGO do not allow finalization of method that can dynamically overriden. Only a JIT can do that.

The main difference between JIT and OAT optimizaer is that JIT can be optimistic, and fix later if it turns out to be wrong. AOT must consider the worst case scenario. The benefit of AOT being, obviously, to pay the cost ahead of time instead of at runtime.

In java, all classes are dynamically loadable, and most functions are virtual. This is a deal breaker for the AOT.

On Thursday, 19 September 2013 at 11:05:27 UTC, 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
>

That is a very good news for java ! However, a lot of code will have to be rewritten to take advantage of this. This will allow to improve on a whole class of performance related problems.

On Thursday, 19 September 2013 at 00:25:57 UTC, Walter Bright wrote:
>
> I wrote a native Java compiler in the 90's that was released by Symantec. There wasn't much interest in it.

Visual Cafe always fascinated me.  Is that something you have rights to and could re-release or is it locked in Symantec's vaults?

On Thursday, 19 September 2013 at 02:37:26 UTC, Walter Bright wrote:
> On 9/18/2013 6:01 PM, Jos van Uden wrote:
>> On 19-9-2013 2:25, Walter Bright wrote:
>>> On 9/18/2013 2:33 PM, Chris wrote:
>>>> Seeing that more and more developers and companies look for or actively develop
>>>> native languages, I wonder will Java go native one day? (Cf.
>>>> http://docs.oracle.com/cd/A97336_01/buslog.102/a83727/jtools5.htm)
>>>
>>> I wrote a native Java compiler in the 90's that was released by Symantec.
>>> There wasn't much interest in it.
>>
>> I remember that. It was part of Visual Cafe. I did use it to create a command
>> line app for a client.
>> It was very convenient to be able to ship a regular executable that needed no
>> further instructions.
>
> I'm glad you liked it!

Just how many compilers have you written?! :)

On Thursday, 19 September 2013 at 11:38:35 UTC, deadalnix wrote:
> On Thursday, 19 September 2013 at 11:23:10 UTC, PauloPinto wrote:
>> On Thursday, 19 September 2013 at 09:52:40 UTC, deadalnix wrote:
>>> On Wednesday, 18 September 2013 at 21:33:50 UTC, Chris wrote:
>>>> Seeing that more and more developers and companies look for or actively develop native languages, I wonder will Java go native one day? (Cf. http://docs.oracle.com/cd/A97336_01/buslog.102/a83727/jtools5.htm)
>>>>
>>>
>>> Java as some design decision that will make it perform worse natively than in a VM.
>>>
>>> Dynamic code loading + virtual by default is one example.
>>>
>>>> Is this Java's only chance to keep up with Go and Rust (and D)?
>>>
>>> It certainly isn't unless the language is modified and a large amount of code is thrown away.
>>
>> Well, nothing that cannot be cured with PGO, just like in C++'s case.
>>
>
> PGO do not allow finalization of method that can dynamically overriden. Only a JIT can do that.
>
> The main difference between JIT and OAT optimizaer is that JIT can be optimistic, and fix later if it turns out to be wrong. AOT must consider the worst case scenario. The benefit of AOT being, obviously, to pay the cost ahead of time instead of at runtime.
>
> 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.

--
Paulo

On 9/19/2013 5:50 AM, Colin Grogan wrote:
> Just how many compilers have you written?! :)

http://www.walterbright.com

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.