Multicore argument (split from Military Base Response rev.)

General discussions about the games by Egosoft including X-BTF, XT, X², X³: Reunion, X³: Terran Conflict and X³: Albion Prelude.

Moderator: Moderators for English X Forum

Cycrow
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 22437
Joined: Sun, 14. Nov 04, 23:26
x4

Post by Cycrow »

Thelic wrote:
WEIRDANIMATOR wrote:Didn't we already have this multi-core debate? :D
We have this debate every few months, along with "Why are there no cockpits in X3?" and other somesuch.
i think the next topic will be about multiplayer.

we've had dual core and cockpits recently :P
Cycrow
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 22437
Joined: Sun, 14. Nov 04, 23:26
x4

Post by Cycrow »

WEIRDANIMATOR wrote:
pjknibbs wrote:I think Windows 64 bit works fine. Just because a lot of the standard apps like IE are 32-bit doesn't change that...and it could be argued that a web browser doesn't really need to be a 64-bit application anyway. Don't forget, if you're not needing to access more than 2Gb of RAM, there's little benefit to going 64-bit and in fact there are some small DISADVANTAGES (because all your pointers are twice the size and thus you need more memory to do the same stuff).
Dude i think you should have had the emphasis on SMALL not on disadvantages, pointers are kinda small to start with are they not? What's the likelihood of that making a difference on a system with over 4gb of RAM?

Ps. Anyone else tempted to make a web page that needs 8gb of ram to open or is it just me? :D
that may be true individually, but u need to remember, that programs dont just have 1 varible, they have a lot.

essentially it would double the memory required

a game engine could be using 1000's upon 1000's of pointers
User avatar
perkint
Posts: 5191
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by perkint »

I know using IE64 doesn't in reality bring many advantages over using the 32bit version, I was just using it as an example - the fact that the 64bit version cannot be used as a default, you have to manually start it.

The number of 64bit drivers which do not get updated with the same functionality as those in 32bit, same frequency of bug fixes, etc. It has really surprised me as I thought that 64bit support would be much closer to 32bit now, but that is not what I'm finding.

So, the number of issues you'd end up seeing on 64bit X3 (if such a thing had, by some quirk of fate/time travel been created) would probably be much higher...

Tim
Struggling to find something from the forums - Google it!!! :D
WEIRDANIMATOR
Posts: 305
Joined: Wed, 12. Oct 05, 10:36
x4

Post by WEIRDANIMATOR »

It would double the amount of RAM used for the pointers but a game isn't just pointers (at least i dont think so), other things go into the RAM that dont change size from 32bit to 64bit so it wont double the amount of RAM the game needs, maybe up it by a quarter or a third

If I am wrong dont hesitate to beat me down, i'm always up for learning something new
CAUTION: this user has tendencies towards the controversial.
User avatar
Incubi
Posts: 5069
Joined: Mon, 2. Jan 06, 06:59
xr

Post by Incubi »

Robert Foster wrote:Exactly, what General Traag & Requiemfang Said........!!

But there are 2 people at fault in this.
The Mod Creator and Egosoft.

The mod creator for knowing the limitations of the current state of the game.

And Egosoft,
Because egosoft has yet taken advantage of Quadcore.
So users can not have and use the full potential of the game because of it.
Also, Egosoft has not made the game for 64bit users.
Giving the player advantage to use up to 16 gigs of DDR3 memory.

Before anything, Egosoft needs to convert the game to use "Quadcore" processors.

While I was running this mod in the game, Only one of my processors
was pinned to the wall, while the other 3 processors was idle and doing nothing.
Mind you I have a AMD Phenom-II 965 Quadcore Processor.
But since the game only uses one core, im screwed.
I can imagine people with only One Core or Dual Core.
This kills peoples system this way.

Egosoft really needs to convert the game into 64-bit, so users having 64 bit operating systems, can take full advantage
of the DDR3 memory expansion by using 64bit and 16gigs of DDR3 memory allocations.

Currently most users using 32bit operating systems, can only use 3.2 gig of DDR2 memory.
If the game was converted to use 64bit operating system,
they can use up to 16-gigs of DDR3 memory with the game.

Gives the game more room to breath.
It would stop the staggering game play all together.

People are having problems and staggering game play because it does not
take the full advantage of the processors being released and used today.
So, how do you think their computers would react by being slammed by many ships.
If the game itself is not capable of handling Singlecore properly
without the staggering and slideshow game play.

Quadcore compatibilities is a must, so users/players can fully take advantage of having lots of ships
and very large dog fights in sectors without having the computer running havoc on people.

Once they do that, we all would set and not complaining about this stupid staggering.
it kills the fun really fast. :(


This is why I myself uninstalled the mod.
Besides all the messages every 3 seconds.
My nerves where going crazy.
LOL, the one core the game is using is still a 3.4 ghz unless you under or over clocked it :P I did not see your video card in thre but I assume that by being a black box user that it is something that compliments the rest of your system. If you have an Nividia card make a custom setting for x3tc, and in it set teh threaded optimisation to on. Or whatever the catalyst version of the setting is. And enjoy a rather dramatic performance improvement.

As for the rest of the post. It was not practicle at the time to make the game coded for multicores. And the game as of last patch is limited to 2 gigs of ram anyway ;) And ego is working on some other secret project now and that one probably is going to be coded for multi core.

I see how wonderfully my game runs on my athalon ii 250 3ghz and 2 gigs of ram, and a 896 meg nividia 275 card. I can't imagine you having an issue that cannot be solved with a little tweaking.
Bubbinska
Posts: 189
Joined: Mon, 8. Dec 08, 05:25
x3tc

Post by Bubbinska »

I'm sure Egosoft will be including more modern hardware support for any future games, but as it is, X3TC is one of the few games that does not run silky-smooth on my machine.
DVT
Posts: 2
Joined: Tue, 8. Dec 09, 07:51

A Multicore Solution (If X3TC or future projects were written in C | C++)

Post by DVT »

I haven't had the opportunity to play the game as much as you all.
Why find it necessary to recode the entire serial of the game to use multiple cores when the scheduler could algorithmically/dynamically allocate processing resources? I know other programming languages can do that but this uses a work-stealing algorithm,alternatively you could use OpenMP or any other parallel programming language.
type 'Cilk++' in google.
here are some links.
http://www.cilk.com/
http://www.cilk.com/multicore-products/ ... -overview/
http://www.cilk.com/multicore-products/why-cilk/
http://www.youtube.com/watch?v=FjGKLYINGsg

The steps in Cilk++ programming are generally quite simple.

1.It is up to the programmer to 'expose' the parallelism of the serial code (remove processor specific serial code,re-engineer the code to run serially on 1 processor(mainly to avoid race conditions),global variables(this is where hyperobjects come in),etc).
as stated on Wiki http://en.wikipedia.org/wiki/Cilk
"The biggest principle behind the design of the Cilk language is that the programmer should be responsible for exposing the parallelism, identifying elements that can safely be executed in parallel; it should then be left to the run-time environment, particularly the scheduler, to decide during execution how to actually divide the work between processors. It is because these responsibilities are separated that a Cilk program can run without rewriting on any number of processors, including one."

2.Add the small Cilk code(Alot of the time you'll use just 3 words) to parts of the serial code that may need multiprocessing(when running this will tell the scheduler that it is SAFE to multiprocess,you dont need to specify like you do when serially coding a multicore application,the scheduler dynamically handles that)
eg.Loops are a prime candidate.

3.Run it through race detection (in this case cilkscreen)

And repeat the previous 2 or 3 steps until you are satisfied with the performance,this is as simple as I can describe it,the rest is on the website.

Even if you have 1 processor,the program will still run since the serial code is left intact,you can still assign 2 or more 'workers' on a single processor with Cilk++,this spawns 2 or more threads on the same processor and you can even declare this with a quadcore processor where it spawns 8 threads instead of the usual 4.

Cilk++ is a clean extension of C++,This is by no means a 'For The Win'/'Go Faster' button. Cilk++ DOES NOT compensate for bad code.

I'am by no means an expert programmer,since ive only started understanding C++ recently.
If this were presented to the computer games industry (like thru E3) then I wouldn't have to type this down.

I'm not entirely sure on what programming language X3TC was written in.
But if Egosoft or the community could convert X3TC's serial code into C++ and optimize from there with Cilk++ (assuming it's humanely possible) then that will be the end of ALL multicore arguments here in these forums,almost all.
If not then I think Egosoft should write their next project(including source code) in Cilk++,not that it's much different to C++ since it's a clean extension.


Now If you're going to start an argument I will not answer.
No more of this "It's impossible" S%$t,It IS possible to multicore a game/application without having to change much of the serial code.
Got it?
Good...

I understand this is particularly good news to gamers/modders/scripters and egosoft since having a dual/quad/octa core processor will actually mean something,plus no more lagging slideshows at least in the processors department. Assuming the recoding were to happen.

*Note that Cilk isn't supported anymore,only Cilk++.
Cilk is an extension of C,Cilk++ is an extension of C++
http://supertech.csail.mit.edu/cilk/ for Cilk
http://www.cilk.com/home/try-and-buy-ci ... load-cilk/ for Cilk++

What do you think?
CBJ
EGOSOFT
EGOSOFT
Posts: 54278
Joined: Tue, 29. Apr 03, 00:56
x4

Post by CBJ »

Merged with existing multi-core thread, and off-topic poll removed.

Frankly this doesn't add a lot to the debate. The idea that by adding a few lines of library calls to an existing single-threaded application to magically make it multi-threaded is, frankly, ridiculous. This is the kind of tool you use when designing a new game engine, not to paste into an old one. It's not a question of compensating for bad code; it's a question of code not being designed with multi-threading in mind, because at the time that code was written multi-core CPUs were not really on the agenda.

There's one more small issue with this grand idea too, namely that half the game is not written in C++ anyway. :roll:
User avatar
supakillaii
Posts: 2385
Joined: Mon, 19. Nov 07, 19:52
x4

Post by supakillaii »

Why nto just patch it to use C++!?

:lol:

Anyway, joking aside, any news on Ego's Next Game?
Perhaps Y universe? Or C universe located at the intersection of B and J lines?
:P
jlehtone
Posts: 22552
Joined: Sat, 23. Apr 05, 21:42
x4

Post by jlehtone »

supakillaii wrote:Why nto just patch it to use C++!?
Did you have

Code: Select all

rm -fR *
in mind? :twisted:

There were free lunches as long as clocks were easy to turn up. There will be free lunches again, but with different diet, and the chefs are still reading the recipe. But old cookies won't turn into beef overnight. No, I don't assume that to be humanly possible. It could be possible with unlimited budget, but if you have that, please send it to my Nigerian account. :roll:

IMO, if there still is a dime left to be spent on X3TC, then there are much better spots in the code for it than the parallelism.
Dodgey
Posts: 198
Joined: Sun, 20. Sep 09, 23:49
x4

Post by Dodgey »

I've read about 50% of this thread, so not all of it - some of it seemed like arguing so I skipped that much.

The one thing I would say is X3TC is not very processor or memory bound as far as I can tell. I run a Core 2 Duo with 2Gb of ram on Windows 7 and I run at 1280x1024 with max everything and 4x FSAA and rarely get slowdown, not even looking at my complexes. The only time I got noticeable slowdown was once during a huge battle as part of a Plot line.

I believe my GTX 260 is doing the lion's share of the work.
CBJ
EGOSOFT
EGOSOFT
Posts: 54278
Joined: Tue, 29. Apr 03, 00:56
x4

Post by CBJ »

I'm afraid you are wrong there. Your graphics card is barely ticking over, and your CPU (one core of it at least) and memory are being used to their utmost. ;)
DVT
Posts: 2
Joined: Tue, 8. Dec 09, 07:51

Post by DVT »

CBJ:
Frankly this doesn't add a lot to the debate. The idea that by adding a few lines of library calls to an existing single-threaded application to magically make it multi-threaded is, frankly, ridiculous. This is the kind of tool you use when designing a new game engine, not to paste into an old one. It's not a question of compensating for bad code; it's a question of code not being designed with multi-threading in mind, because at the time that code was written multi-core CPUs were not really on the agenda.

There's one more small issue with this grand idea too, namely that half the game is not written in C++ anyway. :roll:
Not in C++? aww dang,I thought as much.
anyway i'm no expert at it,but its plausible atleast from a juniors point of view...I think :thinking:
To be honest I came across this about a week ago when looking up what suitable languages there were for parallel programming.
but I wouldnt it rule out just yet :wink: maybe such languages can be used,who knows whats in store for the future. :smile:
supakillaii:
Why nto just patch it to use C++!?
Lol why not eh?
but yeah I dont think X3tc has much more profitss in it anymore so Ill just leave it at that.
WEIRDANIMATOR
Posts: 305
Joined: Wed, 12. Oct 05, 10:36
x4

Post by WEIRDANIMATOR »

Now if we could convince the wonderful people at egosoft to release the source code for X3 (after they release their next game of course) we might be able to get all you eager beaver types to try to convert it to support multi-threading
:lol:
CAUTION: this user has tendencies towards the controversial.
Rive
Posts: 2260
Joined: Fri, 24. Apr 09, 16:36
xr

Post by Rive »

Cycrow wrote:i think the next topic will be about multiplayer.
Nope - the next will be the UFO base :P

Ps.: Already there is a multiplayer-topic library somewhere - maybe it can be useful to collect together the multicoresuch ones too...
User avatar
Incubi
Posts: 5069
Joined: Mon, 2. Jan 06, 06:59
xr

Post by Incubi »

I do have one question. Since X3 was not coded for multicores, how does the setting in nividia Threaded optimization to on have such an imporement to performance? This has remained true over multiple computers and video cards for me, and others that followed my advice has noticed it too. So the how this works is confusing me.
User avatar
Gazz
Posts: 13244
Joined: Fri, 13. Jan 06, 16:39
x4

Post by Gazz »

DVT wrote:Not in C++? aww dang,I thought as much.
Build a 300 station complex and you'll see that it was written in Turtle.
My complete script download page. . . . . . I AM THE LAW!
There is no sense crying over every mistake. You just keep on trying till you run out of cake.
CBJ
EGOSOFT
EGOSOFT
Posts: 54278
Joined: Tue, 29. Apr 03, 00:56
x4

Post by CBJ »

Incubi wrote:I do have one question. Since X3 was not coded for multicores, how does the setting in nividia Threaded optimization to on have such an imporement to performance? This has remained true over multiple computers and video cards for me, and others that followed my advice has noticed it too. So the how this works is confusing me.
The game itself uses a single thread, but that doesn't stop things that are called from the game such as drivers from making use of many threads. What you're doing there is allowing drivers more freedom to use cores other than the one the game is using, giving the game itself more CPU time and potentially improving performance of the drivers themselves as well.
User avatar
Incubi
Posts: 5069
Joined: Mon, 2. Jan 06, 06:59
xr

Post by Incubi »

CBJ wrote:
Incubi wrote:I do have one question. Since X3 was not coded for multicores, how does the setting in nividia Threaded optimization to on have such an imporement to performance? This has remained true over multiple computers and video cards for me, and others that followed my advice has noticed it too. So the how this works is confusing me.
The game itself uses a single thread, but that doesn't stop things that are called from the game such as drivers from making use of many threads. What you're doing there is allowing drivers more freedom to use cores other than the one the game is using, giving the game itself more CPU time and potentially improving performance of the drivers themselves as well.
Ahh, that makes sense.
jlehtone
Posts: 22552
Joined: Sat, 23. Apr 05, 21:42
x4

Post by jlehtone »

@Incubi: I did try turning the 'Threaded optimization' off (it was on by default?) but saw no drop in X3R. Lucky me?
Gazz wrote:
DVT wrote:Not in C++? aww dang,I thought as much.
Build a 300 station complex and you'll see that it was written in Turtle.
But for 1000+ station complexes it shifts to Whitespace.

Return to “X Trilogy Universe”