www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GCs in the news

reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
It appears still to be a general meme that performance required no GC
and GC mean poor performance. The debate has been restarted on the Go
mailing list under the banner "go without garbage collector". The
response to will Go remove the garbage collector was somewhat
unequivocal: nope.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 17 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via 
Digitalmars-d wrote:
 It appears still to be a general meme that performance required 
 no GC
 and GC mean poor performance. The debate has been restarted on 
 the Go
 mailing list under the banner "go without garbage collector". 
 The
 response to will Go remove the garbage collector was somewhat
 unequivocal: nope.
That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
Jul 17 2014
next sibling parent "eles" <eles eles.com> writes:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
 On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via 
 Digitalmars-d wrote:
 That's good news in a way. If a big company accepts GC and the 
 Go crowd go with it (pardon the pun), then it will find more 
 acceptance (as Paulo pointed out in a different thread).
do not aim for the "systems programming language" mantra. (BTW, there are/will be .NET native and gcj). More, in embedded systems (and, generally, in system programming), having or no a GC is not only about speed. It is also about the amount of memory that is used and about predictability. And let's not even talk about the finalizers/destructors and so on. Go went for servers, not for systems. Rename D to Vibe.D and everything will fall in place.
Jul 17 2014
prev sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
 On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via 
 Digitalmars-d wrote:
 It appears still to be a general meme that performance 
 required no GC
 and GC mean poor performance. The debate has been restarted on 
 the Go
 mailing list under the banner "go without garbage collector". 
 The
 response to will Go remove the garbage collector was somewhat
 unequivocal: nope.
That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management. Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers). Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language? Within this community the question is rhetorical but to outsiders I feel it's a major concern.
Jul 17 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"currysoup"  wrote in message news:iustbzgyagrlbtnfcton forum.dlang.org... 

 Once you're going to 
 these lengths to avoid garbage collection it begs the question, 
 why are you even using this language?
Because D has plenty of other things to offer.
Jul 17 2014
prev sibling next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
 On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
 On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via 
 Digitalmars-d wrote:
 It appears still to be a general meme that performance 
 required no GC
 and GC mean poor performance. The debate has been restarted 
 on the Go
 mailing list under the banner "go without garbage collector". 
 The
 response to will Go remove the garbage collector was somewhat
 unequivocal: nope.
That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.
Point taken. But as has been said before 90-95% of all apps can live happily with GC, and if you want, you can still go bare metal with D. The security GC offers should not be underestimated either. With "acceptance" I meant that people see "it cannot be that bad after all for *most* applications". The GC issue is often cited as a D-eal breaker. I understand that there are applications that need total control over the memory. But those apps have always been programmed in C or any other close-to-the-machine language, and even then programmers (in gaming for example) have to use additional tricks and hacks to squeeze out every little bit of performance. What D has to do is to facilitate control over the memory, but I still consider it a systems programming language due to the fact that it has many things to offer as regard the direct interaction with the machine yes, tell me how, I'm interested.
 Just from watching a few of the DConf 2014 talks, if you want 
 performance you avoid the GC at all costs (even if that means 
 allocating into huge predefined buffers). Once you're going to 
 these lengths to avoid garbage collection it begs the question, 
 why are you even using this language? Within this community the 
 question is rhetorical but to outsiders I feel it's a major 
 concern.
Don't know if it's really a "major concern" or the favorite weak spot that C++ et. al guys like to flog to death in order to distract from the many strengths that D has (in comparison with C++ et al.) The answer is always "D has GC, it's the Devil, don't touch it!" Also, let's put a little faith in the brilliant developers behind D, I'm sure there's a huge performance boost for D around the corner.
Jul 17 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
 On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
 On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
 On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via 
 Digitalmars-d wrote:
 It appears still to be a general meme that performance 
 required no GC
 and GC mean poor performance. The debate has been restarted 
 on the Go
 mailing list under the banner "go without garbage 
 collector". The
 response to will Go remove the garbage collector was somewhat
 unequivocal: nope.
That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.
Point taken. But as has been said before 90-95% of all apps can live happily with GC, and if you want, you can still go bare metal with D. The security GC offers should not be underestimated either. With "acceptance" I meant that people see "it cannot be that bad after all for *most* applications". The GC issue is often cited as a D-eal breaker. I understand that there are applications that need total control over the memory. But those apps have always been programmed in C or any other close-to-the-machine language, and even then programmers (in gaming for example) have to use additional tricks and hacks to squeeze out every little bit of performance. What D has to do is to facilitate control over the memory, but I still consider it a systems programming language due to the fact that it has many things to offer as regard the direct interaction drive in Java, if yes, tell me how, I'm interested.
 Just from watching a few of the DConf 2014 talks, if you want 
 performance you avoid the GC at all costs (even if that means 
 allocating into huge predefined buffers). Once you're going to 
 these lengths to avoid garbage collection it begs the 
 question, why are you even using this language? Within this 
 community the question is rhetorical but to outsiders I feel 
 it's a major concern.
Don't know if it's really a "major concern" or the favorite weak spot that C++ et. al guys like to flog to death in order to distract from the many strengths that D has (in comparison with C++ et al.) The answer is always "D has GC, it's the Devil, don't touch it!" Also, let's put a little faith in the brilliant developers behind D, I'm sure there's a huge performance boost for D around the corner.
Ah, and there's inline asm too!
Jul 17 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
 On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
 On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
 On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via 
 Digitalmars-d wrote:
 It appears still to be a general meme that performance 
 required no GC
 and GC mean poor performance. The debate has been restarted 
 on the Go
 mailing list under the banner "go without garbage 
 collector". The
 response to will Go remove the garbage collector was somewhat
 unequivocal: nope.
That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.
Point taken. But as has been said before 90-95% of all apps can live happily with GC, and if you want, you can still go bare metal with D. The security GC offers should not be underestimated either. With "acceptance" I meant that people see "it cannot be that bad after all for *most* applications". The GC issue is often cited as a D-eal breaker. I understand that there are applications that need total control over the memory. But those apps have always been programmed in C or any other close-to-the-machine language, and even then programmers (in gaming for example) have to use additional tricks and hacks to squeeze out every little bit of performance. What D has to do is to facilitate control over the memory, but I still consider it a systems programming language due to the fact that it has many things to offer as regard the direct interaction drive in Java, if yes, tell me how, I'm interested.
Easy, like in any language that offers FFI. Expose a Driver class with native method declarations, whose implementation is written in Assembly. The SquakVM used to drive SunSPOT devices had the device drivers written in Java. There are quite a few other examples in the embedded market, like the MicroEJ platform. That is no different from writing drivers in ANSI C, which provides zero features for hardware interaction. -- Paulo
Jul 17 2014
prev sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
 Don't know if it's really a "major concern" or the favorite 
 weak spot that C++ et. al guys like to flog to death in order 
 to distract from the many strengths that D has (in comparison 
 with C++ et al.) The answer is always "D has GC, it's the 
 Devil, don't touch it!" Also, let's put a little faith in the 
 brilliant developers behind D, I'm sure there's a huge 
 performance boost for D around the corner.
I'm not here to hate on D, the reason I read these forums is because I love the language. I feel it is a major concern, if I'm starting a project with low latency requirements* I certainly think twice about using D. I think this could apply especially to people outside the community who might not have experienced the benefits D provides. The issue is not there is a GC, it's that the GC is viewed as bad. If the GC was as good as Azul's C4 GC then D would be perfect. I'm not sure if D's memory model supports such a collector though. *According to Don Clugston's talk the default GC can pause for ~250ms which is totally insane for any kind of interactive or near-real-time system. If their concurrent version of the GC could reduce this to 10ms it shows the GC implementation is fairly naive.
Jul 17 2014
next sibling parent "eles" <eles eles.com> writes:
On Thursday, 17 July 2014 at 13:30:15 UTC, currysoup wrote:
 On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:

 *According to Don Clugston's talk the default GC can pause for 
 ~250ms which is totally insane for any kind of interactive or 
 near-real-time system. If their concurrent version of the GC 
 could reduce this to 10ms it shows the GC implementation is 
 fairly naive.
The sequencer that I use executes a loop every 10 ms.
Jul 17 2014
prev sibling parent "Araq" <rumpf_a web.de> writes:
 I feel it is a major concern, if I'm starting a project with 
 low latency requirements* I certainly think twice about using 
 D. I think this could apply especially to people outside the 
 community who might not have experienced the benefits D 
 provides. The issue is not there is a GC, it's that the GC is 
 viewed as bad. If the GC was as good as Azul's C4 GC then D 
 would be perfect. I'm not sure if D's memory model supports 
 such a collector though.
It doesn't.
Jul 17 2014
prev sibling next sibling parent reply "John" <john.joyus gmail.com> writes:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
 It's not about "acceptance", it's about the reality that a GC 
 is not a universal solution to memory management.

 Just from watching a few of the DConf 2014 talks, if you want 
 performance you avoid the GC at all costs (even if that means 
 allocating into huge predefined buffers). Once you're going to 
 these lengths to avoid garbage collection it begs the question, 
 why are you even using this language? Within this community the 
 question is rhetorical but to outsiders I feel it's a major 
 concern.
If D came without GC, it would have replaced C++ a long time ago!
Jul 17 2014
next sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
 If D came without GC, it would have replaced C++ a long time 
 ago!
That's overly optimistic I think, but I believe that the adoption rate would have been far greater for a D without GC, or perhaps with a more GC friendly design, as the GC comes up first or close in every D discussion with prospective adopters. However, it's way too late to change that now. IMO, the way forward involves removing all or most hidden allocations from the D libraries, making programming sans GC easier ( nogc everywhere, a compiler switch, documentation for how to work around the lack of GC, etc.) and a much better, precise GC as part of the D release. Any spec changes necessary to support precision should be in a fast path.
Jul 17 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 17 July 2014 at 14:05:02 UTC, Brian Rogoff wrote:
 On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
 If D came without GC, it would have replaced C++ a long time 
 ago!
That's overly optimistic I think, but I believe that the adoption rate would have been far greater for a D without GC, or perhaps with a more GC friendly design, as the GC comes up first or close in every D discussion with prospective adopters. However, it's way too late to change that now. IMO, the way forward involves removing all or most hidden allocations from the D libraries, making programming sans GC easier ( nogc everywhere, a compiler switch, documentation for how to work around the lack of GC, etc.) and a much better, precise GC as part of the D release. Any spec changes necessary to support precision should be in a fast path.
Yeah. Best avoid GC in the first place. If GC can stop the world for ~250ms, wouldn't it be possible (just an innocent thought) to tell the GC only to work, if it can guarantee to stay below a certain threshold, and do the rest later (or in a parallel thread)?
Jul 17 2014
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 17 July 2014 at 14:05:02 UTC, Brian Rogoff wrote:
 On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
 If D came without GC, it would have replaced C++ a long time 
 ago!
That's overly optimistic I think, but I believe that the adoption rate would have been far greater for a D without GC, or perhaps with a more GC friendly design, as the GC comes up first or close in every D discussion with prospective adopters.
This claim is being made frequently, but you need to consider that D started out as a more simpler language than it is today. Many of the distinguishing advantages of D can only be made possible _in a safe way_ when there is a GC. Everyone seems to agree, for example, that array slicing is one of these features. Without a GC, you'd either have to add a complicated reference counting scheme, thus destroying performance and simplicity, or you'd have to rely on the user for ownership management, which is unsafe. (A third way would be borrowing, which D doesn't have (yet).) I also believe that the Range concept was introduced at a later stage in D's history, thus the GC avoidance strategies that are being implemented in Phobos right now weren't available back then. Therefore I cannot agree that D would have been adopted more eagerly without a GC; in fact, the adoption rate would have likely been less, because the language would have been crippled.
 However, it's way too late to change that now. IMO, the way 
 forward involves removing all or most hidden allocations from 
 the D libraries, making programming sans GC easier ( nogc 
 everywhere, a compiler switch, documentation for how to work 
 around the lack of GC, etc.) and a much better, precise GC as 
 part of the D release. Any spec changes necessary to support 
 precision should be in a fast path.
Add borrowing!
Jul 19 2014
prev sibling next sibling parent reply "bachmeier" <no spam.com> writes:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
 On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
 It's not about "acceptance", it's about the reality that a GC 
 is not a universal solution to memory management.

 Just from watching a few of the DConf 2014 talks, if you want 
 performance you avoid the GC at all costs (even if that means 
 allocating into huge predefined buffers). Once you're going to 
 these lengths to avoid garbage collection it begs the 
 question, why are you even using this language? Within this 
 community the question is rhetorical but to outsiders I feel 
 it's a major concern.
If D came without GC, it would have replaced C++ a long time ago!
The only thing that would have been replaced is the complaints that D has a garbage collector with complaints that D doesn't have the tools and existing libraries of C++. If C++ users were sincere in their claims that they really want to use D, they'd have disabled the garbage collector and used it. I think the GC issue is eating resources that would be better spent elsewhere.
Jul 17 2014
parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 17 July 2014 at 15:19:59 UTC, bachmeier wrote:
 On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
 On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
 It's not about "acceptance", it's about the reality that a GC 
 is not a universal solution to memory management.

 Just from watching a few of the DConf 2014 talks, if you want 
 performance you avoid the GC at all costs (even if that means 
 allocating into huge predefined buffers). Once you're going 
 to these lengths to avoid garbage collection it begs the 
 question, why are you even using this language? Within this 
 community the question is rhetorical but to outsiders I feel 
 it's a major concern.
If D came without GC, it would have replaced C++ a long time ago!
The only thing that would have been replaced is the complaints that D has a garbage collector with complaints that D doesn't have the tools and existing libraries of C++. If C++ users were sincere in their claims that they really want to use D, they'd have disabled the garbage collector and used it. I think the GC issue is eating resources that would be better spent elsewhere.
+1
Jul 17 2014
prev sibling parent reply "Vic" <vic.cvc gmx.com> writes:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
<snip>
 If D came without GC, it would have replaced C++ a long time 
 ago!
Agree +1000. If GC is so good, why not make it an option, have a base lib w/o GC. If I want GC, I got me JRE. It seems that some in D want to write a better JRE, and that just won't happen ever. Cheers, Vic
Jul 17 2014
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
 If GC is so good, why not make it an option, have a base lib 
 w/o GC.
Much of Phobos already is GC free. The parts that aren't should be easy to convert to use user-supplied buffers. Please add enhancement requests for cases where there isn't a GC-free alternative to a standard library routine.
Jul 17 2014
parent reply "Vic" <vic.cvc gmx.com> writes:
On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander wrote:
 On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
 If GC is so good, why not make it an option, have a base lib 
 w/o GC.
Much of Phobos already is GC free. The parts that aren't should be easy to convert to use user-supplied buffers. Please add enhancement requests for cases where there isn't a GC-free alternative to a standard library routine.
If that is true, I may even do a $ bounty to make Phobos GC free. I may do the same, $ bounty on vibe.d port to GC free. I don't know D enough to be able to do that, but good news to me. Cheers, Vic
Jul 17 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 17, 2014 at 05:28:01PM +0000, Vic via Digitalmars-d wrote:
 On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander wrote:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why not make it an option, have a base lib w/o GC.
Much of Phobos already is GC free. The parts that aren't should be easy to convert to use user-supplied buffers. Please add enhancement requests for cases where there isn't a GC-free alternative to a standard library routine.
If that is true, I may even do a $ bounty to make Phobos GC free. I may do the same, $ bounty on vibe.d port to GC free. I don't know D enough to be able to do that, but good news to me.
[...] Over the last year or so, IIRC, there has been a push (a slow but nonetheless steady push) to make as much of Phobos GC-free as possible. I'd say most (all?) of std.algorithm and std.range should be GC-free by now, and probably many of the others can be made GC-free quite easily with the tools that we now have. 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 -- Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
Jul 17 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Thu, Jul 17, 2014 at 05:28:01PM +0000, Vic via Digitalmars-d 
 wrote:
 On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander 
 wrote:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why not make it an option, have a base lib 
w/o GC.
Much of Phobos already is GC free. The parts that aren't should be easy to convert to use user-supplied buffers. Please add enhancement requests for cases where there isn't a GC-free alternative to a standard library routine.
If that is true, I may even do a $ bounty to make Phobos GC free. I may do the same, $ bounty on vibe.d port to GC free. I don't know D enough to be able to do that, but good news to me.
[...] Over the last year or so, IIRC, there has been a push (a slow but nonetheless steady push) to make as much of Phobos GC-free as possible. I'd say most (all?) of std.algorithm and std.range should be GC-free by now, and probably many of the others can be made GC-free quite easily with the tools that we now have. 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.
Jul 17 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
 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.
Usually GC-free API is added by providing new overloads that take an output range instance as an argument so no existing code should break (it will still use allocating versions)
Jul 17 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 17 July 2014 at 18:08:18 UTC, Dicebot wrote:
 On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
 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.
Usually GC-free API is added by providing new overloads that take an output range instance as an argument so no existing code should break (it will still use allocating versions)
Yes, output ranges are underused by now.
Jul 17 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 17, 2014 at 06:09:49PM +0000, deadalnix via Digitalmars-d wrote:
 On Thursday, 17 July 2014 at 18:08:18 UTC, Dicebot wrote:
On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
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.
Usually GC-free API is added by providing new overloads that take an output range instance as an argument so no existing code should break (it will still use allocating versions)
Yes, output ranges are underused by now.
Actually, I've realized that output ranges are really only useful when you want to store the final result. For data in mid-processing, you really want to be exporting an input (or higher) range interface instead, because functions that take output ranges are not composable. And for storing final results, you just use std.algorithm.copy, so there's really no need for many functions to take an output range at all. T -- One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion
Jul 17 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Actually, I've realized that output ranges are really only 
 useful when
 you want to store the final result. For data in mid-processing, 
 you
 really want to be exporting an input (or higher) range interface
 instead, because functions that take output ranges are not 
 composable.
 And for storing final results, you just use std.algorithm.copy, 
 so
 there's really no need for many functions to take an output 
 range at
 all.
Plain algorithm ranges rarely need to allocate at all so those are somewhat irrelevant to the topic. What I am speaking about are variety of utility functions like this: S detab(S)(S s, size_t tabSize = 8) if (isSomeString!S) this allocates result string. Proper alternative: S detab(S)(ref S output, size_t tabSize = 8) if (isSomeString!S); plus void detab(S, OR)(OR output, size_t tab_Size = 8) if ( isSomeString!S && isSomeString!(ElementType!OR) )
Jul 17 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 17, 2014 at 06:32:58PM +0000, Dicebot via Digitalmars-d wrote:
 On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via Digitalmars-d
 wrote:
Actually, I've realized that output ranges are really only useful
when you want to store the final result. For data in mid-processing,
you really want to be exporting an input (or higher) range interface
instead, because functions that take output ranges are not
composable.  And for storing final results, you just use
std.algorithm.copy, so there's really no need for many functions to
take an output range at all.
Plain algorithm ranges rarely need to allocate at all so those are somewhat irrelevant to the topic. What I am speaking about are variety of utility functions like this: S detab(S)(S s, size_t tabSize = 8) if (isSomeString!S) this allocates result string. Proper alternative: S detab(S)(ref S output, size_t tabSize = 8) if (isSomeString!S); plus void detab(S, OR)(OR output, size_t tab_Size = 8) if ( isSomeString!S && isSomeString!(ElementType!OR) )
I think you're missing the input parameter. :) void detab(S, OR)(S s, OR output, size_t tabSize = 8) { ... } I argue that you can just turn it into this: auto withoutTabs(S)(S s, size_t tabSize = 8) { static struct Result { ... // implementation here } static assert(isInputRange!Result); return Result(s, tabSize); } auto myInput = "..."; auto detabbedInput = myInput.withoutTabs.array; // Or: MyOutputRange sink; // allocate using whatever scheme you want myInput.withoutTabs.copy(sink); The algorithm itself doesn't need to know where the result will end up -- sink could be stdout, in which case no allocation is needed at all. Or are you talking about in-place modification of the input string? That's a different kettle o' fish. T -- EMACS = Extremely Massive And Cumbersome System
Jul 17 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 18 July 2014 at 00:08:17 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Thu, Jul 17, 2014 at 06:32:58PM +0000, Dicebot via 
 Digitalmars-d wrote:
 On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via 
 Digitalmars-d
 wrote:
Actually, I've realized that output ranges are really only 
useful
when you want to store the final result. For data in 
mid-processing,
you really want to be exporting an input (or higher) range 
interface
instead, because functions that take output ranges are not
composable.  And for storing final results, you just use
std.algorithm.copy, so there's really no need for many 
functions to
take an output range at all.
Plain algorithm ranges rarely need to allocate at all so those are somewhat irrelevant to the topic. What I am speaking about are variety of utility functions like this: S detab(S)(S s, size_t tabSize = 8) if (isSomeString!S) this allocates result string. Proper alternative: S detab(S)(ref S output, size_t tabSize = 8) if (isSomeString!S); plus void detab(S, OR)(OR output, size_t tab_Size = 8) if ( isSomeString!S && isSomeString!(ElementType!OR) )
I think you're missing the input parameter. :) void detab(S, OR)(S s, OR output, size_t tabSize = 8) { ... } I argue that you can just turn it into this: auto withoutTabs(S)(S s, size_t tabSize = 8) { static struct Result { ... // implementation here } static assert(isInputRange!Result); return Result(s, tabSize); } auto myInput = "..."; auto detabbedInput = myInput.withoutTabs.array; // Or: MyOutputRange sink; // allocate using whatever scheme you want myInput.withoutTabs.copy(sink); The algorithm itself doesn't need to know where the result will end up -- sink could be stdout, in which case no allocation is needed at all.
Yes this looks better.
Jul 18 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 5:06 PM, H. S. Teoh via Digitalmars-d wrote:
 	MyOutputRange sink;	// allocate using whatever scheme you want
 	myInput.withoutTabs.copy(sink);

 The algorithm itself doesn't need to know where the result will end up
 -- sink could be stdout, in which case no allocation is needed at all.
Exactly! The algorithm becomes completely divorced from the memory allocation. I believe this is a very powerful technique.
Jul 19 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 11:32 AM, Dicebot wrote:
 Plain algorithm ranges rarely need to allocate at all so those are somewhat
 irrelevant to the topic. What I am speaking about are variety of utility
 functions like this:

 S detab(S)(S s, size_t tabSize = 8)
      if (isSomeString!S)

 this allocates result string. Proper alternative:

 S detab(S)(ref S output, size_t tabSize = 8)
      if (isSomeString!S);

 plus

 void detab(S, OR)(OR output, size_t tab_Size = 8)
      if (   isSomeString!S
          && isSomeString!(ElementType!OR)
         )
That algorithm takes a string and writes to an output range. This is not very composable. For example, what if one has an input range of chars, rather than a string? And what if one wants to tack more processing on the end? A better interface is the one used by the byChar, byWchar, and byDchar ranges recently added to std.utf. Those accept an input range, and present an input range as "output". They are very composable, and can be stuck in anywhere in a character processing pipeline. They do no allocations, and are completely lazy. The byChar algorithm in particular can serve as an outline for how to do a detab algorithm, most of the code can be reused for that.
Jul 17 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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 -- Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard
Jul 17 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 I don't think it will affect existing code (esp. given Walter's 
 stance on breaking changes!).
Making various parts of Phobos GC-free doesn't mean that nothing GC-allocates, it means that Phobos will offer means to use memory provided by the user. There are many situations where using a GC is OK, so both kinds of usages should be supported by Phobos. It should contain nothrow nogc functions to format and to convert to number and strings. It's a matter of offering choice. Bye, bearophile
Jul 17 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
 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
Boss, dat's pretty much de plan, de plan!
Jul 17 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
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>.
Jul 18 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jul 20 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2014-07-20 at 16:40 +0000, Paulo Pinto via Digitalmars-d wrote:

[=E2=80=A6]
 Java has AOT compilers available since the early days. Most=20
 developers just tend to ignore them, because they are not part of=20
 the free package.
Also, it is not entirely clear that AOT optimization can beat JIT optimization, at least on the JVM. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 21 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jul 21 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jul 21 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-07-22 at 06:35 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
 Yes it can, if developers bother to do PGO + AOT instead and=20
 learn the compiler flags.
=20
 I used to have a stronger opinion on JIT, but given how many JITs=20
 perform and do not actually use the hardware as they, in theory=20
 could, JIT tend to only be an advantage for dynamic languages not=20
 strong typed ones.
=20
 With JIT, writing the code in a way that makes the JIT compiler=20
 happy is a lost battle, as it depends on the exact same JIT=20
 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 22 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jul 22 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-07-22 at 10:55 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
 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. [=E2=80=A6]
 Functional programming languages have AOT compilers and they=20
 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=20
 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.=20 [=E2=80=A6]
=20
 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:
=20
 - A programming language X
In the case at hand X =3D Java.
 - The state of the art JIT compiler implementation for the given=20
 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=20
 language
=20
 I know a few commercial AOT compilers for Java, not sure which=20
 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,=20
 Google replacing Dalvik with AOT and Oracle has added AOT=20
 compilation (Substract) to Graal, the candidate to Hotspot=20
 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 23 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jul 23 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-07-23 at 09:11 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
 I will happily use it when it gets to the same execution speed=20
 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. [=E2=80=A6]
 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.
=20 Yes it is. =20 It was presented as such at JavaONE for possible future Java 9+=20 improvements. =20 I can try to dig out the presentation, if you wish.
Clearly I need to update my knowledge! [=E2=80=A6]
 I agree in the cases the toolchain offers both possibilities out=20
 of the box and does not force developers to choose among=20
 different vendors toolchains.
I am trying to get folk in the JVM benchmarking trade to tell me what the latest SP is on things. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 23 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 23.07.2014 21:27, schrieb Russel Winder via Digitalmars-d:
 On Wed, 2014-07-23 at 09:11 +0000, Paulo Pinto via Digitalmars-d wrote:
 […]

 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!
So far I could only find "Looking into the JVM Crystal Ball" http://www.parleys.com/play/524f6b5be4b0a43ac12123a9/about Between 00:40:00 and 00:45:50, compilation gets discussed, including AOT. Not the ones about Graal, though. I am pretty sure I saw a slide with it as part of the Java 9+ wishlist, now just have to remember if it was actually at JavaONE, Devoxx, FOSDEM or Jax. :\ -- Paulo
Jul 23 2014
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-07-23 at 22:58 +0200, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
 So far I could only find
 "Looking into the JVM Crystal Ball"
 http://www.parleys.com/play/524f6b5be4b0a43ac12123a9/about
=20
 Between 00:40:00 and 00:45:50, compilation gets discussed, including AOT.
=20
 Not the ones about Graal, though.
=20
 I am pretty sure I saw a slide with it as part of the Java 9+ wishlist,
 now just have to remember if it was actually at JavaONE, Devoxx, FOSDEM=
=20
 or Jax. :\
I'll check this out. I am also getting the folk from the LJC who represent the LJC on the JCP EC (LJC is an elected members) to get a definitive statement on the road map. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 24 2014
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Jul 23 2014
next sibling parent "Bienlein" <jeti789 web.de> writes:
 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.
Jul 23 2014
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
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
Jul 23 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 23 July 2014 at 11:54:19 UTC, Atila Neves wrote:
 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
It usually does in memory intensive benchmark that aren't multithreaded. Java's GC is a free shot of concurrency that C won't get.
Jul 23 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-07-23 at 09:16 +0000, John Colvin via Digitalmars-d wrote:
[=E2=80=A6]
 I am suspicious. I understand that a situation can be contrived=20
 such that C will lose, but in normal, sensible code the only=20
 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 23 2014
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
Jul 23 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 23 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 23 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 f=
or
 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
=20 Fresh photo comparing buck with gradle: http://i.imgur.com/uGHdfyq.jpg=
=20
 -- Andrei
Were any of the Gradleware folk there, that should really scare them. BTW what's with the rabbit and the monkey? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 23 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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
Jul 23 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-07-23 at 21:32 +0200, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
=20
 I only tried Graddle because of Android Studio, it makes so bad use of=
=20
 hardware resources, pegging my i7 and core duo processors, that I=20
 returned to Eclipse + ADT on the same day.
I have not tried Android Studio for anything as yet. It is based on IntelliJ IDEA though (as is PyCharm) and IntelliJ IDEA beats Eclipse hands down for Java and Groovy working (as PyCharm beats Eclipse/PyDev hands down for Python). For me, YMMV.
 The situation is so bad it was even mentioned at this Google IO Android=
=20
 developer tools talk.
I think this will be a JetBrains problem rather than a Gradle problem.
 This aborted my attempt to try to use Kotlin instead of C++ on my hobby=
=20
 Android projects.
Kotlin is great fun, but I only use IntelliJ IDEA for that.
 As for our Fortune 500 customers portfolio, the ones using Java are=20
 still 100% in a mix of Ant and Maven.
<shudder/> I gave up Ant when I wrote Gant (*), and avoided Maven until Gradle arrived. Humans should not have to hand write XML ever. (*) Someone forked this to create the Groovy front end to Ant, which must beat the XML one any and every day of the week. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 24 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 24 July 2014 at 08:34:30 UTC, Russel Winder via 
Digitalmars-d wrote:
 On Wed, 2014-07-23 at 21:32 +0200, Paulo Pinto via 
 Digitalmars-d wrote:
 […]

 The situation is so bad it was even mentioned at this Google 
 IO Android developer tools talk.
I think this will be a JetBrains problem rather than a Gradle problem.
Nope, Gradle, as shown by the CPU usage on the task manager. -- Paulo
Jul 24 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2014-07-24 at 09:38 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
=20
 Nope, Gradle, as shown by the CPU usage on the task manager.
I am surprised, but data always trumps opinion. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 24 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via 
Digitalmars-d wrote:
 On Thu, 2014-07-24 at 09:38 +0000, Paulo Pinto via 
 Digitalmars-d wrote:
 […]
 
 Nope, Gradle, as shown by the CPU usage on the task manager.
I am surprised, but data always trumps opinion.
One of the first Google results, http://askubuntu.com/questions/469709/gradle-compiling-slows-down-my-computer You can find many more out there, in many combinations use cases.
Jul 24 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2014-07-24 at 11:09 +0000, Paulo Pinto via Digitalmars-d wrote:
 On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via=20
 Digitalmars-d wrote:
 On Thu, 2014-07-24 at 09:38 +0000, Paulo Pinto via=20
 Digitalmars-d wrote:
 [=E2=80=A6]
=20
 Nope, Gradle, as shown by the CPU usage on the task manager.
I am surprised, but data always trumps opinion.
=20 One of the first Google results, =20 http://askubuntu.com/questions/469709/gradle-compiling-slows-down-my-comp=
uter
=20
 You can find many more out there, in many combinations use cases.
Looks like Android Studio tells Gradle to use the number of threads that there are cores, so this is an Android Studio problem, not a Gradle problem per se. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 24 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 24 July 2014 at 11:35:09 UTC, Russel Winder via 
Digitalmars-d wrote:
 On Thu, 2014-07-24 at 11:09 +0000, Paulo Pinto via 
 Digitalmars-d wrote:
 On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via 
 Digitalmars-d wrote:
 On Thu, 2014-07-24 at 09:38 +0000, Paulo Pinto via 
 Digitalmars-d wrote:
 […]
 
 Nope, Gradle, as shown by the CPU usage on the task manager.
I am surprised, but data always trumps opinion.
One of the first Google results, http://askubuntu.com/questions/469709/gradle-compiling-slows-down-my-computer You can find many more out there, in many combinations use cases.
Looks like Android Studio tells Gradle to use the number of threads that there are cores, so this is an Android Studio problem, not a Gradle problem per se.
In this specific case yes, but as I mentioned there are lots of uses cases being reported. -- Paulo
Jul 24 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2014-07-24 at 11:39 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
 In this specific case yes, but as I mentioned there are lots of=20
 uses cases being reported.
It turns out to be a "known fact" even in Gradleware. Hans mentions it specifically inhis "vision for the future" document of a month ago. He also mentions that the C/C++ build aspects of Gradle are to be used by the Android NDK folk. I already asked them about including D in the package, but the response was "nobody uses D". So maybe we (I guess this mean I) should do a user contributed patch to add D to the whole thing. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 27 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Sunday, 27 July 2014 at 08:24:44 UTC, Russel Winder via 
Digitalmars-d wrote:
 On Thu, 2014-07-24 at 11:39 +0000, Paulo Pinto via 
 Digitalmars-d wrote:
 […]
 In this specific case yes, but as I mentioned there are lots 
 of uses cases being reported.
It turns out to be a "known fact" even in Gradleware. Hans mentions it specifically inhis "vision for the future" document of a month ago. He also mentions that the C/C++ build aspects of Gradle are to be used by the Android NDK folk. I already asked them about including D in the package, but the response was "nobody uses D".
I am nobody.
 So maybe we (I guess this
 mean I) should do a user contributed patch to add D to the 
 whole thing.
Jul 27 2014
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2014-07-27 at 12:51 +0000, Chris via Digitalmars-d wrote:
 On Sunday, 27 July 2014 at 08:24:44 UTC, Russel Winder via=20
 Digitalmars-d wrote:
[=E2=80=A6]
 He also mentions that the C/C++ build aspects of Gradle are to=20
 be used
 by the Android NDK folk. I already asked them about including D=20
 in the
 package, but the response was "nobody uses D".
=20 I am nobody.
I was fairly appalled at the response so I have requested ability to clone the C/C++ stuff so as to add D and send in pull requests. Whatever anyone things of Gradle (or SCons) for D, it is looking more and more like Gradle is the route to build on Android. So if we want D on Android ensuring "buildable with Gradle" is a way of removing a hurdle. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 27 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/23/14, 12:23 PM, Russel Winder via Digitalmars-d wrote:
 BTW what's with the rabbit and the monkey?
He promised his kid they'll go on an adventure with daddy. A really nice touch. I might steal it for my own talks. -- Andrei
Jul 23 2014
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-07-23 at 14:37 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 7/23/14, 12:23 PM, Russel Winder via Digitalmars-d wrote:
 BTW what's with the rabbit and the monkey?
=20 He promised his kid they'll go on an adventure with daddy. A really nice=
=20
 touch. I might steal it for my own talks. -- Andrei
Excellent. Perhaps we should make the "a thing". Every speaker must have their "cuddly toy" companion on stage. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 24 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 23 July 2014 at 18:45:23 UTC, Andrei Alexandrescu
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
Say hi to Simon :)
Jul 23 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/23/2014 1:46 AM, Russel Winder via Digitalmars-d wrote:
 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.
Fun fact: the guy who wrote Symantec's JVM JIT, Steve Russell, is the very guy who wrote Optlink!
Jul 23 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 July 2014 at 17:28:02 UTC, Vic wrote:
 If that is true, I may even do a $ bounty to make Phobos GC 
 free.
Unless you do some hard real-time barebone stuff it is quite likely you can do with limited usage of GC. Hiring some of experienced D user to make a one-time case study with detailed recommendation can be an option if you are seriously concerned.
 I may do the same, $ bounty on vibe.d port to GC free.
vibe.d has -version=VibedManualMemoryManagement which removes much of GC usage from its internals. Not 100% nogc but some entry point to start with for interested parties.
 I don't know D enough to be able to do that, but good news to 
 me.
Here Don mentions some of techniques we (Sociomantic) use to minimize GC impact : https://www.youtube.com/watch?v=WmE7ZR1_YKs In the end it comes to famous Bjarne quote : "C++ may be the best language for garbage collection because it generates so few garbage". Same can be applied to D with proper coding style.
Jul 17 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Vic:

 If D came without GC, it would have replaced C++ a long time 
 ago!
Agree +1000.
I see no proof of this. And not everybody hates GCs. Bye, bearophile
Jul 17 2014
parent reply "Right" <Ohright ohplease.com> writes:
  I hate GC, so there.

 I see no proof of this. And not everybody hates GCs.

 Bye,
 bearophile
Jul 17 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 17, 2014 at 05:32:36PM +0000, Right via Digitalmars-d wrote:
  I hate GC, so there.
 
I see no proof of this. And not everybody hates GCs.
[...] I don't, so here. :D T -- I see that you JS got Bach.
Jul 17 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/17/14, 2:32 PM, Right wrote:
   I hate GC, so there.

 I see no proof of this. And not everybody hates GCs.

 Bye,
 bearophile
Java is everywhere and it has a GC. Go is starting to be everywhere and I don't think everyone hates GCs. :-)
Jul 17 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2014-07-17 at 15:11 -0300, Ary Borenszweig via Digitalmars-d
wrote:
[=E2=80=A6]
 Java is everywhere and it has a GC. Go is starting to be everywhere and=
=20

=20
 I don't think everyone hates GCs. :-)
I think we need to try and turn this to a more constructive debate and the above gives a hook. The Go thread is coming to the conclusion that they need a better GC than they currently have. I suspect this will now become a unit of work and that something good will come of it. For many years GC in Java has been a bit of a problem; Java relies on GC, yet the algorithms were always a bit of a compromise and second rate. However Java now has the G1 garbage collector and there is evidence and a huge amount of hope that this is actually a turning point. Java exhibits the behaviour of having a lot of very short lived objects so it becomes crucial to be able to deal with object creation as a very lightweight activity and for very lightweight collection of rapidly useless objects. Java originally went for a generational GC strategy but this has always led to problems especially in a multicore context. Taking an alternative strategy, G1 has seemingly ameliorated a lot of the problems leading to a system that is not "stop the world", is multicore and multithread compatible, and works very well such that soft real time is seemingly not a problem. With C++ I am coming to grips with RAII management of the heap. With Java, Groovy, Go and Python I rely on the GC doing a good job. I note though that there is a lot of evidence that the Unreal folk developed a garbage collector for C++ exactly because they didn't want to do the RAII thing. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jul 17 2014
next sibling parent reply "Right" <Ohright ohplease.com> writes:
  I'm rather fond of RAII, I find that I rarely every need shared 
semantics.
  I use a custom object model that allows for weak_ptrs to 
unique_ptrs which I think removes some cases where people might 
otherwise be inclined to use shared_ptr.

  Shared semantics are so rare in fact I would say I hardly use it 
at all, I go for weeks of coding without creating a shared type, 
not because I'm trying to do so, but because it just isn't 
necessary.

  Which is why GC seems like such a waste, given my experience in 
C++, where I hardly need shared memory, I see little use for a 
GC(or even ARC etc), all it will do is decrease program 
performance, make deterministic destruction impossible, and 
prevent automatic cleanup of none memory resources.

  Rust seems to have caught on to what C++ has accomplished here.


  Oh, and Unreal? Yes they have a GC type "UObject", I worked on 
Unreal at one point, my impression was that this originated back 
with the original Unreal(circa 1998?), likely caused by the 
popularity of Java at the time. As for the Unreal code base? Pass 
on that.
Jul 17 2014
next sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Thursday, 17 July 2014 at 19:14:06 UTC, Right wrote:
  I'm rather fond of RAII, I find that I rarely every need 
 shared semantics.
  I use a custom object model that allows for weak_ptrs to 
 unique_ptrs which I think removes some cases where people might 
 otherwise be inclined to use shared_ptr.

  Shared semantics are so rare in fact I would say I hardly use 
 it at all, I go for weeks of coding without creating a shared 
 type, not because I'm trying to do so, but because it just 
 isn't necessary.

  Which is why GC seems like such a waste, given my experience 
 in C++, where I hardly need shared memory, I see little use for 
 a GC(or even ARC etc), all it will do is decrease program 
 performance, make deterministic destruction impossible, and 
 prevent automatic cleanup of none memory resources.

  Rust seems to have caught on to what C++ has accomplished here.


  Oh, and Unreal? Yes they have a GC type "UObject", I worked on 
 Unreal at one point, my impression was that this originated 
 back with the original Unreal(circa 1998?), likely caused by 
 the popularity of Java at the time. As for the Unreal code 
 base? Pass on that.
UEngine has been rewritten from scratch. UnrealScript doesn't even exist anymore. It is the new UEngine that depends on GC, and we're talking C++, not UnrealScript here (again, UnrealScript is gone).
Jul 17 2014
parent "Right" <Ohright ohplease.com> writes:
  UE4 wasn't really rewritten from scratch, was more like, take 
UE3,  rewrite various parts and add new features, keep doing that 
for a few years--

  Code style isn't modern C++.
No lambda, r-value refs, unique types, algorithms(everyone just 
bangs out for loops), task implementation is laughable, code 
mostly single threaded.

Basically verbosity hell.

  The dependency on GC is the same as previous versions, they did 
not fundamentally change the object model in UE4. I think they 
did work on the GC, so perhaps it is faster /shrug. They only use 
the GC for certain objects(deriving UObject).

  Powerful engine? Yes for sure. If I needed to make a graphically 
AAA game ASAP I'd use UE4. Doesn't change the fact that the code 
is nothing impressive.

The Blueprint system technically compiles down to UnrealScript 
bytecode-- but yes Unrealscript is dead, thankfully.


 UEngine has been rewritten from scratch.
 UnrealScript doesn't even exist anymore.
 It is the new UEngine that depends on GC, and we're talking 
 C++, not UnrealScript here (again, UnrealScript is gone).
Jul 17 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 17 July 2014 at 19:14:06 UTC, Right wrote:
  I'm rather fond of RAII, I find that I rarely every need 
 shared semantics.
  I use a custom object model that allows for weak_ptrs to 
 unique_ptrs which I think removes some cases where people might 
 otherwise be inclined to use shared_ptr.

  Shared semantics are so rare in fact I would say I hardly use 
 it at all, I go for weeks of coding without creating a shared 
 type, not because I'm trying to do so, but because it just 
 isn't necessary.

  Which is why GC seems like such a waste, given my experience 
 in C++, where I hardly need shared memory, I see little use for 
 a GC(or even ARC etc), all it will do is decrease program 
 performance, make deterministic destruction impossible, and 
 prevent automatic cleanup of none memory resources.

  Rust seems to have caught on to what C++ has accomplished here.
Though, GC is safer, easier and cheaper than ownership model, which is possible in D too, if you want it.
Jul 19 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 11:44 AM, Russel Winder via Digitalmars-d wrote:
 With C++ I am coming to grips with RAII management of the heap. With
 Java, Groovy, Go and Python I rely on the GC doing a good job. I note
 though that there is a lot of evidence that the Unreal folk developed a
 garbage collector for C++ exactly because they didn't want to do the
 RAII thing.
RAII has a lot of costs associated with it that I am often surprised go completely unrecognized by the RAII comunity: 1. the "dec" operation (i.e. shared_ptr) is expensive 2. the inability to freely mix pointers allocated with different schemes 3. slices become mostly unworkable, and slices are a fantastic way to speed up a program
Jul 19 2014
parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Saturday, 19 July 2014 at 21:12:44 UTC, Walter Bright wrote:
 3. slices become mostly unworkable, and slices are a fantastic 
 way to speed up a program
They are even more fantastic for speeding up programming. I think that programmer time isn't included often enough in discussions. I have a program which I used D to quickly prototype and form my baseline implementation. After getting a semi-refined implementation I converted the performance critical part to C++. The D code that survived the rewrite uses slices + ranges, and it's not worth converting that to C++ code (it would be less elegant and isn't worth the time.) The bottom line is that without D's slices, I might not have bothered bringing that small project to the level of completion it has today.
Jul 20 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
 On 7/17/14, 2:32 PM, Right wrote:
   I hate GC, so there.

 I see no proof of this. And not everybody hates GCs.

 Bye,
 bearophile
Java is everywhere and it has a GC. Go is starting to be everywhere and I don't think everyone hates GCs. :-)
http://www.stroustrup.com/C++11FAQ.html#gc-abi Andrei
Jul 17 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/17/14, 3:55 PM, Andrei Alexandrescu wrote:
 On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
 On 7/17/14, 2:32 PM, Right wrote:
   I hate GC, so there.

 I see no proof of this. And not everybody hates GCs.

 Bye,
 bearophile
Java is everywhere and it has a GC. Go is starting to be everywhere and I don't think everyone hates GCs. :-)
http://www.stroustrup.com/C++11FAQ.html#gc-abi Andrei
Sorry, but I don't understand your reply by just reading that link.
Jul 17 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/17/14, 12:26 PM, Ary Borenszweig wrote:
 On 7/17/14, 3:55 PM, Andrei Alexandrescu wrote:
 On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
 On 7/17/14, 2:32 PM, Right wrote:
   I hate GC, so there.

 I see no proof of this. And not everybody hates GCs.

 Bye,
 bearophile
Java is everywhere and it has a GC. Go is starting to be everywhere and I don't think everyone hates GCs. :-)
http://www.stroustrup.com/C++11FAQ.html#gc-abi Andrei
Sorry, but I don't understand your reply by just reading that link.
There's work on adding optional GC to C++ starting with C++11. -- Andrei
Jul 17 2014
prev sibling parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
 On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
 <snip>
 If D came without GC, it would have replaced C++ a long time 
 ago!
Agree +1000. If GC is so good, why not make it an option, have a base lib w/o GC. If I want GC, I got me JRE. It seems that some in D want to write a better JRE, and that just won't happen ever. Cheers, Vic
I can't think of anyone posting here, to be honest, who wants to write a better JRE. The JRE is a virtual machine, and java compiles to bytecode that is run on the JVM. On the contrary, and in accordance with the core principle that D is a systems programming language, D compiles to native and (hopefully) highly optimised native machine code. There does exist something of a 'culture clash' where, by the very nature of GCs, there can be not-insignificant pauses in the running of the program that would be inimicable to real-time software such as high res complex games, operating systems, drivers etc. The response to this in the forums is either to improve the GC so that it doesn't ever pause for more than a certain amount of time (e.g. concurrent GCs, remove the global lock so other threads can continue to run), or to offer alternative memory management approaches such as ARC, which can also have pauses, but at other inflections as the program runs. Personally I'm a bit disappointed that the good work that has been done on GCs so far doesn't seem to be being picked up and run with, and nor do I see any reasons given as to why that is the case. Adnrei was threatening to start another GC an one point but unfortunately I haven't seen any more of that and we all know how short of time every one seems to be these days. Also on a personal note, I see some slightly snarky comments Java. I just wish it had Qt (I must finish my bindings for Qt) and/or ran on Android! The GC issues are irrelevant for me.
Jul 17 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/17/14, 2:57 AM, currysoup wrote:
 On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
 On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
 Digitalmars-d wrote:
 It appears still to be a general meme that performance required no GC
 and GC mean poor performance. The debate has been restarted on the Go
 mailing list under the banner "go without garbage collector". The
 response to will Go remove the garbage collector was somewhat
 unequivocal: nope.
That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management. Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers).
Not at all costs! warp creates a little litter during e.g. command line preprocessing and other inconsequential tasks. The core of it is careful to not allocate frequently in inner loops.
 Once you're going to these lengths to
 avoid garbage collection it begs the question, why are you even using
 this language? Within this community the question is rhetorical but to
 outsiders I feel it's a major concern.
I agree there's a perception issue. Andrei
Jul 17 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
 Just from watching a few of the DConf 2014 talks, if you want 
 performance you avoid the GC at all costs (even if that means 
 allocating into huge predefined buffers). Once you're going to 
 these lengths to avoid garbage collection it begs the question, 
 why are you even using this language?
In D you have a choice to use GC or not use it. You would want to not use if you have a severe performance problem, which may or may not exist. There's no guarantee another language is a silver bullet and will magically solve all problems.
Jul 18 2014
prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
The key to making D's GC acceptable lies in two factors I believe.

1. Improve the implementation enough so that you will only be 
impacted by GC in extermely low memory or real time environments.
2. Defer allocation more and more by using ranges and algorithms 
more, and trust that compiler optimisations will make these fast.

The big, big offender I believe for extra allocations is 
functions which return objects, rather than functions which write 
to output ranges. The single most common occurence of this is 
something like this is toString. Instead of writing this...

string toString() {
     // Allocations the user of the library has no control over.
     return foo.toString() ~ bar.toString() ~ " something else";
}

I believe you should always, always instead write this.

// I left out the part with different character types.
void writeString(OutputRange)(OutputRange outputRange)
if (isOutputRange!(OutputRange, char)) {
     // Allocations controlle by the user of the library,
     // this template could appear in a  nogc function.
     foo.writeString(outputRange);
     bar.writeString(outputRange);

     "something else".copy(outputRange);
}

It's perhaps strange at first because you're pre-programmed from 
other languages, except maybe C++ which uses output streams, to 
always be allocating temporary objects everywhere, even if all 
you are doing is writing them to an object.

For improving the GC to an acceptable level, I believe collection 
only needs to execute fast enough such that it will fit within a 
frame comfortably. So for something rendering at 60FPS you have 1 
second / 60 frames ~= 16.6 milliseconds of computation you can do 
without resulting in a single dropped frame. That means you need 
to get collection down to something in the 1ms to 2ms region. At 
which point collection time will only impact something which is 
really pushing the hardware, which would exclude most mobile 
video games, which are about the complexity of Angry Birds.

I firmly believe there's no silver bullet for automatic memory 
management. Reference counting solutions, including automatic 
reference counting, will consume less memory than a garbage 
collector and offer more predictable collection times, but do so 
at the expense of memory safety and simplicity. You need fatter 
pointers to manage the reference counts, and you need to 
carefully deal with reference cycles.

In addition, you cannot easily share slices of memory with 
reference counting, which is an advantage of garbage collection. 
With GC, you can allocate a string, slice a part of it, hand over 
the slice to some other object, and you know that the slice will 
stay around for as long as it's needed. With reference counting, 
you have to either retain the slice and the whole segment in the 
same way and allow for the possibility of hidden cycles, or 
disallow slicing and create copies instead. Slicing in GC is 
important, because you can create much more efficient programs 
which take slices based on regex, which we do right now.

For the environments which cannot tolerate collection whatsoever, 
like Sociomantic's real time bidding operations, then control of 
allocation will have to be left to the user. This is where the 
zero allocation idea behind ranges and algorithms comes into 
play, because then the code which doesn't allocate, which could 
potentially be all of std.algorithm, can still be used in those 
environments, rather than being rendered unusable.

There's my thoughts on it anyway. I probably rambled on too long.
Jul 17 2014
next sibling parent "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:

 For improving the GC to an acceptable level, I believe 
 collection only needs to execute fast enough such that it will 
 fit within a frame comfortably. So for something rendering at 
 60FPS you have 1 second / 60 frames ~= 16.6 milliseconds of 
 computation you can do without resulting in a single dropped 
 frame. That means you need to get collection down to something 
 in the 1ms to 2ms region.
That's easy, just make sure your heap never grows over 0.4 MB. Seriously, 200 MB of small object in heap = 1 second. That's how bad it is now. And here Walter says it won't get much better. Ever. http://www.reddit.com/r/programming/comments/2avdod/dconf_2014_realtime_big_data_in_d_by_don_clugston/
Jul 17 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:
 The key to making D's GC acceptable lies in two factors I 
 believe.

 1. Improve the implementation enough so that you will only be 
 impacted by GC in extermely low memory or real time 
 environments.
 2. Defer allocation more and more by using ranges and 
 algorithms more, and trust that compiler optimisations will 
 make these fast.

 The big, big offender I believe for extra allocations is 
 functions which return objects, rather than functions which 
 write to output ranges. The single most common occurence of 
 this is something like this is toString. Instead of writing 
 this...

 string toString() {
     // Allocations the user of the library has no control over.
     return foo.toString() ~ bar.toString() ~ " something else";
 }

 I believe you should always, always instead write this.

 // I left out the part with different character types.
 void writeString(OutputRange)(OutputRange outputRange)
 if (isOutputRange!(OutputRange, char)) {
     // Allocations controlle by the user of the library,
     // this template could appear in a  nogc function.
     foo.writeString(outputRange);
     bar.writeString(outputRange);

     "something else".copy(outputRange);
 }
I agreed with this for awhile but following the conversation here <https://github.com/D-Programming-Language/phobos/pull/2149> I'm more inclined to think we should be adding lazy versions of functions where possible rather than versions with OutputRange parameters. It's more flexible that way and can result in even fewer allocations than even OutputRange parameters would have (i.e. you can have chains of lazy operations and only allocate on the final step, or not at all in some cases). Laziness isn't appropriate or possible everywhere but it's much easier to go from lazy to eager than the other way around.
 [...]
Jul 17 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
 I agreed with this for awhile but following the conversation 
 here 
 <https://github.com/D-Programming-Language/phobos/pull/2149> 
 I'm more inclined to think we should be adding lazy versions of 
 functions where possible rather than versions with OutputRange 
 parameters. It's more flexible that way and can result in even 
 fewer allocations than even OutputRange parameters would have 
 (i.e. you can have chains of lazy operations and only allocate 
 on the final step, or not at all in some cases).

 Laziness isn't appropriate or possible everywhere but it's much 
 easier to go from lazy to eager than the other way around.

 [...]
This is not comparable. Lazy input range based solutions do not make it possible to change allocation strategy, they simply defer the allocation point. Ideally both are needed.
Jul 17 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 17 July 2014 at 22:16:10 UTC, Dicebot wrote:
 On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
 I agreed with this for awhile but following the conversation 
 here 
 <https://github.com/D-Programming-Language/phobos/pull/2149> 
 I'm more inclined to think we should be adding lazy versions 
 of functions where possible rather than versions with 
 OutputRange parameters. It's more flexible that way and can 
 result in even fewer allocations than even OutputRange 
 parameters would have (i.e. you can have chains of lazy 
 operations and only allocate on the final step, or not at all 
 in some cases).

 Laziness isn't appropriate or possible everywhere but it's 
 much easier to go from lazy to eager than the other way around.

 [...]
This is not comparable. Lazy input range based solutions do not make it possible to change allocation strategy, they simply defer the allocation point. Ideally both are needed.
Well the idea is that you then copy into an output range with whatever allocation strategy you want at the end. There is quite a bit of overlap I think. Not complete overlap and OutputRange accepting functions will still be needed but I think we should prefer the lazy approach where possible.
Jul 17 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 17 July 2014 at 22:21:54 UTC, Brad Anderson wrote:
 Well the idea is that you then copy into an output range with 
 whatever allocation strategy you want at the end. There is 
 quite a bit of overlap I think. Not complete overlap and 
 OutputRange accepting functions will still be needed but I 
 think we should prefer the lazy approach where possible.
It is not always possible - sometimes resulting range element must be already "cooked" object. I do agree it is a powerful default when feasible though. At the same time simple output range overloads is much faster to add.
Jul 17 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 17 July 2014 at 22:27:52 UTC, Dicebot wrote:
 On Thursday, 17 July 2014 at 22:21:54 UTC, Brad Anderson wrote:
 Well the idea is that you then copy into an output range with 
 whatever allocation strategy you want at the end. There is 
 quite a bit of overlap I think. Not complete overlap and 
 OutputRange accepting functions will still be needed but I 
 think we should prefer the lazy approach where possible.
It is not always possible - sometimes resulting range element must be already "cooked" object. I do agree it is a powerful default when feasible though. At the same time simple output range overloads is much faster to add.
From what I'm getting is that we might have the chance here to redefine memory usage, as was pointed out by Teoh et al. Reduce allocations as much as possible, avoiding a problem in the first place is better than solving it. It's worth thinking in this direction, cos the GC / RC issue will always boil down to the fact that there is a price to be paid.
Jul 17 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 17, 2014 at 10:27:51PM +0000, Dicebot via Digitalmars-d wrote:
 On Thursday, 17 July 2014 at 22:21:54 UTC, Brad Anderson wrote:
Well the idea is that you then copy into an output range with
whatever allocation strategy you want at the end. There is quite a
bit of overlap I think. Not complete overlap and OutputRange
accepting functions will still be needed but I think we should prefer
the lazy approach where possible.
It is not always possible - sometimes resulting range element must be already "cooked" object.
Example?
 I do agree it is a powerful default when feasible though. At the same
 time simple output range overloads is much faster to add.
As Brad said, it's far easier to go from lazy to eager than the other way round, e.g., by sticking .array at the end, or .copy(buf) where buf is allocated according to whatever scheme the user chooses. Since buf is declared by the user, the user is free to use whatever allocation mechanism he wishes, the string algorithm doesn't know nor care what it is (and it shouldn't need to). T -- What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??
Jul 17 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 4:01 PM, H. S. Teoh via Digitalmars-d wrote:
 As Brad said, it's far easier to go from lazy to eager than the other
 way round, e.g., by sticking .array at the end, or .copy(buf) where buf
 is allocated according to whatever scheme the user chooses. Since buf is
 declared by the user, the user is free to use whatever allocation
 mechanism he wishes, the string algorithm doesn't know nor care what it
 is (and it shouldn't need to).
Yup. It enables separating the allocation strategy from the algorithm.
Jul 17 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 3:16 PM, Dicebot wrote:
 On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
 I agreed with this for awhile but following the conversation here
 <https://github.com/D-Programming-Language/phobos/pull/2149> I'm more inclined
 to think we should be adding lazy versions of functions where possible rather
 than versions with OutputRange parameters. It's more flexible that way and can
 result in even fewer allocations than even OutputRange parameters would have
 (i.e. you can have chains of lazy operations and only allocate on the final
 step, or not at all in some cases).

 Laziness isn't appropriate or possible everywhere but it's much easier to go
 from lazy to eager than the other way around.

 [...]
This is not comparable. Lazy input range based solutions do not make it possible to change allocation strategy, they simply defer the allocation point. Ideally both are needed.
They move the allocation point to the top level, rather than the bottom or intermediate level.
Jul 17 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 17, 2014 at 10:33:26PM -0700, Walter Bright via Digitalmars-d wrote:
 On 7/17/2014 3:16 PM, Dicebot wrote:
On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
I agreed with this for awhile but following the conversation here
<https://github.com/D-Programming-Language/phobos/pull/2149> I'm
more inclined to think we should be adding lazy versions of
functions where possible rather than versions with OutputRange
parameters. It's more flexible that way and can result in even fewer
allocations than even OutputRange parameters would have (i.e. you
can have chains of lazy operations and only allocate on the final
step, or not at all in some cases).

Laziness isn't appropriate or possible everywhere but it's much
easier to go from lazy to eager than the other way around.

[...]
This is not comparable. Lazy input range based solutions do not make it possible to change allocation strategy, they simply defer the allocation point. Ideally both are needed.
They move the allocation point to the top level, rather than the bottom or intermediate level.
Deferring the allocation point to the top level has the advantage of letting high-level user code decide what the allocation strategy should be, rather than percolating that decision down the call graph to every low-level function. Of course, it's not always possible to defer this, such as if you need to tell a container which allocator to use. But IMO this should be pushed up to higher-level code whenever possible. T -- Why can't you just be a nonconformist like everyone else? -- YHL
Jul 17 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2014 10:47 PM, H. S. Teoh via Digitalmars-d wrote:
 Deferring the allocation point to the top level has the advantage of
 letting high-level user code decide what the allocation strategy should
 be, rather than percolating that decision down the call graph to every
 low-level function.
Exactly.
 Of course, it's not always possible to defer this, such as if you need
 to tell a container which allocator to use. But IMO this should be
 pushed up to higher-level code whenever possible.
Andrei's allocator scheme addresses this. It will also allow such decisions to be made at the high level.
Jul 17 2014
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 Jul 2014 13:40, "w0rp via Digitalmars-d" <digitalmars-d puremagic.com>
wrote:
 The key to making D's GC acceptable lies in two factors I believe.

 1. Improve the implementation enough so that you will only be impacted by
GC in extermely low memory or real time environments.
 2. Defer allocation more and more by using ranges and algorithms more,
and trust that compiler optimisations will make these fast.

How about
1. Make it easier to select which GC you want to use at runtime init.
2. Write an alternate GC aimed at different application uses (ie: real-time)

We already have (at least) three GC implementations for D.

Regards
Iain
Jul 20 2014
parent reply "Mike" <none none.com> writes:
On Sunday, 20 July 2014 at 08:41:16 UTC, Iain Buclaw via 
Digitalmars-d wrote:
 On 17 Jul 2014 13:40, "w0rp via Digitalmars-d"
 The key to making D's GC acceptable lies in two factors I 
 believe.

 1. Improve the implementation enough so that you will only be 
 impacted by
GC in extermely low memory or real time environments.
 2. Defer allocation more and more by using ranges and 
 algorithms more,
and trust that compiler optimisations will make these fast.

 How about
 1. Make it easier to select which GC you want to use at runtime 
 init.
 2. Write an alternate GC aimed at different application uses 
 (ie: real-time)
Yes, Please! 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. DIP46 [1] also proposes and interesting alternative to the GC by creating regions at runtime. And given the passion surrounding the GC in this community, if runtime hooks and/or a suitable API for custom memory managers were created and documented, it would invite participation and an informal, highly competitive contest for the best GC would likely ensue. Mike [1] http://wiki.dlang.org/DIP46
Jul 20 2014
parent reply "Kagamin" <spam here.lot> writes:
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.
Jul 20 2014
parent reply "Mike" <none none.com> writes:
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
Jul 20 2014
parent "Kagamin" <spam here.lot> writes:
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.
Jul 21 2014
prev sibling parent reply "Remo" <remo4d gmail.com> writes:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via 
Digitalmars-d wrote:
 It appears still to be a general meme that performance required 
 no GC
 and GC mean poor performance. The debate has been restarted on 
 the Go
 mailing list under the banner "go without garbage collector". 
 The
 response to will Go remove the garbage collector was somewhat
 unequivocal: nope.
GC or no GC is that the right question ? The quality of GC implementation is probably more important. "Simpler and faster GC for Go" https://docs.google.com/document/d/1v4Oqa0WwHunqlb8C3ObL_uNQw3DfSY-ztoA-4wWbKcg/pub Another point that will be ignored in such debates is that GC gives solution for only one problem, memory management. How about other resources, how to manage them ?
Jul 17 2014
parent reply "Vic" <vic.cvc gmx.com> writes:
On Thursday, 17 July 2014 at 13:02:22 UTC, Remo wrote:
<snip>
 The quality of GC implementation is probably more important.
I disagree, I am a burn victim and don't trust smoke. Ideally it is optional. Cheers, Vic
Jul 17 2014
parent "Remo" <remo4d gmail.com> writes:
On Thursday, 17 July 2014 at 17:36:36 UTC, Vic wrote:
 On Thursday, 17 July 2014 at 13:02:22 UTC, Remo wrote:
 <snip>
 The quality of GC implementation is probably more important.
I disagree, I am a burn victim and don't trust smoke.
Well it appears to be very hard to make proper GC. So all the hate again GC could be because of suboptimal implementation? Any way as written before memory is not only one resource that need to be managed. So a language need to offer solution not only for memory management but all other resources. In C++ this is called RAII and work reasonable well. Rust looks even more promising for me.
 Ideally it is optional.
Yes for me too. GC must be optional. I hope nogc will allow this for D.
 Cheers,
 Vic
Jul 17 2014