I have just some general hardware cpu architecture, memory, bus systems and programming knowledge, but I am abit surprised some people seem to consider multithreading (I guess this is about mirc script-multithreading) as something that has little benefits and only for a minority of the users. I think that is just... wrong or shortsighted.
Argv0 said:
No. The point is that only cpu intensive programming truly benefits from multithreading.
...
From experience, multithreading really is not meant to give speed increases, so you shouldn't expect to see much in speed, only bandwidth
I think he completely missed the point here.
This is not about "cpu intensive programming".
This is not about "making things faster"
This is about programming in such a way that a user can do thing A without affecting the operation of thing B. For example, multithreading with two threads is basically processing task A for a little while, then B, then A again, then B and so on. The operation system assigns time 'slices' to the threads, so its impossible one task prevents another getting a time slice, same way as the mirc application can hang due to a scripted endless loop and you can work further with other applications.
Multithreading benefit could be working on your script in the script editor without being annoyed of sluggish typing responses when mirc has some work due to alot networks, channels or generally, alot irc related work.
Multithreading benefit could be editing settings in a dialog without the same annoyance as above.
Multithreading benefit could be a thread for every connection so a flood or alot activity on one connection could not influence the other connections (no pingouts or sluggish responses, lag there)
Multithreading benefit could be indexing folders on the background without noticing it.
Multithreading could be playing a mirc game with no lag for a bot that runs for some or all connection(s).
Multithreading could be sending alot data through sockets with a speed that isnt cranked down depending on other work mirc has to do.
Multithreading is bringing the benefit of a multitasking operating system to within application level (here: mirc script 'engine' under the mirc application).
NrWarren used a good description:
"its like freeing up another hand for it to do its work"
mIRC is already multithreaded in its innards. I have no idea in which ways, but I saw amount threads going from a dozen till over 700.
So, I like to see this in its scripting engine.
The big question is how realistic this 'oh I like it' is, i.e., the amount work involved, and also the effects it would have on the current scripting ways. mIRC scripting is easy in the way it saves the user from complexities inherent to common programming, and that is the big reason for the large amount scripters. Its well possible the implementation of multithreading takes away a (big?) deal of this benefit. Though, the examples I listed earlier could already be enough.
Suppose an IRC-only script, no common objects with other code, could be inherently (no conditions like now) bound to a connection (seen as a thread only for that connection), that would need little to no multithreading related code, so mIRC could run 5 bots on 5 connections and they would not affect eachother regardless amount IRC activity.
I am busy on a script that has grown over years, a myriad of functions and, being on average on a dozen networks and a mere 60 chans, it is very prone to sluggyness as soon as overall activity raises. I had to use queues for the core functions and I even switch temp-off the two main queues as a sort of time-slicing.
If mIRC would do such things itself, in fast .exe code, that would simply rock. Imagine, a scripted-overhead turned into executable-multithreading.
