www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve

reply Ethan <gooberman gmail.com> writes:
There's many nuanced points to consider here, so given that GC 
came up on the live Q&A and I got in to a bit of a chat there I 
figured copy/pasting that log and getting in to a (real, 
stop-saying-gamedev-doesn't-want-this) longer form discussion 
about the exact kind of GC we want in game development.

There's a few people in the community here that are involved in 
console game dev, and they would know the kind of characteristics 
we require. Similarly, many of the lower level programmers that 
work with GPUs and the like are well aware that garbage 
collection is not good enough for releasing resources outside of 
the main system environment and would know the kind of control we 
require over deallocation and release paths.

The short form of my view is that we are actively using GC in 
game dev at all levels. The largest commercial AAA engine has 
been garbage collecting since the 90s (and go deeper, the 
original Doom garbage collected). But as we scale up to massively 
parallel execution across all forms of programming, the 
monolithic program-halting mark and sweep GC that comes with D is 
not good enough.

I've not yet sat down to do the full research in to the subject 
that it demands, but I have ideas on what I want to look at. 
Conversation copied to below:


TheRealGooberMan
​I want to write a task-based GC, that will handle 
destruction/deallocation as a task when the last reference to a 
section of memory is unacquired

FeepingCreature
​is freeing memory that costly in D?

TheRealGooberMan
​The advantage of a collector is that it's a batch process

TheRealGooberMan
​And computers LOVE batch processes

TheRealGooberMan
​But in gamedev, we need a bit more immediate control at times

FeepingCreature
​no I mean, it just feels like you're optimizing the fastest part 
of the process

FeepingCreature
​ya'll are really sensitive to question marks ending a line 🙂

TheRealGooberMan
​The collector blocks the program currently. That's bad for 
gamedev

TheRealGooberMan
​And yes, we do have Unreal Engine as the most direct example 
that does exactly this

TheRealGooberMan
​Anyone saying "gamedev doesn't GC" isn't paying attention

TheRealGooberMan
​We just want a better solution

FeepingCreature
​the collector blocks the program, but it blocks for scanning, 
and task-based doesn't speed that up, right?

TheRealGooberMan
​No, it's not about speeding it up at that point. It's about not 
blocking anything else from running

FeepingCreature
​right but mark phase has to block inherently, unless you get 
really clever with your design or get hardware support

TheRealGooberMan
​This is an extra advantage of the pointer acquire/unacquire 
runtime hooks that I want. It's a bit more code, but it also 
negates the need to do any kind of sweep

TheRealGooberMan
​And it is something that should be opt-in, yeah. If your GC 
doesn't define the hooks, then the code gen shouldn't try to 
insert them

TheRealGooberMan
​Pay as you go functionality!

FeepingCreature
​I don't know the background of that, but yeah, I don't know how 
the relative cost of mark and sweep is, if sweep is using a lot 
of the fraction than speed it up by all means

Lawrence Aberba
​I love GC 🐱‍🏍

FeepingCreature
​😆
Nov 22 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 22 November 2020 at 14:30:45 UTC, Ethan wrote:

 There's many nuanced points to consider here, so given that GC 
 came up on the live Q&A and I got in to a bit of a chat there I 
 figured copy/pasting that log and getting in to a (real, 
 stop-saying-gamedev-doesn't-want-this) longer form discussion 
 about the exact kind of GC we want in game development.


You cannot have incremental collection as that requires barriers 
and there is no way in D to tell whether you should or should not 
emit costly barriers statically during code gen. D would need to 
add an actor concept to get there.

So that means there are only three options left: single threaded 
GC pool, non-language GC or ARC.
Nov 22 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 23/11/2020 4:48 AM, Ola Fosheim Grostad wrote:

 So that means there are only three options left: single threaded GC 
 pool, non-language GC or ARC.


Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.

We are only missing Windows support for a partially concurrent GC atm.

This is the direction I believe our default should be. It covers pretty 
much all use cases with reasonable performance.
Nov 22 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole 
wrote:

 On 23/11/2020 4:48 AM, Ola Fosheim Grostad wrote:

 So that means there are only three options left: single 
 threaded GC pool, non-language GC or ARC.


 Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.

 We are only missing Windows support for a partially concurrent 
 GC atm.

 This is the direction I believe our default should be. It 
 covers pretty much all use cases with reasonable performance.


Fork is expensive in the sense that when the game modifies memory 
the process has to halt while the OS creates a copy of that 
memory page.

You have to be very careful when writing applications that call 
fork, you don't want two processes appending to the same file etc.

It a very special cased soltuion that basically won't work with 
existing c++ codebases without vetting...

More suitable for a high level language where the compiler can 
set up the application for fork.
Nov 23 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 08:17:30 UTC, Ola Fosheim Grostad 
wrote:

 You have to be very careful when writing applications that call 
 fork, you don't want two processes appending to the same file 
 etc.


I guess this is not an issue with POSIX fork in this context as 
it only keeps the thread that called fork. But there can be 
issues related to resources.
Nov 23 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 08:58:43 UTC, Ola Fosheim Grostad 
wrote:

 On Monday, 23 November 2020 at 08:17:30 UTC, Ola Fosheim 
 Grostad wrote:

 You have to be very careful when writing applications that 
 call fork, you don't want two processes appending to the same 
 file etc.


 I guess this is not an issue with POSIX fork in this context as 
 it only keeps the thread that called fork. But there can be 
 issues related to resources.


For instance, if the app marks memory as dontfork with madvise 
and the gc traces a pointer into that memory.
Nov 23 2020
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole 
wrote:

 On 23/11/2020 4:48 AM, Ola Fosheim Grostad wrote:

 So that means there are only three options left: single 
 threaded GC pool, non-language GC or ARC.


 Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.



 ...

 This is the direction I believe our default should be. It 
 covers pretty much all use cases with reasonable performance.


Can you expand on this?
Nov 23 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/11/2020 12:50 AM, aberba wrote:

 On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole wrote:

 On 23/11/2020 4:48 AM, Ola Fosheim Grostad wrote:

 So that means there are only three options left: single threaded GC 
 pool, non-language GC or ARC.


 Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.


 

 ...

 This is the direction I believe our default should be. It covers 
 pretty much all use cases with reasonable performance.


 
 Can you expand on this?


There isn't much to say.

We already have POSIX support done, just need to implement Windows now.

The basic gist of it is, you want to move the scanning + collecting to a 
separate concurrently executed thread. In a fork based model, that uses 
another process to do it. On Windows you would use another thread with a 
(non-changing) view of the memory of the process.

The reason I say it should be the default is: with multi-core systems 
being the default now, adding a dedicated thread for scanning + 
collecting isn't all that expensive and it allows to keep the main logic 
of the program running without any interruptions to the end user unless 
an OOM situation occurs.

But as Ola has said, there are down sides to this approach once you 
start needing performance.
Nov 23 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 12:05:14 UTC, rikki cattermole 
wrote:

 But as Ola has said, there are down sides to this approach once 
 you start needing performance.


Rikki, I want to add that I don't argue that it shouldn't be the 
default.  I was arguing in the context of games and other 
demanding low latency, high memory, computation applications.

Your fork-collector could be excellent for most GUI applications 
that are mostly based on D code. For instance, a GUI application 
can detect that the user is inactive and trigger a fork.

It could also work for turn-based games.
Nov 23 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/11/2020 1:58 AM, Ola Fosheim Grøstad wrote:

 On Monday, 23 November 2020 at 12:05:14 UTC, rikki cattermole wrote:

 But as Ola has said, there are down sides to this approach once you 
 start needing performance.


 
 Rikki, I want to add that I don't argue that it shouldn't be the 
 default.  I was arguing in the context of games and other demanding low 
 latency, high memory, computation applications.
 
 Your fork-collector could be excellent for most GUI applications that 
 are mostly based on D code. For instance, a GUI application can detect 
 that the user is inactive and trigger a fork.
 
 It could also work for turn-based games.


Its not actually my idea. Rainer has already done an implementation :)

http://rainers.github.io/visuald/druntime/concurrentgc.html
Nov 23 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 13:09:31 UTC, rikki cattermole 
wrote:

 Its not actually my idea. Rainer has already done an 
 implementation :)

 http://rainers.github.io/visuald/druntime/concurrentgc.html


Alright! So now we need a high quality portable GUI framework 
that also can be used for turn based games.

There is a push for simple games in Flutter. Maybe possible to 
"steal" their codebase.
Nov 23 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/11/2020 2:31 AM, Ola Fosheim Grøstad wrote:

 Alright! So now we need a high quality portable GUI framework that also 
 can be used for turn based games.


I'm working on it.

Problem is I'm starting all the way back at colorimetry. A fascinating 
deep subject that pretty much every organization in the industry has 
their own thing on (as I say, you implement a dozen color spaces and now 
you need to implement two dozen more).
Nov 23 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 13:53:04 UTC, rikki cattermole 
wrote:

 On 24/11/2020 2:31 AM, Ola Fosheim Grøstad wrote:

 Alright! So now we need a high quality portable GUI framework 
 that also can be used for turn based games.


 I'm working on it.

 Problem is I'm starting all the way back at colorimetry. A 
 fascinating deep subject that pretty much every organization in 
 the industry has their own thing on (as I say, you implement a 
 dozen color spaces and now you need to implement two dozen 
 more).


Haha! Yea, I've spent a lot of time reading about this topic. 
Very interesting. And it is fun how many image rescaling 
applications get gamma wrong! :-D Of course, anyone who has 
written their own toy raytracer understands gamma (as you use 
linear intensity during computations).

I think you can start by assuming sRGB as the default, though.
Nov 23 2020
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole 
wrote:


 Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.


FYI, `fork` is not available on iOS, tvOS and watchOS.

--
/Jacob Carlborg
Nov 23 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 13:29:58 UTC, Jacob Carlborg wrote:

 On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole 
 wrote:


 Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.


 FYI, `fork` is not available on iOS, tvOS and watchOS.


On iOS you probably should use ARC. LLVM IR has ObjC ARC support.
Nov 23 2020
prev sibling next sibling parent Guillaume Piolat <first.name guess.com> writes:
On Monday, 23 November 2020 at 13:29:58 UTC, Jacob Carlborg wrote:

 On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole 
 wrote:


 Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.


 FYI, `fork` is not available on iOS, tvOS and watchOS.

 --
 /Jacob Carlborg


Actually on macOS latest I had problems with program that ask for 
the current directory with `absolute`. I guess the cwd could be 
used for a side-channel attack somehow.
Nov 23 2020
prev sibling parent Ethan <gooberman gmail.com> writes:
On Monday, 23 November 2020 at 13:29:58 UTC, Jacob Carlborg wrote:

 On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole 
 wrote:


 Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.


 FYI, `fork` is not available on iOS, tvOS and watchOS.

 --
 /Jacob Carlborg


And I've said this every time the word "fork" is mentioned: We 
cannot use forking methods on consoles. This will not 
realistically change in your lifetime.
Nov 23 2020
prev sibling next sibling parent reply Ethan <gooberman gmail.com> writes:
On Sunday, 22 November 2020 at 14:30:45 UTC, Ethan wrote:

 ...longer form discussion about the exact kind of GC we want in 
 game development...


So chatting with Atila on beerconf. The conversation that comes 
up, apart from this needing to be a DIP, is that I need to fill 
out some of the ideas that I have here.

One of the things I mentioned is that I don't get why library 
solutions are pursued for handling memory allocations/garbage 
collecting when the runtime already exists and can be used for 
the same purpose. This led to highlighting that the runtime 
should be more templatised anyway so that it can get that deeper 
knowledge of objects via DbI. The runtime as designed and 
implemented is about ten years behind how the language 
progressed, so there's definitely some work that needs to happen 
there.

But the single reason I'm focused on runtime versus a library 
solution. If you get the pointer acquire/release hooks in to the 
runtime that I talk about, then the whole argument between ARC GC 
and other forms comes down to a single question: "Who cares?"

A library solution actively requires the user to specify the kind 
of memory management they want. This is not what most modern 
programmers need to care about. A runtime solution means that if 
you want to switch between ARC GC and a traditional mark/sweep GC 
then you just swap the runtime implementation out. The user's 
code does not change, and it should not need to.

But yeah, this all comes down to the fact that the runtime really 
needs work these days. And to a degree, I imagine user-provided 
templates that dictate how code should be generated is an 
interesting compiler design paradigm that can help there.

So tl;dr - DIP, but I can't think about writing one for a few 
months because time, but there's bound to be interesting 
discussion that can come up as a result of this.
Nov 22 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 22 November 2020 at 19:54:14 UTC, Ethan wrote:

 But yeah, this all comes down to the fact that the runtime 
 really needs work these days. And to a degree, I imagine 
 user-provided templates that dictate how code should be 
 generated is an interesting compiler design paradigm that can 
 help there.


If you want to mix ARC and GC in the same executable, for high 
efficiency, you need at least two types of pointers: owning and 
nonowning, and to break cycles you also need weak pointers (turns 
to null on destruction) which are useful for speculative caching 
as well.

The good news is that going from ARC to GC is free and that ARC 
annotated pointers will collect faster with a precise tracing GC 
than is the case today. So clearly a win for libraries, either 
way.

The bad news is that doing ARC in the LLVM IR is nontrivial so 
you may need a new intermediary typed language specific IR. But 
you need that to do  live well anyway... So, why not?
Nov 22 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 22 November 2020 at 20:20:50 UTC, Ola Fosheim Grostad 
wrote:

 If you want to mix ARC and GC in the same executable, for high 
 efficiency, you need at least two types of pointers: owning and


That was a bit terse. What I meant is that you could use the same 
library for both ARC and GC if you have a distinction between 
nonowning and owning pointers, and that this would be needed for 
efficient ARC/precise GC. If you also attatch a magic hidden 
template parameter to functions then you can have one thread 
using ARC and another one using a thread local GC using the same 
templated libraries.
Nov 22 2020
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 22 November 2020 at 20:20:50 UTC, Ola Fosheim Grostad 
wrote:

 On Sunday, 22 November 2020 at 19:54:14 UTC, Ethan wrote:

 But yeah, this all comes down to the fact that the runtime 
 really needs work these days. And to a degree, I imagine 
 user-provided templates that dictate how code should be 
 generated is an interesting compiler design paradigm that can 
 help there.


 If you want to mix ARC and GC in the same executable, for high 
 efficiency, you need at least two types of pointers: owning and 
 nonowning, and to break cycles you also need weak pointers 
 (turns to null on destruction) which are useful for speculative 
 caching as well.

 The good news is that going from ARC to GC is free and that ARC 
 annotated pointers will collect faster with a precise tracing 
 GC than is the case today. So clearly a win for libraries, 
 either way.

 The bad news is that doing ARC in the LLVM IR is nontrivial so 
 you may need a new intermediary typed language specific IR. But 
 you need that to do  live well anyway... So, why not?


Other bad news is that if you don't want the runtime to look bad 
against tracing GC implementations,

https://github.com/ixy-languages/ixy-languages

You need to ship your own CPU with ARC specific improvments,

https://blog.metaobject.com/2020/11/m1-memory-and-performance.html
Nov 23 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 11:54:24 UTC, Paulo Pinto wrote:

 Other bad news is that if you don't want the runtime to look 
 bad against tracing GC implementations,

 https://github.com/ixy-languages/ixy-languages

 You need to ship your own CPU with ARC specific improvments,

 https://blog.metaobject.com/2020/11/m1-memory-and-performance.html


Not exactly sure what you mean by this. Swift isn't really 
representative of what you can achieve with ARC. Swift is 
designed to be easy to use and compatible with Obj-C semantics.

ARC can also improve over time as more theory about shape 
analysis of heap patterns becomes available and you can gradually 
improve pointer analysis passes over time.

The key issue is to not provide the programmer with manual 
acquire/release or any way to access the ref count.

Also, in D owning!T would be nonatomic, and owning!shared(T) 
would be atomic unless the compiler can prove that it isn't 
shared yet.

My own on-paper language is ARC based.

Although for D, it would probably be better to add actors and 
limit actors from calling nogc code, then emit barriers for all 
gc code and use incremental collection. Incremental collection 
would be good for game-world collection as you could call it 
between iterations and specify it to complete in 5ms or something.
Nov 23 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 23 November 2020 at 12:10:27 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 23 November 2020 at 11:54:24 UTC, Paulo Pinto wrote:

 Other bad news is that if you don't want the runtime to look 
 bad against tracing GC implementations,

 https://github.com/ixy-languages/ixy-languages

 You need to ship your own CPU with ARC specific improvments,

 https://blog.metaobject.com/2020/11/m1-memory-and-performance.html


 Not exactly sure what you mean by this. Swift isn't really 
 representative of what you can achieve with ARC. Swift is 
 designed to be easy to use and compatible with Obj-C semantics.

 ARC can also improve over time as more theory about shape 
 analysis of heap patterns becomes available and you can 
 gradually improve pointer analysis passes over time.

 The key issue is to not provide the programmer with manual 
 acquire/release or any way to access the ref count.

 Also, in D owning!T would be nonatomic, and owning!shared(T) 
 would be atomic unless the compiler can prove that it isn't 
 shared yet.

 My own on-paper language is ARC based.

 Although for D, it would probably be better to add actors and 
 limit actors from calling nogc code, then emit barriers for all 
 gc code and use incremental collection. Incremental collection 
 would be good for game-world collection as you could call it 
 between iterations and specify it to complete in 5ms or 
 something.


It is always about theory, in practice tracing GC always wins.

While we are on the subject Herb Sutter's talk on C++ deferred 
pointers talk at CppCon (aka tracing GC, as he points out half 
way through the talk).

https://www.youtube.com/watch?v=JfmTagWcqoE

https://github.com/hsutter/gcpp

A design that influenced C++/WinRT, which uses background threads 
and clever uses of modern C++ to reduce the impact of RC on 
program performance. Still they are slower than tradicional 
.NET/Win32 applications.
Nov 23 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 23 November 2020 at 12:36:07 UTC, Paulo Pinto wrote:

 It is always about theory, in practice tracing GC always wins.


That really depends, but a tracing GC is easier to use, as it 
catches cycles. So it would be better to have an incremental 
collector.

But I don't think D can get there within 5 years, and do people 
want to discuss what D could have in 5 years?  I think we need to 
figure out what the time frame should be.

You could get non-optimized ARC in 6 months.
And basic optimized ARC in 12 months.
Optimized ARC in 18 months.
Opiimized ARC with borrow checker in 24 months.

That is a lot more attractive IMO.

Open Source should focus on strategies which can be done as small 
incremental steps and ARC can be made compatible with 
std::shared_ptr when it is allocated with std::make_shared. That 
is a big plus.
Nov 23 2020
prev sibling next sibling parent reply random <frederick.mueller existiert.net> writes:
On Sunday, 22 November 2020 at 19:54:14 UTC, Ethan wrote:

 One of the things I mentioned is that I don't get why library 
 solutions are pursued for handling memory allocations/garbage 
 collecting when the runtime already exists and can be used for 
 the same purpose.


A benefit of the library solution is that the user can always 
create their own
implementation when needed.
You can write your own malloc in C, which is useful if you want 
to program an os... (for example)


 A library solution actively requires the user to specify the 
 kind of memory management they want. This is not what most 
 modern programmers need to care about. A runtime solution means 
 that if you want to switch between ARC GC and a traditional 
 mark/sweep GC then you just swap the runtime implementation 
 out. The user's code does not change, and it should not need to.


I'm not a gamedev but I can imagine that (unlike most 
programmers) they care about it.
You might want to use ARC for resources on the GPU, but mark and 
sweep on CPU.
You could use region-based memory management for some objects to 
optimize performance.


 So tl;dr - DIP, but I can't think about writing one for a few 
 months because time, but there's bound to be interesting 
 discussion that can come up as a result of this.


Would it be possible that you have different pointer types, but 
code which doesn't care about it is somehow generic?
Nov 22 2020
next sibling parent Ethan <gooberman gmail.com> writes:
On Sunday, 22 November 2020 at 20:49:19 UTC, random wrote:

 A benefit of the library solution is that the user can always 
 create their own
 implementation when needed.


The runtime is 100% overridable by the user. Walter continually 
says that the linker will just take the most recent symbol 
provided, ignoring symbols provided by the pack-in static 
libraries.

We even have the beginnings of a gamedev focused runtime in the 
works. Whatever, they're symbols the linker expects to find, we 
can define them however we want.
Nov 22 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 22 November 2020 at 20:49:19 UTC, random wrote:

 On Sunday, 22 November 2020 at 19:54:14 UTC, Ethan wrote:

 One of the things I mentioned is that I don't get why library 
 solutions are pursued for handling memory allocations/garbage 
 collecting when the runtime already exists and can be used for 
 the same purpose.


 A benefit of the library solution is that the user can always 
 create their own
 implementation when needed.
 You can write your own malloc in C, which is useful if you want 
 to program an os... (for example)


Actually no, you cannot not, at least not with pure ISO C.

Allocating from a global static buffer yes, but for something 
like a proper malloc() taking from a OS wide memory pool, either 
inline Assembly, external Assembly or compiler intrisics are 
required to interface with the memory management hardware.

If we are talking about GCC C, clang C, MSVC, TI C, aCC, xlC,... 
then yeah C can do it.

This is one of my trick questions, how to implement malloc() in 
ISO C on bare metal.
Nov 22 2020
prev sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Sunday, 22 November 2020 at 19:54:14 UTC, Ethan wrote:

 On Sunday, 22 November 2020 at 14:30:45 UTC, Ethan wrote:

 ...longer form discussion about the exact kind of GC we want 
 in game development...


 So chatting with Atila on beerconf. The conversation that comes 
 up, apart from this needing to be a DIP, is that I need to fill 
 out some of the ideas that I have here.

 One of the things I mentioned is that I don't get why library 
 solutions are pursued for handling memory allocations/garbage 
 collecting when the runtime already exists and can be used for 
 the same purpose. This led to highlighting that the runtime 
 should be more templatised anyway so that it can get that 
 deeper knowledge of objects via DbI. The runtime as designed 
 and implemented is about ten years behind how the language 
 progressed, so there's definitely some work that needs to 
 happen there.


I've been looking into this and the main issue that has caused 
slow progress in templatizing the runtime is the fact that the 
hooks need to be ` trusted pure  nogc nothrow`. Why? Because 
those hooks may get called from ` trusted pure  nogc nothrow` 
code and you do not want the user getting errors like "you cannot 
do that because our runtime implementation is not pure". This 
leads to all sorts of problems: some functions cannot be pure, 
others cannot be  nogc etc.

I don't know if this can be fixed without a major redesign of 
druntime. Actually, I'm not even sure that all of the hooks can 
be `pure  nogc nothrow`.
Nov 22 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 23 November 2020 at 03:27:48 UTC, RazvanN wrote:

 I've been looking into this and the main issue that has caused 
 slow progress in templatizing the runtime is the fact that the 
 hooks need to be ` trusted pure  nogc nothrow`. Why? Because 
 those hooks may get called from ` trusted pure  nogc nothrow`


 trusted I understand, but the others should be correctly 
inferred be a template anyway and if they can't be.... so be it. 
There are already druntime functions you can't use from  nogc, 
they're just special cased in the compiler instead picked up from 
the implementation...
Nov 22 2020
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Monday, 23 November 2020 at 03:44:02 UTC, Adam D. Ruppe wrote:

 On Monday, 23 November 2020 at 03:27:48 UTC, RazvanN wrote:

 I've been looking into this and the main issue that has caused 
 slow progress in templatizing the runtime is the fact that the 
 hooks need to be ` trusted pure  nogc nothrow`. Why? Because 
 those hooks may get called from ` trusted pure  nogc nothrow`


  trusted I understand, but the others should be correctly 
 inferred be a template anyway and if they can't be.... so be 
 it. There are already druntime functions you can't use from 
  nogc, they're just special cased in the compiler instead 
 picked up from the implementation...


What about purity? If your code is pure but the runtime hook is 
not? And then there are many functions like this in druntime:

void checkSomething(T)(T a)  trusted nothrow  nogc
{
     /* some other checks */
     assert(a != fun(), "Fail");
     /* some other checks */
}

Let's say this function is used everywhere in druntime. You 
cannot mark it as pure because the compiler will then optimize it 
away and if you need it you just have to duplicate the code. Also 
if you want to format the message of the assert, normally you 
would use `~` however, you want your function to be  nogc so then 
you have to use the existing crippled AssertFormat in druntime 
which may not be enough for your needs.

My point is that you have to work around a lot of hindrances to 
implement this.
Nov 22 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 23 November 2020 at 03:53:04 UTC, RazvanN wrote:

 And then there are many functions like this in druntime:


Do you have a specific example in there now? Your little given 
example uses assert and would thus be compiled out anyway of the 
normal druntime build.


 Also if you want to format the message of the assert, normally 
 you would use `~` however, you want your function to be  nogc


With the `debug` keyword you can do stuff like this. Of course 
only sometimes compiled in so not necessarily helpful to druntime 
but maybe.
Nov 22 2020
parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Monday, 23 November 2020 at 04:04:44 UTC, Adam D. Ruppe wrote:

 On Monday, 23 November 2020 at 03:53:04 UTC, RazvanN wrote:

 And then there are many functions like this in druntime:


 Do you have a specific example in there now? Your little given 
 example uses assert and would thus be compiled out anyway of 
 the normal druntime build.


Hmmm, I struggled with this in 
https://github.com/dlang/druntime/pull/3267 .
I did not know that asserts are ignored in normal builds. So 
typically you
would need to manually throw an Error in cases like checking 
array bounds.


 Also if you want to format the message of the assert, normally 
 you would use `~` however, you want your function to be  nogc


 With the `debug` keyword you can do stuff like this. Of course 
 only sometimes compiled in so not necessarily helpful to 
 druntime but maybe.
Nov 22 2020
prev sibling next sibling parent reply ryuukk_ <ryuukk_ gmail.com> writes:
This is a step in the right direction, but as usual, when will we 
see the results?

- GC that doesn't eat my precious memory

- GC that doesn't stop the world

- GC that doesn't affect the frame budget for a game


That is it, requirements are simple

I agree and i hear, GC is welcome in D, so be proud of it, and 
make it great! if nobody can, then drop it and implement some 
sort of ARC/RC what ever it is called, that would be better than 
having something that stop the world

Whoever has GC knowledge, open a patreon account and i'll give 
you my money
Nov 24 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 25 November 2020 at 05:55:39 UTC, ryuukk_ wrote:

 This is a step in the right direction, but as usual, when will 
 we see the results?

 - GC that doesn't eat my precious memory

 - GC that doesn't stop the world

 - GC that doesn't affect the frame budget for a game


 That is it, requirements are simple

 I agree and i hear, GC is welcome in D, so be proud of it, and 
 make it great! if nobody can, then drop it and implement some 
 sort of ARC/RC what ever it is called, that would be better 
 than having something that stop the world

 Whoever has GC knowledge, open a patreon account and i'll give 
 you my money


ARC/RC also stops the world, hence the typical optimization to 
move the referenced data to a background thread when the 
reference count reaches zero for cleanup, and use of 
deferred/hazardous pointers.

Which when coupled with a couple of other optimizations, it 
becomes hardly indistinguishable from basic tracing GC algorithms.
Nov 24 2020
next sibling parent Araq <rumpf_a web.de> writes:
On Wednesday, 25 November 2020 at 06:21:21 UTC, Paulo Pinto wrote:

 ARC/RC also stops the world, hence the typical optimization to 
 move the referenced data to a background thread when the 
 reference count reaches zero for cleanup, and use of 
 deferred/hazardous pointers.

 Which when coupled with a couple of other optimizations, it 
 becomes hardly indistinguishable from basic tracing GC 
 algorithms.


Except that it's an algorithm oblivious to the involved heap 
sizes. And that it doesn't require heuristics how to handle the 
different "generations" (as there are none). And that it requires 
much less memory. And that it works well with custom destructors.
Nov 24 2020
prev sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 06:21:21 UTC, Paulo Pinto wrote:

 ARC/RC also stops the world, hence the typical optimization to 
 move the referenced data to a background thread when the 
 reference count reaches zero for cleanup, and use of 
 deferred/hazardous pointers.


ARC does not stop the world.
Algorithms that need hazard should do their own.

ARC should be as light as it can be. D is for systems programming.
Nov 24 2020
parent reply Araq <rumpf_a web.de> writes:
On Wednesday, 25 November 2020 at 07:43:23 UTC, Ola Fosheim 
Grostad wrote:

 ARC does not stop the world.


He means the "unbounded" destruction phase when an enormous data 
structure needs to be free()d. This problem -- if it really comes 
up -- is not part of the reference counting mechanism at all. 
Manual memory management with free() calls produces exactly the 
same effect.
Nov 24 2020
next sibling parent reply ryuukk_ <ryuukk_ gmail.com> writes:
Unity moving to incremental GC

https://www.youtube.com/watch?v=5Fks2NArDc0
Nov 24 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 07:58:13 UTC, ryuukk_ wrote:

 Unity moving to incremental GC


But they have the money for it. What would you charge for 
implementing one that is fine tuned for D?

I've given it some thought and concluded that it would be rather 
risky to take it on with less than 2 years pay... So if we do it 
as a collective spare time project it would take at least 5 to 
get to something that could even approach ARC. That's a very 
rough estimate. Maybe pessimistic, but the risk is that it leads 
to something unusable, and then you have wasted a lot of 
resources for nothing.

With ARC you can be certain that you have something that can 
complement manual strategies.
Nov 25 2020
prev sibling parent reply Guillaume Piolat <first.name guess.com> writes:
On Wednesday, 25 November 2020 at 07:58:13 UTC, ryuukk_ wrote:

 Unity moving to incremental GC

 https://www.youtube.com/watch?v=5Fks2NArDc0


I love the irony there.

Two top game engines in the world use garbage collection (Unity, 
Unreal), and the problem they _had_ is: a missed frame 60fps to 
30fps (I wouldn't be able to see it). The example to show this is 
of course a FPS game where players can see this. It's not a 
common game genre to make for most companies if I understand.

That problem would probably be solvable will less memory 
allocation. But it hurts developer experience so the engine deals 
with that. "The GC is perfectly adequate in high-performance 
scenario" would be a logical conclusion.


BUT In the blogging and recruiting world though, Amazon will say 
on the AWS blog that
"Because Rust does not require a runtime or garbage collector, it 
is able to achieve runtime performance similar to C and C++."
https://aws.amazon.com/fr/blogs/opensource/why-aws-loves-rust-and-how-wed-like-to-help/

People really do like the idea that GC prevents top performance, 
disregarding that _Fortnite_ has a garbage collector.
Nov 25 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 09:05:16 UTC, Guillaume Piolat 
wrote:

 Two top game engines in the world use garbage collection 
 (Unity, Unreal), and the problem they _had_ is: a missed frame 
 60fps to 30fps (I wouldn't be able to see it). The example to 
 show this is of course a FPS game where players can see this.


I dont know. In my experience dropped frames are annoying in 
smooth artistic scenes. You want to suspend disbelief to create 
immersion.
Nov 25 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 09:36:41 UTC, Ola Fosheim 
Grostad wrote:

 I dont know. In my experience dropped frames are annoying in 
 smooth artistic scenes. You want to suspend disbelief to create 
 immersion.


btw, Ive had a lot if headaches over missed frames when doing 
even simple animations in browsers. Large objects with linear 
motion and high contrast makes missing frames very noticable. For 
some reason it looks even worse to me when objects move slow, 
probably because the object is more in focus and the eye tracks 
it better.

You can make it less noticable by adding blur and use less linear 
motion, but why should I have to waste hours on such tweaks just 
because the tech is shitty?
Nov 25 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 25 November 2020 at 09:52:20 UTC, Ola Fosheim 
Grostad wrote:

 On Wednesday, 25 November 2020 at 09:36:41 UTC, Ola Fosheim 
 Grostad wrote:

 I dont know. In my experience dropped frames are annoying in 
 smooth artistic scenes. You want to suspend disbelief to 
 create immersion.


 btw, Ive had a lot if headaches over missed frames when doing 
 even simple animations in browsers. Large objects with linear 
 motion and high contrast makes missing frames very noticable. 
 For some reason it looks even worse to me when objects move 
 slow, probably because the object is more in focus and the eye 
 tracks it better.

 You can make it less noticable by adding blur and use less 
 linear motion, but why should I have to waste hours on such 
 tweaks just because the tech is shitty?


🤷‍♂️ Can't change your opinion about JavaScript. I know 100s of 
online games (including MMORPGs) are using it. So D with GC can 
totally do it too.
Nov 25 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 14:24:08 UTC, aberba wrote:

 🤷‍♂️ Can't change your opinion about JavaScript. I know 100s of 
 online games (including MMORPGs) are using it. So D with GC can 
 totally do it too.


I am not discussing JavaScript, the Chrome team has put a massive 
effort into improving the bad situation with dropped frames over 
the past years for good reason. Their GC is in a different 
ballpark than D.

Consistency is king, 30hz without dropped frames is perceived as 
more fluid than 60hz with dropped frames. A sidescroller with 
fixed speed looks like a trainwreck if you get dropped frames.
Nov 25 2020
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 25 November 2020 at 09:05:16 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 25 November 2020 at 07:58:13 UTC, ryuukk_ wrote:

 [...]


 I love the irony there.

 Two top game engines in the world use garbage collection 
 (Unity, Unreal), and the problem they _had_ is: a missed frame 
 60fps to 30fps (I wouldn't be able to see it). The example to 
 show this is of course a FPS game where players can see this. 
 It's not a common game genre to make for most companies if I 
 understand.

 [...]


+1. Couldn't have said it any better.
Nov 25 2020
prev sibling next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 07:54:57 UTC, Araq wrote:

 On Wednesday, 25 November 2020 at 07:43:23 UTC, Ola Fosheim 
 Grostad wrote:

 ARC does not stop the world.


 He means the "unbounded" destruction phase when an enormous 
 data structure needs to be free()d. This problem -- if it 
 really comes up -- is not part of the reference counting 
 mechanism at all. Manual memory management with free() calls 
 produces exactly the same effect.


It could happen in a game where you can teleport, but ARC can be 
combined with scene allocators. So if you delete the whole scene 
you would not need to deallocate individual objects.
Nov 25 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 25 November 2020 at 08:25:33 UTC, Ola Fosheim 
Grostad wrote:

 On Wednesday, 25 November 2020 at 07:54:57 UTC, Araq wrote:

 On Wednesday, 25 November 2020 at 07:43:23 UTC, Ola Fosheim 
 Grostad wrote:

 ARC does not stop the world.


 He means the "unbounded" destruction phase when an enormous 
 data structure needs to be free()d. This problem -- if it 
 really comes up -- is not part of the reference counting 
 mechanism at all. Manual memory management with free() calls 
 produces exactly the same effect.


 It could happen in a game where you can teleport, but ARC can 
 be combined with scene allocators. So if you delete the whole 
 scene you would not need to deallocate individual objects.


Which is also possible alongside tracing GC implementations.
Nov 25 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 10:24:28 UTC, Paulo Pinto wrote:

 Which is also possible alongside tracing GC implementations.


If it allows for separate pools.
Nov 25 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 25 November 2020 at 11:01:06 UTC, Ola Fosheim 
Grostad wrote:

 On Wednesday, 25 November 2020 at 10:24:28 UTC, Paulo Pinto 
 wrote:

 Which is also possible alongside tracing GC implementations.


 If it allows for separate pools.


Indeed, and I have used them in Go, Java and .NET, so D can 
easily do it.
Nov 25 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 11:24:27 UTC, Paulo Pinto wrote:

 On Wednesday, 25 November 2020 at 11:01:06 UTC, Ola Fosheim 
 Grostad wrote:

 If it allows for separate pools.


 Indeed, and I have used them in Go, Java and .NET, so D can 
 easily do it.


Didn't know Go had that in, cool. :)

I wonder if D's fork collector supports this?
Nov 25 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 25 November 2020 at 11:39:05 UTC, Ola Fosheim 
Grostad wrote:

 On Wednesday, 25 November 2020 at 11:24:27 UTC, Paulo Pinto 
 wrote:

 On Wednesday, 25 November 2020 at 11:01:06 UTC, Ola Fosheim 
 Grostad wrote:

 If it allows for separate pools.


 Indeed, and I have used them in Go, Java and .NET, so D can 
 easily do it.


 Didn't know Go had that in, cool. :)

 I wonder if D's fork collector supports this?


What is so special about having memory allocated over OS APIs and 
then making of the language features (using/SafeHandles, try, 
defer) to create arenas?
Nov 25 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 25 November 2020 at 13:01:20 UTC, Paulo Pinto wrote:

 On Wednesday, 25 November 2020 at 11:39:05 UTC, Ola Fosheim 
 Grostad wrote:

 On Wednesday, 25 November 2020 at 11:24:27 UTC, Paulo Pinto 
 wrote:

 On Wednesday, 25 November 2020 at 11:01:06 UTC, Ola Fosheim 
 Grostad wrote:

 If it allows for separate pools.


 Indeed, and I have used them in Go, Java and .NET, so D can 
 easily do it.


 Didn't know Go had that in, cool. :)

 I wonder if D's fork collector supports this?


 What is so special about having memory allocated over OS APIs 
 and then making of the language features (using/SafeHandles, 
 try, defer) to create arenas?


It isnt sufficient to have arenas you need to prove that there 
are no pointers crossing the pool boundaries?
Nov 25 2020
prev sibling parent reply Elronnd <elronnd elronnd.net> writes:
On Wednesday, 25 November 2020 at 07:54:57 UTC, Araq wrote:

 This problem -- if it really comes up -- is not part of the 
 reference counting mechanism at all. Manual memory management 
 with free() calls produces exactly the same effect.


That's not true.  The problem with reference counting is that the 
deallocation happens behind your back, and can be difficult to 
reason about or occur inconsistently.  With manual free calls, 
everything happens explicitly, and you have more flexibility 
about it.

All this aside the fact that, for games, automatic memory 
management isn't competing with 'malloc', it's competing with 
custom arenas.  Where you can deallocate everything at once and 
not have to worry about tracing an object graph.

Malloc is fairly slow as is, and the overhead of reference 
counting on top of it is generally acceptable (esp. with 
optimizations), but rc still has pathological cases.
Nov 25 2020
parent Araq <rumpf_a web.de> writes:
On Wednesday, 25 November 2020 at 08:32:37 UTC, Elronnd wrote:

 On Wednesday, 25 November 2020 at 07:54:57 UTC, Araq wrote:

 This problem -- if it really comes up -- is not part of the 
 reference counting mechanism at all. Manual memory management 
 with free() calls produces exactly the same effect.


 That's not true.  The problem with reference counting is that 
 the deallocation happens behind your back, and can be difficult 
 to reason about or occur inconsistently.  With manual free 
 calls, everything happens explicitly, and you have more 
 flexibility about it.


That's about implicit vs explicit code, still not about the 
refcounting mechanism. And the flexibility remains in the 
implicit code, move an owner to a different thread/owning data 
structure.


 All this aside the fact that, for games, automatic memory 
 management isn't competing with 'malloc', it's competing with 
 custom arenas.  Where you can deallocate everything at once and 
 not have to worry about tracing an object graph.

 Malloc is fairly slow as is, and the overhead of reference 
 counting on top of it is generally acceptable (esp. with 
 optimizations), but rc still has pathological cases.


Areas still have pathological cases where you never free anything 
whatsoever in a runaway loop...
Nov 25 2020
prev sibling parent reply ryuukk_ <ryuukk_ gmail.com> writes:
https://technology.riotgames.com/news/leveraging-golang-game-development-and-operations
Nov 26 2020
parent reply ryuukk_ <ryuukk_ gmail.com> writes:
On Thursday, 26 November 2020 at 23:09:12 UTC, ryuukk_ wrote:

 https://technology.riotgames.com/news/leveraging-golang-game-development-and-operations


Oops forgot to add my text

As maybe people said, the industry doesn't mind the GC, as long 
as the job is done in an efficient way, GO gc seems to scale 
super well, since GO is opensource, is it possible to somewhat 
copy their GC, add their GC as a custom GC (since you can setup 
your own GC in D)
Nov 26 2020
next sibling parent reply ryuukk_ <ryuukk_ gmail.com> writes:
On Thursday, 26 November 2020 at 23:10:41 UTC, ryuukk_ wrote:

 On Thursday, 26 November 2020 at 23:09:12 UTC, ryuukk_ wrote:

 https://technology.riotgames.com/news/leveraging-golang-game-development-and-operations


 Oops forgot to add my text

 As maybe people said, the industry doesn't mind the GC, as long 
 as the job is done in an efficient way, GO gc seems to scale 
 super well, since GO is opensource, is it possible to somewhat 
 copy their GC, add their GC as a custom GC (since you can setup 
 your own GC in D)


Why no EDIT feature on the forum? i shouldn't type after drinking 
this much for thanksgiving lol
Nov 26 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 27/11/2020 12:11 PM, ryuukk_ wrote:

 Why no EDIT feature on the forum? i shouldn't type after drinking this 
 much for thanksgiving lol


This is not a forum. It is a mailing list with a fancy web interface.
Nov 26 2020
parent Mike Parker <aldacron gmail.com> writes:
On Friday, 27 November 2020 at 05:20:11 UTC, rikki cattermole 
wrote:

 On 27/11/2020 12:11 PM, ryuukk_ wrote:

 Why no EDIT feature on the forum? i shouldn't type after 
 drinking this much for thanksgiving lol


 This is not a forum. It is a mailing list with a fancy web 
 interface.


It's a newsgroup with a mailing list interface and a fancy web 
interface.
Nov 27 2020
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 26 November 2020 at 23:10:41 UTC, ryuukk_ wrote:

 On Thursday, 26 November 2020 at 23:09:12 UTC, ryuukk_ wrote:

 https://technology.riotgames.com/news/leveraging-golang-game-development-and-operations


 Oops forgot to add my text

 As maybe people said, the industry doesn't mind the GC, as long 
 as the job is done in an efficient way, GO gc seems to scale 
 super well, since GO is opensource, is it possible to somewhat 
 copy their GC, add their GC as a custom GC (since you can setup 
 your own GC in D)


It doesn't need to be opensource as such, the point is "as long 
as the job is done".

Even C and C++, now the elite languages of game development were 
seen back in the day as "Unity", because any serious game 
developer would be using Assembly (or C, by the time C++ started 
gaining some traction).

This is relatively easy to check still, you just need to go dig a 
bit on archives from books, magazines and BBS/USENET posts. One 
day theses sources will eventually vanish though, and with luck 
some do end up in some sort of museum.

Many also forget that before a language gets traction to be used 
in games, it has gone through the long path of adoption via tool 
building. This is where Java and .NET started to gain traction 
initially, by replacing MFC based tools, and then being the 
languages used for the server side.

Not everyone is doing Crysis (I guess it is time to replace the 
example with Fortnight, written in Unreal C++/Blueprints, with 
their GC infrastructure), and as proven by Minecraft, there is 
more to be successful in games than if the language has a GC or 
not.

Besides, everyone using DirectX or Metal, is using a GC 
(reference counted based) on their game stack anyway.
Nov 26 2020
prev sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 23:10:41 UTC, ryuukk_ wrote:

 On Thursday, 26 November 2020 at 23:09:12 UTC, ryuukk_ wrote:

 https://technology.riotgames.com/news/leveraging-golang-game-development-and-operations


 Oops forgot to add my text

 As maybe people said, the industry doesn't mind the GC, as long 
 as the job is done in an efficient way, GO gc seems to scale 
 super well, since GO is opensource, is it possible to somewhat 
 copy their GC, add their GC as a custom GC (since you can setup 
 your own GC in D)


That web page was for servers... No, we cannot copy their GC. 
Also, Go code is slowed down because of it.

The easy path to fast GC with LLVM is single threaded.
Nov 26 2020
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 27 November 2020 at 07:36:04 UTC, Ola Fosheim Grostad 
wrote:

 On Thursday, 26 November 2020 at 23:10:41 UTC, ryuukk_ wrote:

 On Thursday, 26 November 2020 at 23:09:12 UTC, ryuukk_ wrote:

 https://technology.riotgames.com/news/leveraging-golang-game-development-and-operations


 Oops forgot to add my text

 As maybe people said, the industry doesn't mind the GC, as 
 long as the job is done in an efficient way, GO gc seems to 
 scale super well, since GO is opensource, is it possible to 
 somewhat copy their GC, add their GC as a custom GC (since you 
 can setup your own GC in D)


 That web page was for servers... No, we cannot copy their GC. 
 Also, Go code is slowed down because of it.

 The easy path to fast GC with LLVM is single threaded.


Better be usable at game servers or game related pipeline 
tooling, than not being used anywhere, but I guess the community
Nov 27 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 08:11:40 UTC, Paulo Pinto wrote:

 Better be usable at game servers or game related pipeline 
 tooling, than not being used anywhere, but I guess the 

 pie.


Why would one of the current GCs be a problem on a server?

Memory? Well, in that case Rust will win.
Nov 27 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 27 November 2020 at 09:00:02 UTC, Ola Fosheim Grostad 
wrote:

 On Friday, 27 November 2020 at 08:11:40 UTC, Paulo Pinto wrote:

 Better be usable at game servers or game related pipeline 
 tooling, than not being used anywhere, but I guess the 

 the pie.


 Why would one of the current GCs be a problem on a server?

 Memory? Well, in that case Rust will win.


It wouldn't, hence why I think it is better outcome focusing on 
proving a good experience on engines like Godot, similar to what 


Making this https://github.com/sheepandshepherd/godot-d-plugin 
appear here 
https://docs.godotengine.org/en/stable/tutorials/plugins/editor/
aking_plugins.html, would do so much more for adopting D in game development
circles than yet another half baked attempt to reboot the GC.

Meanwhile, indie devs will start with something like Godot, 
search the web for how to continue, land on 
https://dotnet.microsoft.com/apps/games and carry on from there, 
regardless of what the community keeps trying to do to atract an 
imaginary set of game developers, because "booooo GC".
Nov 27 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 09:16:57 UTC, Paulo Pinto wrote:

 https://docs.godotengine.org/en/stable/tutorials/plugins/editor/
aking_plugins.html, would do so much more for adopting D in game development
circles than yet another half baked attempt to reboot the GC.


Maybe something for people interested in existing frameworks. I 
am more interested in WASM and ARC is the only sensible solution.
Nov 27 2020
prev sibling parent reply Guillaume Piolat <first.name guess.com> writes:
On Friday, 27 November 2020 at 09:16:57 UTC, Paulo Pinto wrote:

 Meanwhile, indie devs will start with something like Godot, 
 search the web for how to continue, land on 
 https://dotnet.microsoft.com/apps/games and carry on from 
 there, regardless of what the community keeps trying to do to 
 atract an imaginary set of game developers, because "booooo GC".


+1

It's all about having top-down libraries that nails one domain.
- having a library that allows to do X where X is not trivial
- **with a nice API**, this is the styling on the car
- being willing to manage/engage a community around that lib
- having a plan for monetization

Godot has incredibly nice API.
It can make 2D games.
It's quite innovative with the nested pre-fab, however it's not 
sure it's a big factor in its success.
It needs dedication!

Libraries are like products, they must sell some big goal, not 
"parse this format" which is a bottom-up approach. Products are 
top-down.
Nov 27 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 14:56:03 UTC, Guillaume Piolat 
wrote:

 It's all about having top-down libraries that nails one domain.
 - having a library that allows to do X where X is not trivial
 - **with a nice API**, this is the styling on the car


Yes, but that is not a language feature.

If you want to create a framework like that you are better off 
stripping down flutter and implement the gameworld in Dart: 
instant support for ios, android and web.
Nov 27 2020
parent reply Guillaume Piolat <first.name guess.com> writes:
On Friday, 27 November 2020 at 15:08:38 UTC, Ola Fosheim Grostad 
wrote:

 On Friday, 27 November 2020 at 14:56:03 UTC, Guillaume Piolat 
 wrote:

 It's all about having top-down libraries that nails one domain.
 - having a library that allows to do X where X is not trivial
 - **with a nice API**, this is the styling on the car


 Yes, but that is not a language feature.


I'm not discounting that D is a nice language (if people say they 
can't use anything else after knowing D, that says a lot really), 
I'm saying that the traits that make people switch to a new 
language are desirable properties of the _library they want to 
use_, more than the language.
It has been proven in research papers about programming language 
adoption.



 If you want to create a framework like that you are better off 
 stripping down flutter and implement the gameworld in Dart: 
 instant support for ios, android and web.


Soft disagree. This sounds to me like a high-debt solution.
If you make a game engine for example, cost of making N games is 
O(N), but cost of having a new platform is O(1). If added value 
flow to the game engine properly, you _will_ end up having 
support for all platforms needed.

You can totally start with only one platform (aka segmentation), 
actually Unity has started with a one plateform:
https://techcrunch.com/2019/10/17/how-unity-built-the-worlds-most-popular-game-engine



 Its story began on an OpenGL forum in May 2002, where Francis 
 posted a call for collaborators on an open source 
 shader-compiler (graphics tool) for the niche population of 
 Mac-based game developers like himself. It was Ante, then a 
 high school student in Berlin, who responded.


Unity had one platform and solved a smaller problem.
Nov 27 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 20:41:33 UTC, Guillaume Piolat 
wrote:

 really), I'm saying that the traits that make people switch to 
 a new language are desirable properties of the _library they 
 want to use_, more than the language.


Yes, or the service it runs on. Which is why I think D ought to 
encourage separating  framework from app. Let the framework do 
the multithreading and let the app author write simple single 
threaded tasks. So basically the framework deals with shared and 
app authors can mostly ignore that... That would be a good reason 
to have single threaded GC, which also would enable fast 100% 
precise collection and correct destruction and RAII. I think we 
could even get the destructor order right.

However, ARC is more generally useful... For me.


 Soft disagree. This sounds to me like a high-debt solution.
 If you make a game engine for example, cost of making N games 
 is O(N), but cost of having a new platform is O(1). If added 
 value flow to the game engine properly, you _will_ end up 
 having support for all platforms needed.


Godot does not even support Metal or Direct X?

For web I actually only want really efficient debuggable wasm. 
The browser is the framework and apps should load and run in 1 
second. Flutter is a bit bloated, but probably less bloated than 
unity/godot... And better UI support... But generally speaking... 
Frameworks are more a hindrance for what I want to achieve.

Anyway, my point was more: if your goal is to build a framework, 
then you would not do it to promote a specific language. So I 
dont think the D community can decide this to be a focus.

We can only focus on the enabling language features, getting rid 
of the irritatiting pain points.

(Why is typing on ipads so... Nggh?)
Nov 27 2020
parent reply Guillaume Piolat <first.name guess.com> writes:
On Friday, 27 November 2020 at 21:08:28 UTC, Ola Fosheim Grostad 
wrote:

 Anyway, my point was more: if your goal is to build a 
 framework, then you would not do it to promote a specific 
 language. So I dont think the D community can decide this to be 
 a focus.


"framework" word really is the point of conflict.
It is supposed to be a bad thing, you should prefer "libraries"!

That's what people say, but in reality people want a cohesive, 
framework-like experience, with all kinds of problems already 
solved and tutorial'ed before they get aware of the issue.

"library" experience is not cohesive enough and will even feel 
ugly to some.
Your library really is domain-specific after all.

That's what I discovered making Dplug, who has a few users. 
Promoting D was certainly not a goal, rather it was "using D 
because it's practical".



 (Why is typing on ipads so... Nggh?)


Well you definitely have some grit there :)
Nov 27 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat 
wrote:

 "framework" word really is the point of conflict.
 It is supposed to be a bad thing, you should prefer "libraries"!

 That's what people say, but in reality people want a cohesive, 
 framework-like experience, with all kinds of problems already 
 solved and tutorial'ed before they get aware of the issue.


Focused frameworks are good if they are written to coexist with 
others. I guess a framework has more of a runtime/service feel to 
it than a library? I guess service might be a useful term. It 
signals that you have a clean separation/encapsulation, not too 
fragmented interface.

The library approach might be flexible, but harder to learn as 
you get more parts, less encapsulation and basically end up 
spending too much time reading docs/tutorials. I rember the first 
time I opened a window on X-windows. 800 lines. Waaaayyyy too 
flexible.


 That's what I discovered making Dplug, who has a few users. 
 Promoting D was certainly not a goal, rather it was "using D 
 because it's practical".


Yes, good libraries and frameworks usually distill patterns 
discovered in developing concrete applications.  Which is why, I 
guess, standard libraries often feel uhm... Inadequate, as they 
have been conjured from ideas that appeared elegant on paper.  
But those ideas often turn into idiomatic religion... STL code 
tend to be clumsy for instance... Writing your own libs for C++ 
leads to much better looking code. At some point... Create your 
own idioms. Life is too short.
Nov 27 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 27 November 2020 at 22:24:05 UTC, Ola Fosheim Grostad 
wrote:

 On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat 
 wrote:

 [...]


 Focused frameworks are good if they are written to coexist with 
 others. I guess a framework has more of a runtime/service feel 
 to it than a library? I guess service might be a useful term. 
 It signals that you have a clean separation/encapsulation, not 
 too fragmented interface.

 The library approach might be flexible, but harder to learn as 
 you get more parts, less encapsulation and basically end up 
 spending too much time reading docs/tutorials. I rember the 
 first time I opened a window on X-windows. 800 lines. Waaaayyyy 
 too flexible.


 [...]


 Yes, good libraries and frameworks usually distill patterns 
 discovered in developing concrete applications.  Which is why, 
 I guess, standard libraries often feel uhm... Inadequate, as 
 they have been conjured from ideas that appeared elegant on 
 paper.  But those ideas often turn into idiomatic religion... 
 STL code tend to be clumsy for instance... Writing your own 
 libs for C++ leads to much better looking code. At some 
 point... Create your own idioms. Life is too short.


So here are plenty of examples using Go in WASM with a 2D games 
framework.

https://ebiten.org/examples/

https://medium.com/a-journey-with-go/go-image-rendering-in-2d-video-games-with-ebiten-912cc2360c4f

Enough juice to do Flash style games.
Dec 01 2020
parent reply Ben Jones <fake fake.fake> writes:
On Tuesday, 1 December 2020 at 08:46:06 UTC, Paulo Pinto wrote:

 On Friday, 27 November 2020 at 22:24:05 UTC, Ola Fosheim 
 Grostad wrote:

 On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat 
 wrote:

 [...]






Here's an interesting paper from MSR about doing precise ARC.  
Basically it seems like a handful of compiler optimization passes 
to eliminate most RC operations at compile time.

https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v1.pdf
Dec 09 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 9 December 2020 at 19:02:50 UTC, Ben Jones wrote:

 On Tuesday, 1 December 2020 at 08:46:06 UTC, Paulo Pinto wrote:

 On Friday, 27 November 2020 at 22:24:05 UTC, Ola Fosheim 
 Grostad wrote:

 On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat 
 wrote:

 [...]






 Here's an interesting paper from MSR about doing precise ARC.  
 Basically it seems like a handful of compiler optimization 
 passes to eliminate most RC operations at compile time.

 https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v1.pdf


Thanks fo sharing, I will certainly read this later when I have 
more time. Xmas?:)
Dec 09 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 9 December 2020 at 19:02:50 UTC, Ben Jones wrote:

 On Tuesday, 1 December 2020 at 08:46:06 UTC, Paulo Pinto wrote:

 On Friday, 27 November 2020 at 22:24:05 UTC, Ola Fosheim 
 Grostad wrote:

 On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat 
 wrote:

 [...]






 Here's an interesting paper from MSR about doing precise ARC.  
 Basically it seems like a handful of compiler optimization 
 passes to eliminate most RC operations at compile time.

 https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v1.pdf


Thanks, quite interesting read.
Dec 09 2020
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 November 2020 at 07:36:04 UTC, Ola Fosheim Grostad 
wrote:

 On Thursday, 26 November 2020 at 23:10:41 UTC, ryuukk_ wrote:

 The easy path to fast GC with LLVM is single threaded.


But only if the thread has low memory footprint. The downside of 
a fast scan is that it may wipe out all caches, thus slowing down 
nongc threads.

To combat that you either need memory barriers to get incremental 
collection, which most likely require a language change, or you 
can only collect very slowly.

So well, ARC.
Nov 27 2020
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 22 November 2020 at 14:30:45 UTC, Ethan wrote:

 There's many nuanced points to consider here, so given that GC 
 came up on the live Q&A and I got in to a bit of a chat there I 
 figured copy/pasting that log and getting in to a (real, 
 stop-saying-gamedev-doesn't-want-this) longer form discussion 
 about the exact kind of GC we want in game development.

 There's a few people in the community here that are involved in 
 console game dev, and they would know the kind of 
 characteristics we require. Similarly, many of the lower level 
 programmers that work with GPUs and the like are well aware 
 that garbage collection is not good enough for releasing 
 resources outside of the main system environment and would know 
 the kind of control we require over deallocation and release 
 paths.

 [snip]


Maybe organize a group to meet once a week to discuss issues and 
a path forward?
Nov 22 2020