34 replies to this topic

[krejic]

I admit I indirectly questioned your programming skills. But at the same time, you admit that your scripts could use optimisation. Isn't it a little early then to ask for 'multi-core support' then?

I don't know, support can't hurt anybody. And better to much performance than to less performance. Right?
And what do I have to loose?

But that's not the point.

I agree.

Your 'argument' for the case is simply stating it is useful while you ignore my arguments that it doesn't have a point because it would make Game Maker very complex and unfriendly to use, that there are some built-in alternatives and, most important of all, there doesn't seem to be be much room for it's implementation because threads run at machine code level rather than GML script level.

I didn't ignore your agruments in my vision but okay.
So GM would be to complex if it supports dualcore?
That's kinda strange because I thought there is a way so let the executable work on both cores.
Windows automatically balances it to the cores if the support is there.

But if you say so, I guess you're right. You're the Smarty and closest to Gamemaker itself.

If you wish to uphold the argument for multi-core support, then I would appreciate it if you address the points I made.

Hmmm... couldn't hurt... but okay, what do you expect from me then?

Give me a percentage of how many home players have multiple-core processors or systems. 'Many' isn't a valid qualification. It's not even an argument. Just because it's there, doesn't mean it's useful or that it has to be used.

At home we have 2 of the 5 PC's with dualcore.
My upcoming laptop get's dualcore.
My friends have all dual and quadcore's.
At this moment, I don't know many people who still have singlecore (no joke).
But I guess that i'm in the range of hardcore gamers.

Most people still have singlecore but because Intel's Core 2 Duo processors it will get higher and higher. The future looks bright for the multicore.


Any way, thanks for the answers Smarty!

Edited by krejic, 18 December 2007 - 12:11 PM.

[paul23]

Let me ask you something. What do you know about my knowledge?

I admit I indirectly questioned your programming skills. But at the same time, you admit that your scripts could use optimisation. Isn't it a little early then to ask for 'multi-core support' then?

But that's not the point.

Your 'argument' for the case is simply stating it is useful while you ignore my arguments that it doesn't have a point because it would make Game Maker very complex and unfriendly to use, that there are some built-in alternatives and, most important of all, there doesn't seem to be be much room for it's implementation because threads run at machine code level rather than GML script level.

If you wish to uphold the argument for multi-core support, then I would appreciate it if you address the points I made.

I may be not a professional but it's nice to discuss about some good support for future use?
And why not? Many people have dual- or quadcore already!

Give me a percentage of how many home players have multiple-core processors or systems. 'Many' isn't a valid qualification. It's not even an argument. Just because it's there, doesn't mean it's useful or that it has to be used.

<{POST_SNAPBACK}>

Well I can think of a way it might be implemented: create some extra special resource (like a scripts) which gm performs on a seperated cpu. Now it's up to the programmer to make sure it doesn't use any "global" variables - only those which are initialized at the scripts' start. (and gm might actually split those two things visually apart using tabs: init/declaration and the actual code - initializing would be "performed" on the first cpu and then all data will be sent to the second cpu to handle the processor unfriendly computations). Then there could be some other event which would be triggered if the second cpu was ready with it's script. (so as overhead gm actually needs to check a certain variable every step to see if the cpu is ready.) .

It's then the programmers responsibility to use only non-global (well if you want to use globals be my guest, it might actually make a pretty funny/random game if used correctly) variables. Also it might make gm a bit more difficult since declaration/initialization is splitted.

So it IS possible to implement I think. However the usefullness isn't too high. -However using 2 or 1 core for the actual game will make a difference in the way the program works - and will give differences in gameplay.


and about percentages: well I think 90% of the nowadays NEW computers are multicore. - So in a year or 2-3 I think 75% of all computers will be multicore.

[krejic]

I totally agree with paul23.
Else there wasn't dualcore on the market. It is faster and you can seperate CPU eating scripts like my AI which can't be more optimized.

[Smarty]

Well I can think of a way it might be implemented: create some extra special resource (like a scripts) which gm performs on a seperated cpu. Now it's up to the programmer to make sure it doesn't use any "global" variables - only those which are initialized at the scripts' start.

You're only thinking of variables. There are hundreds of script commands that are thread-unsafe, not just because of the parameters they require but also because of what they do - to name but one, those relating to the state of an instance. A single execution of one of those commands in a threaded environment can disrupt the logic of the engine's processes. That doesn't leave you with a lot of GML to work with.

GML is not thread-safe, period. It's not going to work.

(and gm might actually split those two things visually apart using tabs: init/declaration and the actual code - initializing would be "performed" on the first cpu and then all data will be sent to the second cpu to handle the processor unfriendly computations). Then there could be some other event which would be triggered if the second cpu was ready with it's script. (so as overhead gm actually needs to check a certain variable every step to see if the cpu is ready.).

There are many more issues to be covered.

Is the thread called from a script? Does it get a return value? Does the script that calls the thread continue or wait for the return value? Who or what is owner of the process, the instance that calls it? What happens if the instance that called the process was destroyed in the meantime? What happens if the result triggers an event, and no event can be triggered? What happens if the room or the game ends before the threads end? What happens if one thread calls another thread, should the calling threads wait for the other? Can threads be terminated? Who is responsible for cleaning up after the thread, when it is killed or it's owner is lost?

and about percentages: well I think 90% of the nowadays NEW computers are multicore. - So in a year or 2-3 I think 75% of all computers will be multicore.

<{POST_SNAPBACK}>

Yes, and (quoting Yourself) 90% of statistics are made up on the spot.

Else there wasn't dualcore on the market.

I wasn't arguing that there is no purpose for multiple-core or multi-processor systems. I was arguing that GM, and GM users in particular, could benefit from it. GM wasn't designed to.

It is faster and you can seperate CPU eating scripts like my AI which can't be more optimized. 

<{POST_SNAPBACK}>

Which you can't optimize more.

[krejic]

I wasn't arguing that there is no purpose for multiple-core or multi-processor systems. I was arguing that GM, and GM users in particular, could benefit from it. GM wasn't designed to.

That reaction was ment for Paul23.

Which you can't optimize more.

I guess, Smarty

Edited by krejic, 18 December 2007 - 09:14 PM.

[paul23]

You're only thinking of variables. There are hundreds of script commands that are thread-unsafe, not just because of the parameters they require but also because of what they do - to name but one, those relating to the state of an instance. A single execution of one of those commands in a threaded environment can disrupt the logic of the engine's processes. That doesn't leave you with a lot of GML to work with.

GML is not thread-safe, period. It's not going to work.

Well that's the programmers responsibility, but even for these "few" commands -The commands you would also be able to put in a dll- it can be very usefull to use another thread. - now that I think about it, in my vision this actually looks a lot like dlls: they should be "seperated" programs in fact, and just like dlls they shouldn't be able to change any environment! Maybe as a smaller feature gm should be capable of only using dlls for threads?

(and gm might actually split those two things visually apart using tabs: init/declaration and the actual code - initializing would be "performed" on the first cpu and then all data will be sent to the second cpu to handle the processor unfriendly computations). Then there could be some other event which would be triggered if the second cpu was ready with it's script. (so as overhead gm actually needs to check a certain variable every step to see if the cpu is ready.).
There are many more issues to be covered.
Is the thread called from a script? how are dlls called? Does it get a return value? what other point is there if it doesn't return anything? Does the script that calls the thread continue or wait for the return value? what's the point of using another thread, if the script waits till the thread is finished? Who or what is owner of the process, the instance that calls it? This is an interesting problem, I think best would be using a "global" controller (the game) so the core doesn't get "flooded" What happens if the instance that called the process was destroyed in the meantime? what happens to surfaces, datastructures etc. if the contaigning variable gets destroyed? What happens if the result triggers an event, and no event can be triggered? well it shouldn't be able to trigger real "events" - only the "thread finished" event in the calling instance (possibly with an thread-id so also 3+ cores can be handled) What happens if the room or the game ends before the threads end? again what happens with surfaces etc? What happens if one thread calls another thread, should the calling threads wait for the other? again an intersting problem, I can't think of an easy solution other than that it simply can't be possible Can threads be terminated? that's up to yoyogames Who is responsible for cleaning up after the thread, when it is killed or it's owner is lost?who is responsible forsurfaces etc?

Well these aren't real "issues" I rather name them "decisions to be made" (see bold for my "suggestions").

Yes, and (quoting Yourself) 90% of statistics are made up on the spot.

true, though I think this describes it even better: "There are three types of lies - lies, damn lies, and statistics.". So there's no real point in waiting till the "majority" has it: simply add it when it's usefull and necessary! (but wether that's now or some point in the future or maybe never? I don't know!)

Edited by paul23, 19 December 2007 - 01:55 AM.

[Skarik]

So - give me a Game Maker example in which a multi-core (and therefore multi-threading) engine would be useful. If you're going to start again about things being faster, then you're still fine with a single-core CPU.

I'm going to be a jerk and say this:
It could make my game go faster!

Wait, I've got one! It can let me finally complete my Pie fractal! It's a fractal that draws a piece of chocolate coconut fudge haupia pie!

Is this spam? If it is, I must only have two strikes! Right?

I thought I'd like to say that when I get into an infinite loop in GM, the task manager says my first CPU is at 50% use and the other CPU is at 25% use.

Also, did you notice that the original topic creator has only posted once and then seemingly not come back?

So just for the heck of it, I'll go back on topic!

1) Yes
2) No
3) Not at the moment

I've think that the questions have been answered several times and really, reading this kind of stuff is a lot more funny than doing my history project. Can't you guys argue about it over PM? I thought - nvm, this is the GMC.

Nothing against the rules.

I probably should have never posted this, but then again, why not?

Edited by Skarik, 19 December 2007 - 03:14 AM.

[Sapidus3]

I do have to say there are times that more direct multi-threading support would be useful.

That said it would be unreasonable to expect it to be useful to all but some of the more experienced coders.

There still seems to be some confusion in this thread.

You can have a program that uses up all of the capacity of one of your cores, but there is no magical process that suddenly allows it to use the other core and double its speed. Multi-threading doesn't make things just go faster.

Asking for GM to have easy to use support for this is also unreasonable. It may be possible, but I would say at great difficulty and that there are other things more worth the time investment in GM.

One of the things I've done over the past years is work to get programs to run on super computing clusters. It is no easy task, and tracking down bugs is ten times as difficult. The degree of coordination and oversight that is needed is not something that is simple to automate, nor is it something that beginners should be trying, though if the feature was in it would be tempting.

This actually becomes much more feasible when each "core" has access to its own dedicated memory, storage device, and copy of the program data. You can then have a 'master' core coordinating and averaging the results you get. But this is beyond a PC dual core setup.

One important thing to realize is that you are getting a benefit out of your dual core processor already while you are running it. Make a program with an infinite loop, run it, then try opening your web browser. You will notice something interesting, it actually works. Your program may only be able to use one core, but the other core is still doing stuff as well. Most computers are running dozens of other processes other than your program that will all be dumped on your other core.

Probably the most important fact though is that while, for some people, in certain circumstances support might be nice, its not needed. Every time I have wished for this I have found some other way to go about it. If you are simply wishing your program would run faster then there are two big solutions. Look at your code, usually the best code can still be optimized. Try writing things out on paper of whats actually happening. I would say its not uncommon that you could reduce code to as little as 20% of what it originally was. Perhaps more important though, if you feel that it is really limiting you, begin to look for another solution. For any problem there are usually multiple answers and there are usually better approaches if you look hard enough.

Ok enough rambling.

[DZiW]

Hi guys,
So much wording...

1) why shoud one care about the possibility of multy-core/threading tech use?
If you need to utilize ALL cpu power then just run DOS,*NIX, or close all apps and try REAL-TIME priority with ALL cpu affinity; either use proper software.

2) If you need JUST to know then you may be pretty sure that almost every USER does know it
Cheers

[Smarty]

Indeed the terminology between threaded applications and multiple-core operating systems had not been pointed out sufficiently. I introduced the concept of threads here as it is a vital property for applications to divide their workload between cores. Perhaps that wasn't clear.

So, good post Sapidus3. I wouldn't call it rambling.

[lethman427]

Anyway, I love to see that GM get's multicore support!

<{POST_SNAPBACK}>

And I think you don't know what you wish for. It seems people here mix it up with having a computer with better performance, but there is a huge difference between doing multiple things at the same time and doing things faster.

So - give me a Game Maker example in which a multi-core (and therefore multi-threading) engine would be useful. If you're going to start again about things being faster, then you're still fine with a single-core CPU.

One scenario I can think of is a server. Multi-threading would allow you to receive multiple packets and execute them. As well, pretty much anything that involves external data would benifit from multi-threading. For example, loading a level in a game, you could load all the models while at the same time loading the level data. Just my opinion though.
Cheers,
~Lethman~

[HaRRiKiRi]

You do know that you bumped a 4 year old thread... also, any game with physics is a good candidate for multitreading.

Anyway, I love to see that GM get's multicore support!

<{POST_SNAPBACK}>

And I think you don't know what you wish for. It seems people here mix it up with having a computer with better performance, but there is a huge difference between doing multiple things at the same time and doing things faster.

So - give me a Game Maker example in which a multi-core (and therefore multi-threading) engine would be useful. If you're going to start again about things being faster, then you're still fine with a single-core CPU.

One scenario I can think of is a server. Multi-threading would allow you to receive multiple packets and execute them. As well, pretty much anything that involves external data would benifit from multi-threading. For example, loading a level in a game, you could load all the models while at the same time loading the level data. Just my opinion though.
Cheers,
~Lethman~

[loverock125]

One reason why multi-threading would be useful would be a mini-game in the loading screen (You know, one of those tic-tac mini-games that keep the user busy while the game is loading).

You can do that with 1 thread but you would have to update the screen once in an amount of steps in the code which would dramatically slow down the loading process and may also affect the performance of the mini-game since you can't be sure when to update the screen (And when to handle user input).

Edited by loverock125, 13 May 2012 - 02:01 AM.

[RevenantGhost]

Multi-threading is good for whatever needs long time (loading, creating a model, etc.) without freezing the game, i was reading it and then i noticed is so old xD Anyway almost every computer now is dualcore or quadcore, all the people i know have a quadcore, even my grandma (not kidding) and yea that would make GM harder for beguinners but is not a problem as soon as multi-threading is avaible only for users that purchased the pro version. Beguinners should stay with lite, as soon as they are good enough they can have all the good stuff from the pro and the multi-threading too. So i dont get why dont add it... GM is slow as hell and there's nothing to do about that, i think; but multi-threading atleast would make the game do more things in the same moment, fixing this issue. I know there's strong single-core processors, even 3ghz+, but a 2.6ghz quadcore or dualcore is better than a single-core 3ghz; a GOOD single core processor is like a man with a single BIG leg xD and a normal quadcore processor is like a man with 2 normal legs, the one with a single BIG leg will jump higher than the one with 2 normal legs, but the 2 legged one is able to walk, run, dance or wathever, things that the single legged one will never be able to do.
I think that the multi-threading is the main lack of GM, i hope to see it in GM 9

[theloon]

Hmmn? Has everyone forgotten about the gmthreads extension?
http://gmc.yoyogames...howtopic=390517