How to run? hercules with multi thread?

[Zephyrus]

i use E3-1240v2 4C/8T
map server use only single thread

3000+ player cpu use 80%+

can it run on multi thread

 

[evilpuncker]

no. unless you recode it entirely

 

[Zezicla]

tho all ticks are x64 now

 

[Judas]

I believe parts would have to be coded to enable multi threads

 

[Zephyrus]

I believe parts would have to be coded to enable multi threads

Judas, can you coded to enable multi threads??

 

[Judas]

to my knowledge, you would have to inspect what part of the code would make sense to multi thread.

My experience is probably basic, so probably something I can't help too much with

 

[Zephyrus]

to my knowledge, you would have to inspect what part of the code would make sense to multi thread.

My experience is probably basic, so probably something I can't help too much with

i have more one question.

if i run on windows server, is it run on multi thread?

 

[Tepoo]

3000+ Players?

i would like to see this server.

 

[Dastgir]

to my knowledge, you would have to inspect what part of the code would make sense to multi thread.

My experience is probably basic, so probably something I can't help too much with

 i have more one question.

if i run on windows server, is it run on multi thread?

I guess, you still have to recode.

 

[pan]

To add multi-thread support in something that's already coded is a lot of trouble. I'll read on this subject and see the cost-benefit of adding this 'feature' in Hercules.

 

[Tepoo]

dont know if this is realy needed.

 

[Zephyrus]

To add multi-thread support in something that's already coded is a lot of trouble. I'll read on this subject and see the cost-benefit of adding this 'feature' in Hercules.

Can you send cost for adding this feature to pm

 

[pan]

To add multi-thread support in something that's already coded is a lot of trouble. I'll read on this subject and see the cost-benefit of adding this 'feature' in Hercules.

Can you send cost for adding this feature to pm

There's no cost in adding features to Hercules, but it may take some time as I have to analyse our source-code first, and then test everything.

 

[Variant]

To add multi-thread support in something that's already coded is a lot of trouble. I'll read on this subject and see the cost-benefit of adding this 'feature' in Hercules.

Can you send cost for adding this feature to pm

There's no cost in adding features to Hercules, but it may take some time as I have to analyse our source-code first, and then test everything.

Another issue to recall is multi-platform support. It'd have to be platform specific implementations for linux and windows, both of which have their own optimal solutions (linux has POSIX threads, pthread.h, and windows just has all the functionality within windows.h to create threads, though I believe there's a pthread for win32 out there, I've never used it). Boost also has its own thread library, but that's C++, at which point you might as well use C++11 standard if you had that option for the built-in threading.

Though pan is right, the major issue is trying to figure out what you can really throw into threads safely. At the very least, it'd be interesting to see certain scripts be async. That is to say, if there are no global dependencies (only character variables being used in the script), then it might be totally feasible to handle processing in different threads. Imagine 1000 people using the refiner, and instead of each user blocking another (which isn't noticeable unless you have a high volume of players usually), each one runs asynchronously. 

Though there's also the overhead of thread creation to consider. 

Then there's also creating testbenches so you don't need 3000 players to test how well it worked.

 

[pan]

To add multi-thread support in something that's already coded is a lot of trouble. I'll read on this subject and see the cost-benefit of adding this 'feature' in Hercules.

Can you send cost for adding this feature to pm

There's no cost in adding features to Hercules, but it may take some time as I have to analyse our source-code first, and then test everything.

 Another issue to recall is multi-platform support. It'd have to be platform specific implementations for linux and windows, both of which have their own optimal solutions (linux has POSIX threads, pthread.h, and windows just has all the functionality within windows.h to create threads, though I believe there's a pthread for win32 out there, I've never used it). Boost also has its own thread library, but that's C++, at which point you might as well use C++11 standard if you had that option for the built-in threading.

Though pan is right, the major issue is trying to figure out what you can really throw into threads safely. At the very least, it'd be interesting to see certain scripts be async. That is to say, if there are no global dependencies (only character variables being used in the script), then it might be totally feasible to handle processing in different threads. Imagine 1000 people using the refiner, and instead of each user blocking another (which isn't noticeable unless you have a high volume of players usually), each one runs asynchronously. 

Though there's also the overhead of thread creation to consider. 

Then there's also creating testbenches so you don't need 3000 players to test how well it worked.

It's not that difficult to code a thread-implementation that supports both platform specific ones. The real issue is to design a system that is more resource efficient that the current one, also designing multi-threading in legacy code without breaking any functionality is more difficult than designing in green field projects. Implementing this in code wouldn't be so difficult as designing such system, that's why it's needed to research on the subject extensively before trying to do anything otherwise it'd be wasted work. When my next break begins I'll start looking possible ways to implement this system in our current design and post a project to other developers analyse.