SB Pro PE and dual core CPUs

[TankHunter]

I am wondering. Would Pro PE be able to use both cores, or will it only use one?

[Sean]

It will only use one of them.

[Ssnake]

...and I don't expect a quick transition. From what I've heard it's a lot of work to make such a switch and to debug code that is written for parallelization. I could imagine however that some new code segments would be written for it.

Having said that, if you are planning to buy a new computer I'd still recommend a dual core CPU simply because the user experience is better. For example, you can leave a virus scanner on. With my single core Athlon 64 every update brings a serious stutter of maybe half a minute duration (three times a day) - with the notebook and its dual-core Pentium the same virus scanner doesn't cause any noticeable slowdown at all. So, there is a tangible benefit from a dual core processor and no real disadvantage. Anything beyond this will, for the next two or three years, bring about zero additional advantage but cost you some money. The sole exception here may be users with movie render farms or people who are performing computationally intensive number-crunching (e.g. MATLAB).

So, in short: Single core isn't bad, but dual-core is better. Quad-core is no better than dual but noticeably more expensive.

[gunship]

but unreal 3 engine..... gimme cooorrreeessss :sonic:

[Ssnake]

Give me 1.5 million dollar cash and we might license it - for SB Pro and SB Pro PE, and then a third time for SB2. And for every other derivative that we might, one day, develop. And then let's not forget all the work that would be involved just to restore what already is possible. So you gain multi-core support and zero additional functionality, lose a productive year with transition time, and end up with the same product, just half a million more expensive and running on several cores.

Is it worth it?

[TankHunter]

Well, I see it like this. With one core, run Pro PE, and with the other do whatever you want to do with it. Use a P2P software, do antivirus scans, etc. Update AOL if one so happens to be burdened by it :shudders:

[JamesT73J]

I went dual core recently, and the biggest improvement I've seen is largely down to the individual cores running quicker than my old Sempron. FS2004 runs on one core better than FSX does on two, which gave me a chuckle.

As Nils said, I don't think you gain that much.

J

[Sabot_Up]

I went dual core recently, and the biggest improvement I've seen is largely down to the individual cores running quicker than my old Sempron. FS2004 runs on one core better than FSX does on two, which gave me a chuckle.

As Nils said, I don't think you gain that much.

Does FS2004 benefit from dual cores? Or is it the same as SB in that regard?

[Ssnake]

Few games are really set up yet to maximize their benefit from a multi-core environment. It will come, but it will take time. Programmers that so far could afford bypassing the programming skills for multithreaded applications will now need to learn it, game engines need to be developed for this, and from them the games need to be developed. This will take time. There already are a few and expensive game engines out there that do take advantage from parallel processing. Of course they are now taking the biggest profits from being early in the market. But consequently only a few AAA titles will these days benefit from multiple cores. For the rest, it's a gradual transition that will take about five years until all but the simplistic games are running on parallelized code. Let's not forget that at least 80% of all PCs on the market are based on single-core CPUs. These need to get replaced as well.

[ShoutingDog]

FWIW I could see big improvements in any type of real time wargame where one core handles the mechanics and the other the AI.

Don't know if code like that could be written for a dual core processor but if not I've just got to ask - WHY NOT?

[Ssnake]

It can and should definitely written that way if you start from ground up. Making the transition from a code that is not been written that way is a lot more difficult and time-consuming.

[tankenator]

Not to mention that threading will slightly improve the single core performance as well. Looking foward to this becoming standard one day--BeOS did this pervasively with very impressive os speedups....

[FlashPan]

...and I don't expect a quick transition. From what I've heard it's a lot of work to make such a switch and to debug code that is written for parallelization. I could imagine however that some new code segments would be written for it.

I'm a software developer by profession and can quite safely say that it is a huge amount of work to convert a standard application to a multithreaded one. Creating the threads isn't the problem - that's trivial. It's the managing and debugging of these threads that will be a nightmare.

One characteristic of converted multithreaded apps are the occasional lockups that occur due to thread race conditions. The really cool thing about these, is that they have a tendency to 'go-away' when debugging the code due to the fact the debugger itself subtly alters the internal timings of the threads. This means that when bugs arise the developers are having to debug blind. This adds much additional time and headaches to the debug process.

Apps written from the ground up to be multithreaded are easier, but the design needs very careful consideration.

[Ludwigmeister]

Well, I see it like this. With one core, run Pro PE, and with the other do whatever you want to do with it. Use a P2P software, do antivirus scans, etc. Update AOL if one so happens to be burdened by it :shudders:

So what about using one core to run Pro PE and one core to run TS so that it doesn't cause extra uneeded lag on the network? Would that work? Does teh computer automaticall yknow when to use a second core (say for a virus scan), or is this somethign the end user has to specify?

[Ssnake]

Windows will do the load balancing between the cores for you. Of course there are ways to enforce processes to run only on core X if I am not mistaken, but that usually results in inferior performance.

In short, you need not worry about that.

[OnAlienware]

Ssnake, when will the technology reach such critical mass that you can't pass on it?

Will eight cores by 2010 tip the balance?

[GH_Lieste]

The most significant choke-point on my machine is file I/O, especially when AV is operational.

Having the ability to process this one one core while the other does useful stuff would be a significant increase in my performance... but unfortunately my MOBO predates multi-core processors so I don't have that luxury.

I have used multi-core processors of the same speed, and although speed isn't any higher, there were less freezes, and performance was more consistent. This is a useful capability even without explicit support for multi-threading.

[Sean]

It depends on what you mean by mutithreaded. He could decide to spawn LOS calculations in another thread or something along those lines - other than that, it seems like the major bottleneck is the GPU, which threading will not help with as far as I know. Fine grained threading would be near impossible to do, and even doing the LOS stuff in another thread would create complications. Threading would surely make memory management much more complicated.

I doubt it will happen in the next several years.