ID:132963
 
Just to say, byond has a lag issue, because, I have old Windows XP computer that is pretty quick, however, when I try and host, it takes up 60% cpu in hosting Rise of Heroes, and even when nobody is logged into it.

In my new Windows Vista computer im on right now, well, when I try and host with it, it maxes out 1 core on my multi-core computer, there is a serious issue here, as, I know ROH has monster wandering, but still, nobody was logged in, and Dream Daemon host has no map control or anything, so any visuals and all don't even need to be displayed, why is there such a lag issue with hosting roh?

Anyways, my actual proposal...

Multi-Core computers are becoming common these days, add the ability instead of like background, which doesn't thread it, to add ability to add threading.

I want to specify if I can specifically, what core a given code should run on, i'd run intensive calculations and non-intensive to core 1, graphics to core 2, core 3 would be for AI processing, core 4 would be to do more graphics on, as graphics are intensive...

Anyways...what do you guys think?

2.Second proposal, well, simply, add some processing on the client-side so that the server doesn't have to use up 100% cpu when trying to do some simple spell animations...

(In my game, I simple create 8 at most 3 at little using missile() proc and using s_damage by spuzzum, or similar, and well, even with 3 monsters it hits using missile and 3 times to show damage, well, my game spikes to 100% cpu on the core, since it can only use single core, i cant run my computer total more than 25% of its power...

this is seriously why im saying there is lag issue, because no multi core as #1, and #2 is that using missile() 3 times, and then showing damage above the enemy using s_damage shouldn't take up so much cpu.
Dan0971 wrote:
Multi-Core computers are becoming common these days, add the ability instead of like background, which doesn't thread it, to add ability to add threading.

I want to specify if I can specifically, what core a given code should run on, i'd run intensive calculations and non-intensive to core 1, graphics to core 2, core 3 would be for AI processing, core 4 would be to do more graphics on, as graphics are intensive...


Lag is caused by outdated / poorly coded games. Specifying each core would have to be done by the creator of the game (who's to say what is the difference between AI and a simple proc to add 2 numbers) and if the creator preset these and someone with a single core (like me and millions of other people) that would be an example of Murphy's Law, "Anything that can go wrong, will go wrong."
In response to Inuyashaisbest (#1)
I dont give my game source away, and it will only do it for server-side things, so i dont see much of a problem here.

Also, I could if byond had a way, see how many cores a computer has, and make it run on a certain core based on that as well, if I decided I would want to release it.

Anyways, all there is is the ability to set background on procs and verbs, but there is no way to implement any kind of multi-core processing at all.

I don't want lag, but I don't want to make it wait to execute code either.

Anyways, I checked a dumbed down project with nothing but me, and one monster, and me staying stationary, I launch 3 missiles using the missile() proc, and then, 25% cpu...

This clearly shouldn't happen, especially in a otherwise blank project.
In response to Dan0971 (#2)
This is on the "To look into" list, I think. You have to keep in mind that its difficult to add multithreading into a project like BYOND, though.
Dan0971 wrote:
Anyways...what do you guys think?

Way too difficult to implement, given that BYOND doesn't use threading to begin with.

BYOND executes things on a single thread, but prioritizes between what needs to be done now and what can wait for later.

2.Second proposal, well, simply, add some processing on the client-side so that the server doesn't have to use up 100% cpu when trying to do some simple spell animations...

The client is meant to work on every single game. How could client-side processing work without some kind of special .dmb file for clients?

(In my game, I simple create 8 at most 3 at little using missile() proc and using s_damage by spuzzum, or similar, and well, even with 3 monsters it hits using missile and 3 times to show damage, well, my game spikes to 100% cpu on the core, since it can only use single core, i cant run my computer total more than 25% of its power...

I believe missile() is already executed solely on the client and not on the server, at the very least that shouldn't be causing it. And I've seen s_damage used seamlessly in multiple games.

There must be something else in your game causing all of this. Perhaps some poorly constructed AI system? Frankly the only system on BYOND that is allowed to use 15-40% of my dual-core is SS13's air system. No other game should have to lag that badly.
In response to Android Data (#4)
Your right, however, I think this may be bugged on my computer, when im using dream seeker, i can do 5000 missile() proc easily at a time, however when doing daemon hosting, i can do exactly, 3 at a time, and with lag issues, this seems a bit odd...

anyways, AI in my system sucks, they sit there like bumps on a log till someone comes on screen, and then they start moving and attacking.

anyways, I also had to get rid of random movement because of this lag issue im having.

they seem to be because of daemon hosting, but seems fine when using dream seeker hosting.

im not sure what could be causing it.
In response to Dan0971 (#5)
Dan0971 wrote:
im not sure what could be causing it.

Probably poor programming.
In response to Dan0971 (#5)
Dan0971 wrote:
Your right, however, I think this may be bugged on my computer, when im using dream seeker, i can do 5000 missile() proc easily at a time, however when doing daemon hosting, i can do exactly, 3 at a time, and with lag issues, this seems a bit odd...

That's odd. It seems to be the opposite for me. Running things in Dream Seeker is slower than hosting through Dream Daemon, though not to your extent.
In response to Popisfizzy (#6)
Popisfizzy wrote:
Dan0971 wrote:
im not sure what could be causing it.

Probably poor programming.

It's not because of poor programming, it's just grass in my game and the following code

obj
spell
icon stuff
turf
grass
icon stuff
mob
verb
lag_test()
missile(src,/obj/Spell,locate(11,11,1))


besides this code, two icons, and one map, its an otherwise blank project that im working on when the lag is created....

so this is definitely odd, unless ur saying those very few lines would slow the game down to a point of disaster....

it is a completely blank project besides this.....

no more code than is shown is in this project either, i typed it out as a template of my code, because i deleted the test project after i confirmed there was lag.
In response to Inuyashaisbest (#1)
Statistically you won't let the programmer assign tasks to cores themselves, because BYOND can implement scheduling logic that is vastly superior to the programmer's own logic in 99.99% of cases. The same goes for register optimization from C compilers. The days where a human could out optimize a well implemented system have long past.

As it goes, this could perhaps be done without affecting old projects, as it is purely a VM architectural design matter. Given they have a soft scheduler already, it's also plausible that it could be quite do-able to implement. Your real blockers are VM assumptions about their data access model, potential corner case bugs with certain opcodes etc etc, the latter of which tends to harpoon a lot of major reworks.
While multithreading would be awesome it would require that more things be added to the language so we could make critical sections, mutexes, or other means of controlling data access and synchronization so you don't have one thread working on something while another is trying work on it at the same time.

And to get proper use out of it your game would have to be properly designed otherwise you'll end up using more CPU power just to have your game slower or even work at all for that matter. Debugging multithreaded apps is a lot harder and can lead to very random seeming bugs that are very hard to track down since they occur when two threads just happen to be at the right spot to make strange stuff happen. You can't just launch a proc on another thread and expect to get a performance boost.

Plus not only would you have to do a rewrite, you probably couldn't use any of other peoples libraries until they were also thread safe or avoid making simultaneous calls on separate threads which may or may not be simple.

Your missile problem may be a bug however in most cases games running poorly and sucking up a lot of CPU power do tend to be written poorly, are using basic data structures and algorithms for massive amounts of data where special purpose ones(And it can make a massive difference), or simply trying to load and run the whole world at once. Even if a game is written in something like C and it tried to do some of the stuff people were doing in BYOND it'd still run terrible, because nothing is going to save you from bad code. Not to say your code is good or bad just that there are a lot of people here with no proper education in computer science thinking they are a lot better than they really are.
In response to Jeff8500 (#3)
Jeff8500 wrote:
You have to keep in mind that its difficult to add multithreading into a project like BYOND, though.

In this case, "like BYOND" means "possessing the quality of existence."
In response to Android Data (#4)
Android Data wrote:
Way too difficult to implement, given that BYOND doesn't use threading to begin with.

I think that this is fundamentally a misleading statement. BYOND uses threading, but it is done in a manner rooted in the fact that it's intended for games and simplicity. There's a global scheduler and whatever's at the top of it is executed first, until it explicitly gives up control (by either the entire procedure tree finishing, or a sleep() statement), at which point processing goes to the next waiting event. Mutexes are not required because they are implicit in everything. A developer does not need to even be aware of this because they are using sleep() statements often enough in order to make their game.

To say that this is not threading is missing the entire concept of threading: rapidly switching control between multiple processes to achieve the illusion of simultaneity. A processor inherently cannot perform multiple actions at the same time (and if somebody says "PIPELINES" I will slap them for their pedantry), and so threading in BYOND is just as thread-y as threading in any other language.

Anyway, as has already been stated, multi-core processing in BYOND is not currently feasible. In order for it to work with the current model (read: developers not having to worry about it), there would need to be some way to divide processes into mutually exclusive blocks, where one had NO WAY of interacting with the other. Technically, I can imagine that being feasible, but I wonder how often it would really be able to actually take a game and split it into two non-interacting priority trees that could operate on different cores, considering how interrelated the games are. Oh, and then having to deal with an event moving from one to the other (IE: a player with a proc waiting to be executed moving to another Z-level where they are now able to interact with other procs).
In response to Garthor (#12)
I personally worry for the latency caused by locks held on objects on the server that particular clients are trying to perform actions on. You'd almost be considering a preemption model for those locks, which ... is not pleasant.
In response to Stephen001 (#13)
I think it can be accepted that if there were ever any client-side actions, they would have no effect on the server. It would rather just be the server offloading non-vital actions (such as icon operations) to the client.
In response to Garthor (#14)
Well, I think it's a good idea for multi-threading, yes, it would take a lot of work though....

Also, this is supposed to be for the big games, or games which just runs lots and lots of calculations, and they want it to finish quicker...

I know a code where I have made a puzzle solver, the bigger 100x100 puzzles take a year to process though, and I have optimized my code as much as possible.

The reason you would let the developer be able to decide this is because then the developer can run some calculations on core 1, and totally seperate calculations to solve some other part of it on core 2, and such, with this, it's hard to be able to make one that could function on 2 cores, and yet, not mess with each-other if byond tried to do it automatically.

If this was implemented, then, you could make say spells process on another core or something if people use spells a lot, so that the spells will still run and all, without creating lag on your main thread, so players could still talk, move, and such.

Then you could offload a smart-ai system to another core, that deals with random movement, because, no matter how you do this, if you have thousands of enemies that are wandering around, well, it's just gonna take a lot of cpu.
In response to Superbike32 (#15)
Assuming your puzzle solver is perfectly parallisable, it'll take 3 months to run on a 100x100 puzzle on a four-core system. Either the problem is just hard, period, or more likely, your algorithm is crap.

And if your "smart AI" system moves thousands of enemies around at a time, randomly, you're doing it wrong. If no players are in range, why does the enemy even need to exist, let alone move?
In response to Jp (#16)
1.100x100 puzzle right now takes 3 hours to solve is all...

If it could run on 4 cores to their max, I expect it to take around 3hr/4 less time...

I actually have a program written the same as i do in byond mostly, considering the languages are different, but the logic is the same, in vb it takes 1hr.

In VB, I can easily make it run on two cores, so i diminished that down to 20 minutes of time...it took less than half because what the other one solved helped in the end solve other parts of the puzzle quicker...

This would really help create a good puzzle solver on byond.
In response to Superbike32 (#17)
What puzzle may I ask?

George Gough
In response to KodeNerd (#18)
The exact puzzle?

The type of puzzle doesn't matter really, it could be a soduko puzzle, or a crossword puzzle, or any other type of puzzle.

I know someone could possibly find a better way to make it solve faster than I did, but, I am not looking for that...

Regardless of how it is used, or why it is used, this would be nice to have, if you didn't know, this is a features page, not how-to or code help.
Page: 1 2