Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[Jesper Louis Andersen]

On Fri, May 12, 2017 at 4:55 PM T L  wrote:

>
> The 100µs is STW duration. I mean the fps may decrease some during the
> period of GC running.
>

This is true. But if a refcounter needs to use a bit of CPU power in the
background to eventually collect data then it has the same problems with
fps drops. And in general, refcount maintenance is more expensive than
maintaining GC. There is a bit more instruction pressure in a system with
refcounting.

I've mentioned "A unified theory of Garbage collection' by Bacon, Cheng,
and Rajan (2004) before. In that paper they conjecture that refcounting and
(mark'n'sweep) garbage collection are each others duals and that they tend
to converge to the same methods. In short: it doesn't matter that much if
you use one of the other in practice.

I'd have absolutely no qualms on using Go for a game now. A 100us stw pause
can easily be hidden in a 16.7ms frame rendering time. And if you ask the
GC itself, it usually reports how much time it is spending. I'd be much
surprised if you don't have 16ms available per frame even in the worst
situation.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[Dave Cheney]

Maybe that tells us something about the prescience of the design decisions made 
by Go's authors. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Saturday, May 13, 2017 at 3:42:36 PM UTC+8, Sokolov Yura wrote:
>
> 1. Go's GC is quite predictable.
> 2. Go's runtime has no deallocation without GC for simplicity. You want to 
> return complexity to runtime.
> 3. Why not use other language? Go is quite opinionated by its creators. 
> Either you share that opinion, or use other language.
> For example, D language can use both GC and ARC (with template-defined 
> custom pointer types). It also has fibers (but with fixed stack). Vibe.d 
> adds async networking with sync interface. I think, you will be able to 
> implement channels and select. Go ahead.


But it looks the go ecosystem is larger and more active.  :(

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[Sokolov Yura]

1. Go's GC is quite predictable.
2. Go's runtime has no deallocation without GC for simplicity. You want to 
return complexity to runtime.
3. Why not use other language? Go is quite opinionated by its creators. Either 
you share that opinion, or use other language.
For example, D language can use both GC and ARC (with template-defined custom 
pointer types). It also has fibers (but with fixed stack). Vibe.d adds async 
networking with sync interface. I think, you will be able to implement channels 
and select. Go ahead.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Saturday, May 13, 2017 at 1:26:31 PM UTC+8, Tamás Gulácsi wrote:
>
> Reference counting does not come without unforseen stalls - dereference a 
> huge structure with millions of objects!


Programmers can choose use ARC pointers or not.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[Tamás Gulácsi]

Reference counting does not come without unforseen stalls - dereference a huge 
structure with millions of objects!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Saturday, May 13, 2017 at 12:02:39 AM UTC+8, JuciÊ Andrade wrote:
>
> Any memory management strategy costs time. Reference counting is not 
> cheap. Incrementing and decrementing millions of reference counters costs 
> time. Please consider caching issues as well.
>
> Go GC, as it currently stands, is very effective, as other people in this 
> forum can confirm to you. Several Gigs of data and the only way to perceive 
> any performance impact is by generating a profile chart! 
>

In fact, the need to ARC is not efficiency, it is predictability and 
consistency instead.
And I don't expect ARC to be the main memory collect way, but I think it 
can be a supplement.
For example, maybe two types, sync.Pointer and sync.WeakPointer can be 
added.
 

>
> Only a practical test, tailored to your case, could tell if Go GC could 
> degrade your fps. If by any chance you find a challenging situation I am 
> sure the Go Team would be very eager to investigate, because it is 
> increasingly difficult to find new challenges to the GC.
>
>
> On Friday, May 12, 2017 at 11:55:36 AM UTC-3, T L wrote:
>>
>>
>>
>> On Thursday, May 11, 2017 at 8:48:05 PM UTC+8, JuciÊ Andrade wrote:
>>>
>>> Maybe a 100µs GC would be fast enough for you to be at easy with your 
>>> game FPS.
>>>
>>>
>>> https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ
>>>
>>>
>> The 100µs is STW duration. I mean the fps may decrease some during the 
>> period of GC running.
>>  
>>
>>> On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote:

 ARC would be a better option for game apps than GC, to keep the fps 
 stable.

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[ojucie]

Any memory management strategy costs time. Reference counting is not cheap. 
Incrementing and decrementing millions of reference counters costs time. 
Please consider caching issues as well.

Go GC, as it currently stands, is very effective, as other people in this 
forum can confirm to you. Several Gigs of data and the only way to perceive 
any performance impact is by generating a profile chart! 

Only a practical test, tailored to your case, could tell if Go GC could 
degrade your fps. If by any chance you find a challenging situation I am 
sure the Go Team would be very eager to investigate, because it is 
increasingly difficult to find new challenges to the GC.


On Friday, May 12, 2017 at 11:55:36 AM UTC-3, T L wrote:
>
>
>
> On Thursday, May 11, 2017 at 8:48:05 PM UTC+8, JuciÊ Andrade wrote:
>>
>> Maybe a 100µs GC would be fast enough for you to be at easy with your 
>> game FPS.
>>
>>
>> https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ
>>
>>
> The 100µs is STW duration. I mean the fps may decrease some during the 
> period of GC running.
>  
>
>> On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote:
>>>
>>> ARC would be a better option for game apps than GC, to keep the fps 
>>> stable.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Thursday, May 11, 2017 at 8:48:05 PM UTC+8, JuciÊ Andrade wrote:
>
> Maybe a 100µs GC would be fast enough for you to be at easy with your game 
> FPS.
>
>
> https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ
>
>
The 100µs is STW duration. I mean the fps may decrease some during the 
period of GC running.
 

> On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote:
>>
>> ARC would be a better option for game apps than GC, to keep the fps 
>> stable.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[ojucie]

Maybe a 100µs GC would be fast enough for you to be at easy with your game 
FPS.

https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ

On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote:
>
> ARC would be a better option for game apps than GC, to keep the fps stable.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[Sokolov Yura]

Where will you store reference counter for interior pointer?

type st struct { j int }
type at { i int; s st }
var a at
var s st
dealWithSt()
dealWithSt()

So, you have two choices:
- either you have to find base address for pointer on every rc 
increment/decrement - and it is quite expensive operation (with current GC it 
is done very rare),
- or you forbid interior pointers (and store a.s in separate location) - and 
then it is not Go language.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Friday, May 5, 2017 at 2:10:03 AM UTC+8, Jesper Louis Andersen wrote:
>
> To see why the "immediately" solution is not adequate:
>
> Step 1: Create a single linked list or a binary tree of a couple billion 
> elements. Make sure there is only a single reference to the head element.
> Step 2: Release the pointer to the head
> Step 3: Twiddle your thumbs while your program is blocked since all 
> elements needs to be immediately freed.
>

No, "immediately freed" doesn't mean all unused memory blocks should be 
released by consuming all CPU.
The unused memory blocks can be eventually collected by consuming a very 
small percentage of CPU. 
 

>
> Alternative method:
>
> Moon instructs a student --
>
> One day a student came to Moon and said: “I understand how to make a 
> better garbage collector. We must keep a reference count of the pointers to 
> each cons.” Moon patiently told the student the following story: “One day a 
> student came to Moon and said: ‘I understand how to make a better garbage 
> collector...
>
>
>
> On Thu, May 4, 2017 at 6:33 PM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> As so often is the question: Why?
>>
>> I don't believe this will ever be supported by gc; but if you think it's 
>> a good idea, you can of course do it and see whether it actually solves 
>> your problems (my prediction would be "there won't be a net change in 
>> problems", but am ready to be proven wrong).
>>
>> On Thu, May 4, 2017 at 6:00 PM, T L  
>> wrote:
>>
>>> sometimes, I really want to some memory blocks be collected when they 
>>> become unreferenced immediately..
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Friday, May 5, 2017 at 12:33:57 AM UTC+8, Axel Wagner wrote:
>
> As so often is the question: Why?
>
> I don't believe this will ever be supported by gc; but if you think it's a 
> good idea, you can of course do it and see whether it actually solves your 
> problems (my prediction would be "there won't be a net change in problems", 
> but am ready to be proven wrong).
>

ARC is not part of GC.

The current official GC algorithm will tolerate the percentage of garbages 
set by GOGC environment variable.
The default value of GOGC is 100. That means most half of the memory 
allocated is garbage before gc starts.
Sometimes I want to make GOGC small. But small GOGC value will run garbage 
collector frequently and consume much CPU.

In fact, to find which memory blocks are garbages, most energy consumed by 
the garbage collector is wasteful.
For an extreme case, there are  alive pointers which all reference very 
small memory blocks,
then a very large short-lived memory block is allocated and becomes unused 
soon. 
If the garbage collector starts now, the collector will waste most time to 
find the only garbage.

If the runtime use ARC to manage pointer to the large short-lived memory 
block,
the memory block will be collected immediately after it becomes unused.
This will largely reduce burden of running garbage collector.

ARC would be a better option for game apps than GC, to keep the fps stable.
 

>
> On Thu, May 4, 2017 at 6:00 PM, T L  
> wrote:
>
>> sometimes, I really want to some memory blocks be collected when they 
>> become unreferenced immediately..
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[Jesper Louis Andersen]

To see why the "immediately" solution is not adequate:

Step 1: Create a single linked list or a binary tree of a couple billion
elements. Make sure there is only a single reference to the head element.
Step 2: Release the pointer to the head
Step 3: Twiddle your thumbs while your program is blocked since all
elements needs to be immediately freed.

Alternative method:

Moon instructs a student --

One day a student came to Moon and said: “I understand how to make a better
garbage collector. We must keep a reference count of the pointers to each
cons.” Moon patiently told the student the following story: “One day a
student came to Moon and said: ‘I understand how to make a better garbage
collector...



On Thu, May 4, 2017 at 6:33 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> As so often is the question: Why?
>
> I don't believe this will ever be supported by gc; but if you think it's a
> good idea, you can of course do it and see whether it actually solves your
> problems (my prediction would be "there won't be a net change in problems",
> but am ready to be proven wrong).
>
> On Thu, May 4, 2017 at 6:00 PM, T L  wrote:
>
>> sometimes, I really want to some memory blocks be collected when they
>> become unreferenced immediately..
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

['Axel Wagner' via golang-nuts]

As so often is the question: Why?

I don't believe this will ever be supported by gc; but if you think it's a
good idea, you can of course do it and see whether it actually solves your
problems (my prediction would be "there won't be a net change in problems",
but am ready to be proven wrong).

On Thu, May 4, 2017 at 6:00 PM, T L  wrote:

> sometimes, I really want to some memory blocks be collected when they
> become unreferenced immediately..
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.