Re: GCs in the news
On Monday, 21 July 2014 at 18:31:46 UTC, Russel Winder via Digitalmars-d wrote: On Sun, 2014-07-20 at 16:40 +, 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
Re: GCs in the news
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 +, 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
Re: GCs in the news
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.
Re: GCs in the news
On Sun, 2014-07-20 at 16:40 +, Paulo Pinto via Digitalmars-d wrote: […] Java has AOT compilers available since the early days. Most developers just tend to ignore them, because they are not part of the free package. Also, it is not entirely clear that AOT optimization can beat JIT optimization, at least on the JVM. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: GCs in the news
On Monday, 21 July 2014 at 18:31:46 UTC, Russel Winder via Digitalmars-d wrote: On Sun, 2014-07-20 at 16:40 +, 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.
Re: GCs in the news
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.
Re: GCs in the news
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
Re: GCs in the news
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
Re: GCs in the news
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.
Re: GCs in the news
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
Re: GCs in the news
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!
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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
Re: GCs in the news
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!
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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 +, 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.
Re: GCs in the news
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 +, 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.
Re: GCs in the news
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).
Re: GCs in the news
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.
Re: GCs in the news
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). The same (ie: big companies with GC) holds for C# and Java. They do not aim for the systems programming language mantra. If D is another competitor for Java and C#... (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.
Re: GCs in the news
currysoup wrote in message news:iustbzgyagrlbtnfc...@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.
Re: GCs in the news
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 that Java and C# don't. Can you write a device 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.
Re: GCs in the news
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 with the machine that Java and C# don't. Can you write a device 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!
Re: GCs in the news
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 with the machine that Java and C# don't. Can you write a device 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
Re: GCs in the news
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.
Re: GCs in the news
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 ?
Re: GCs in the news
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!
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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)?
Re: GCs in the news
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.
Re: GCs in the news
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
Re: GCs in the news
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
Re: GCs in the news
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/
Re: GCs in the news
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
Re: GCs in the news
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.
Re: GCs in the news
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
Re: GCs in the news
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
Re: GCs in the news
I hate GC, so there. I see no proof of this. And not everybody hates GCs. Bye, bearophile
Re: GCs in the news
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
Re: GCs in the news
On Thu, Jul 17, 2014 at 05:32:36PM +, 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.
Re: GCs in the news
On Thu, Jul 17, 2014 at 05:28:01PM +, 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
Re: GCs in the news
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 +, 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.
Re: GCs in the news
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)
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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 it has a GC. C# too has a GC, and I think they use it to make games too. I don't think everyone hates GCs. :-)
Re: GCs in the news
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 about D targeting C# and Java. Well from my perspective I'm extremely happy with the fact that D is a better C# and a better 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.
Re: GCs in the news
On Thu, Jul 17, 2014 at 05:58:14PM +, 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
Re: GCs in the news
On Thu, Jul 17, 2014 at 06:09:49PM +, 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
Re: GCs in the news
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
Re: GCs in the news
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) )
Re: GCs in the news
On Thu, 2014-07-17 at 15:11 -0300, Ary Borenszweig via Digitalmars-d wrote: […] Java is everywhere and it has a GC. Go is starting to be everywhere and it has a GC. C# too has a GC, and I think they use it to make games too. 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. I have no data re C#. 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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: GCs in the news
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 it has a GC. C# too has a GC, and I think they use it to make games too. I don't think everyone hates GCs. :-) http://www.stroustrup.com/C++11FAQ.html#gc-abi Andrei
Re: GCs in the news
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
Re: GCs in the news
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.
Re: GCs in the news
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 it has a GC. C# too has a GC, and I think they use it to make games too. 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.
Re: GCs in the news
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 it has a GC. C# too has a GC, and I think they use it to make games too. 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
Re: GCs in the news
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).
Re: GCs in the news
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.
[...]
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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).
Re: GCs in the news
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.
Re: GCs in the news
On Thu, Jul 17, 2014 at 10:27:51PM +, 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??
Re: GCs in the news
On Thu, Jul 17, 2014 at 06:32:58PM +, 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
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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.
Re: GCs in the news
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
