[Development] ScorpiaSauce (v1.0)

[retep998]

Alright, it seems like nobody is capable of making an intelligent reply so here goes...

The general architectural idea behind separation of servers is that you host the separate portions on different machine, hereby allowing more resources to be available for each piece of server software and pauses between thread execution switches to be minimized (this isn't a major problem in regards to the networking portion of the software, since mina-core does the job of scaling fairly well). In essence, it is implemented for performance metrics rather than memory efficiency even though the discrepancy between the memory use is fairly small. Granted, however, that the typical model would require separate machines for optimum output.

I agree for the most part, although this typical model you speak of isn't all that typical for ms pservers. Yes there are some pservers that use it, or at least have the capability to support it. However, many servers are designed as a single process, and considering how few people are on most servers, keeping everything on one server actually speeds things up because you spend zero time in inter-server communication and synchronization.

Stability has nothing to do with memory specifications, and in fact they are hardly related. Efficiency =/= stability and never has.
There is a rule of thumb: the more performance-oriented your code gets, the less memory efficient it is going to be. Essentially, it is up to the programmer to decide in which spots of the software it is needed for the sake of throughput.

The major problem with pservers is not their memory efficiency, but their memory leaks. With enough memory leaks, your server will eat up memory until it reaches the limit and crashes; certainly not very stable. As a general rule of thumb, when it comes to MapleStory pservers, the more memory efficient a server is, the more stable it is, due to the programmer being better at what they're doing.

Now, this does not always need to be the case (since the initial code could not have been made with this in mind). Notice in the screenshot with MapleAES.java that they made the cryptography scaled so that each server that requires it only needs one instance (saving a good amount of memory per new session created). Granted, the better way of performing this is by making MapleAES scaled to individual session groups in mina-core rather than a single object throughout the software. Doing it on a session group basis decreases the amount of memory needed per session (by 16 bytes and a Cipher object, but creating a new cipher and key per session group) and maintains performance because of the way mina-core manages scaling.

Pile of java garbage.
I had to deal with the C++ version of this garbage in NoLifeStory recently (although completely single-threaded), so I know exactly what his java code is doing.

You realize that there is a limit to how much a program can allocate for memory (specifically on Windows OS), right? In fact, you can set a parameter for the software's overall memory limit on run-time. If you have that much trouble with memory, then you should reconsider your base or consider writing your source from the ground up to ensure you get what you need for minimum software specifications.

On windows, an x86 program can use up to 2 GB of memory on an x86 computer. If it was built with large address aware then it can use up to 3 GB if windows has the /3GB directive enabled, or 4 GB on an x64 OS. x64 programs can use up to 8 TB of memory.
I've never heard of any other limits for a processes' memory usage, except for java which has its command line limits. The problem is, if the program reaches these software limits, it doesn't automatically lower its usage, it simply crashes. Even Minecraft is known for crashing with 32 bit java because it ran out of memory.

The easiest way to prevent memory leaks is to not rely on a GC and simply keep track of every allocation yourself and delete it when you're done (this is where C++ and Vana shine). Although it is easier to simply let a GC deal with stuff, it's much harder trying to figure out if you have circular references preventing the GC from deallocating an object, than simply checking whether you forgot to delete it. Remember, you know exactly what your program is doing, the GC can only guess.

[Xerixe]

Alright, it seems like nobody is capable of making an intelligent reply so here goes...


I agree for the most part, although this typical model you speak of isn't all that typical for ms pservers. Yes there are some pservers that use it, or at least have the capability to support it. However, many servers are designed as a single process, and considering how few people are on most servers, keeping everything on one server actually speeds things up because you spend zero time in inter-server communication and synchronization.

The major problem with pservers is not their memory efficiency, but their memory leaks. With enough memory leaks, your server will eat up memory until it reaches the limit and crashes; certainly not very stable. As a general rule of thumb, when it comes to MapleStory pservers, the more memory efficient a server is, the more stable it is, due to the programmer being better at what they're doing.

On windows, an x86 program can use up to 2 GB of memory on an x86 computer. If it was built with large address aware then it can use up to 3 GB if windows has the /3GB directive enabled, or 4 GB on an x64 OS. x64 programs can use up to 8 TB of memory.
I've never heard of any other limits for a processes' memory usage, except for java which has its command line limits. The problem is, if the program reaches these software limits, it doesn't automatically lower its usage, it simply crashes. Even Minecraft is known for crashing with 32 bit java because it ran out of memory.

The easiest way to prevent memory leaks is to not rely on a GC and simply keep track of every allocation yourself and delete it when you're done (this is where C++ and Vana shine). Although it is easier to simply let a GC deal with stuff, it's much harder trying to figure out if you have circular references preventing the GC from deallocating an object, than simply checking whether you forgot to delete it. Remember, you know exactly what your program is doing, the GC can only guess.

99.99% of everyone here don't.

[Cyclone999]

Can both retep and DancesWithOdin, respectfully, talk in a language that us mortals can understand?

[retep998]

Can both retep and DancesWithOdin, respectfully, talk in a language that us mortals can understand?

If you guys seriously can't understand that stuff...

[Cyclone999]

Forgib me mastar :(

Actually, it's not that it's too complex, now that I think about it. It's just...
Wall of text is hard to read.

Us mortals say:


Btw, retep, add me on MSN/skype please, there is something really important I need to discuss with you :)

[SuperLol]

The easiest way to prevent memory leaks is to not rely on a GC and simply keep track of every allocation yourself and delete it when you're done (this is where C++ and Vana shine). Although it is easier to simply let a GC deal with stuff, it's much harder trying to figure out if you have circular references preventing the GC from deallocating an object, than simply checking whether you forgot to delete it. Remember, you know exactly what your program is doing, the GC can only guess.

Well that's not as easy as it sounds. Tell people here to code what they do in C++ and they will end up worse than if they coded in Java if they allocate memory themselves. Not only do you have to know exactly how the program is run, you also have to know what parts of memory you allocate, and then which parts to call delete to. Coding in Java is mindless. There is little thinking involved about how to do this stuff.

Anyhow, I haven't had memory problems in about a year and a half. We leave the server up for a week at a time, and as of now: 6 days and we're hovering ~700mb with 800 allocated heap space. Yeah it's underpopulated now but we did have over 100 online during the summer and the memory usage was around the same. Actually when we had 400 online, the memory usages wasn't even that much more. There are just a few major leaks in the public odinms sources and when fixed, take all the problems away.

About hosting on multiple servers, there's really no point for servers like these as they are not meant to be super powerful. One server that has nice specs will do.

View Post
Stability has nothing to do with memory specifications, and in fact they are hardly related. Efficiency =/= stability and never has.
There is a rule of thumb: the more performance-oriented your code gets, the less memory efficient it is going to be. Essentially, it is up to the programmer to decide in which spots of the software it is needed for the sake of throughput.

This is rather incorrect... So you are saying if we implement better algorithms for programs (hence making it more performance oriented -- perhaps better searching, inserting, and deleting, and/or manipulating), the memory usage will go up? Using certain data structures might cause the memory to increase by a little, but such increase is negligible. Also a counter example would be using ArrayLists instead of LinkedList at certain times. Sometimes ArrayList is better and I think ArrayList has slightly lower overhead.

[Squiggles]

You're so smart moogra. I actually learn things when I read your posts.

[retep998]

Well that's not as easy as it sounds. Tell people here to code what they do in C++ and they will end up worse than if they coded in Java if they allocate memory themselves. Not only do you have to know exactly how the program is run, you also have to know what parts of memory you allocate, and then which parts to call delete to. Coding in Java is mindless. There is little thinking involved about how to do this stuff.

For the level of programmers here in RZ, you are right. For a good programmer who knows what he's doing, however, C++ does have its advantages. You don't even need to deal with allocations and deletions; when used correctly, the STL containers can handle it all for you. Of course, this assumes you know what you're doing, which is rarely the case around here.

This is rather incorrect... So you are saying if we implement better algorithms for programs (hence making it more performance oriented -- perhaps better searching, inserting, and deleting, and/or manipulating), the memory usage will go up? Using certain data structures might cause the memory to increase by a little, but such increase is negligible. Also a counter example would be using ArrayLists instead of LinkedList at certain times. Sometimes ArrayList is better and I think ArrayList has slightly lower overhead.

He was assuming the programmer already made such optimizations and the only stuff left to do was choose between the more processor intensive and the more memory intensive options. To be honest, as a C++ programmer myself, I've never had to make that choice. I've always been making optimizations which made my programs faster and less memory intensive at the same time.

[Squiggles]

If I had the brainpower I would have it be more cpu intensive peter. I've never ever had an issue with cpu usage getting over 2% lol

[SuperLol]

Then again there are some things that you really shouldn't "optimize" like small things such as magic numbers. Sometimes adding readability is better than optimizing. Using clever math things isn't always good when readability is needed. This is especially prevalent when coding in assembly when you have the worst variable names possible (like none). The compiler is smart enough to make such optimizations and this is true in Java and C++ (only languages I know so I can't speak about any others).

For me, I don't even implement anything until I can find a "decent" solution to do it with. I'm not going to add a lame feature that is going to take tons of cpu power. I find it easier to code it decently the first time then going back to improve it. I've heard it go both ways though. Some people prefer to get it done first, then optimize it later. It's not that they're noob as some are actually professionals (literally). It's just preference.

[humphrey123]

hope to see somewhat of a release soon. Would be awesome for the public to further enhance.

[xerta]

Hows its going here? Last since a new update :D

[Squiggles]

Then again there are some things that you really shouldn't "optimize" like small things such as magic numbers. Sometimes adding readability is better than optimizing. Using clever math things isn't always good when readability is needed. This is especially prevalent when coding in assembly when you have the worst variable names possible (like none). The compiler is smart enough to make such optimizations and this is true in Java and C++ (only languages I know so I can't speak about any others).

For me, I don't even implement anything until I can find a "decent" solution to do it with. I'm not going to add a lame feature that is going to take tons of cpu power. I find it easier to code it decently the first time then going back to improve it. I've heard it go both ways though. Some people prefer to get it done first, then optimize it later. It's not that they're noob as some are actually professionals (literally). It's just preference.

Unfortunately in a lot of cases that leads to "well it isn't like I can optimize it much, so I'll just leave it".

[SuperLol]

Unfortunately in a lot of cases that leads to "well it isn't like I can optimize it much, so I'll just leave it".

There's a difference between can't optimize and should not optimize. A programmer should know what the compiiler should be able to optimize. Also doing micro-optimizations like changing * 2 to << 1 would save you like 5 microseconds on a good processor at best -- not really worth it. I used to do things like that... and then I went to do assembly and learned that comments, whitespace, and readable code matters a lot.

[humphrey123]

Well, any updates with the source? Haven't heard from the DEVs in a while..