Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nordak]

+BUMP+

I'm going to start looking into multithreading this game.  No promises, I don't know if I'll make it back out sane...

[thijser]

Has anybody tried to use a simmulator to make df work in multicore yet?

[G-Flex]

+BUMP+

I'm going to start looking into multithreading this game.  No promises, I don't know if I'll make it back out sane...

Er, how? You can't magically parallelize a game that isn't programmed to run in a multithreaded fashion. You can't perform miracles, nor do you even have the source code.

Has anybody tried to use a simmulator to make df work in multicore yet?

I'm not sure how you think this would work, but you can't do that. Short story: It just doesn't work that way.

[thijser]

+BUMP+

I'm going to start looking into multithreading this game.  No promises, I don't know if I'll make it back out sane...

Er, how? You can't magically parallelize a game that isn't programmed to run in a multithreaded fashion. You can't perform miracles, nor do you even have the source code.

Has anybody tried to use a simmulator to make df work in multicore yet?

I'm not sure how you think this would work, but you can't do that. Short story: It just doesn't work that way.

There are programs that are able to "fool" your system into thinking it's 2 4 or 8 cores are really one. This is of course at a great loss of performance but it could be usefull to research for df.

[G-Flex]

No, it wouldn't. You aren't getting the point.

It doesn't matter if you "fool" your system into thinking it has 16 cores. Hell, it doesn't matter if your system actually has 16 cores. DF will still only run on one.


DF won't run in a parallelized fashion, period.

Also, fooling your computer into thinking your single-core CPU has two cores won't make anything actually run in parallel, even multithreaded programs, because you still only have one actual core to work with.

[Brightgalrs]

There are programs that are able to "fool" your system into thinking it's 2 4 or 8 cores are really one. This is of course at a great loss of performance but it could be usefull to research for df.

No, it wouldn't. You aren't getting the point.

It doesn't matter if you "fool" your system into thinking it has 16 cores. Hell, it doesn't matter if your system actually has 16 cores. DF will still only run on one.


DF won't run in a parallelized fashion, period.

Also, fooling your computer into thinking your single-core CPU has two cores won't make anything actually run in parallel, even multithreaded programs, because you still only have one actual core to work with.

Epic fail.

[G-Flex]

You got me. I thought he was talking about the exact opposite.


However, it still doesn't matter, and for the same reasons. If your computer has 4 cores, nothing you do will cause a single-threaded application to be run on multiple cores truly in parallel, because the program simply isn't parallelized. There is nothing you can really do to change that.

[Sean Mirrsen]

Unlike hyperthreading, multicore and multiprocessor systems actually have more total processing power in multiple cores than in one. So, hypothetically, it is still possible to let the multiple cores function as one, by performing the data processing equivalent of current alternation. This would most certainly only reach its full potential when implemented in hardware, as a function of the mainboard/BIOS. But not impossible. In fact, I believe there already exist some mainboards and processors with that functionality.

[thijser]

What I'm talking about is basically this:
1 The required calculations are loaded into a program
2 The program has a amout of treads that is the same as the amout of cores you have.
3 The program runs the needed calculations (it probably works best on low fps as it allows most calculations to be put into the program at the same time).
4 The output of the program is used to calculate what happens in df.

Now this wouldn't work for all program because most programs want to have all calculations done after eachother however as df syncs in frames it could work, at least in theory.

Most basic thing I know about computer: everything is passble.

[G-Flex]

Unlike hyperthreading, multicore and multiprocessor systems actually have more total processing power in multiple cores than in one.

It doesn't matter if you can't actually run instructions on multiple cores simultaneously.

What I'm talking about is basically this:
1 The required calculations are loaded into a program
2 The program has a amout of treads that is the same as the amout of cores you have.
3 The program runs the needed calculations (it probably works best on low fps as it allows most calculations to be put into the program at the same time).
4 The output of the program is used to calculate what happens in df.

Now this wouldn't work for all program because most programs want to have all calculations done after eachother however as df syncs in frames it could work, at least in theory.

Most basic thing I know about computer: everything is passble.

This is not how programming works. An iterative program like DF consists of a set of instructions which are to be carried out sequentially. You cannot just break up that list of instructions however you want, try to run groups of them simultaneously, and expect it to work. That's the equivalent of taking a cake recipe, handing out each step to a different person, having them do them all at the same time, and expecting the result to turn out the same but faster.

[Soralin]

Unlike hyperthreading, multicore and multiprocessor systems actually have more total processing power in multiple cores than in one.

It doesn't matter if you can't actually run instructions on multiple cores simultaneously.

What I'm talking about is basically this:
1 The required calculations are loaded into a program
2 The program has a amout of treads that is the same as the amout of cores you have.
3 The program runs the needed calculations (it probably works best on low fps as it allows most calculations to be put into the program at the same time).
4 The output of the program is used to calculate what happens in df.

Now this wouldn't work for all program because most programs want to have all calculations done after eachother however as df syncs in frames it could work, at least in theory.

Most basic thing I know about computer: everything is passble.

This is not how programming works. An iterative program like DF consists of a set of instructions which are to be carried out sequentially. You cannot just break up that list of instructions however you want, try to run groups of them simultaneously, and expect it to work. That's the equivalent of taking a cake recipe, handing out each step to a different person, having them do them all at the same time, and expecting the result to turn out the same but faster.

You sort of can, with some checks in place, in fact individual cores already do some of this, although trying to extend it to multiple processors rather than it being done directly in hardware, might end up being a bit slow. See for example:

http://en.wikipedia.org/wiki/Instruction_level_parallelism
http://en.wikipedia.org/wiki/Out-of-order_execution

[G-Flex]

You have a point, but that's still only done on a very low level and isn't nearly the kind of parallelism offered by actually threading a program properly.

[Brightgalrs]

You got me. I thought he was talking about the exact opposite.

It happens. 

[thijser]

You have a point, but that's still only done on a very low level and isn't nearly the kind of parallelism offered by actually threading a program properly.

Yes but say that we have 4 cores and we lose 60% performance in the procces then we still have a speed up.

[G-Flex]

That's assuming all four cores are working at capacity. It's also assuming that the benefit would outweigh whatever overhead is involved, and that it would work properly to begin with. I honestly don't know enough to say, but neither do you.