[patch][8735] Intel Memory Allocator

[Ambal]

i have some crashes related to this patch

Provide a crashdumps and your system spec (OS type, version, compiler) please.

P.S. I'm more than sure that those crashes with Intel TBB ver2.2 were caused by faulty patches =/

[Mordaunt]

Hi Ambal,

I'm using this patch without any problems. Excely, the lagspikes reduces in terms of duration. So this is for windows servers, a step into better performance. Unfortunately not completely fix for the bottleneck, but hell, every step is one, right?

I'm using this patch in combination with OpenMP and one of the latest revisions before switch to 3.3.2.

Thanks for your efforts. Hope to see much more from you!

edit: Uptime 4 days+, with 125 testers.

[nanounico]

well i use RHEL maybe is for that? i delete all crashlog and desactivate this patch so i cant put the crash log but all relate to "pexecute sql" , a least for now, without patch no crashes

[Ambal]

well i use RHEL maybe is for that?

Check whether patch applied correctly in Database.h/.cpp - this affects greatly DB memory allocator usage. Also, could you test MemoryAllocator w/o any other custom patches to be sure that this particular one causes problems?

[shane99]

RHEL is Red Hat Enterprise Linux

[Ambal]

For those who want to get patch for 3.2.2 server, check "rebase_branch" in my repo

[nanounico]

my good friend ambal, i'm going to test again with the patch for 3.2.2 ^^

[Woweur]

With 2200 players, i havn't crash cause by this patch. (debian64)

But my CPU usage is the same

[Ambal]

Intel TBB sources for 3.2.2 server got latest updates, 1st BugFix from Intel. Several important bugs and crashes are fixed! Please check 'rebase_branch' once again!

[nanounico]

Cant compile

/root/Desktop/Mangos/Sources/src/shared/vmap/AABSPTree.h:1535: instantiated from \\u2018void G3D::AABSPTree<T>::getMembers(G3D::Array<Key>&) const [with T = VMAP::ModelContainer*]\\u2019

/root/Desktop/Mangos/Sources/src/shared/vmap/VMapManager.h:113: instantiated from here

/root/Desktop/Mangos/Sources/src/shared/vmap/../../../dep/include/g3dlite/G3D/Array.h:125: warning: \\u2018cdecl\\u2019 attribute ignored

/root/Desktop/Mangos/Sources/src/shared/vmap/../../../dep/include/g3dlite/G3D/Array.h: In instantiation of \\u2018G3D::Array<G3D::_AABSPTree::Handle<VMAP::ModelContainer*>*>\\u2019:

/root/Desktop/Mangos/Sources/src/shared/vmap/AABSPTree.h:380: instantiated from \\u2018G3D::AABSPTree<VMAP::ModelContainer*>::Node\\u2019

/root/Desktop/Mangos/Sources/src/shared/vmap/AABSPTree.h:1497: instantiated from \\u2018void G3D::AABSPTree<T>::intersectRay(const G3D::Ray&, RayCallback&, float&, bool, bool) const [with RayCallback = VMAP::IntersectionCallBack<VMAP::ModelContainer>, T = VMAP::ModelContainer*]\\u2019

/root/Desktop/Mangos/Sources/src/shared/vmap/VMapManager.cpp:560: instantiated from here

/root/Desktop/Mangos/Sources/src/shared/vmap/../../../dep/include/g3dlite/G3D/Array.h:125: warning: \\u2018cdecl\\u2019 attribute ignored

AR libmangosvmaps.a

make[5]: Entering directory `/root/Desktop/Mangos/Sources/objdir/src/shared/vmap'

make[5]: Nothing to be done for `install-exec-am'.

make[5]: Nothing to be done for `install-data-am'.

make[5]: Leaving directory `/root/Desktop/Mangos/Sources/objdir/src/shared/vmap'

make[4]: Leaving directory `/root/Desktop/Mangos/Sources/objdir/src/shared/vmap'

make[4]: Entering directory `/root/Desktop/Mangos/Sources/objdir/src/shared'

CXX Base.o

CXX Common.o

CXX Log.o

CXX MemoryLeaks.o

CXX ProgressBar.o

CXX Threading.o

CXX Util.o

AR libmangosshared.a

make[5]: Entering directory `/root/Desktop/Mangos/Sources/objdir/src/shared'

make[5]: Nothing to be done for `install-exec-am'.

make[5]: Nothing to be done for `install-data-am'.

make[5]: Leaving directory `/root/Desktop/Mangos/Sources/objdir/src/shared'

make[4]: Leaving directory `/root/Desktop/Mangos/Sources/objdir/src/shared'

make[3]: Leaving directory `/root/Desktop/Mangos/Sources/objdir/src/shared'

make[2]: Leaving directory `/root/Desktop/Mangos/Sources/objdir/src/shared'

Making install in realmd

make[2]: Entering directory `/root/Desktop/Mangos/Sources/objdir/src/realmd'

CXX AuthSocket.o

CXX Main.o

CXX RealmList.o

CXXLD mangos-realmd

/usr/bin/ld: cannot find libtbbmalloc.so.2

collect2: ld returned 1 exit status

make[2]: *** [mangos-realmd] Error 1

make[2]: Leaving directory `/root/Desktop/Mangos/Sources/objdir/src/realmd'

make[1]: *** [install-recursive] Error 1

make[1]: Leaving directory `/root/Desktop/Mangos/Sources/objdir/src'

make: *** [install-recursive] Error 1

[Ambal]

nanounico, is libtbbmalloc.so.2 didn't compile or it didn't copied correctly?

[nanounico]

i think didn't compile becouse the problem is cant find to copy so do error in compile i think so.

[voidx]

any report?

[Ambal]

Quickfix for recent compilation issues in rebase_branch is removing Makefile from "../dep/tbb/" folder. There should be only Makefile.am Try and report ASAP. Update in GIT will come soon.

[nanounico]

Ok Ambal, after test, i think the improvement is not the same in Linux System's, i noted that in the latest rev, i have more speed whitout Intel Allocator, noted that i tested in RHEL 5.4 x64.

[Ambal]

Ok Ambal, after test, i think the improvement is not the same in Linux System's, i noted that in the latest rev, i have more speed whitout Intel Allocator, noted that i tested in RHEL 5.4 x64.

Thanks for report, nanounico What about stability with new Intel TBB sources in 'rebase_branch'? Is it better or not? Do you still get crashes with memory allocator on your RHEL system?

Like I said before, performance gains depend greatly on OS you use Because there are tons of different *nix OSes, some of which have very powerful standard memory allocator, thats why some of you, guys, do not notice any differences in performance

P.S. You can compile mangos w/o Intel TBB memory allocator just by specifying USE_STANDARD_MALLOC define while compiling 'framework' project :rolleyes:

[voidx]

Ambal +1 for you

[Ambal]

Patch is in [8735]. Thanks to everyone involved in testings. Remember, you can always switch to default OS memory allocator just by using define USE_STANDARD_MALLOC while compiling 'framework' project!

[The_Game_Master]

I was wondering, couln't you make "tbb.so/tbbmalloc.so on *nix and tbb(_debug).dll/tbbmalloc(_debug).dll on windows" auto copy in the release dir?

And offcourse not copy in case USE_STANDARD_MALLOC is given?

[Ambal]

I was wondering, couln't you make "tbb.so/tbbmalloc.so on *nix and tbb(_debug).dll/tbbmalloc(_debug).dll on windows" auto copy in the release dir?

Well, these libraries auto-copy into output folder You just need to copy them further into you mangos folder

And yes, if USE_STANDARD_MALLOC is defined, there is no need in them in mangos folder... Atleast for now since we are going to base all threading code on Intel TBB library in nearest future

[nanounico]

Congrats Ambal for Push on Master.. Great Work, We need more improvements like this..

Chears.

PD: I dont know if is only me, but i feel a little angry when "Trinity" Stole(adapt) the best codes(Updates) created for Mangos, i say this, becouse, i suppose that not be long before they implement it well. sorry if I offend someone, is only my opinion.

[ML006]

rev. 8736. OS - Linux. mangos-worldd runs, mangos-realmd an error at startup http://i057.radikal.ru/0910/1a/3c6f7ffc0934.png

[Ambal]

rev. 8736. OS - Linux. mangos-worldd runs, mangos-realmd an error at startup http://i057.radikal.ru/0910/1a/3c6f7ffc0934.png

Copy libtbb.so.2 and libtbbmalloc.so.2 libs into your mangos folder and problem should go away

[ML006]

Copy tbb.so.2 and tbbmalloc.so.2 libs into your mangos folder and problem should go away

http://i060.radikal.ru/0910/20/bf989cfd21ce.png

tbb.so.2 and tbbmalloc.so.2 absent. There is only libtbb.so.2 and libtbbmalloc.so.2, which after compilation is automatically copied to the folder lib. Maybe'll come in [email protected]?

[Ambal]

There is only libtbb.so.2 and libtbbmalloc.so.2

Then use these ones, lolz I can be mistaken in *nix libraries names