First, it's mentioned that mIRC script on default runs as a single thread. Does this also imply that if you run a mIRC bot on a Quadcore, it only uses at most a quarter of the processor's raw processing power?
Yes.
Second, if you use external .dll files like mthreads.dll to create additional threads, would these threads also run on the same part of the processor, or would they be able to trigger other parts of the processor, causing a gain in speed on Dual- and Quadcores?
Any threads spawned from a DLL would be eligible for scheduling on all 4 cores. So yes, you can get speed increase from using a dll-- HOWEVER,
This speed increase only applies to the processing done inside your dll (outside of mIRC). Once you start touching mIRC (SendMessage, etc.) you are thrown back into mIRC's single thread. You also have to take care, when using such a threaded DLL, to make sure that you properly synchronize threads. Manipulating mIRC in multiple threads (without proper locking) can easily cause mIRC to crash.
Third, does anyone have any experience with mthreads.dll? The documentation is very limited, though the accompanying mIRC code is clear enough. What about version compatibility?
I cannot answer this. I would guess that the dll is a very low level API over pthread or Windows' threading API, and you can probably find much more documentation on MSDN.
Fourth, if you run separate threads, you of course have to make sure that you're not working with the same variables, since that would screw up your own data results. But what about addressing the same hash table. If I'm using a "$hget(MyTable, ValueA)" in one thread, and a "hadd MyTable ValueB 100" in a parallel thread, does a chance exist that while the $hget of the first thread is executing, the hadd of the second thread is being triggered?
Again, it depends how you do it. You would need to create semaphores or mutexes around all of your data accesses, though. This means if your dll does nothing but interact with mIRC, you will basically see no speed increase, because you will constantly be locked in a single thread (you might even see a speed decrease from that). With SendMessage, your thread is going to block until mIRC returns the data anyway (see the remarks on
SendMessage threading), so theres no synchronization needed there-- but of course there's no threading done there either (it's essentially going to lock you into one thread again).
Perhaps the chance of that would be kind of small, but possibly a more practical example: I'm running a bot that stores quite a bit of data in hash tables. To prevent the data from disappearing due to a power loss, I hsave all the hash tables every 10 minutes. This causes mIRC to "freeze" for a good 3-4 seconds every 10 minutes.
Now, if I would use mthreads.dll for saving the data, I shouldn't notice the "freeze" effect, correct? But could there be a problem if another script would be writing data to one of those hash files during that time? I wouldn't mind if that single entry wouldn't be stored (after all, it wouldn't be stored during serial processing), but could it corrupt the data being saved to the harddisk?
I don't know enough about mthreads.dll to comment. It looks like it just separates the script engine from the UI. mIRC will continue to look active but the script layer will be blocked. This may have unwanted consequences, though I'm not sure exactly what. I wouldn't recommend using it, in general.
If it's taking 3-4seconds to save, you've probably outgrown hash tables, or at least outgrown using a single hash table. As I mentioned earlier in the thread, you probably shouldn't be loading all of your data directly into memory if this is the case. You should consider using sqlite or some data store with the ability to index your data and optimize lookups without requiring everything in memory. This would also guarantee persistence, too (no 10 minute timer needed for saving data).
Alternatively you can use multiple hash tables-- one for persistent read-only data storing the bulk of the data but only saved on exit, and one hash table for new and modified entries that were added in your current session only. That table would be much smaller and would be the one that was saved every 5-10 minutes. When you close mIRC (or force a flush to disk) you would move the data from the "current session" table to your persistence table and store that.
