On Sunday, 20 July 2014 at 12:07:47 UTC, Kagamin wrote:
> On Sunday, 20 July 2014 at 11:44:56 UTC, Mike wrote:
>> Being able to specify an alternate memory manager at compile-time, link-time and/or runtime would be most advantageous, and probably put an end to the GC-phobia.
>
> AFAIK, GC is not directly referenced in druntime, so you already should be able to link with different GC implementation. If you provide all symbols requested by the code, the linker won't link default GC module.

Yes, I believe you are correct.  I also believe there is even a GCStub in the runtime that uses malloc without free.  What's missing is API documentation and examples that makes such features accessible.

Also missing, are language/runtime hooks that could allow users to try alternative memory management schemes such as ARC and find what works best for them through experimentation.

In short, IMO, D should not embrace one type of automatic memory management, they should make it extensible.  In time two ore three high quality memory managers will prevail.

Mike

On Friday, 18 July 2014 at 09:25:46 UTC, Chris wrote:
> On Thursday, 17 July 2014 at 18:19:04 UTC, H. S. Teoh via Digitalmars-d wrote:
>> On Thu, Jul 17, 2014 at 05:58:14PM +0000, Chris via Digitalmars-d wrote:
>>> On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via Digitalmars-d
>>> wrote:
>> [...]
>>> >AFAIK some work still needs to be done with std.string; Walter for
>>> >one has started some work to implement range-based equivalents for
>>> >std.string functions, which would be non-allocating; we just need a
>>> >bit of work to push things through.
>>> >
>>> >DMD 2.066 will have @nogc, which will make it easy to discover which
>>> >remaining parts of Phobos are still not GC-free. Then we'll know
>>> >where to direct our efforts. :-)
>>> >
>>> >
>>> >T
>>> 
>>> That's good news! See, we're getting there, just bear with us. This
>>> begs the question of course, how will this affect existing code? My
>>> code is string intensive.
>>
>> I don't think it will affect existing code (esp. given Walter's stance
>> on breaking changes!). Probably the old GC-based string functions will
>> still be around for backwards-compatibility. Perhaps some of them might
>> be replaced with non-GC versions where it can be done transparently, but
>> I'd expect you'd need to rewrite your string code to take advantage of
>> the new range-based stuff. Hopefully the rewrites will be minimal (e.g.,
>> pass in an output range as argument instead of getting a returned
>> string, replace allocation-based code with a UFCS chain, etc.). The
>> ideal scenario may very well be as simple as tacking on
>> `.copy(myBuffer)` at the end of a UFCS chain. :-P
>>
>>
>> T
>
> That sounds good to me! This gives me time to upgrade my old code little by little and use the new approach when writing new code. Phew!
>
> By the way, my code is string intensive and I still have some suboptimal (greedy) ranges here and there. But believe it or not, they're no problem at all. The application (a plugin for a screen reader) is fast and responsive* (according to user feedback) like any other screen reader plugin, and it hasn't crashed for ages (thanks to GC?) - knock on wood! I use a lot of lazy ranges too plus some pointer magic for work intensive algorithms. Plus D let me easily model the various relations between text and speech (for other use cases down the road). Maybe it is not a real time system, but it has to be responsive. So far, GC hasn't affected it negatively. Once the online version will be publicly available, I will report how well vibe.d performs. Current results are encouraging.
>
> As regards Java, the big advantage of D is that it compiles to a native DLL and all users have to do is to double click on it to install. No "please download JVM" nightmare. I've been there. Users cannot handle it (why should they?), and to provide it as a developer is a waste of time and resources, and it might still go wrong which leaves both the users and the developers angry and frustrated.
>
> * The only thing that bothers me is that there seems to be a slight audio latency problem on Windows, which is not D's fault. On Linux it speaks as soon as you press <Enter>.

Java has AOT compilers available since the early days. Most developers just tend to ignore them, because they are not part of the free package.

--
Paulo

On Sunday, 20 July 2014 at 12:30:02 UTC, Mike wrote:
> Yes, I believe you are correct.  I also believe there is even a GCStub in the runtime that uses malloc without free.  What's missing is API documentation and examples that makes such features accessible.

The existing functions should be understandable, so you can document them yourself. If you want to standardize the API, you can write a small wrapper library, which will account for possible internal API changes and map them to your standard API. Examples are up to you, since nobody knows, what features you will implement in your GC implementation and what API they should have. You have gcstub as an example with GC proxy substitution API.

> In short, IMO, D should not embrace one type of automatic memory management, they should make it extensible.  In time two ore three high quality memory managers will prevail.

It's a matter of writing an appropriate library and providing it as a dub module. Do you know the best, what you want, you are the one to make your wish come to life.

On Sun, 2014-07-20 at 16:40 +0000, Paulo Pinto via Digitalmars-d wrote:

[…]
> Java has AOT compilers available since the early days. Most developers just tend to ignore them, because they are not part of the free package.

Also, it is not entirely clear that AOT optimization can beat JIT optimization, at least on the JVM.

-- 
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 Monday, 21 July 2014 at 18:31:46 UTC, Russel Winder via
Digitalmars-d wrote:
> On Sun, 2014-07-20 at 16:40 +0000, Paulo Pinto via Digitalmars-d wrote:
>
> […]
>> Java has AOT compilers available since the early days. Most developers just tend to ignore them, because they are not part of the free package.
>
> Also, it is not entirely clear that AOT optimization can beat JIT
> optimization, at least on the JVM.

They probably aren't mutually exclusive.

On Monday, 21 July 2014 at 18:31:46 UTC, Russel Winder via Digitalmars-d wrote:
> On Sun, 2014-07-20 at 16:40 +0000, Paulo Pinto via Digitalmars-d wrote:
>
> […]
>> Java has AOT compilers available since the early days. Most developers just tend to ignore them, because they are not part of the free package.
>
> Also, it is not entirely clear that AOT optimization can beat JIT
> optimization, at least on the JVM.

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.

--
Paulo

On Tue, 2014-07-22 at 06:35 +0000, 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.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 Tuesday, 22 July 2014 at 08:10:31 UTC, Russel Winder via Digitalmars-d wrote:
> On Tue, 2014-07-22 at 06:35 +0000, 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

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.

> 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.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 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:
> […]
>> 
>
>> 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