News for hackers. Stuff that matters.
Re:Crystal: Fast as C, Slick as Ruby by m_mueller on Thursday August 04, 2016 @02:53AM (#12223877)
Obj-C? Or do you count ARC as a GC?
Re:Crystal: Fast as C, Slick as Ruby by exDM69 on Thursday August 04, 2016 @06:15AM (#12224536)
Whether reference counting is GC or not is arguing about semantics.

But correctly implemented reference counting is essentially pause-free. It's consistently "slow", which is better for some cases that unpredictably "fast".

Re:Crystal: Fast as C, Slick as Ruby by m_mueller on Thursday August 04, 2016 @10:22AM (#12225695)
IMO it's not just semantics, rather, GC is too general of a term if it includes ARC. In terms of performance analysis the two are vastly different. One has basically an unbounded worst case but a good average case, the other is the opposite.
Re:Crystal: Fast as C, Slick as Ruby by quotemstr on Thursday August 04, 2016 @12:26PM (#12226633)
Reference counting also has an unbounded worst case: what if you drop the last reference to a very large graph of objects? Then you free the whole thing, which can take an arbitrarily large amount of time.
Re:Crystal: Fast as C, Slick as Ruby by m_mueller on Thursday August 04, 2016 @12:35PM (#12226701)
The main difference there is: You can control the timing of when to pay that penalty. With a full blown GC, if you run into performance issues because of it, you basically have to rearchtect the whole app (with something like memory pools, which you pay by needing more RAM than strictly necessary and with a vastly more complex code). With ARC I can track down a slow memory operation to a single line of code and deal with it there (e.g. by moving the complex object into a singleton). IMO a full GC is just the wrong level of abstraction for anything that's timing relevant, which includes all UI threads.
Re:Crystal: Fast as C, Slick as Ruby by quotemstr on Thursday August 04, 2016 @03:10PM (#12227754)
> IMO a full GC is just the wrong level of abstraction for anything that's timing relevant, which includes all UI threads.

Hard real-time GC systems exist. In these systems, you can prove that pauses last no longer than a certain number of milliseconds. They're definitely applicable to programs with UI.

Can you prove that dropping a reference doesn't free an arbitrarily large number of objects? You can probably convince yourself in specific cases for specific programs that you don't see arbitrarily large refcount-release times, but any change you make to the code might invalidate this analysis.

A hard real-time GC stays hard real time.

Re:Crystal: Fast as C, Slick as Ruby by m_mueller on Thursday August 04, 2016 @04:37PM (#12228279)
I keep hearing about these, but which of the popular GC languages (read: lots of library support) have real time GC? Aren't we talking about industrial RT applications rather than GUIs?
Re:Crystal: Fast as C, Slick as Ruby by SamReidHughes on Thursday August 04, 2016 @04:10PM (#12228103)
You don't have to free the whole thing right away, you (the implementation) can free O(1) things and put the rest on a list to process later.
Re:Crystal: Fast as C, Slick as Ruby by pjmlp on Thursday August 04, 2016 @02:12PM (#12227385)
Any good CS book about GC includes RC as a GC algorithm.

For example, the classical "The Garbage Collection Handbook"

http://gchandbook.org/

Re:Crystal: Fast as C, Slick as Ruby by Ygg2 on Thursday August 04, 2016 @05:20AM (#12224366)
Reference counting is GC. Simple, but GC.