08 Oct, 2008, Lobotomy wrote in the 1st comment:
Votes: 0
I'm curious if anyone else that has worked with Socketmud has set about recoding the event handler system, and if so what their thoughts are regarding the chosen value for MAX_EVENT_HASH. I've already more or less completed a painstakingly thorough rennovation of its event handler system, and I understand the math at work behind it; I'm just trying to figure out if there's any particular reason the value is what it is.

From stock, MAX_EVENT_HASH is 128. I figured this would have some relation to PULSES_PER_SECOND which is set to 4 by default, as the event handler runs once every game pulse; my reason for suspecting this is that MAX_EVENT_HASH / PULSES_PER_SECOND comes out to a nice round 32. However, according to the base design for the event handler (which I've more or less decided to stick to as it's rather orderly) the value doesn't seem to actually matter.

Each event is given a "passes" value when enqueued that ensures it isn't run until the correct time; passes being a value derrived from the pulse amount given to the event divided by the max event hash value. The event is put into a "bucket" (or LIST) according to an equation using its pulses, the current bucket, and the modulo of the max event hash. In the "heartbeat" function that runs every pulse to handle the events, the current bucket is set to itself, incremented by one, and then modulo'd by the max event hash. Unless I'm missing something, this pretty much means that the system will run normally so long as the max event hash is higher than pulses per second. The only varying factor seems to be how many buckets there are, determining how many or how few events will have to be potentially listed through each pulse. To that end, it seems like it could be a performance issue, but I'm not sure.

The major reason this even has come up at all, other than working on overhauling everything, is that I've chosen to increase pulses per second from 4 to 10. I worry that, while the remainder of the game's math is fine, it divides unevenly into the current max event hash of 128. I.e, it comes out to 12.8 instead of 32. I'm considering setting the hash as a macro that becomes whatever pulses per second is as multiplied by 32, keeping with the prior division - that is, assuming there is some kind of logic to that value I am not understanding. The only reason I hesitate is that it increases the number of allocated buckets from 128 to 320; and could become more, if I or someone else decides to further increase pulses per second to increase performance.

Currently, the pulses per second is still 10, the max event hash is 128, and in all the tests I've run of the system so far everything is running perfectly. I.e, an event set to trigger in 60 seconds does so, and so on. So, some insight or confirmation of my suspicion(s) or othersuch on the matter would be appreciated.

P.s., I would contact the creator of Socketmud about the matter directly via email so as to ascertain the intent of the value directly, however he does not seem to reply in a particularly timely manner, if even at all, so I am opting for the forums here instead. :thinking:
08 Oct, 2008, David Haley wrote in the 2nd comment:
Votes: 0
The efficiency of a hash table is directly proportional to how occupied the buckets are. A perfect hash table has one element at most per bucket. A realistic hash table distributes elements fairly evenly across buckets.

The hash function is the function that takes an element and returns some number. This number is then converted to a bucket number, typically by taking the modulo w.r.t. the number of buckets. Assuming that your hash function returns numbers over a large enough range, the modulo operation doesn't change the distribution. If the hash function returns numbers that are all congruent modulo the number of buckets, your hash function is kind of terrible.

That the hash table has 32 times more buckets than the pulse per second is basically a total coincidence.

The only thing you should be worried about is whether your change causes the buckets to be less evenly filled. The best way to verify this without doing complex math is to just look at average and standard deviation bucket occupancy before and after your change.

Lobotomy said:
if I or someone else decides to further increase pulses per second to increase performance.

Increasing PPS won't increase performance – it increases the number of times the game state is updated per second. In some sense, that is actually decreasing performance because you are increasing CPU usage.
08 Oct, 2008, Lobotomy wrote in the 3rd comment:
Votes: 0
DavidHaley said:
If the hash function returns numbers that are all congruent modulo the number of buckets, your hash function is kind of terrible.

I'm not particularly certain what you mean by this (I have a guess, but I could be wrong). Could you explain further?

DavidHaley said:
Increasing PPS won't increase performance – it increases the number of times the game state is updated per second. In some sense, that is actually decreasing performance because you are increasing CPU usage.

I'm aware of the increased CPU usage. I suppose the more accurate word to use for what I meant would have been responsiveness. That is to say, after making the increase I noticed a jump in the "performance" of the game; i.e, it was more responsive.
08 Oct, 2008, David Haley wrote in the 4th comment:
Votes: 0
Lobotomy said:
DavidHaley said:
If the hash function returns numbers that are all congruent modulo the number of buckets, your hash function is kind of terrible.

I'm not particularly certain what you mean by this (I have a guess, but I could be wrong). Could you explain further?

If the hash function returns numbers 0, 6, 12, 18, 24, 30, … and you have six buckets, then everything is going into bucket 0, which is terrible.

Numbers x and y being congruent modulo some number z just means that x % z == y % z.


Lobotomy said:
I'm aware of the increased CPU usage. I suppose the more accurate word to use for what I meant would have been responsiveness. That is to say, after making the increase I noticed a jump in the "performance" of the game; i.e, it was more responsive.

Oh, sure, in that case yes, it's much more responsive. That's because it's processing the network code more often. There are other ways to accomplish that than by increasing the number of logical ticks per second. The network code should, really, be separated from that in the first place.
08 Oct, 2008, Lobotomy wrote in the 5th comment:
Votes: 0
Edit: It seems that what I just reported as happening is a result of my own error, not the math. The equations actually do work correctly, it seems. The former bug of it only going through buckets 0, 1, 2, 3, is a result of accidentally putting 4 for the max event hash instead of into pulses per second as I was moving values around in a rush to test things to see what was going on. Rather embarassing, really. :smile:
08 Oct, 2008, David Haley wrote in the 6th comment:
Votes: 0
No problem :smile: By the way, your most recent comment made me go back to your initial analysis and I noticed this:
Lobotomy said:
The event is put into a "bucket" (or LIST) according to an equation using its pulses, the current bucket, and the modulo of the max event hash. In the "heartbeat" function that runs every pulse to handle the events, the current bucket is set to itself, incremented by one, and then modulo'd by the max event hash.

If I'm understand this correctly, then SocketMUD is doing something very strange. You should never rehash something by manually shifting things from one bucket to another. You should always call the hash function again.

It sounds like somebody might be taking some pretty dodgy shortcuts in all of this… it's like they're trying to treat the hash table like a queue at the same time, which is a recipe for trouble. I mean, sure, it works as-is, but it's hard to maintain. The event storage mechanism should be completely agnostic to the number of pulses per second.
08 Oct, 2008, Lobotomy wrote in the 7th comment:
Votes: 0
Edit: Is there a function for deleting a post I'm simply not aware of? :mad:
08 Oct, 2008, David Haley wrote in the 8th comment:
Votes: 0
A hash table is a data structure that aims to provide very rapid lookup performance by dividing elements into buckets. Instead of searching through a list of all elements, you only search through elements with the same bucket number according to the hash function. The hash function is the formula that takes the element and converts it to a bucket number. When you want to find an element, you put it through the hash function, which gives you a bucket; you then search through the elements in that bucket to see if one matches the one you're looking for.

In particular, hash tables do not have order. The sequence of buckets is completely arbitrary, as is the contents of those buckets.

A queue, on the other hand, is a data structure in which the order of elements is crucial.

Even on a very conceptual level, implementing a queue with a hash table really doesn't make sense at all.

Hash tables are often used to implement sets. You can also implement a map where each element is a key/value pair. For instance, the key could be a string, and the value a count of how many times that string is in use. (Sound familiar? :smile:)

The Wikipedia articles on hash tables and queues are pretty good, so if you want to learn more I'd suggest going there since I'd say most of the same stuff anyhow. :wink:



EDIT: err, I replied to a post that has now been edited away :rolleyes: No, I don't think you can delete a post.
08 Oct, 2008, Conner wrote in the 9th comment:
Votes: 0
Lobotomy said:
Edit: Is there a function for deleting a post I'm simply not aware of? :mad:

Not that e members have access to here, and the site admins also frown upon editing a post to remove all content for the same reasons that they don't give us delete privileges.
08 Oct, 2008, Lobotomy wrote in the 10th comment:
Votes: 0
DavidHaley said:
EDIT: err, I replied to a post that has now been edited away No, I don't think you can delete a post.

It'd be useful to me if there were a way to do so. I don't much like the idea of leaving blank posts hanging about. Anyhow, I ended up looking up the matter shortly after replying about it (prior to your response), although I do appreciate the explanation.

I suppose the Socketmud method must then just merely be a shortcut to the math involved for figuring out what bucket an event needs to go into and how many passes it should get so that it executes at the correct time. My apologies if my misunderstanding of the matter has caused unnecessary misunderstanding on your end as to what I was saying or asking about.

Conner said:
Not that e members have access to here, and the site admins also frown upon editing a post to remove all content for the same reasons that they don't give us delete privileges.

That seems rather odd to me…
08 Oct, 2008, Caius wrote in the 11th comment:
Votes: 0
Lobotomy said:
Conner said:
Not that e members have access to here, and the site admins also frown upon editing a post to remove all content for the same reasons that they don't give us delete privileges.
That seems rather odd to me…

I don't know the exact reason why they frown upon it, but the reason I personally don't like posts being edited out is because there may be other people looking for the same answers down the road.
08 Oct, 2008, Cratylus wrote in the 12th comment:
Votes: 0
Lobotomy wrote:
Quote
That seems rather odd to me…

Not to me. I run a forum also and allow for a post's
deletion or editing up to around 15 minutes (I don't
remember for sure now). This lets people re-read and
modify…maybe even get rid of words they fired off
in the heat of the moment. But ultimately it's
important to maintain the integrity of the information
being shared, and for that reason eventually posts
stop being editable/deletable.

It would be far more difficult and frustrating
for folks to find technical fixes if the standard
response to getting an answer were deleting
"dumb question" posts in embarrassment.

There's also the whole "you did so say that, before
you edited it", "did not" thing.

DavidHaley wrote:
Quote
err, I replied to a post that has now been edited away

That is super frustrating.

I rather like TMC's policy, where you can delete a
post up to an hour after making it, unless someone
posts after you. If someone posts in the thread, that's
it, your post can be *added* to, but the original
words can't be deleted or modified. One of these days
I'll get around to implementing that for my own forum.

-Crat
http://lpmuds.net
08 Oct, 2008, Guest wrote in the 13th comment:
Votes: 0
Lobotomy said:
DavidHaley said:
EDIT: err, I replied to a post that has now been edited away No, I don't think you can delete a post.

It'd be useful to me if there were a way to do so. I don't much like the idea of leaving blank posts hanging about. Anyhow, I ended up looking up the matter shortly after replying about it (prior to your response), although I do appreciate the explanation.


Deletions are never allowed, as it leaves too much open for removing the chain of a thread, especially once a reply is made. I've been considering making it impossible to edit or delete a post once a reply is made, but haven't looked into it much beyond toying with the idea. Better things to code etc. But if end-running that by editing out the contents is going to become a problem, I suppose it'll have to be considered.

Conner said:
Not that e members have access to here, and the site admins also frown upon editing a post to remove all content for the same reasons that they don't give us delete privileges.

Lobotomy said:
That seems rather odd to me…


There is a hard time limit right now on edits that last for 6 hours. Mainly so that you can have a chance to go back and correct typos and whatnot, or bad bbcode. Perhaps 6 hours is a bit too generous. Either way the logic is the same. Removing the contents entirely deprives someone of finding a solution later. If the question was worth asking, it was worth seeing a response to.

Maybe we need to shorten the time frame to an hour, or 30 minutes, or even 15 like Cratylus uses. I don't like the idea of being totally off limits though until after a response is posted.
09 Oct, 2008, Conner wrote in the 14th comment:
Votes: 0
I think having a few hours leeway is a good thing, especially if no one has yet replied because you might change your mind about something you posted 'in the heat of the moment' but perhaps 6 hours is a bit generous.. on the other hand, 15 minutes might be a bit too brief as well. :shrug:
09 Oct, 2008, quixadhal wrote in the 15th comment:
Votes: 0
I would think an hour or two is a good amount of time to correct yourself, or cool down and rethink it…. provided that nobody has replied. I totally agree with locking your postings once a reply exists.
0.0/15