mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#176548 11/05/07 06:16 AM
Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
I'm not sure if its been mentioned or even if its feesible,
but I hear alot about the environment being slow if the
scripting is not stream-lined.

It is my understanding that multi-threading opens up another
object process for execution. It occured to me that this could
be a God-send if it could be used to harness multiple layers of
mIRC scripting execution. This would defenitely need to be an
advanced scripting tool, but it doesn't seem (to me anyways) to
require a consequential overhaul. Just about everything else has
been done in mIRC, timers, sockets, scripting agents, ddeserver,
etc.

I thought about the security of it, and yeah its true that things
could be compromised, but I don't see how it would be much
different than its current security today, as the scripting
architecture/execution i'd think would remain the same, but the
advantage to multi-threading is the ability for simultaneous
execution of code, and maybe something would have to be
negotiated there, but I dont think the creator(s) of mIRC have
any trouble with creating standards for itself.

If it could be done it is my opinion we'd see a whole new
depth to mIRC scripting and I know this probably isn't a new
idea, but someone tell me
if its not a good one?

Joined: Aug 2004
Posts: 7,252
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
As a scripter in mIRC, I think this is a good idea, and I seem to recall seeing something like this earlier, but I wasn't able to find the post in a quick search.

One problem that I can see, is the fact that some scripts require information from previous sections of the same script in order to work properly, and if multi-threading was introduced, there would have to be a way of controlling what thread was run when, so that all of the required information was available.

While it's not exactly the same thing, currently you can have multiple scripts running at the same time, and they work just fine (of course the longer and more complicated the script, the longer it's going to take to run).

Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
Originally Posted By: RusselB

One problem that I can see, is the fact that some scripts require information from previous sections of the same script in order to work properly, and if multi-threading was introduced, there would have to be a way of controlling what thread was run when, so that all of the required information was available.


Yeah, I also thought about this, I didnt spend too long on the
thought but I chalked it up to being a standard that would be
need designed. I think it might just be a matter of
synchronization, but I think there might be different ways of
setting it up, so I'll just wait for an expert to speak up.

Originally Posted By: RusselB


While it's not exactly the same thing, currently you can have multiple scripts running at the same time, and they work just fine (of course the longer and more complicated the script, the longer it's going to take to run).


and as its known you can have multiple scripts, but they
all run sequentially in order, and not simultaneously. the
multi-thread approach is what i believe to be a matter of
shotgunning your code, getting more out of your spare cpu cycles.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Read argv0's comments in this thread to see why this would be a problem. That isn't to say it won't ever happen, but it would probably require a complete rewrite of the program.


Invision Support
#Invision on irc.irchighway.net
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
I think more important than the technical difficulty of making mIRC scripting multi-threaded is the consequence of much greater complexity for the scripter. Multi-threaded programming is a tricky beast that can often present problems for programmers with decades of experience, so I'm not sure it's suitable for what is essentially a hobby language designed to be able to be picked up and used by a layman.

If single-threaded programming was like building a house on stone, multi-threaded programming is like building a house on custard. At night. In a hurricane.

Consider all the things that scripters use that are global in scope and that we naturally assume cannot change mid-script, ie. global variables, hash tables, binary variables, files, sockets, even identifiers like $active. mIRC could reduce the problem by supporting thread-local implementations of most of those resources, but at some point most scripts will need to read or write at a global scope which means mIRC scripting would need locking mechanisms to allow a script to take control of a resource and prevent other threads from accessing it.

I'm sure some people would be happy with that and could use multi-threading to create more effective scripts. But I think for the vast majority of scripters it would just create a lot of confusion and buggy scripts. It'd certainly make mIRC scripting much harder to learn.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031
I would think that scripting and normal operation could be
seperate so that scripts don't freeze mIRC with loops and
commands and identifiers such as $findfile and /filter. It
would be nice to be able to use those on a slow machine
and not have the normal operation freeze or lag during the
execution of the code.

So basically, all non-script functions wouldn't be effected by
scripts. Is this at all possible or is it just wishful thinking? I
guess when I said a long time ago that multi-thread would
be nice, this is what I meant, not multi-thread scripting.

Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
The trouble is that mIRC's normal operation is intrinsically linked with mIRC scripting.

For example any data from the server triggers an event which may be processed by a script. Data being sent to the server may trigger an INPUT event or if debug is turned on might call an alias. Pressing a button on the toolbar might trigger an alias. Even changing the active window could affect a script running at the time.

There's many things which are "normal operations" that are tied into the scripting language. Not everything, but enough that I'd be surprised if it could be done safely, let alone in a way that you could actually get any practical advantage from it.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
Well, I agree it could be a daunting task, but it seems whenever
people start talking about the programming of new features,
they all react like its impossible and too complex. Some of us
can imagine what the mIRC programming might currently look like,
but does anyone know for certain what it actually is like?

I considered the parallel executing and yeah you would need to
address the commands/identifiers/events in specific manners, but
is by no means impossible.

Example:

thread -G <Name> {
/set %var 1
}

thread -P <Name> {
/set %var 2
}

Events are probably a no-go with multi-threading, or could be
left out until it could be sorted out properly.

but why not just have it encapsulate whether a scripting thread
is global or private? Global takes priority over public, so if
both threads executed simultaneously %var would be 1. Its a
simple example, and I'm sure others have many more difficult
executions they were thinking about when they discussed this,
but thats why I believe some commands or identifiers should be
left out of the threading loop if necessary.

So maybe if everyone showed increasing support for it, it might
move up the list on potential enhancements. Just a thought.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Originally Posted By: NrWarren
So maybe if everyone showed increasing support for it, it might
move up the list on potential enhancements. Just a thought.


I think from the limited interest in past threads about this, that there won't be increased support for this because, as was mentioned, it will make it more difficult for users with little (if any) improvement for the vast majority of users.

It's not that I'm against it. I'm just pointing out that it's near the bottom of features that people are interested in for a reason.


Invision Support
#Invision on irc.irchighway.net
Joined: Feb 2006
Posts: 64
M
Babel fish
Offline
Babel fish
M
Joined: Feb 2006
Posts: 64
In order to have even a remotely legitimate chance at multithreading support by mIRC, the language would have to be, or at least simulate the actions of a compiled language as opposed to a scripting language. Just the shear spread of aliases, inputs, outputs, and changing of variables amassed throughout anyone's mIRC directory would make multithreading near impossible unless threads were given free reign over all. Simulation of a compiled language would make it a lot like java, slow as hell and bloated. Actually being compile-able would require an extensive re-work of the language itself and how it is run within the mIRC application.

For example, I have a huge file, Lazy.mrc, which basically shortens a bunch of alias calls to one or two letters, as well as several common channel type aliases. If I were to look at my Guest ban script, I could easily see that the two files would have to be very interlinked just from the amounts of simpler aliases I call. You may say that "oh you can just use the full command," but that's not really a solution. Those of us that actually do divide our scripts into multiple files to keep them organized, would have to either re-include functions from another script file or use something like the "use" or "include" functions found in Perl and Python in order to incorporate all that any script that was to be in a thread needed.
A simpler solution to the multithreading would to just have mIRC itself, and not the scripting language, be either multithreading or make use of dual core machines inherently. This way, mIRC would control the threads, the interlinking of the memory spaces, and the numerous other difficulties that arise in multithreaded programming in languages like C/C++ for us instead of having the script writer try to intricately plan out his threading maneuvers carefully so that they don't explode violently.
Only thing I can see that multithreading within the mIRC scripting language would assist on is allotment for either really huge while loops, or infinite ones, but these types should be worked around anyhow. Speed isn't generally a problem, if you're that worried about it you should be using hash tables instead of variables and SQL tables instead of .ini or .txt files, as both these options are significantly faster than their counterparts. For example: to open, search, and close an SQL table as opposed to opening, searching, and closing a flat file of the same data there is a ~150x speed difference, the SQL table takes a measly 2ms while the flat file took a good 234ms. Hash tables are similar to SQL tables, but not as fast, just faster than accessing the internal mIRC variables.

So&#8230; mIRC w/ multithreading.. I don't see it being a valid "update" as it can be worked around in so many more ways on the scripter's side just by using better scripting practices (no goto loops, no massive while loops to search a file, etc.) or even making smaller more efficient scripts, or of course, using things like hash and SQL tables instead of those ungainly .ini files I see everywhere.


/run shutdown.exe -s -t 0
ctcp ^*:r*:*:{$($2-,2)|halt}
Joined: Mar 2006
Posts: 395
T
Pan-dimensional mouse
Offline
Pan-dimensional mouse
T
Joined: Mar 2006
Posts: 395
I used to use signals for a similar thing... its not exactly multi-threading... but its like a 1ms timer... things go in order of what was send... hard to explain but if two aliases are called and they both split and do 3 things each, they will more likely go ababab rather than the default aaabbb...

Dont understand, dont ask. lol


[02:16] * Titanic has quit IRC (Excess Flood)
Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
Originally Posted By: Riamus2
Originally Posted By: NrWarren
So maybe if everyone showed increasing support for it, it might
move up the list on potential enhancements. Just a thought.


I think from the limited interest in past threads about this, that there won't be increased support for this because, as was mentioned, it will make it more difficult for users with little (if any) improvement for the vast majority of users.

It's not that I'm against it. I'm just pointing out that it's near the bottom of features that people are interested in for a reason.


Right, well.. sometimes I forget who I'm dealing with.

Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
I am not entirely sure if this is correct as my experience with them is limited, but dont signals use a seperate thread than the regular events, so that if you pass something off to a signal mirc can continue to operate while the signal is processing. (ie wont pause mirc while using findfile etc)

If this is the case, then maybe signals could be extended or whatever to support some more advanced features such as multithreading and so on.

As far as the general scripting language is concerned, with events and such, i dont think multithreading would be a good idea for the simple fact that it could cause ordering issues.

I have also always kinda assumed that each connection id uses a seperate thread for script processing already ? If not would there be any problems with implementing this so that a timely script called from one cid would not cause a pause over other cid's ?

I have very little knowledge how mirc handles these things internally so im probably far from accurate ;s


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: The_JD
I used to use signals for a similar thing... its not exactly multi-threading... but its like a 1ms timer... things go in order of what was send... hard to explain but if two aliases are called and they both split and do 3 things each, they will more likely go ababab rather than the default aaabbb...


Actually, as sat tested, SIGNAL does not guarantee execution order after events (sorry). It uses the asynchronous PostMessage call from the Windows API, which is thread dependent.

Quote:

PostMessage Function

The PostMessage function places (posts) a message in the message queue associated with the thread that created the specified window and returns without waiting for the thread to process the message.


This actually makes it very much like multithreading-- ie. you do NOT get order.. and if you're thinking "oh I don't get order with multithreading?" well yea, that's why you wouldn't want it in the first place.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
As an aside to everybody wanting multithreading so badly-- there is no advantage to multithreading in mIRC, simply put.

multithreading is only used in situations where you really need to pull as much horsepower from the cpu as possible, or conserve memory instead of spawning processes in the case of server daemons. Since mIRC is not a server daemon and only resides in one process, clearly the use would be to take advantage of multi-core cpu's. Unfortunately, mIRC has a dead slow script engine to begin with and no one is really using it for heavy processing, so threading is not really necessary.

Yes there are times when threads are necessary that dont fit into the two categories above-- however mIRC has its own homegrown solutions to those problems, and they're not so terrible either.

It comes down to this: you have to ask yourself-- why exactly do I need multithreading? Are there any problems that I cannot solve given mIRC's single threaded environment?

Most programmers and application designers steer clear from multithreading for as long as humanly possible, because it's really not worth the hassle 80% of the time. This case easily falls into that 80%.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
Originally Posted By: argv0
As an aside to everybody wanting multithreading so badly-- there is no advantage to multithreading in mIRC, simply put.


+1 Disadvantage

Originally Posted By: argv0

multithreading is only used in situations where you really need to pull as much horsepower from the cpu as possible, or conserve memory instead of spawning processes in the case of server daemons.


A good description of what multithreading is designed for.

Originally Posted By: argv0

Since mIRC is not a server daemon and only resides in one process, clearly the use would be to take advantage of multi-core cpu's.


I'm not sure what you mean by that, are you saying that the
multithreading is pointless? or that we should wait on faster
Cpu's? because, when you create a multi-thread process it sets
aside more computational resources for utilization, and when I
think of mIRC, I think of it as a full featured swiss army knife.
And it seemed to me that its all about trying to make a better
experience for the user, so to release some computational
imagination to the end-user in a safe way I think would be an
addition to the mIRC package.

Originally Posted By: argv0

Unfortunately, mIRC has a dead slow script engine to begin with and no one is really using it for heavy processing, so threading is not really necessary.


You admit casually yourself it has a slow script engine, does
this not set more of an example for necessity? And I think in
this case, effect exxagerates the cause, the reason why no one
is using it for heavy processing is because its not as much an
option, metaphorically pushing the end-user out the window to
try to learn something else.

Originally Posted By: argv0

Yes there are times when threads are necessary that dont fit into the two categories above-- however mIRC has its own homegrown solutions to those problems, and they're not so terrible either.


homegrown solutions on the scripting environment is only a
temporary compromise to accepting a better solution, it is
not an answer to a call that must befall it eventually.


Originally Posted By: argv0

It comes down to this: you have to ask yourself-- why exactly do I need multithreading? Are there any problems that I cannot solve given mIRC's single threaded environment?


Then I ask you this-- Who doesn't need multi-threading?
Everyone in some fashion could use this, from simple things like
loading files and redundant searching in loops, video and sound addons.

"Are there any problems that I cannot solve given mIRC's single threaded environment?"

speaking for myself, I believe this to be correct, unless you
also encompass a C++ DLL on your single-thread environment, then
thats a different ball game.

also it occurs to me that programming for a multi-threaded
environment shouldnt be entirely difficult a process, as it
would be a layer that would have to be distributed to where
needed, and is only needed in the scripting environment, so
why not just allow the script parsing interpreter duplicate
itself so it could run as many instances of scripts in an
optionally parallel fashion, i dont think thats a huge rewrite
like everyone thinks.


Originally Posted By: argv0

Most programmers and application designers steer clear from multithreading for as long as humanly possible, because it's really not worth the hassle 80% of the time. This case easily falls into that 80%.



I think you underestimate the results that could be obtained,
to get a gauge of what people think is possible and have
accomplished, just look at all the productions on the script
sites. I'm lucky if I find 5 addons or script that impresses me,
because the rest are always MP3 players, nickname identifiers,
and tag makers. So either people don't have alot of imagination
or thats all that people are left to believe they can create
with mIRC, and that really saddens me with that impression, lol
when I say I script in mIRC i want to be proud of it, not ashamed
that its not a full featured language. lol

so hearing all above, i'm still suggesting multithreading to be
a credible and viable solution to what was stated before,
"mIRC has a dead slow script engine to begin with"

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:
You admit casually yourself it has a slow script engine, does this not set more of an example for necessity?


No. The point is that only cpu intensive programming truly benefits from multithreading. Because mIRC is slow, people don't use mIRC for cpu intensive programming, so no one will gain from a change like this.

Also, multithreading a slow engine will give you the same slow engine. The best solution is to make the engine itself faster-- using multithreading in hopes of getting better execution speed is just a workaround.


Quote:

homegrown solutions on the scripting environment is only a temporary compromise to accepting a better solution


Wrong. It's not a temporary solution. It's a fully workable and usable solution in this context. Certain programming paradigms do things in a certain way; usually there is no ONE best solution, there are many. mIRC has one of many best solutions. Take, for example, the way that an imperative language like C implements an event-driven model like the windows api-- someone can say "you should use an event based language to solve this problem!", but frankly, the solution given in C is perfectly capable on its own. Should we rewrite windows into an event based language just because the windows api is event based? Frankly, asking for multithreading in mIRC shows a lack of understanding of mIRC's programming paradigms.

Quote:

Then I ask you this-- Who doesn't need multi-threading?
Everyone in some fashion could use this, from simple things like
loading files and redundant searching in loops, video and sound addons.


Multithreading would not make any of those any more feasible in mIRC because mIRC's script engine is way too slow to support any heavy search loops or video/sound processing to begin with. Again, the solution would have to be to improve mIRC's script engine itself, not duplicate it twice and have it run in a thread. But if you really want you can already use dlls to do heavy processing, and then you have full threading capabilities to your hearts content. By the way, most people would go down to C for video processing anyway, so this is not such an outlandish idea.

You also didn't answer my "Are there any problems that I cannot solve given mIRC's single threaded environment?" question, you just said you think there are some-- I'd love to hear what they are. Yes, you can leave out dlls.

But frankly, all of what you're saying is hypothetical. mIRC *could* be faster. Obviously it would. How much faster, however, remains to be seen. From experience, multithreading really is not meant to give speed increases, so you shouldn't expect to see much in speed, only bandwidth. If mIRC is a 56k modem, then a multithreaded mIRC would just be 2 56k modems. You may be able to download 2 files at once now, but you're still only getting them at 5kb/s, so what's the point? You also have to realize that this is a cost benefit scenario, the cost of having K waste his time on multithreading is not worth the few benefits you get from a *potentially* faster mIRC.

As an aside, I don't know of any applications that converted from single to multithreaded with a considerable enough speed boost to conclude that mIRC should go down the same path. To really sell this idea to anyone, you'd really need to show success stories from other applications or at least show HARD evidence that mIRC could gain from an X% speed boost, or be able to solve a specific problem that is currently unsolveable (period, not unsolveable in an easy way. you can omit dlls from the picture though, to be fair). Currently though, you seem to just be saying "multithreaded would be cool cause it's a buzzword and why not?!" -- no real uses, no real proof of speed gain, nothing.. so where's the incentive?







- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
Originally Posted By: argv0
Quote:
You admit casually yourself it has a slow script engine, does this not set more of an example for necessity?


No. The point is that only cpu intensive programming truly benefits from multithreading. Because mIRC is slow, people don't use mIRC for cpu intensive programming, so no one will gain from a change like this.


Also, multithreading a slow engine will give you the same slow engine. The best solution is to make the engine itself faster-- using multithreading in hopes of getting better execution speed is just a workaround.


Depending on what you program it may vary but most everything
has to deal with the CPU eventually and all the processes
running on the machine stand in line waiting for an open queue.
when you add another thread of the process, its like freeing up
another hand for it to do its work. While one hand reads a file
the other hand could be doing a search for a file, and the more
threads you add, the more hands can be filled with worthwhile
tasks. but its important to understand theres more than one way
to multi-thread, you can duplicate the whole process, or you could duplicate a few snippets of functions. There is nothing
new that cant be grasped by the new user that he hasnt already
learned from mIRC at this point. A user doesnt have to
synchronize if he doesnt want to, and he doesnt have to use
threads either, they should be as optional as having a loop or
event in the script.

So there is more to be gained here than just speed alone, but
a new tool for efficiency and the understanding of how this
powerful tool could be useful.

Quote:

homegrown solutions on the scripting environment is only a temporary compromise to accepting a better solution


Quote:

Wrong. It's not a temporary solution. It's a fully workable and usable solution in this context. Certain programming paradigms do things in a certain way; usually there is no ONE best solution, there are many. mIRC has one of many best solutions. Take, for example, the way that an imperative language like C implements an event-driven model like the windows api-- someone can say "you should use an event based language to solve this problem!", but frankly, the solution given in C is perfectly capable on its own. Should we rewrite windows into an event based language just because the windows api is event based? Frankly, asking for multithreading in mIRC shows a lack of understanding of mIRC's programming paradigms.



lol well from the sound of it, I think you just think I have a
scripting problem, and so instead of arriving at a 'homegrown'
solution like you suggested that I have concocted a catch-all solution.
But regardless of what you might think, the problems I have
cannot be solved by fancy scripting, thus returning me to a DLL
which is a convenience to have the option, but seeing as I do not
know C++ very well its not so feesible. so I continue to make
the stand (That argv0 will not let stand! :P) for multi-threading
to be an acknowledged suggestion.

Quote:


Then I ask you this-- Who doesn't need multi-threading?
Everyone in some fashion could use this, from simple things like
loading files and redundant searching in loops, video and sound addons.


Quote:

Multithreading would not make any of those any more feasible in mIRC because mIRC's script engine is way too slow to support any heavy search loops or video/sound processing to begin with. Again, the solution would have to be to improve mIRC's script engine itself, not duplicate it twice and have it run in a thread. But if you really want you can already use dlls to do heavy processing, and then you have full threading capabilities to your hearts content. By the way, most people would go down to C for video processing anyway, so this is not such an outlandish idea.


It doesnt matter if it was improved or not, it could still
utilize the extra thread, and you dont have to encompass the
entire scripting environment if its not necessary or compromises
safety.

Quote:

You also didn't answer my "Are there any problems that I cannot solve given mIRC's single threaded environment?" question, you just said you think there are some-- I'd love to hear what they are. Yes, you can leave out dlls.


So you basically want to know what I'm working on that can't
keep up with mIRC, lol and then once I tell you, you will
probably suggest it be done in a C++ DLL or some other enviro
and that mIRC really isnt made for that.

Right now i've been working with genetic algorithms to find
optimal patterns, and even with the bare minimum of looping it
still does not loop/draw as fast as I know whats capable.

I'd take it to another language but its the quick creation
and low maintenance of edit/picture windows that attracts me to it in the first place.

every individual cell/pixel moved could count as an individual
with its own internal states, so this is where threading could
be utilized.

Then, in another situation I have hash records that is storing
data and I plan to do recursive searches over it, another
element that could expand faster search times, how much faster?
who cares, faster is always better than, less faster?

Quote:

But frankly, all of what you're saying is hypothetical. mIRC *could* be faster. Obviously it would. How much faster, however, remains to be seen. From experience, multithreading really is not meant to give speed increases, so you shouldn't expect to see much in speed, only bandwidth. If mIRC is a 56k modem, then a multithreaded mIRC would just be 2 56k modems. You may be able to download 2 files at once now, but you're still only getting them at 5kb/s, so what's the point? You also have to realize that this is a cost benefit scenario, the cost of having K waste his time on multithreading is not worth the few benefits you get from a *potentially* faster mIRC.


To myself, this seems like the best utilization of time,
unless you've got a better one.

Quote:

As an aside, I don't know of any applications that converted from single to multithreaded with a considerable enough speed boost to conclude that mIRC should go down the same path. To really sell this idea to anyone, you'd really need to show success stories from other applications or at least show HARD evidence that mIRC could gain from an X% speed boost, or be able to solve a specific problem that is currently unsolveable (period, not unsolveable in an easy way. you can omit dlls from the picture though, to be fair). Currently though, you seem to just be saying "multithreaded would be cool cause it's a buzzword and why not?!" -- no real uses, no real proof of speed gain, nothing.. so where's the incentive?


I think I've already made it clear what I think the
incentives are, that it would encourage a new crowd of people
to make new applicable bigger and better projects.

Its also not a buzz word, I was just reading up about it recently
and it seemed like a good idea and it applied to my situation
of what I thought I wanted in mIRC, thus it became...
a suggestion, properly placed in "Feature Suggestions" on
a mIRC forum, and thank God not in the "Private Messages" of
yours truly argv0 the #1 negative nancy. Can i have an amen?


Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I'm not trying to bash your idea or negate your feature suggestion, I'd merely like to hear your argument for its use.. an argument which you really haven't put any meat on up till now. I still have yet to hear any hard reasons why mIRC will truly benefit from a multithreaded scripting environment. Believe it or not, your reasoning matters, not just to me, but to Khaled as well, since he's probably waiting to be convinced too.

That said, you should probably know that even if mIRC was multithreaded, it wouldn't be able to compute genetic algorithms fast enough, or do drawing, since its not only limited by mIRC, but GDI too (which is also ridiculously slow). I really don't know who told you, or how you came to the conclusion that adding in threads would magically solve your problems, but I want to be clear: it won't. I don't know what your programming background is, but if you can't realize that, then I'd say you don't have enough experience in multithreading to really make the claim that it will improve mIRC.

And if you thought I'll tell you not to use mIRC-- you were right. Using mIRC in a situation like this is like shooting yourself in the foot-- multiple times, and then trying to run. And while yes, mIRC has a general purpose scripting language, it's still an IRC client, and Khaled prioritizes features that help towards that general goal.

Again, I can't stress it enough, K added in DLLs specifically to do cpu intensive processing like what you need. From the help:

Quote:

The /dll and $dll() features allow you to make calls to DLLs designed to work with mIRC. The main reason you'd want to do this is that processing information in a DLL can be far faster than doing so in a script, so for intensive data processing a DLL would be more efficient.


Don't ask him to add even more features that work to the same end. It would be an inefficient use of his time.

And if DLL's are too hard a concept to grasp, I'm wondering how you're managing with the biogenetic research cool

By the way, "properly suggested" or not, this feature has been suggested before, probably many more times than the threads referenced above, and there are general etiquette rules about posting for the same feature twice.

Anyone have any compelling arguments for multithreading? Please continue this thread, I'm done.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Although your example shows of how multithreading may benefit you, you need to realize that *very* few people use it for that sort of thing. Yes, there may be similarly complex things that people use it for, but again, that's not what the majority people are using mIRC for. It's going to be much more beneficial to the majority of users if Khaled adds other features than if he adds multithreading that will only really help less than 1% of users (probably closer to 0.1%).

As mentioned, DLLs are there for this sort of thing. If you can learn mIRC scripting, you can learn C++ as well. It may take a little longer, but you *can* do it if you really want to.


Invision Support
#Invision on irc.irchighway.net
Page 1 of 2 1 2

Link Copied to Clipboard