Your memory performance

[Dareltibus]

how much times takes to you to execute this code? (both debug and release optimized)

Code: Select all

 
class Test{ // empty class
 
};
 
for(int i=0;i<10000000; i++) //ten millions allocations
    {
        Test * a = new Test;
        delete a;
    }
 
    return 0;
 

on debug it required 4.22 seconds (roughly 39.000 allocations per frame. assuming framerate of 60) (debugging symbols on)

on release it required 6.08 seconds (more time!very strange) (no debuggin symbols, -O2, stripping symbols)

after some testing seems that "stripping symbols in g++" increase allocation time even if this should speed up other things.

release build with only O2 to required 3.75 seconds (no debuggin, -O2, 44.000 allocations per frame)
optimizing for size (Os) required 3.7 seconds.

[hendu]

Don't do that. You should remove all memory allocation from hot paths.

[REDDemon]

Don't do that. You should remove all memory allocation from hot paths.

he posted a virus? I'll not execute his code but at least explain why. (personally don't know anything about hot paths.)

If you are going to measure memory allocations speed you likely need microseconds timers, and anyway you can't profile memory like that.
A good allocator performance is measured in real cases (exactly where needed, since every allocator behaves differently)

Just to say, when I replace standard "new" in my game with specialized allocators I reduce allocation time from 2 to 30 times (this is not going to affect in significative manner framerate since there are not so many allocations every frame in my game so I left "new" not overloaded since is assumed to be more stable than custom allocators.).

Probably keeping a code like your will increase throughput of allocations but that's not a real case of allocation
so u should not assume your code as valid testing case (there are complex frameworks for this kind of tests just search on google/wikipedia. lot of material about memory
profiling).

and anyway.. 4 seconds are referred to wich CPU?, wich hardware you have? memory is affected by your internal PC architecture (bus speed, RAM speed, in some cases even HD speed since if your application is going to sleep for a while, Operative system is likely to temporary transfer your app on HD for later restore to free extra RAM for other processes). without knowing wich hardware you have, those numbers are mostly useless.

[hybrid]

If you have a good allocator, there's almost no bus transaction taking place here. C++ does not initialize memories, so you only need to store the consumption of the memory area in your used mem list. This test case basically shows the performance of you libc you use.

[REDDemon]

so that code is safe ? (hendu scared me to compile it even if at a first look seems normal code)..

and anyway yes BUS is very slow, but i measured it only once in a empiric way (don't know other ways to measure it):

http://irrlicht.sourceforge.net/forum/v ... =3&t=45360

and found that the time for computing a "cos(x)" was almost the same of fectching its value from RAM (at this point compute cos(X) without lookup tables is better, and supposed to be even faster on newer CPUs since my laptop is quite old.) the same test repetead on PCs at schools revelaed that my "20% faster cosine function" was in reality "35% slower". (but now that caches are several MBs maybe this result will change again?)

[hendu]

Yes it's safe, but it makes no sense. It's common sense to not to allocate memory in a hot path like that.

[serengeor]

Yes it's safe, but it makes no sense. It's common sense to not to allocate memory in a hot path like that.

what exactly are 'hot paths'?

[hendu]

I thought it was a generally known term in the computersphere.

Hot path = code that is run often, such as every frame
Cold path = code run rarely

[serengeor]

Thanks, first time I heard of it

[Granyte]

Yes it's safe, but it makes no sense. It's common sense to not to allocate memory in a hot path like that.

so much for my galactic explorer and my planet generator all the alocation is done on the fly

[hendu]

You better rethink that if you want good performance, yes. Perhaps a pool of ready-to-use objects.

[Dareltibus]

that's not hotpath. code is runned as benchmark and so, is a benchmark, the sense it makes is to measure "new" time. and since is made for that every other usage is of course senseless.. anyway I have 2.3 ghz cpu (AMD opteron)

[hendu]

Yes, it's a benchmark. But if you have proper code, you don't need to have good new performance, so it does point fingers

[Granyte]

You better rethink that if you want good performance, yes. Perhaps a pool of ready-to-use objects.

well performance is not bad because the allocation is hapening only when the user move around and then the generated object stay around until the user move again

also i cannot use a pool of pre generated object because in some region i have 52k stars rendered and in some other i have only 3k

[hybrid]

That's ok. Could be that in some regions you have up to 49k regions unused, but not unallocated. Also watch out for re-allocations, which are even worse, as they also copy the whole old region to a new place. You will really kill any performance if you use new too often.