3Ghz Dualcore running at 1.5Ghz?

[Mr Sarkey 0]

Seeming as the game doesn't support dualcore does that mean my game is running at 1.5Ghz and not 3Ghz.

[NeMeSiS 11]

No, you cant add up the core mhz anyway

Telling us your processor would help more

[sickboy 13]

Seeming as the game doesn't support dualcore does that mean my game is running at 1.5Ghz and not 3Ghz.

If you have a 3ghz Dual core, you have 2 cores of 3ghz, not 2 cores of 1.5 ghz

[Easy_tiger 0]

Hi,

ive been looking into how multicore operates from a programming perspective and it seems that support for dual core threading is a bit of a grey area for the majority of major programming languages, this would explain why it has not been implemented in ArmA.

Currently apps and games generate threads on a single core so if for example you have a dual core 3ghz CPU with 2 1.5ghz cores then your Arma thread /s will run on one core at 1.5ghz.

Also thread handling on a single core can be complicated enough as it is let alone handling threads spread between 2 cores!

So to summarise it looks like until the classes for dual core threading are implemented for the language Arma was developed in ArmA will stay single core only and Arma will run at the sclock speed of the primary core.

Slightly of topic:

When dual core compatibility is introduced it potentially have some really useful applications e.g all island processing on one core, player operations on the other or Ai on one core etc....

I'm personnally going to stay away from dual core until the rest of the development community catch up as theres no point having the technology if you cant use it!

[wamingo 1]

Easy_tiger, the fastest single cores sits on dual core processors today, so if you were to pick one of the fastests cpu to play non-multithreaded games you would go for a dual core anyway.

However, Suma said something along the lines of 5-20% more fps on dual core because of thread capable graphics drivers, which is not too bad. This number will probably vary a lot from game to game.

But you may be right to stretch the single core for as long as possible as the benefit of the dual core may not quite match the price tag.

[low light 0]

<span style='color:grey'><s>Like many on these forums, I am waiting to purchase a new PC to enable me to play and take advantage of 'next generation' games. And like many, I am looking to get a Dual core or, as I am starting to see, Quad core systems. I have budgeted a lot of money and have enough put away to get a fairly powerful PC. I am now in two minds as to whether to get a Multi core system, as I fear that I could save the money and get high specification Single core PC for better ARMA playability.

I understand that Muticore systems are useful for mutli-tasking and running a number of applications simultaneously, but would there be any benefit in getting a multicore or waiting till BIS makes appropriate enhancements to take advantage of Multicore systems running 64bit OS's?...I suppose the real question is can I wait long enough for such changes to happen...

Is there anyone running a Quad core system that can comment on performance?</s></span>

<span style='color:blue'>Just searched (and found) a related thread that answered my question. Sorry.</span>

<span style='color:purple'>@Sickboy (post below): I managed to answer my own question...If only I'd searched before hand. Cheers for the information anyway </span>

[sickboy 13]

I'm personnally going to stay away from dual core until the rest of the development community catch up as theres no point having the technology if you cant use it!

If you have an nvidia card you get a performance boost on dual core due to the Drivers being able to do the shader compiles on the different core, so it will help anyway.

Besides, most games, apps etc. that are being made right now are going to support multi-core.. (And many already do!

I don't think there is any (generally known) programming language at this moment in time that does not support multi-cpu m8... But there are simply many many considerations and expanded development complexity and costs to write for multi-cpu setups.

BIS has been concentrating on other things and gaining technology advancements in other regions... Now that they got these technologies in home, they can conentrate on other things for the next game... Which very well might be the ability for using multi-core, further and deeper work on gameplay aspects as opposed to graphics, etc. etc.

Oh and once more: A dualcore 3.0ghz cpu has 2 cores of 3.0ghz (not 1.5ghz).

Quad systems wont do you any good at this time unless you are planning to play Alan Wake And when ur planning in doing multiple tasks at once or when you have applications that can use the extra cores and thus perform better...

For ArmA the quad core will not help you, and I even doubt that there will be dual core optimizations for ArmA (apart from the few % performance increase due to shaders being compiled on the other cpu)

[Easy_tiger 0]

I agree that upcoming games will be multi core compatible but at the moment im having trouble findng evidence that the relevent methods/classes are in place so you can actually use the other core/s.

for example for c# (my native language) i can find no immediate info on how to implement and manage multi-threading on multiple cores. Currently if i create a thread there is no way of dictating on which core that thread executes, unless of course there is a load bearing algorithm hard coded in the cpu?

I also agree that this will not be on BIS's most important list as from experience with threading myself I can confirm that it can be a very complex area even for a smaller app. I suspect the amount of development work required to redesign the thread managing classes in arma could prove a little bit labour intensive

Oh and with regard to a 3ghz Dual Core not having 2x 1.5ghz cores, i know i was just using it as an example cuz im just to lazy to actually go and look at a CPU spec

[feersum.endjinn 6]

for example for c# (my native language) i can find no immediate info on how to implement and manage multi-threading on multiple cores. Currently if i create a thread there is no way of dictating on which core that thread executes, unless of course there is a load bearing algorithm hard coded in the cpu?

It is responsibility of operating system and generally speaking if you launch another thread, they will go on to whatever core is free at the moment. What CPU thread runs might change at every time slice, which happens ~1000 times per second (of course there are some optimizations like processor affinity to prevent cache trashing)

[sickboy 13]

It is responsibility of operating system and generally speaking if you launch another thread, they will go on to whatever core is free at the moment. What CPU thread runs might change at every time slice, which happens ~1000 times per second (of course there are some optimizations like processor affinity to prevent cache trashing)

Hmmm, but multi threaded applications do not per definition support multi-cpu yes?

I thought that all threads from 1 application would only run on 1 cpu at a time, but the threads together would switch between the 2 cpu's depending on the OS?

Which aspects within code/a program needs to be changed/considered to make the app really use&take advantage both cpu's?

[crashdome 3]

Quote[/b] ]for example for c# (my native language) i can find no immediate info on how to implement and manage multi-threading on multiple cores. Currently if i create a thread there is no way of dictating on which core that thread executes, unless of course there is a load bearing algorithm hard coded in the cpu?

Change your app from a

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[STAThread]

to

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[MTAThread]

but that is just the beginning, you need to create the threads, make sure your not overstepping any boundaries, AND make sure you are doing it correctly.

I've programmed a multi-threaded app once....

once...

it IS a pain in the ass. Only because you have no control over when each thread executes exactly. It's like racing horses and you as a rider get two horses... you need to build the links and the basket(chariot, whatever) to pull you along. You cannot just hop on and expect them both to run the same distance equally fast so you can balance on them. One will get ahead of the other and you will fall. So you need to add extra equipment to get them working together... which adds weight, size, etc.. but hopefully to get more benfit in the long run.

The OS controls when the thread executes on which core and your app tells the OS how many threads you have. To build a game to use multiple threads you need to break out what you want on each thread. Then you need to syncronize each thread, balance, and control them. All the while you could potentially be adding more work to be done for a benefit of how much performance improvement?

Now, why does dual core give performance benefit even if a game is single threaded? Because the OS will throw other background processes onto the other core if it is available. People need to stop thinking that once they run a game, that it has 100% of the resources available to it. If you have say.. a virus scanner, an IM program, or a screen capture program, email, etc.. running you gain a benefit immediately because those apps can be diverted.

Why do some tests show single core processors running better than dual-core of same type/speed? Because the test machine is not a production machine. It doesn't have the extra apps that people run all the time. It is a bad test.

Why does quad-core not improve many games? Because game manufacturers are having hard enough time to generate two threads and to allow for more can be difficult. At this time, I'd like to say Falcon 4 Allied Force is by design optimized for multi-core systems which means a quad core does offer 'some' improvement. This is because the game is designed to run on ALOT of different threads. If you only have dual-core or single-core those threads get mashed into two or one anyways.

And anyone who says that two 1.5ghz cores makes a 3.0ghz processor needs to stop talking and go back to school.

[Mr Sarkey 0]

Interesting debate going on here.

But it appears the anwser to my original question is no. Instead I have <s>6Ghz</s> sitting on my desk...

[sickboy 13]

Interesting debate going on here.

But it appears the anwser to my original question is no. Instead I have 6Ghz sitting on my desk...

No, you have 2 cpu's of each 3.0ghz.

Works the same as with speakers... when you have 2x 500 watt... you dont have 1000watt but 2 speakers of 500watt

[feersum.endjinn 6]

Hmmm, but multi threaded applications do not per definition support multi-cpu yes?

I thought that all threads from 1 application would only run on 1 cpu at a time, but the threads together would switch between the 2 cpu's depending on the OS?

Which aspects within code/a program needs to be changed/considered to make the app really use&take advantage both cpu's?

In all Windows versions with support for multiple CPUs threads from same process can and often will be sent to different CPUs, so every multithreaded program by default benefits from multiple CPUs. As for how much they benefit, it depends on what program is doing. Some problems are easier parallelize than others.

[Easy_tiger 0]

Wether single or multi-threading is deployed it seems a bit odd to allow the OS to dictate on which core the thread is run. It would be really useful to add core selection functionality to a programming languages threading class so it could be dictated by the app not the OS. As previously stated this could bring some interesting resource management options to ArmA/Game2/beyond....

however ive just thought........

would it bring a performance increase? After all a thread is a thread and provided threads are managed correctly and dont lock each other out, does it really matter which core its executing on?

[crashdome 3]

Wether single or multi-threading is deployed it seems a bit odd to allow the OS to dictate on which core the thread is run. It would be really useful to add core selection functionality to a programming languages threading class so it could be dictated by the app not the OS. As previously stated this could bring some interesting resource management options to ArmA/Game2/beyond....

HAHAHAHA

Sorry if I am laughing. It is not to mock you.. it is because I can only imagine the disasters if this were true.

I think you misunderstand the real purpose of an Operating System. The OS is to control applications and their access to hardware because back in the old days, programs were written on punch cards and the OS was literally a human person who managed who got to run what program when.

The idea is the same today, if we let the applications dictate who gets what core, then wouldn't ALL applications want to utilize ALL of EVERY resource?

[Easy_tiger 0]

true..... I momentarily forgot that ArmA isnt the only app running on a OS lol

but as previously stated

would it bring a performance increase? After all a thread is a thread and provided threads are managed correctly and dont lock each other out, does it really matter which core its executing on?

[feersum.endjinn 6]

would it bring a performance increase? After all a thread is a thread and provided threads are managed correctly and dont lock each other out, does it really matter which core its executing on?

No, not with current CPUs we have where each core is identical. Though operating systems generally try to run thread on same CPU it was run on last time slice, as it is very likely that L1 cache is populated with that data belonging to thread.

[feersum.endjinn 6]

Wether single or multi-threading is deployed it seems a bit odd to allow the OS to dictate on which core the thread is run. It would be really useful to add core selection functionality to a programming languages threading class so it could be dictated by the app not the OS.

Well, generally speaking OS probably knows better where thread is best run on, as it can see big picture what's going on with processes. Of course, if application thinks it knows better, it can suggest OS where processes should be run using Win32 calls like SetThreadIdealProcessor and SetThreadAffinityMask but they aren't really useful in most real life applications, process affinity is most often used to force old buggy multithreaded applications to run on single core (like every game based on Unreal engine :P )

[Whargod 0]

Just thought I'd chime in here. Been a fan of OFP since it came out and I'm patiently waiting for ArmA. Well, not patiently, but anyhow...

I do a lot of development with multi-threaded apps, my last project was a communications stack that implements about 25 thread s in total. The performance is wicked fast and highly stable.

At home one of my machines is a dual processor (NOT dual core) PIII and I love it more than any dual core. There's no cache problems due to the shared cache idea in the dual cores nowadays, double the IRQ pins, etc.

As pointed out, dual core/processor is a real bonus for any game because other Windows processes are sent to the processor with the most available time slices. It's a real treat to have a game run on it's own "dedicated" CPU.

As for programming considerations, I've done enough threading to realize it's almost as easy as programming a single-threaded app. The biggest concern comes in the form of data sharing between the threads. For some reason people still think all tasks have to be completed before allowing the main app to wake up and finish.

To me that's sill unless it's absolutely necessary. Take AI for example, let's assume there's 10 threads and 10 AI opponents. Who cares if each one gets a full processing time before the screen is updated? It almost feels more realistic when sometimes one AI agent seems to pause for thought while the others go nuts. And by pause, I don't mean for any great amount of time, just in processing terms where is might take an instant longer for a couple of the AI players to react.

I've done some game coding in the past and I've seen how game coders think in general and they're really set on this whole single-thread idea. Not knocking them of course, they do a wonderful job. Just look at this game!

Anyhoo, I'm rambling. I just wanted to say that multi-threaded or not, it really doesn't matter right now. As long as the OS can isolate the game on one core and the background processes on another it's all good.

[SWAT_BigBear 0]

I'm still atleast a month or so away from getting a hard copy of ArmA... I'm curious about running a dedi server and playing at the same time on this new pc. The possibilities of creating/testing missions, would be alot easier compared to uploading to a dedi box for each lil change...just to test for multi~play errors.

Tools like FireDaemon should make the task of pinning cpu's to apps fairly easy.

And thx to the topic starter...even though this went way off topic, alot of great info has been shared. Atleast you did get your answer

[feersum.endjinn 6]

I'm still atleast a month or so away from getting a hard copy of ArmA... I'm curious about running a dedi server and playing at the same time on this new pc. The possibilities of creating/testing missions, would be alot easier compared to uploading to a dedi box for each lil change...just to test for multi~play errors.

Tools like FireDaemon should make the task of pinning cpu's to apps fairly easy.

Tools like ImageCfg.exe from Microsoft can mark .exe header permanently so that executable runs always on certain processor.

But I've gt AMD X2 4400+, running game and dedicated server at the same time doesn't give any kind of performance hit even without forcing them to run on certain CPU.

[MamiyaOtaru 1]

Wether single or multi-threading is deployed it seems a bit odd to allow the OS to dictate on which core the thread is run. It would be really useful to add core selection functionality to a programming languages threading class so it could be dictated by the app not the OS.

Please look up Cooperative Multitasking for an understanding of why that would be a bad idea. There's a reason why DOS and Mac OS 9 uses cooperative multitasking while XP and OSX don't. (you weren't talking about cooperative multitasking exactly, that is about when programs run while you were talking about where. The same ideas apply though).

Choosing when and where an application runs is the job of the operating system. If it wasn't, when an application died it could take the OS down with it. Believe me, whenever ArmA crashes you'd rather crash to the desktop than have to reboot.

Only the operating system can decide how to fairly assign resources. For a program to do so, it would need to know the state of every other program running, and then it would only be needlessly reproducing the functionality of the OS. If more than one program did so, possibly in different ways, it would be a colossal mess.

[SWAT_BigBear 0]

But I've gt AMD X2 4400+, running game and dedicated server at the same time doesn't give any kind of performance hit even without forcing them to run on certain CPU.

This is why I look forward to testing this pc. It's the Asus "4x4"...2cpu's, 4 cores......unlike Intel's Quad Xeon, 1cpu, 4 cores.

I had a tuff time choosing between those chips....basically price and alot of AMD's I've built for work, myself and friends helped my decision.