mtmaps (OpenMP)

[Hummer]

Put please complete patch for revision mangos 8774

[Infinity_return]

Thanks for using it, but my name is not Derex (while it's nice that you compare me with him). Actually it's my patch with Infinity's mods, and slight omp critical lock added somewhere where i was too stupid to forget. EVEN if Derex added something to it, It's rude to completely remove any credits of Infinity's and mine work.

Thank you, but i have made no contributions to this patch

-- and slight omp critical lock

you meant #pragma omp critical, for thread save? I will try to implement this

I will make sure i add balrok's fixes in the latest patch

If i'm not banned i will release latest version by tomorrow

[kero99]

Thx, but in this patch there is not my merits

-- and slight omp critical lock

you meant #pragma omp critical, for thread save? I will try to implement this

I will include a new version of fixes by balrok

If me will not banned tomorrow, then in the evening expect a new version patch

Cool!!! ty

[Infinity_return]

Patch for rev 8779+(master)

http://paste2.org/p/502055 - Updated(fixed link on nix)

What new in patch:

1) Update to last rev 8779+

2) Added some Guard in ObjectAccessor, Map(for more stable work)

3) Added ACE_Thread_Mutex for LinkMap/UnlinkMap/FindHelper in ObjectAccessor(for more stable work)

4) Small cleanup code in MapManager::Update

5) Removed wrong #pragma omp task of World

6) Removed wrong #pragma omp critical of Util(these functions are safe in a multithreaded)

7) Removed win support(only *nix)

[unlucky]

8780 rev - 1k ppl
36478     20  50    0  3273M  2446M select 2   4:35 172.85% mangos-worldd

36478        103    0  3276M  2450M uwait  5  15:45 31.15% mangos-worldd
36478         54    0  3276M  2450M uwait  7   5:45 13.28% mangos-worldd
36478         53    0  3276M  2450M CPU3   3   5:44 13.18% mangos-worldd
36478         53    0  3276M  2450M RUN    6   5:43 12.99% mangos-worldd
36478         52    0  3276M  2450M CPU1   1   5:43 12.79% mangos-worldd
36478         52    0  3276M  2450M CPU2   2   5:47 12.35% mangos-worldd
36478         52    0  3276M  2450M CPU0   0   5:45 12.35% mangos-worldd
36478         52    0  3276M  2450M uwait  6   5:46 12.16% mangos-worldd
36478         51    0  3276M  2450M select 5   4:35 11.96% mangos-worldd
36478         51    0  3276M  2450M select 6   4:36 11.67% mangos-worldd
36478         51    0  3276M  2450M RUN    7   4:46 11.57% mangos-worldd
36478         50    0  3276M  2450M select 7   4:37 10.89% mangos-worldd 

gcc version 4.4.2

FreeBSD 7.2-RELEASE-p3

[divisorxx]

8780 rev - 1k ppl
36478     20  50    0  3273M  2446M select 2   4:35 172.85% mangos-worldd

36478        103    0  3276M  2450M uwait  5  15:45 31.15% mangos-worldd
36478         54    0  3276M  2450M uwait  7   5:45 13.28% mangos-worldd
36478         53    0  3276M  2450M CPU3   3   5:44 13.18% mangos-worldd
36478         53    0  3276M  2450M RUN    6   5:43 12.99% mangos-worldd
36478         52    0  3276M  2450M CPU1   1   5:43 12.79% mangos-worldd
36478         52    0  3276M  2450M CPU2   2   5:47 12.35% mangos-worldd
36478         52    0  3276M  2450M CPU0   0   5:45 12.35% mangos-worldd
36478         52    0  3276M  2450M uwait  6   5:46 12.16% mangos-worldd
36478         51    0  3276M  2450M select 5   4:35 11.96% mangos-worldd
36478         51    0  3276M  2450M select 6   4:36 11.67% mangos-worldd
36478         51    0  3276M  2450M RUN    7   4:46 11.57% mangos-worldd
36478         50    0  3276M  2450M select 7   4:37 10.89% mangos-worldd 

gcc version 4.4.2

FreeBSD 7.2-RELEASE-p3

Hi men, one question, how stable is?

[kero99]

Since 3.2.2a... core is same inestable with or without mtmaps... but good CPU use of all procesors

Greetings

[XTZGZoReX]

Hi balrok, Thanks for your time, just one question it's this assert the one that you remove ? And it's this safe to remove?

Object.h

It's used for keeping things in check. Removing such asserts is bad idea.

Hi men, one question, how stable is?

In what unit? Meters? Approximately 4326243.

6) Removed wrong #pragma omp critical of Util(these functions are safe in a multithreaded)

I actually think this is wrong. Back in the day, there were loads of crashes due to this not having a critical section on it.

7) Removed win support(only *nix)

You could just add some #if to make things work .

[divisorxx]

In what unit? Meters? Approximately 4326243.

Sorry if my english is not too good but i don't see any errors in my word. In any case I mean how much uptime do you have... because in my experience I have a lot of crashes due _UpdateSpells in Unit.cpp using mtmaps (I think due race conditions)...due to this I move Players update out of Maps and problem solved...but again main thread have the almost charge(load) compare to the others.

Again sorry If my english is not too good. Bye

[Infinity_return]

Sorry if my english is not too good but i don't see any errors in my word. In any case I mean how much uptime do you have... because in my experience I have a lot of crashes due _UpdateSpells in Unit.cpp using mtmaps (I think due race conditions)...due to this I move Players update out of Maps and problem solved...but again main thread have the almost charge(load) compare to the others.

Again sorry If my english is not too good. Bye

try again

#pragma omp critical(UpdateThreadSafety)
{
     m_Events.Update( p_time );
     _UpdateSpells( p_time );
}

in Unit.cpp, updated m_Events.Update, _UpdateSpells in 1 thread

[nanounico]

Infinity, After 8786 you need to update the patch? or is possible apply manually?

[Infinity_return]

Infinity, After 8786 you need to update the patch? or is possible apply manually?

For 8786+

http://paste2.org/p/504873

but old too would work

[XTZGZoReX]

Sorry if my english is not too good but i don't see any errors in my word. In any case I mean how much uptime do you have... because in my experience I have a lot of crashes due _UpdateSpells in Unit.cpp using mtmaps (I think due race conditions)...due to this I move Players update out of Maps and problem solved...but again main thread have the almost charge(load) compare to the others.

Oh, nono, that wasn't what I was picking at didn't know you meant uptime. Back when I ran my server with this, I was able to pull uptimes of up to 7 days.

#pragma omp critical(UpdateThreadSafety)

{

m_Events.Update( p_time );

_UpdateSpells( p_time );

}

I'm curious: Is this necessary? After all this happens within Player::Update which only happens within Map::Update on the single map the player is on .

[przemratajczak]

are there any plans to adjust it to Windows OS? I am working on Win but server is running on Debian. So would be nice to have at least option that when MapThreads = 1 than core avoid using threading and goes normal, "MaNGOS" way (like without any changes).

I am green in this stuff so maybe my question is dumb ; (

[divisorxx]

I'm curious: Is this necessary? After all this happens within Player::Update which only happens within Map::Update on the single map the player is on .

In fact there is a crash log of what i'm talking about, using ACE mtmaps. With 7XX characters... it crash like 5 times by day (some days less).. but like a said before once that i move Players:Update from Map:Update...I got like 3day uptimes.

http://pastebin.com/m836455e

To infinfny, thanks for your suggestions i will try it with your patch.

[GriffonHeart]

In fact there is a crash log of what i'm talking about, using ACE mtmaps. With 7XX characters... it crash like 5 times by day (some days less).. but like a said before once that i move Players:Update from Map:Update...I got like 3day uptimes.

http://pastebin.com/m836455e

To infinfny, thanks for your suggestions i will try it with your patch.

I have the same crash Can you provide patch, how to fix this?

[divisorxx]

I have the same crash Can you provide patch, how to fix this?

Like I said early...problem seems to be in multithreaded player updates, so revert this commit http://github.com/mangos/mangos/commit/e24d2938b21e8d6910c5aed1a3f115abf0fbddf1 and problem solved but again almost all load will remain in main thread like time ago. Also you can try openmt maps with Infinity suggestions , if that work you can still have Player:Update in Map:Updates w/o crash.

P.S.: By the way... just for curiosity , what kind of mtmaps patch are you using? (Ace mtmaps or OpenMP mtmaps)

[GriffonHeart]

P.S.: By the way... just for curiosity , what kind of mtmaps patch are you using? (Ace mtmaps or OpenMP mtmaps)

I using ACE mtmaps. But what kind is more better? ACE or OpenMP?

[XTZGZoReX]

Using two threading libs at the same time is always bound to cause some sort of trouble.

[nanounico]

Infinity, Can update the patch again

[Infinity_return]

Infinity, Can update the patch again

I will update ACE and OpenMP in the evening

-- updated:

mtmaps OpenMP (8799+):

http://paste2.org/p/508049

mtmaps ACE (8799+):

http://paste2.org/p/508050

[nanounico]

Inifity Finally Who is better, Ace or OpenMP? i dont know what is the diference

[Infinity_return]

Inifity Finally Who is better, Ace or OpenMP? i dont know what is the diference

I'm using -march=core2 and gcc 4.4.2;) uses 2 cores, 2500 with no lag

In a choice between OpenMP and ACE, i choose ACE(5.7.x)

[nanounico]

But i'm a little confuse, for use the ace patch, is necessary update the ace code?

EDIT: And is necessary compile with gcc 4.4? i compile with 4.1, and i no see any problem.

[crashuncle]

I use a very old MTmaps ACE revision which got created by Scamp and cant complain, over 1000 with 2-3 days of uptime and no lag. So I guess ACE is better since others got problems with OpenMT.

Well it would be helpful if you write down your experiences.