February 01, 2014
On Sat, 01 Feb 2014 06:33:15 -0800, Frank Bauer <x@y.com> wrote:

> On Saturday, 1 February 2014 at 09:27:18 UTC, Adam Wilson wrote:
>> For the vast majority of use cases, a GC is the right call and D has to cater to the majority if it wants to gain any significant mindshare at all. You don't grow by increasing specialization...
>
> So catering to the C++ crowd who shun Java and C# not so much for JITing their code but precisely for their forced use of a GC is a "minority" issue then? Again, please take those of us more serious who don't like a GC to interfere with their business and if it's only for "programming hygiene" reasons. As you consider handling low latency requirements undue "specialisation" anyways.
>

Real-time or low-latency programming is absolutely specialization, and for more reasons than a GC. It might be what you do all day, but it's not what the majority of programmers do all day.

As far as catering to C++. TIOBE says that C++ made up 7.5% of programmer interest in January. Whereas Java+C# made up 22.4% of programmer interest. That's almost three-times the interest. Like it or not, C++ IS the minority and D's mission is not solely based on converting C++ users, many of whom can't convert anyways. The reason I picked those three languages is because they are D's primary audience.

> On Saturday, 1 February 2014 at 12:04:56 UTC, JR wrote:
>> To my uneducated eyes, an ARC collector does seem like the near-ideal solution
>
> ARC would be a plus for heavily interdependent code. But it doesn't beat unique_ptr semantics in local use that free their memory immediately as they go out of scope or are reassigned.
>

So you want C++ back then? Got it. But the goal of D is NOT to be a slightly better C++, it's a be a Safe, Simple, systems language with well defined semantics that just happens to trace it's lineage back to C++.

>> I would *dearly* love to have concurrency in whatever we end up with, though. For a multi-core personal computer threads are free lunches, or close enough so.
>
> No they are not. I want to make good use of all the cores I have available and I don't want to share them a bit with the GC. It's myyy ... precious.
>

Ahem. You only have the illusion of control over the CPU, the OS scheduler set's the rules, all you can do is provide hints. Giving some up to the GC will not materially affect the performance of the your code since you never had a choice anyways.

> As you may have guessed, my criticism is harsh because I love the language :)


-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
February 01, 2014
On Saturday, 1 February 2014 at 19:35:08 UTC, Manu wrote:
> I also firmly believe that if D - a native compiled language familiar to
> virtually all low-level programmers - doesn't have any ambition to service
> the embedded space in the future, what will?

I feel like Rust have already won this. It has more suitable basic and has more developers -> evolves faster in general. Can be too late to even call it priority.

// only 50% trolling
February 01, 2014
On Sat, 01 Feb 2014 02:15:42 -0800, Manu <turkeyman@gmail.com> wrote:

> On 1 February 2014 19:27, Adam Wilson <flyboynw@gmail.com> wrote:
>
>> On Fri, 31 Jan 2014 23:35:44 -0800, Manu <turkeyman@gmail.com> wrote:
>>
>>  On 1 February 2014 16:26, Adam Wilson <flyboynw@gmail.com> wrote:
>>>
>>>  On Fri, 31 Jan 2014 21:29:04 -0800, Manu <turkeyman@gmail.com> wrote:
>>>>
>>>>  On 26 December 2012 00:48, Sven Over <dlang@svenover.de> wrote:
>>>>
>>>>>
>>>>>   std.typecons.RefCounted!T
>>>>>
>>>>>>
>>>>>>
>>>>>>> core.memory.GC.disable();
>>>>>>>
>>>>>>>
>>>>>>>  Wow. That was easy.
>>>>>>
>>>>>> I see, D's claim of being a multi-paradigm language is not false.
>>>>>>
>>>>>>
>>>>>
>>>>> It's not a realistic suggestion. Everything you want to link uses the
>>>>> GC,
>>>>> and the language its self also uses the GC. Unless you write software in
>>>>> complete isolation and forego many valuable features, it's not a
>>>>> solution.
>>>>>
>>>>>
>>>>>  Phobos does rely on the GC to some extent. Most algorithms and ranges
>>>>> do
>>>>>
>>>>>  not though.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  Running (library) code that was written with GC in mind and turning
>>>>>> GC
>>>>>> off
>>>>>> doesn't sound ideal.
>>>>>>
>>>>>> But maybe this allows me to familiarise myself more with D. Who knows,
>>>>>> maybe I can learn to stop worrying and love garbage collection.
>>>>>>
>>>>>> Thanks for your help!
>>>>>>
>>>>>>
>>>>>>  I've been trying to learn to love the GC for as long as I've been
>>>>> around
>>>>> here. I really wanted to break that mental barrier, but it hasn't
>>>>> happened.
>>>>> In fact, I am more than ever convinced that the GC won't do. My current
>>>>> #1
>>>>> wishlist item for D is the ability to use a reference counted collector
>>>>> in
>>>>> place of the built-in GC.
>>>>> You're not alone :)
>>>>>
>>>>> I write realtime and memory-constrained software (console games), and
>>>>> for
>>>>> me, I think the biggest issue that can never be solved is the
>>>>> non-deterministic nature of the collect cycles, and the unknowable
>>>>> memory
>>>>> footprint of the application. You can't make any guarantees or
>>>>> predictions
>>>>> about the GC, which is fundamentally incompatible with realtime
>>>>> software.
>>>>> Language-level ARC would probably do quite nicely for the miscellaneous
>>>>> allocations. Obviously, bulk allocations are still usually best handled
>>>>> in
>>>>> a context sensitive manner; ie, regions/pools/freelists/whatever, but
>>>>> the
>>>>> convenience of the GC paradigm does offer some interesting and massively
>>>>> time-saving features to D.
>>>>> Everyone will always refer you to RefCounted, which mangles your types
>>>>> and
>>>>> pollutes your code, but aside from that, for ARC to be useful, it needs
>>>>> to
>>>>> be supported at the language-level, such that the language/optimiser is
>>>>> able to optimise out redundant incref/decref calls, and also that it is
>>>>> compatible with immutable (you can't manage a refcount if the object is
>>>>> immutable).
>>>>>
>>>>>
>>>> The problem isn't GC's per se. But D's horribly naive implementation,
>>>> games are written on GC languages now all the time (Unity/.NET). And
>>>> let's
>>>> be honest, games are kind of a speciality, games do things most programs
>>>> will never do.
>>>>
>>>> You might want to read the GC Handbook. GC's aren't bad, but most, like
>>>> the D GC, are just to simplistic for common usage today.
>>>>
>>>
>>>
>>> Maybe a sufficiently advanced GC could address the performance
>>> non-determinism to an acceptable level, but you're still left with the
>>> memory non-determinism, and the conundrum that when your heap approaches
>>> full (which is _always_ on a games console), the GC has to work harder and
>>> harder, and more often to try and keep the tiny little bit of overhead
>>> available.
>>> A GC heap by nature expects you to have lots of memory, and also lots of
>>> FREE memory.
>>>
>>> No serious console game I'm aware of has ever been written in a language
>>> with a GC. Casual games, or games that don't attempt to raise the bar may
>>> get away with it, but that's not the industry I work in.
>>>
>>
>> That's kind of my point. You're asking for massive changes throughout the
>> entire compiler to support what is becoming more of an edge case, not less
>> of one. For the vast majority of use cases, a GC is the right call and D
>> has to cater to the majority if it wants to gain any significant mindshare
>> at all. You don't grow by increasing specialization...
>
>
> Why is ARC any worse than GC? Why is it even a compromise at the high level?
> Major players have been moving away from GC to ARC in recent years. It's
> still a perfectly valid method of garbage collection, and it has the
> advantage that it's intrinsically real-time compatible.
>

Define Major Players? Because I only know about Apple, but they've been doing ARC for almost a decade, and IIRC, like GC's, it's not universally loved there either. Microsoft is desperately trying to get people to move back to C++ but so far the community has spoken with a resounding "You can pry C#/.NET from our cold, dead, hands." Java has shown no particular interest in moving away from GC's probably because their GC is best in class. Even games are starting to bring in GC's (The Witcher 2 for example, and almost all of the mobile/casual games market, which is actually monetarily bigger than the triple-A games market.)

> I don't think realtime software is becoming an edge case by any means,
> maybe 'extreme' realtime is, but that doesn't change the fact that the GC
> still causes problems for all realtime software.
>

Yes, but my point is that there is very little real-time software written as a percentage of all software written, which, by definition, makes it an edge-case. Even vehicle control software is no longer completely real-time. [I just happen to know that because that's the industry I work in. Certain aspects are, with the rest scheduled out.] And more to the point, D has made no claim about it's suitability for RT software and I have seen little demand for it outside a very small very vocal minority that is convinced that it has the dynamic resource management panacea if everyone would just do as they say.

> I personally believe latency and stuttering is one of the biggest usability
> hindrances in modern computing, and it will become a specific design focus
> in software of the future. People are becoming less and less tolerant of
> latency in all forms; just consider the success of iPhone compared to
> competition, almost entirely attributable to the silky smooth UI
> experience. It may also be a telling move that Apple switched to ARC around
> the same time, but I don't know the details.
>

I use .NET every day, seriously not one day goes by when I haven't touched some C# code. I can happily report that you are *ahem* wrong. Even Visual Studio 2013 doesn't stutter often, and only when I am pulling in some massive third-party module that may or may not be well written. Ironically, it is VisualD, it of D code fame that most slows down VS for me. I write software in C# every day I can happily report that I have yet to have a problem with stuttering in my code that wasn't of my own devise. (If you forget to asynchronously call that web-service it WILL stutter)

And that's a point. I can write software in C# that works will without having to worry about circular references or if my data prematurely falls out of scope or any other of the details that are associated with ARC. And for my not-effort, I pay an effective cost of 0. Win-win. You're demanding that to suit your needs, we make a massive philosophical and language change to D that will incur HIGHER cognitive load on programmers for something that will not measurably improve the general use case? Ahem, that's good for D how?

> I also firmly believe that if D - a native compiled language familiar to
> virtually all low-level programmers - doesn't have any ambition to service
> the embedded space in the future, what will? And why not?
> The GC is the only thing inhibiting D from being a successful match in that
> context. ARC is far more appropriate, and will see it enter a lot more
> fields.
> What's the loss?
>

Cognitive load. How many details does the programmer have to worry about per line of code. Ease-of-use. A GC is easier to use in practice. You can say well they should learn to use ARC because it's better (for certain definitions of better) but they won't. They'll just move on. I'd say that's a pretty big loss.

And based on my conversations with Walter, I don't think that D was ever intended to make a play for the embedded space. If D can be made to work there great, but Walter, as near as I can tell, has no interest in tying the language in knots to make it happen. So that's a non-issue. And let's be honest, the requirements of that space are fairly extreme.

> I think it's also telling that newcomers constantly raise it as a massive
> concern, or even a deal-breaker. Would they feel the same about ARC? I
> seriously doubt it. I wonder if a poll is in order...
> Conversely, would any of the new-comers who are pro-GC feel any less happy
> if it were ARC instead? $100 says they probably wouldn't even know, and
> almost certainly wouldn't care.

I DON'T see a majority of newcomers raising an issue with the GC, I only see it from newcomers with some pretty extreme latency requirements, primarily for the real-time crowd. The majority of newcomers aren't interested in RT work. I think you're falling prey to confirmation bias here.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
February 02, 2014
Granted, low latency apps are the minority. C++ apps are a minority compared to C# and Java combined. Beyond any doubt there is merit to a GC in all apps that don't have to squeeze the last bit of performance out of the machine, yes, the vast majority, I know.

But maybe we should ask ourselves if it makes sense to get the low latency developers on board, especially if D's syntax remains basically unchanged in the process. Heck, we could even keep 'new' instead of Rusts '~' for owning pointers.

On Saturday, 1 February 2014 at 19:40:20 UTC, Adam Wilson wrote:
> On Sat, 01 Feb 2014 06:33:15 -0800, Frank Bauer <x@y.com> wrote:
>> ARC would be a plus for heavily interdependent code. But it doesn't beat unique_ptr semantics in local use that free their memory immediately as they go out of scope or are reassigned.
>>
> So you want C++ back then? Got it.

Ahem ... no you don't. I tried to make my point as clear as possible. Unique_ptr *semantics*, e.g. Rusts 'let x = ~X' *without* GC is as easy to use as 'auto x = new X' *with* GC. In both cases the runtime takes care of freeing the object without user intervention.

So newbies should not be turned off, if that is your concern.

In general, I don't understand your arguments against dumping the GC if it does not make much difference in your code anyways? Getting rid of mandatory GC would not take away one iota of your D expressiveness. It means more work on the part of D's implementers, to be sure.

I'm close to Stuttgart and Ingolstadt where Mercedes Benz and Audi produce their flagship cars for a tiny minority of customers. Yet their reputation with the average buyer relies heavily on how well their top of the line products fare.

Do we want D to be the flagship?
February 02, 2014
On 02/01/2014 06:57 PM, Frustrated wrote:
>
> Right, and because of the mentality that the GC is one size that
> fits all, phobos got this way. That mentality is still pervasive. ...

In the D community? Hardly.

> I call it laziness.
> ...

Well, name-calling does not get anything fixed.
February 02, 2014
On Sat, 01 Feb 2014 16:07:20 -0800, Frank Bauer <y@z.com> wrote:

> Granted, low latency apps are the minority. C++ apps are a minority compared to C# and Java combined. Beyond any doubt there is merit to a GC in all apps that don't have to squeeze the last bit of performance out of the machine, yes, the vast majority, I know.
>
> But maybe we should ask ourselves if it makes sense to get the low latency developers on board, especially if D's syntax remains basically unchanged in the process. Heck, we could even keep 'new' instead of Rusts '~' for owning pointers.
>
> On Saturday, 1 February 2014 at 19:40:20 UTC, Adam Wilson wrote:
>> On Sat, 01 Feb 2014 06:33:15 -0800, Frank Bauer <x@y.com> wrote:
>>> ARC would be a plus for heavily interdependent code. But it doesn't beat unique_ptr semantics in local use that free their memory immediately as they go out of scope or are reassigned.
>>>
>> So you want C++ back then? Got it.
>
> Ahem ... no you don't. I tried to make my point as clear as possible. Unique_ptr *semantics*, e.g. Rusts 'let x = ~X' *without* GC is as easy to use as 'auto x = new X' *with* GC. In both cases the runtime takes care of freeing the object without user intervention.
>
> So newbies should not be turned off, if that is your concern.
>
> In general, I don't understand your arguments against dumping the GC if it does not make much difference in your code anyways? Getting rid of mandatory GC would not take away one iota of your D expressiveness. It means more work on the part of D's implementers, to be sure.
>
> I'm close to Stuttgart and Ingolstadt where Mercedes Benz and Audi produce their flagship cars for a tiny minority of customers. Yet their reputation with the average buyer relies heavily on how well their top of the line products fare.
>
> Do we want D to be the flagship?

The problem isn't syntax, it's semantics. It's not 'new' versus '~' (which by the way is not easy to type on a standard US keyboard, it's a shift+key that's in an an uncomfortable position). It's the number of rules and special cases around what happens when I do something. You're right, you are not asking for a big syntactic change, and I know that. What you are asking for is a massive semantics change, and that means new rules and most likely, more of them.

Let's look at some numbers. TIOBE, Go is #36, Rust does not even make the Top 100. On TIOBE, there are three non-GC languages in the entire top 20 (C, C++, Obj-C) the rest feature a non-ARC GC of some form. I am not concerned with how the languages manage memory under-the-hood, only how they present their memory management semantics to the user.

It's interesting that you bring up Mercedes and Audi. Yes, their reputation is defined by their high-end products. But how many people actually buy an R8 or an SLK Black? The vast majority or everyday don't buy a completely bonkers super-car, they by cars that get the job done. Why do Toyota and Volkswagen produce the most cars in the world? Not because either company (yes, I am aware of VW's 13 name-plates, I'm talking about the VW name-plate here) is particularly renowned for producing supercars, but because their cars reliably get the job done. A Corolla is not the fastest, it's not the prettiest, and it's certainly not the most expensive. More Corolla's have been sold world-wide (40 million) than any other single car model in history.

You want a super-car, with all the fancy buttons and knobs and options, and ARC is very analogous to a super-car in this respect. In fact many of the complaints I see about Obj-C's ARC have to do with the semantics of it. ARC is by definition semantically more complex than a GC. But most people don't want those options, they just want to put the key in and have the car reliably do what they ask within reasonable boundaries and that is what a GC does best. The semantics of a good GC are nearly transparent.

But that's where the analogy breaks down. You can stratify car models. You can't deliver multiple exclusive strata in a programming language. A language is what it is, there are no multiple levels.

You say, let's bring on the low-latency developers to prove how fast D is and how it has all these great options. The problem is most programmers don't need those options on a day to day basis, but having to carry around the semantics for them everywhere is wearying. I say, let's fix the GC to so that the masses can do what they need to do without any fuss.

Most car drivers aren't Jeremy Clarkson. And most programmers aren't real-time embedded developers. A friend of mine has a saying "Sell to the masses, eat with the classes. Sell to the classes, eat with the masses." It's a catchy way of saying, you don't make money or gain popularity by catering to the most demanding of users or the most wealthy of clients. You gain popularity by catering to the NEEDS of the everyday user, or the middle-class client.

The reason I am being to vehement, is that I unlike most people here, I see D as needing to focus on making the experience better for the every day programmer, NOT the experience of the most demanding users. And as C++ has proven, the two are distinct, writing a language that caters to the high-end often precludes the semantics that appeal to the everyday precisely because those semantics are too slow.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
February 02, 2014
On 1 February 2014 22:04, JR <zorael@gmail.com> wrote:

> On Saturday, 1 February 2014 at 05:36:44 UTC, Manu wrote:
>
>> I write realtime and memory-constrained software (console games), and for me, I think the biggest issue that can never be solved is the non-deterministic nature of the collect cycles, and the unknowable memory footprint of the application. You can't make any guarantees or predictions about the GC, which is fundamentally incompatible with realtime software.
>>
> (tried to manually fix ugly linebreaks here, so apologies if it turns out
> even worse.)
>
> (Maybe this would be better posted in D.learn; if so I'll crosspost.)
>
> In your opinion, of how much value would deadlining be? As in, "okay handyman, you may sweep the floor now BUT ONLY FOR 6 MILLISECONDS; whatever's left after that you'll have to take care of next time, your pride as a professional Sweeper be damned"?
>

This has been my only suggestion for years. Although 6ms is way too much
(almost half a frame), 500us is more realistic (a little over 3% of a
frame, still quite a lot of time).

It obviously doesn't address memory footprint, but you would get the
> illusion of determinism in cases similar to where race-to-idle approaches work. Inarguably, this wouldn't apply if the goal is to render as many frames per second as possible, such as for non-console shooters where tearing is not a concern but latency is very much so.
>

If it were running a small amount every frame, maybe the memory footprint would stay within a predictable level... don't know. I'd be interested in experimenting with this, but as far as I know, nobody knows how to do it.

I'm very much a layman in this field, but I'm trying to soak up as much
> knowledge as possible, and most of it from threads like these. To my uneducated eyes, an ARC collector does seem like the near-ideal solution -- assuming, as always, the code is written with the GC in mind. But am I right in gathering that it solves two-thirds of the problem? You don't need to scan the managed heap, but when memory is actually freed is still non-deterministic and may incur pauses, though not necessarily a program-wide stop. Aye?
>

I'm not sure what you mean. If you mean pauses because it's simply doing
work to free things, then that's deterministically issued workload just
like anything else and can (should) be budgeted. It doesn't disappear in a
GC context, it just happens in bursts at unpredictable times.
Like you say, it doesn't stop the world, no need for that. Additionally, it
leaves room for case-by-case flexibility in destruction approach. If
something takes some time to destroy, and you're okay to have it hang
around for a while, you can easily plonk it in a dead list waiting for some
idle time to work through it; thus truly allows the opportunity to use idle
time to clean stuff up since you don't need to scan the heap every time, a
list of things waiting to be destroyed is already known.
You could also add dead objects to a list which can be processed by another
thread (without stopping all threads).
There is far more opportunity to implement the destruction pattern that
suits your application, and for those not interested in implementing their
own destruction patterns, it would be easy to offer a library function
setDestructionPattern(patternType); which would configure a particular
policy application-wide, and they'd never have to think about it again.

At the same time, Lucarella's dconf slides were very, very attractive. I
> gather that allocations themselves may become slower with a concurrent collector, but collection times in essence become non-issues. Technically parallelism doesn't equate to free CPU time; but that it more or less *is* assuming there is a cores/thread to spare. Wrong?
>

IIRC, it assumes a particular operating system, and required significant
resource overhead. I recall being impressed, but concluding that it wasn't
a solution that could be merged into D across the board.
I'd need to go back and revisit the slides...

Lastly, am I right in understanding precise collectors as identical to the
> stop-the-world collector we currently have, but with a smarter allocation scheme resulting in a smaller managed heap to scan? With the additional bonus of less false pointers. If so, this would seem like a good improvement to the current implementation, with the next increment in the same direction being a generational gc.
>

I think the reduction in heap to scan is due to only following what are
known to be pointers, but I don't think that reduces the scan volume, the
memory footprint of your app is the same (more because there's new
metadata), but it wouldn't chase false pointers anymore.
I recall most agreed that it was a good improvement (although it
benchmarked something like 5% slower), I would appreciate it simply for the
improved precision... but it doesn't solve the problem in any way. The
practical application for me is that it wouldn't leak (much) memory.

I would *dearly* love to have concurrency in whatever we end up with,
> though. For a multi-core personal computer threads are free lunches, or close enough so. Concurrentgate and all that jazz.
>

The kicker for me with the whole GC thing, is that as long as I've been
talking about it around here (among a whole bunch of experts), I've been
saying that an acceptable GC would require to 1. not stop the world, 2.
support incremental collection/time-slicing, so I can budget it a maximum
amount of time per frame.
I'm yet to hear anyone suggest how they can even IMAGINE writing a
collector like that. As far as I can tell, the consensus is, that it's
impossible.
Certainly, nobody has ever given any suggestions how it could possibly be
done in the future, or steps in that direction, which says a lot to me.
I've abandoned the idea as unrealistic fantasy.


February 02, 2014
On 1 February 2014 22:35, develop32 <develop32@gmail.com> wrote:

> On Saturday, 1 February 2014 at 12:29:10 UTC, Nick Sabalausky wrote:
>
>> Come to think of it, I wonder what language Frostbite 3 uses for game-level "scripting" code. From what I've heard about them, Frostbite 3 and Unreal Engine 4 both sound like they have some notable similarities with Unity3D (from the standpoint of the user-experience for game developers), although AIUI Unreal Engine 4 still uses C++ for game code (unless the engine user wants to to do lua or something on their own). I imagine Frostbite's probably the same, C++, but I haven't actually heard anything.
>>
>
> Frostbite has an option for both Lua and C++. C++ is the preferred one.
>
> Unreal Engine went from Unrealscript to C++ and everyone applauded that.
>

Correct, this is the general trend I see. idTech also uses C/C++ DLL's for 'scripting'.

At Remedy, we were keen to migrate our scripts to native code in the same way, except using D instead of C++. The proof of concept is solid.


February 02, 2014
On 2 February 2014 00:33, Frank Bauer <x@y.com> wrote:

> On Saturday, 1 February 2014 at 09:27:18 UTC, Adam Wilson wrote:
>
>> For the vast majority of use cases, a GC is the right call and D has to cater to the majority if it wants to gain any significant mindshare at all. You don't grow by increasing specialization...
>>
>
> So catering to the C++ crowd who shun Java and C# not so much for JITing their code but precisely for their forced use of a GC is a "minority" issue then? Again, please take those of us more serious who don't like a GC to interfere with their business and if it's only for "programming hygiene" reasons. As you consider handling low latency requirements undue "specialisation" anyways.
>
>
> On Saturday, 1 February 2014 at 12:04:56 UTC, JR wrote:
>
>> To my uneducated eyes, an ARC collector does seem like the near-ideal solution
>>
>
> ARC would be a plus for heavily interdependent code. But it doesn't beat unique_ptr semantics in local use that free their memory immediately as they go out of scope or are reassigned.


Why wouldn't ARC do this?

 I would *dearly* love to have concurrency in whatever we end up with,
>> though. For a multi-core personal computer threads are free lunches, or close enough so.
>>
>
> No they are not. I want to make good use of all the cores I have available and I don't want to share them a bit with the GC. It's myyy ... precious.
>
> As you may have guessed, my criticism is harsh because I love the language :)
>


February 02, 2014
On Sat, 01 Feb 2014 17:58:01 -0800, Manu <turkeyman@gmail.com> wrote:

> On 1 February 2014 22:04, JR <zorael@gmail.com> wrote:
>
>> On Saturday, 1 February 2014 at 05:36:44 UTC, Manu wrote:
>>
>>> I write realtime and memory-constrained software (console games), and for
>>> me, I think the biggest issue that can never be solved is the
>>> non-deterministic nature of the collect cycles, and the unknowable memory
>>> footprint of the application. You can't make any guarantees or predictions
>>> about the GC, which is fundamentally incompatible with realtime software.
>>>
>> (tried to manually fix ugly linebreaks here, so apologies if it turns out
>> even worse.)
>>
>> (Maybe this would be better posted in D.learn; if so I'll crosspost.)
>>
>> In your opinion, of how much value would deadlining be? As in, "okay
>> handyman, you may sweep the floor now BUT ONLY FOR 6 MILLISECONDS;
>> whatever's left after that you'll have to take care of next time, your
>> pride as a professional Sweeper be damned"?
>>
>
> This has been my only suggestion for years. Although 6ms is way too much
> (almost half a frame), 500us is more realistic (a little over 3% of a
> frame, still quite a lot of time).
>
> It obviously doesn't address memory footprint, but you would get the
>> illusion of determinism in cases similar to where race-to-idle approaches
>> work. Inarguably, this wouldn't apply if the goal is to render as many
>> frames per second as possible, such as for non-console shooters where
>> tearing is not a concern but latency is very much so.
>>
>
> If it were running a small amount every frame, maybe the memory footprint
> would stay within a predictable level... don't know. I'd be interested in
> experimenting with this, but as far as I know, nobody knows how to do it.
>
> I'm very much a layman in this field, but I'm trying to soak up as much
>> knowledge as possible, and most of it from threads like these. To my
>> uneducated eyes, an ARC collector does seem like the near-ideal solution --
>> assuming, as always, the code is written with the GC in mind. But am I
>> right in gathering that it solves two-thirds of the problem? You don't need
>> to scan the managed heap, but when memory is actually freed is still
>> non-deterministic and may incur pauses, though not necessarily a
>> program-wide stop. Aye?
>>
>
> I'm not sure what you mean. If you mean pauses because it's simply doing
> work to free things, then that's deterministically issued workload just
> like anything else and can (should) be budgeted. It doesn't disappear in a
> GC context, it just happens in bursts at unpredictable times.
> Like you say, it doesn't stop the world, no need for that. Additionally, it
> leaves room for case-by-case flexibility in destruction approach. If
> something takes some time to destroy, and you're okay to have it hang
> around for a while, you can easily plonk it in a dead list waiting for some
> idle time to work through it; thus truly allows the opportunity to use idle
> time to clean stuff up since you don't need to scan the heap every time, a
> list of things waiting to be destroyed is already known.
> You could also add dead objects to a list which can be processed by another
> thread (without stopping all threads).
> There is far more opportunity to implement the destruction pattern that
> suits your application, and for those not interested in implementing their
> own destruction patterns, it would be easy to offer a library function
> setDestructionPattern(patternType); which would configure a particular
> policy application-wide, and they'd never have to think about it again.
>
> At the same time, Lucarella's dconf slides were very, very attractive. I
>> gather that allocations themselves may become slower with a concurrent
>> collector, but collection times in essence become non-issues. Technically
>> parallelism doesn't equate to free CPU time; but that it more or less *is*
>> assuming there is a cores/thread to spare. Wrong?
>>
>
> IIRC, it assumes a particular operating system, and required significant
> resource overhead. I recall being impressed, but concluding that it wasn't
> a solution that could be merged into D across the board.
> I'd need to go back and revisit the slides...
>
> Lastly, am I right in understanding precise collectors as identical to the
>> stop-the-world collector we currently have, but with a smarter allocation
>> scheme resulting in a smaller managed heap to scan? With the additional
>> bonus of less false pointers. If so, this would seem like a good
>> improvement to the current implementation, with the next increment in the
>> same direction being a generational gc.
>>
>
> I think the reduction in heap to scan is due to only following what are
> known to be pointers, but I don't think that reduces the scan volume, the
> memory footprint of your app is the same (more because there's new
> metadata), but it wouldn't chase false pointers anymore.
> I recall most agreed that it was a good improvement (although it
> benchmarked something like 5% slower), I would appreciate it simply for the
> improved precision... but it doesn't solve the problem in any way. The
> practical application for me is that it wouldn't leak (much) memory.
>
> I would *dearly* love to have concurrency in whatever we end up with,
>> though. For a multi-core personal computer threads are free lunches, or
>> close enough so. Concurrentgate and all that jazz.
>>
>
> The kicker for me with the whole GC thing, is that as long as I've been
> talking about it around here (among a whole bunch of experts), I've been
> saying that an acceptable GC would require to 1. not stop the world, 2.
> support incremental collection/time-slicing, so I can budget it a maximum
> amount of time per frame.
> I'm yet to hear anyone suggest how they can even IMAGINE writing a
> collector like that. As far as I can tell, the consensus is, that it's
> impossible.
> Certainly, nobody has ever given any suggestions how it could possibly be
> done in the future, or steps in that direction, which says a lot to me.
> I've abandoned the idea as unrealistic fantasy.

It is impossible with a conservative GC such as the current D implementation. Boehm tried with his C++ collector but could never get beyond the basic Mark-LazySweep because C++ enforces a conservative mindset.

When you have precision a number of options open up. Firstly, you can now parallelize all phases because pointers are precisely known. And second, you can start to do things like moving (a prereq for generational collection) because you don't have to pin things that you conservatively think are pointers. Now that you have a generational collector, it's trivial to do an incremental collection on one or more generations.

So therefore precision is the first step, and more to the point it's already been done in D, VisualD uses a precise version of the stock D GC and special build of the compiler with precise information emitted at compile time. That was what Rainer's talk was about at DConf last year. Getting this merged into the mainline will mean that there is finally enough information for us to go nuts building an actually useful GC in D, but until then you really can't progress beyond what we have right now.

It's quite possible, it's just a matter of getting the worked vetted at merged.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator