[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  The Cost of Note()
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: The Cost of Note()
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sun 26 Jun 2011 10:44 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Candido   USA  (78 posts)  [Biography] bio
Date Sun 26 Jun 2011 10:21 AM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,800 posts)  [Biography] bio   Forum Administrator
Date Sat 18 Jun 2011 10:50 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Sat 18 Jun 2011 10:35 AM (UTC)  [ quote  ]
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.)
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 17 Jun 2011 10:26 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Candido   USA  (78 posts)  [Biography] bio
Date Fri 17 Jun 2011 10:18 PM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 17 Jun 2011 10:00 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Candido   USA  (78 posts)  [Biography] bio
Date Fri 17 Jun 2011 09:58 PM (UTC)  [ quote  ]
Message
A bunch of numbers were wrong. I edited my post above.
[Go to top] top
Posted by Candido   USA  (78 posts)  [Biography] bio
Date Fri 17 Jun 2011 09:56 PM (UTC)  [ quote  ]
Message
Oh woops. I meant 1.5 ms not 0.15 ms.
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 17 Jun 2011 09:53 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Candido   USA  (78 posts)  [Biography] bio
Date Fri 17 Jun 2011 09:44 PM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 17 Jun 2011 09:40 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Candido   USA  (78 posts)  [Biography] bio
Date Fri 17 Jun 2011 09:35 PM (UTC)  [ quote  ]

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.
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 17 Jun 2011 09:25 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Candido   USA  (78 posts)  [Biography] bio
Date Fri 17 Jun 2011 09:07 PM (UTC)  [ quote  ]
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.
[Go to top] top

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.

4,972 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]