Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Entire forum ➜ MUSHclient ➜ General ➜ The Cost of Note()

The Cost of Note()

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Candido USA (78 posts) Bio

Date

Reply #15 on Fri 17 Jun 2011 09:07 PM (UTC)

Message

Twisol said:

Candido said:

Twisol said:

What would happen if the main thread tries to Note() something at the same time as the auxiliary thread?

Understandably, that would be a problem. My plan though was, well, to not let that happen. I'd have only the Note() in the auxiliary thread, and then all the invisible processing takes place in the main thread as normal. When the processing finishes, it joins to the Note thread.

I'm not sure you understand. While your Note thread is running, MUSHclient is also running. It's doing things to the same memory your Note thread is trying to access, including reading in more data from the MUD and rendering it. There is no way to make this work effectively. What you can do is put your processing in an auxiliary thread (so long as it doesn't touch non thread-safe data), and have your Note() in the main thread.

But the Note thread is not concurrent with all processing. A prompt arrives, which triggers a function. The Note thread is created within this function, and dies before the function ends. Inside this space, no further MUD data can be read/rendered, otherwise just a regular Note() in the function could cause the same problem. Unless I'm completely missing something here.

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #16 on Fri 17 Jun 2011 09:25 PM (UTC)

Message

Candido said:
But the Note thread is not concurrent with all processing. A prompt arrives, which triggers a function. The Note thread is created within this function, and dies before the function ends.

Then what's the point of splitting it into a new thread if it's just going to be executed inline anyways? You'd probably have more overhead just in the form of thread switching.

Also, MUSHclient's internals are a bit odd :) so I wouldn't even trust that to work. In theory it might, but in practice I'm not so sure.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Candido USA (78 posts) Bio

Date

Reply #17 on Fri 17 Jun 2011 09:35 PM (UTC)

Amended on Fri 17 Jun 2011 09:57 PM (UTC) by Candido

Message

Twisol said:

Candido said:
But the Note thread is not concurrent with all processing. A prompt arrives, which triggers a function. The Note thread is created within this function, and dies before the function ends.

Then what's the point of splitting it into a new thread if it's just going to be executed inline anyways? You'd probably have more overhead just in the form of thread switching.

Also, MUSHclient's internals are a bit odd :) so I wouldn't even trust that to work. In theory it might, but in practice I'm not so sure.

In reality, there really isn't much point, but the idea was to have what was supposedly an expensive command, Note() at 2 ms, run in one thread, while my calculations, at 1.5 ms ran in the main thread. When calculations finish, the threads are joined, so it'll wait for the Note() thread. Assuming the Note() thread got assigned to a different cpu core, I'd go from 3.5 ms to 2 ms. Though, like you mentioned, this makes a lot of assumptions about Mush's internals.

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #18 on Fri 17 Jun 2011 09:40 PM (UTC)

Message

Hmm. So is there any reason you can't keep the Note() in the main thread and do your calculations in the other thread? You'll be waiting on both to move on, regardless of which one does what.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Candido USA (78 posts) Bio

Date

Reply #19 on Fri 17 Jun 2011 09:44 PM (UTC)

Message

You could do it either way. It's just much easier to make a set and forget Note() thread than a thread you then have to pass a bunch of data into and extract a bunch of data from. I can see why it may be more worthwhile though.

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #20 on Fri 17 Jun 2011 09:53 PM (UTC)

Message

Well, in any set of tasks to be processed in parallel, the best speed you can possibly get is the best speed of the slowest task. According to your tests, Note() is 2ms and your calculations are 0.15ms. That means, in the best case, no matter how you arrange your threads, you will never do better than 2ms. It would be worthwhile if they were both 2ms, since you'd effectively halve the runtime, but 0.15ms is paltry savings.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Candido USA (78 posts) Bio

Date

Reply #21 on Fri 17 Jun 2011 09:56 PM (UTC)

Message

Oh woops. I meant 1.5 ms not 0.15 ms.

Posted by

Candido USA (78 posts) Bio

Date

Reply #22 on Fri 17 Jun 2011 09:58 PM (UTC)

Message

A bunch of numbers were wrong. I edited my post above.

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #23 on Fri 17 Jun 2011 10:00 PM (UTC)

Message

It's better, but when you look at the total time, I don't think it's worth it. Are you optimizing because it looks and feels slow, or just to iron out the wrinkles? Because I'd wait until you really need to before pulling out threads.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Candido USA (78 posts) Bio

Date

Reply #24 on Fri 17 Jun 2011 10:18 PM (UTC)

Message

I'm optimizing because I was getting to the point where short freezes would occur in very spammy situations, and long freezes would occur in artificially spammy situations like sending 1000 commands at once, which I actually have reason to do on a regular though infrequent basis.

2 ms doesn't sound like much, and I'm pretty sure it's considered to be imperceptible to the eye. However, if you get 1000 prompts at once, that's 2 seconds of blocking just from prompt script alone. Now, of course the prompts don't come exactly all at once, so it's a bit more forgiving than that, but that's the gist of it.

People who have run my code on an i7 have been able to send any number of commands at once and not have it freeze, so I'm just trying to clean it up to the point where it will behave like that on my core duo too.

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #25 on Fri 17 Jun 2011 10:26 PM (UTC)

Message

Would you mind posting your code here? There might be easier and more effective optimizations to make first. Sorry, I just don't like to use threads except where absolutely necessary. They tend to cause more problems than they solve.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #26 on Sat 18 Jun 2011 10:35 AM (UTC)

Message

I have tried to use MUSHclient functions from threads in the past. Suffice to say, it is an excellent way to make MUSHclient crash as those functions have proven not to be thread-safe. This makes sense since most GUI frameworks are not thread-safe either.

The best solution is to use a queue for those calls only: if you really need threads for whatever, make sure to post your stuff to a queue that gets emptied by code running on the main thread. I have used this method before and while it is annoying, it works flawlessly. :) For example, you can use a timer to periodically test your queue for items and act on it. That way, the expensive calculations can be off-loaded in their own thread while the display is done in the proper one.

(I freely assume MUSHclient hasn't had tons of prodding happen to make it thread-safe in the last few years. If it has, someone please correct me.)

Posted by

Nick Gammon Australia (23,046 posts) Bio Forum Administrator

Date

Reply #27 on Sat 18 Jun 2011 10:50 AM (UTC)

Message

Worstje said:

(I freely assume MUSHclient hasn't had tons of prodding happen to make it thread-safe in the last few years. If it has, someone please correct me.)

It is not intended to be used under multiple threads.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Candido USA (78 posts) Bio

Date

Reply #28 on Sun 26 Jun 2011 10:21 AM (UTC)

Message

Twisol said:

Would you mind posting your code here? There might be easier and more effective optimizations to make first. Sorry, I just don't like to use threads except where absolutely necessary. They tend to cause more problems than they solve.

Thanks for the offer, but reading through that much vague and uncommented code is not something I'd wish on anyone. All's well in the end though, since by replacing all my GetVariable's with lua variables I managed to get the non-visible processing down to 250 microseconds, which is about equal to the overhead for lua lanes to start a new thread.

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #29 on Sun 26 Jun 2011 10:44 AM (UTC)

Message

Ah, that makes sense. I'm sure it's more costly to hop out of Lua and interoperate with MFC's string class than it is to nab a reference to an already-existing Lua value.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

69,278 views.

This is page 2, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.