More radical ideas about gc and reference counting

[Xavier Bigand via Digitalmars-d]

Le 10/05/2014 01:31, Francesco Cattoglio a écrit :
> On Friday, 9 May 2014 at 21:05:18 UTC, Wyatt wrote:
>> But conversely, Manu, something has been bothering me: aren't you
>> restricted from using most libraries anyway, even in C++? "Decent" or
>> "acceptable" performance isn't anywhere near "maximum", so shouldn't
>> any library code that allocates in any language be equally suspect?
>> So from that standpoint, isn't any library you use in any language
>> going to _also_ be tuned for performance in the hot path?  Maybe I'm
>> barking up the wrong tree, but I don't recall seeing this point
>> addressed.
>>
>> More generally, I feel like we're collectively missing some important
>> context:  What are you _doing_ in your 16.6ms timeslice?  I know _I'd_
>> appreciate a real example of what you're dealing with without any
>> hyperbole.  What actually _must_ be done in that timeframe?  Why must
>> collection run inside that window?  What must be collected when it
>> runs in that situation?  (Serious questions.)
> I'll try to guess: if you want something running at 60 Frames per
> Second, 16.6ms is the time
> you have to do everything between frames. This means that in that timeframe
> you have to:
> -update your game state.
> -possibly process all network I/O.
> -prepare the rendering pipeline for the next frame.
>
> Updating the game state can imply make computations on lots of stuff:
> physics, animations, creation and deletion of entities and particles, AI
> logic... pick your poison. At every frame you will have an handful of
> objects being destroyed and a few resources that might go forgotten. One
> frame would probably only need very little objects collected. But given
> some times the amount of junk can grow out of control easily. Your code
> will end up stuttering at some point (because of random collections at
> random times), and this can be really bad.

As I know AAA game engine are reputed to do zero allocations during the 
frame computation, but I think it less the case noways cause of the 
dynamism of scene and huge environments that are streamed.

I recently fix a performance issue due to a code design that force 
destruction of walls (I am working on an architecture application) 
before creating them back when the user move them. gprof, show me that 
this point took around 30% of CPU time in a frame, and only 
allocations/destructions was about 5%. This 5% percents contains 
destructions of object in the architecture part and the 3D engine, same 
for construction. Construction also add operation like new geometry 
updload, so I don't think place of new and delete was high without the 
job made by constructors and destructors.
Reserving memory (malloc) isn't really an issue IMO, but operations 
related to constructions and destructions of objects can be expensive.