TBB allocator integration

[Im-dex]

Replace standard allocator by the Intel TBB scalable allocator

[jazzvaz]

@Im-dex do we really need it, and if yes, in which case? I think it is better just to use it as needed.

[Im-dex]

@jazzvaz It is useful in case when a multithreading is actively added to the engine

[jazzvaz]

@Im-dex what did you mean by replace STANDART allocator? stl type allocator or xr_memory itself?

[Im-dex]

@jazzvaz all of them, there must be only one tbb's allocator

[jazzvaz]

@Im-dex what about pools that xr_memory uses?

[Im-dex]

@jazzvaz they should all be removed

[jazzvaz]

@Im-dex performance will drop a lot

[Im-dex]

@jazzvaz why?

[jazzvaz]

@Im-dex I might be wrong, but I think gsc did good job with memory optimization. Then to remove it, tbb malloc proxy can be used instead of allocator

[Im-dex]

@jazzvaz I think Intel did a much better job than gsc :) anyway, tbb malloc already contains thread caching pools.

[jazzvaz]

@Im-dex so what is better: malloc proxy or scalable allocator? Furthermore, pool is faster with dealing many allocation and deallocation as calling malloc itself.

[Im-dex]

@jazzvaz What do you mean? scalable allocator is an allocator, malloc proxy is a way to use scalable allocator

[jazzvaz]

@Im-dex yes, that why I asked, what will be the better implementation: create an allocator or use proxy for malloc?

[Im-dex]

@jazzvaz I think proxy will be enough

[jazzvaz]

@Im-dex do we need from xr_memory: debug memory name, debug memory monitor, memory stats?

[Im-dex]

@jazzvaz nope

[jazzvaz]

@Im-dex Can I open pull request now and fill it with time as commits will be big, and you will need time to revise it?

[Im-dex]

@jazzvaz Yes, but keep in mind that it will be better to open one pr for one kind of changes (e.g. macros removing, one feature adding) cause it easier for review and makes merge faster.