a friend of mine told me not to buy a dual core CPU because they are too unstable.

Is this true?

I was thinking of getting the Athlon XP 4200

I think your friend might be on crack...

From everything I've seen and read dual cores seem to be just as stable as single cored cpus.

btw, I think it's Athlon 64 X2, not XP. ;)

Well some people are having problems with them, but it's mainly due to the dual-cores being configured incorrectly and have been fixed with the help of others. There's a huge thread about it on the AMD forums about X2's and gaming. Heh, it's funny because some have reported ungodly speed while playing games. I mean speed so fast it's unplayable as if playing an old DOS game on it being that fast, lol.

- N

Okay hey, I'm the friend. Okay, for gaming getting a dual core thingy is crap to get it now and for it to have an immediate effect. Basically BF2 (battlefield 2) is the only game now (and even then it doesn't have full compatibilty) for dual core processing. Dual core processing will be very good if you are planning for the future.....6months coz all the games which are coming out this year will be compatible with dual core. Dual core is unstable because most apps, games, software etc can't handle dual core because welll they aren't made for it, so i think actually you are on crack, because you really have no idea what you are talking about, dual core processing is very new to the computer world and hell anything which is new is unstable until everything is compatible with it. So please be quiet and go back to snorting....yours dan

If we don't test dual core and use it then it won't progress.

You sound like a F***ing conservative

You have completely missed my point and focused on an insignificant point. I am saying it is unstable because BARELY ANYTHING CAN RUN ON IT, INFACT NOT ONE PEICE OF MAINSTREAM SOFTWARE CAN RUN ON IT. Find me one and then tell me how stable it is on it and then ocme back with your nieve and ignorant reply

You seem very sure considering you have never used a dual core computer yourself

Same to you to. You seem sure. You see my arguement is based on fact and statistics, yours is based on dreams

Okay hey, I'm the friend. Okay, for gaming getting a dual core thingy is crap to get it now and for it to have an immediate effect. Basically BF2 (battlefield 2) is the only game now (and even then it doesn't have full compatibilty) for dual core processing. Dual core processing will be very good if you are planning for the future.....6months coz all the games which are coming out this year will be compatible with dual core. Dual core is unstable because most apps, games, software etc can't handle dual core because welll they aren't made for it, so i think actually you are on crack, because you really have no idea what you are talking about, dual core processing is very new to the computer world and hell anything which is new is unstable until everything is compatible with it. So please be quiet and go back to snorting....yours dan

So what you are saying is that a dual proc system and it would be just as unstable as a dual core system. I mean, since they are basically the same. Two cores in one system I mean.

I guess you've never had to upgrade the HAL on a windows box when putting in a second proc or using a dual core system. Not having the right HAL would cause the system to be unstable, yes, however if you are going on a clean install you SHOULD have the right HAL installed.

Whether something is multi-threaded or not means nothing. Just because a program is not written to take advantage of dual procs doesn't mean that it won't run perfectly fine on it.

As for dual core being new to the computer world, wtf? If you mean that it being dual cores on one chip, then yes, if you mean having two cores in one machine (such as two procs with one core each) then no, you are wrong.

Same to you to. You seem sure. You see my arguement is based on fact and statistics, yours is based on dreams

Facts? Have you EVER looked at spec sheets or read ANY documentation on hardware?

Please go back to your crack.

I have. I checked it and read it. Posted on various forums. (twenty times bigger than this pile of crap) gathered peoples experiences. Read multiple articles. Checked gaming and apllication compatibility and yes im right and ur wrong

I have. I checked it and read it. Posted on various forums. (twenty times bigger than this pile of crap) gathered peoples experiences. Read multiple articles. Checked gaming and apllication compatibility and yes im right and ur wrong

LOL that's the best you've got to prove me wrong?

If your research is sooooo extensive, lets see it.

I'll start by saying I design multiprocessor hardware. Mostly for scientfic and engineering uses, but the facts are the same. Dannyboy has attempted to boil down an EXTREMELY complex and difficult to understand peice of equipment (ie, the new dual, quad and more soon systems) into a yes/no answer for games. You can't do that, and also Danny, try to understand the reasons and not just the answer. Currently, games are indeed written for a singlethreaded execution. This is the same reason very little improvement with games was seen with hyperthreading from Intel (which is actually called SMT for simultaneous multithreading by the creators). Right now, the majority of games use the GPU for most of the hardware, which is the graphics. The only things controlled by the CPU is game AI and basic logic. In the future, these WILL be written in a multithreaded way and some currently are (even if you don't know it). You'll notice games will start to have far better AI abilities, the enemies will seem smarter, you'll be able to have more guys (not necessarily polygons since this is a graphics issue) controllable at any one moment and in general MUCH better physics. In fact, physics is probably the number one reason multithreading will become a necessity in games in 2006+. GPU's don't do physics. When you hit that box, and it falls naturally, bouncing off walls or breaks apart, the CPU has to do ALL of those calculations. A company is now working on a special chip which may someday coexist with your GPU to do these complex calculations but for now, the CPU does it. Say for instance you have an explosion in a game... 100 guys FLY up into the air, they must rotate, possibly bounce off one another and land naturally. Thats 100 guys your CPU has to do the physics calculations for. It only makes sense to do this in a multithreaded way. Some games already do this and you just don't know it because only 1 CPU is detected.

So the fact remains that most games do not currently use multithreaded programming within them because almost no one had a multicpu or multicore computer. That is changing and the games will to. Also, if you've ever used (just used for daily things) a dual core as compared to a single cpu, you'll never go back. Things you never even noticed are far more responsive and its generally a much better experience even if you only minorly multitask while you do your computing.

-AntonK

LOL that's the best you've got to prove me wrong?

If your research is sooooo extensive, lets see it.


aaotracker.com
forums.invisionize.com
phpbb.com
forum.americasarmy.com

aaotracker.com
forums.invisionize.com
phpbb.com
forum.americasarmy.com

You're an idiot.

Two of these forums are game forums and the idiots have no idea what they are talking about. Typcial hardcore gamer. phpbb.com? Are you serious? I know there are some pretty knowledgable people there but none of them know hardware that indepth. As for the invisionize.. It seems to me like that is more of a programming/scripting/skinning page...

I'll start by saying I design multiprocessor hardware. Mostly for scientfic and engineering uses, but the facts are the same. Dannyboy has attempted to boil down an EXTREMELY complex and difficult to understand peice of equipment (ie, the new dual, quad and more soon systems) into a yes/no answer for games. You can't do that, and also Danny, try to understand the reasons and not just the answer. Currently, games are indeed written for a singlethreaded execution. This is the same reason very little improvement with games was seen with hyperthreading from Intel (which is actually called SMT for simultaneous multithreading by the creators). Right now, the majority of games use the GPU for most of the hardware, which is the graphics. The only things controlled by the CPU is game AI and basic logic. In the future, these WILL be written in a multithreaded way and some currently are (even if you don't know it). You'll notice games will start to have far better AI abilities, the enemies will seem smarter, you'll be able to have more guys (not necessarily polygons since this is a graphics issue) controllable at any one moment and in general MUCH better physics. In fact, physics is probably the number one reason multithreading will become a necessity in games in 2006+. GPU's don't do physics. When you hit that box, and it falls naturally, bouncing off walls or breaks apart, the CPU has to do ALL of those calculations. A company is now working on a special chip which may someday coexist with your GPU to do these complex calculations but for now, the CPU does it. Say for instance you have an explosion in a game... 100 guys FLY up into the air, they must rotate, possibly bounce off one another and land naturally. Thats 100 guys your CPU has to do the physics calculations for. It only makes sense to do this in a multithreaded way. Some games already do this and you just don't know it because only 1 CPU is detected.

So the fact remains that most games do not currently use multithreaded programming within them because almost no one had a multicpu or multicore computer. That is changing and the games will to. Also, if you've ever used (just used for daily things) a dual core as compared to a single cpu, you'll never go back. Things you never even noticed are far more responsive and its generally a much better experience even if you only minorly multitask while you do your computing.

-AntonK

First off, if you're having a problem with a certain product, you should go to that product's website/forums for the best information. I find it silly you've not gone to the AMD forums since your concern is specifically about the X2. Gaming websites don't know jack squat and is usually filled with people bitching about games not working blah blah blah, you should know what I'm talking about as it's the same on every game forum.

Anyways, here's the thread I mentioned on the AMD forums and you'll find some helpful tips there. Not everything is there so you should check out the various other sections and threads of that message board.

Problems gaming on my X2:

http://forums.amd.com/index.php?showtopic=60070

- N

omg how fucking geeky are u all? do u have nerd sex on these forums? and show each other ur 1inch weener? and tell people that ur proud ur the only one who has ever touched it except ur mother?

Seriously i find forums which challenge urs and u get so geeky....but then again those forums are bigger and FAR LESS geekier than this crap whole

At least nerds can spell actual words.

resident monkey is that what u call urself on these forums and have as ur title because ur so sophisticated?

omg how fucking geeky are u all? do u have nerd sex on these forums? and show each other ur 1inch weener? and tell people that ur proud ur the only one who has ever touched it except ur mother?

Seriously i find forums which challenge urs and u get so geeky....but then again those forums are bigger and FAR LESS geekier than this crap whole

Sadly the difference between the "other" forums and ours is that you will get actual CORRECT answers here...

Hey Spuriousmonkey, can I groom and pick the bugs off ya if you stroke me so I can lube OptertonGuy's CPU?

Mmm, nerd sexxx0rs. :rolleyes:

- N

resident monkey is that what u call urself on these forums and have as ur title because ur so sophisticated?

I wrote a poem for you because you are so cool


Oh Dannyboy
my dear BIG boy
danny my boy
hmm...My danny
My Big boy...oh my! Big
Ah danny cool

Cool danny
danny cool big boy
Danny oh Danny
Big danny big
biggest danny I know
oh ...
wish I was you
Danny Boy

My dual Operton you are
So big and unstable
and fast and big
dannyboy

Hey Spuriousmonkey, can I groom and pick the bugs off ya if you stroke me so I can lube OptertonGuy's CPU?

Mmm, nerd sexxx0rs. :rolleyes:

- N

ROFLMAO!

yes u are so smart. I mean there aren't any people on bigger and smarter forums oh and better forums who aren't as smart as you lot.....

Oh Spuriousmonkey, that poem gave my 1-inch weewee a chubby.

i <3 u

- N

Again, Dannyboy, if you're having problems with a specific product, doesn't it make the most sense to go to that products forums? You've gone everywhere but there. :p

http://forums.amd.com is the place you should visit as those are the forums of the product you're having troubles with. Go check out that link I showed in my first post as that's specifically about X2 and gaming issues although there's a couple other threads about it too.

- N

yes u are so smart. I mean there aren't any people on bigger and smarter forums oh and better forums who aren't as smart as you lot.....

Look - all you need to do is check out a reliable site like the one Nieldo gave you. Not some gaming site that's full of amateurs that don't know any more than you do. They'll naturally have all the wrong answers.

Some people here are seriously trying to help you so don't turn into a punk just because you didn't check the right sources the first time.

Oh Dannyboy
my dear BIG boy
danny my boy
hmm...My danny
My Big boy...oh my! Big
Ah danny cool

Cool danny
danny cool big boy
Danny oh Danny
Big danny big
biggest danny I know
oh ...
wish I was you
Danny Boy

My dual Operton you are
So big and unstable
and fast and big
dannyboy

What is the tune to that song?

What is the tune to that song?

I think simple beeps and chirps with a few 0's and 1's mixed in. :p

- N

Duel core or HT not stable is more likely due to incorrect BIOS settings or HW/SW upgrades. If you are serious, you should dig it by yourself. Why it's not stable in your system? What was crashing it? Game crashed or OS rebooted? While looking at other's opinions are helpful, but unless you can duplicate them, they remain as opinions.

If I say my dual core system runs CoD2, BF2, Doom3 and Quake4 fine, does that make me a liar or you just making a general bash on dual core cpu?

I'll start by saying I design multiprocessor hardware. Mostly for scientfic and engineering uses, but the facts are the same. Dannyboy has attempted to boil down an EXTREMELY complex and difficult to understand peice of equipment (ie, the new dual, quad and more soon systems) into a yes/no answer for games. You can't do that, and also Danny, try to understand the reasons and not just the answer. Currently, games are indeed written for a singlethreaded execution. This is the same reason very little improvement with games was seen with hyperthreading from Intel (which is actually called SMT for simultaneous multithreading by the creators). Right now, the majority of games use the GPU for most of the hardware, which is the graphics. The only things controlled by the CPU is game AI and basic logic. In the future, these WILL be written in a multithreaded way and some currently are (even if you don't know it). You'll notice games will start to have far better AI abilities, the enemies will seem smarter, you'll be able to have more guys (not necessarily polygons since this is a graphics issue) controllable at any one moment and in general MUCH better physics. In fact, physics is probably the number one reason multithreading will become a necessity in games in 2006+. GPU's don't do physics. When you hit that box, and it falls naturally, bouncing off walls or breaks apart, the CPU has to do ALL of those calculations. A company is now working on a special chip which may someday coexist with your GPU to do these complex calculations but for now, the CPU does it. Say for instance you have an explosion in a game... 100 guys FLY up into the air, they must rotate, possibly bounce off one another and land naturally. Thats 100 guys your CPU has to do the physics calculations for. It only makes sense to do this in a multithreaded way. Some games already do this and you just don't know it because only 1 CPU is detected.

So the fact remains that most games do not currently use multithreaded programming within them because almost no one had a multicpu or multicore computer. That is changing and the games will to. Also, if you've ever used (just used for daily things) a dual core as compared to a single cpu, you'll never go back. Things you never even noticed are far more responsive and its generally a much better experience even if you only minorly multitask while you do your computing.

-AntonK

I completely good post that he just ignores. A+ to you for taking the time for this high school wanker.

I'll start by saying I design multiprocessor hardware. ...
-AntonK

I think then we all should sue for creating such a big mistake. U should have designed a processor that doesnot require any additional programming and could have relied on OS to do the job of using CPU cycles for the programs. U could have easyly modified Linux and became the next MS by patenting thoes Softwares that seemlessly use multyprocessors.

Do U expect people to reprogram every time U add a core ?
Atleast create a new language for it.

Hey Spuriousmonkey, can I groom and pick the bugs off ya if you stroke me so I can lube OptertonGuy's CPU?

Mmm, nerd sexxx0rs. :rolleyes:

- N Oh, poor thing couldnt make enough money to attract women, so now he has to do it with monkeys, just dont recreate Apes.

Duel core or HT not stable is more likely due to incorrect BIOS settings or HW/SW upgrades. If you are serious, you should dig it by yourself. Why it's not stable in your system? What was crashing it? Game crashed or OS rebooted? While looking at other's opinions are helpful, but unless you can duplicate them, they remain as opinions.

If I say my dual core system runs CoD2, BF2, Doom3 and Quake4 fine, does that make me a liar or you just making a general bash on dual core cpu?

Isnt it a good idea to get a Powerful PCIExpress Graphics card instead of Dualcore expense ?

Built five so far. All good - no problems - play games well.

PBCAK.

My "dual core expense" is mainly for converting HDTV files captured from my digital cable DVR. Playing game is just a side job. I think my X800 XT AIW is not too bad for games.

Oh, poor thing couldnt make enough money to attract women, so now he has to do it with monkeys, just dont recreate Apes.

Haha, dude, if you only knew. I used to help run an escort service (yes, female :O ) and make video pr0n, moron. I've had more poontang that you'd ever imagine, Mr Homophobe.

My "dual core expense" is mainly for converting HDTV files captured from my digital cable DVR. Playing game is just a side job. I think my X800 XT AIW is not too bad for games.

Yeah, same here, I love my dual core. I have mine set up as a DVR. Something I could have done before on a single core, but not be able to do other tasks at the same time especially since I love gaming. Why don't you just get a TV tuner and do the same thing instead of having to transfer it from your digital cable DVR box to your computer? Well, unless you like recording a bunch of things to have more than one DVR in the house.

- N

Why don't you just get a TV tuner and do the same thing instead of having to transfer it from your digital cable DVR box to your computer? Well, unless you like recording a bunch of things to have more than one DVR in the house.
- NAs you can see, my AIW has build in TV tuner. But TV recording through S-video looks really sucky. No way it can compare to the raw HDTV stream I extracted from the DVR directly through firewire. That's why I need to convert those .ts files into DVD compatible format.

I think then we all should sue for creating such a big mistake. U should have designed a processor that doesnot require any additional programming and could have relied on OS to do the job of using CPU cycles for the programs. U could have easyly modified Linux and became the next MS by patenting thoes Softwares that seemlessly use multyprocessors.

Do U expect people to reprogram every time U add a core ?
Atleast create a new language for it.

To start, I hope you don't think you've had some magic revelation that no one else in industry or academia hasn't already had. Of course we'd prefer to just let the OS do it, but you'd be surprised how inefficient The OS. If you really have to do a context switch to the kernel space, you're asking for trouble. Secondly, it's not an easy problem, there are papers and books and entire theories on the best ways to parallelize a particular problem. And unfortunately, these never work for every problem. Newer hardware has already been able to do as much ILP (instruction level parallelism) as possible with the super scalar out-of-order execution engines. What we need now is highly efficient programming models and hardware to exploit TLP, or thread level parallelism.

No one is asking for a recompile with more processors. In fact, most problems can be programmed either for 1 processor or for 2+ processors. Once you've programmed for two, you've solved the problem for 2+.

You must also consider there are two points in parallel processing. The first is throughput, this means running all the programs you have open, and making them all run as if they were running alone. This is pretty easy, and is basically being done now. The second problem is making a SINGLE program run very fast and very efficiently on multiple processors. Many problems are difficult because they require communication between the processors and require an efficient distribution of the problem itself. You must also consider how much of the work is necessarily sequential and CANNOT be parallelized. How do you detect these parts? Can you do it in hardware, does it have to be done in the compilation? These are the problems being worked on right now.

-AntonK

Secondly, it's not an easy problem, there are papers and books and entire theories on the best ways to parallelize a particular problem. And unfortunately, these never work for every problem. [quote]

Damned right. An ex-colleague of mine runs seminars or parallel computing, so interested parties can get the best from their Beowulf arrays. If it was simple, folks wouldn't haul ass and cough up!

[quote]You must also consider there are two points in parallel processing. The first is throughput, this means running all the programs you have open, and making them all run as if they were running alone. This is pretty easy, and is basically being done now. The second problem is making a SINGLE program run very fast and very efficiently on multiple processors.

Damned right again! Imagine all the OS crap on one processor, and the app on the other. Instant benefit, no screwing around required. It's not like we need massive transputer power at home, to maximise everything. Dual core, and hyperthreading is more than we need.

Oh, and yes, fresh install for ease and reliability. Updating the HAL works, but is a bit tricky for the average punter. Oh, and the CD you get with your motherboard, er, like, read the readme, in case there's a BIOS/firmware update. RTFM, gamers!

... problem is making a SINGLE program run very fast and very efficiently on multiple processors. Many problems are difficult because they require communication between the processors and require an efficient distribution of the problem itself. You must also consider how much of the work is necessarily sequential and CANNOT be parallelized. How do you detect these parts? Can you do it in hardware, does it have to be done in the compilation? These are the problems being worked on right now.

-AntonK


Thanks for that greeaattee answer. I hope U people come up with something better that what U said. I am not that good at Computer Guy so forgive me for my naiveness on what I am saying.

If the processors cache is seperated in the processor and combined to one bigger instead seperate for each core. Then what will be the difference between alternate instructions handled by multiple cores and a single core from the processor L1 cache ?

i.e. For 2 core alternate, for 3 cores one after two instructions, for 4 cores 1 after 3 instructions. This logic depends on my illusion about what a single instruction is, which may be wrong for sure.

Well first, most processors have 2 levels of on-chip cache. These are usually referred to as L1 and L2 caches. In a dual core, there are many ways you can do it, you can do separate L1 and separate L2, meaning each processor is really completely independent. Or you can do separate L1 and shared L2, which means they share an L2. This is quite common because it allows for more cooperation between the processors since if processor 1 requests a cache line A, and processor 2 needs to do work on that same cache line, then it can use it without having to go to memory.

There are other cache issues with a multiprocessor however, and that is in cache coherence. Imagine if you will the following scenario. Processor 1 accesses memory address 0x1000 (made up address but just go with it) and it gets put into its L2 cache, which also goes into its L1 cache and it does some work with it. Then Processor 2 accesses address 0x1004 which is on the SAME cache line as 0x1000, so it pull that line into its L2 and its L1. Then processor 1 modifies address 0x1000-0x1012. These means that now, processor 1 has the ONLY updated copy of that data, while processor 2 is working with old stale data that is incorrect. This is called the coherence problem. There are multiple ways to solve this, but they all complicate the processor.

As for multiple simultaneous cache accesses, this is actually more of a materials engineering problem, because you simple need to make the cache multiported, that is to say if you need 2 processors to potentially be able to read multiple lines at the same time, you have to make the cache dual ported. This is not hard, it simply makes the cache larger than if it were single ported. So there are trade offs to be made, do you want to make it a take-turns approach where only one can access the cache at a time, or do you want LESS cache (since it is bigger) and have it so they can access at the same time. Usually there is no intuitive way to answer these questions, so we built simulators. It turns out that most of the time for instructions (since you fetch instructions EVERY cycle) you need to have as many ports as you do processors times the super-scalarness of the processor, for instance if you have two processors and each is a 4-way superscalar, it needs to be at least 8-ported. Of course if the L1 isn't shared you only need 2 4 ported caches. For an L2 on the other hand which may not necessarily be accessed every cycle you can have much less porting, so it may be single or just dual ported. Hope that answered some questions.

-AntonK

This has become quite an amusing thread.

...

There are other cache issues with a multiprocessor however, and that is in cache coherence. Imagine if you will the following scenario. Processor 1 accesses memory address 0x1000 (made up address but just go with it) and it gets put into its L2 cache, which also goes into its L1 cache and it does some work with it. Then Processor 2 accesses address 0x1004 which is on the SAME cache line as 0x1000, so it pull that line into its L2 and its L1. Then processor 1 modifies address 0x1000-0x1012. These means that now, processor 1 has the ONLY updated copy of that data, while processor 2 is working with old stale data that is incorrect. This is called the coherence problem. There are multiple ways to solve this, but they all complicate the processor.

... Hope that answered some questions.

-Anton (TJ) Kiriwas That was clearly absolutely practically welleducated answer that went beyond my hopes, Thanks !

Why isnt it possible for the OS to equally distribute all the threads among the cores ? Now that U made it quite clear that having seperate cache is better. Threads do have seperate memory allocations, right ?

Imagine all the OS crap on one processor, and the app on the other. Instant benefit, no screwing around required.

Dedicating a core for OS and the other one for apps is wasting CPU resource because OS remains in idle most the time.

That was clearly absolutely practically welleducated answer that went beyond my hopes, Thanks !

Why isnt it possible for the OS to equally distribute all the threads among the cores ? Now that U made it quite clear that having seperate cache is better. Threads do have seperate memory allocations, right ?

Typically, an OS will have a process (really a thread, if that is the smallest unit of execution in the OS) scheduler that will do its best to schedule equally across the processors. Unfortunately, there are problems with that. The first is that sometimes programs simply aren't written as multiple threads. It takes a lot of overhead to write a program to run on N processors as opposed to 1. This overhead is worth it if you know you'll have a multiprocessor, but until lately, that wasn't the case. Also, you have to remember the processors are still having to fight for access to the main memory. The bus between the memory and the processor is really not as fast as people think. It can quickly become saturated.

As for your question about seperate memory allocations, I'm not quite sure what you're asking. It sounds like an OS question, in which case the answer is: "It depends on the kernel you're using." Perhaps rephrase and I can answer.

-AntonK

This is true.
No it's not.
Yes it is, and I know it is because I know what I am talking about and these people, who know what they're talking about, told me so!
No it's not, and this is exactly why...
You're a big, dumb stupid head and I don't like you or your dumb facts. So there!

*sigh*

What happened to Dannyboy? He made this thread quite amusing.

Wow, This AntonK is dam good and genuienly into answering to the topic.

Typically, an OS will have a process (really a thread, if that is the smallest unit of execution in the OS) scheduler that will do its best to schedule equally across the processors. Unfortunately, there are problems with that. The first is that sometimes programs simply aren't written as multiple threads. Yes, but yet it should be possible to fixate different threads on each one of core, they are always lurking in the memory when we look at the process viewer ? So if there are 10 services/progs running in the memory, the OS should put them 5 in one core and 5 in another for a two core processor.

It takes a lot of overhead to write a program to run on N processors as opposed to 1. This overhead is worth it if you know you'll have a multiprocessor, but until lately, that wasn't the case.
So why not exploit the already existing threads to do the job, let the OS do that. So if we have a big AI Game and there are different components of the program on say 10 different threads the OS should make sure that threads of a single program should be uniformly distributed across the cores. So in our example with two core processor 5 threads will be in one core and 5 in another; the same game should break all performance records with a 10 cores processor.

Also, you have to remember the processors are still having to fight for access to the main memory. The bus between the memory and the processor is really not as fast as people think. It can quickly become saturated. I thought we already have dual channel. But clearly that could be a reason why we wont see double performance with doubling cores each time. Fast memory = hot memory. Super computer are hot ? Quad channel memory ? Multichannel Memory with single sim ?

As for your question about seperate memory allocations, I'm not quite sure what you're asking. It sounds like an OS question, in which case the answer is: "It depends on the kernel you're using." Perhaps rephrase and I can answer.

-AntonK Nope, it was related to the innitial points of cache coherence.

Do the os still use interrupts ? there must be its equivalent; if there is then is it possible to distribute them among the cores and will that make things any faster ? Clearly I am from the old generations.

Are U getting bored ?

Yes, but yet it should be possible to fixate different threads on each one of core, they are always lurking in the memory when we look at the process viewer ? So if there are 10 services/progs running in the memory, the OS should put them 5 in one core and 5 in another for a two core processor.


Okay, well I'll answer each part separately. Yes, this is entirely possible, but I would have to ask the question of why. I think you may be taking the abstraction of what a thread is a little far. Instead, lets look at what a thread (process, whichever, what we're really talking about is the smallest unit of execution for a given OS) really is. A thread is a place in memory with a thread_block. Inside this block, which is in the OS's portion of memory, we store the current PC (program counter) for that thread, its last CPU state (so that we can do a context switch back into the program) and some information about the memory that thread uses, such as page table or virtual memory translation table.

With this in mind, why fixate processes to one core or another? Given that the processors share the exact same physical memory (ram chips), each processor will run a process/thread scheduler. It will look at all 10 (9 if we assume that the other processor is already running one) and choose which will run. This is based on some algorithm usually looking at how long it has run before, how long since it last run, etc. This means that process/thread A may run on processor 1, then be paused, it may start again on processor 2, then pause, start again on processor 2, then pause, etc.

You may ask yourself, why do we do this run,pause,run,pause? This is what gives a single processor, or even dual processors the illusion of running dozens of things AND getting input from you at the same time. Technically every time you press a key or a packet comes into your ethernet card, your OS has to stop whatever program you're running, switch into OS mode, deal with the new input, then switch BACK to a program. (This of course ignores things such as DMA, but that is another issue).


So why not exploit the already existing threads to do the job, let the OS do that. So if we have a big AI Game and there are different components of the program on say 10 different threads the OS should make sure that threads of a single program should be uniformly distributed across the cores. So in our example with two core processor 5 threads will be in one core and 5 in another; the same game should break all performance records with a 10 cores processor.


Here, I'm confused on what you mean by "already existing threads" You can't just make up threads. A given program must be build from scratch to use threading, if it wasn't, it will NEVER be able to use more than 1 thread. For instance, I have a program that takes a large matrix, say 1000x1000 in size. I want to sum up every single cell in that matrix. This is a simple loop in a single threaded program, right? Well, if we write the program to just use this single loop, how could the OS ever know how to run the program with 2 threads? It wouldn't know what to do with the other one? If instead I wrote the program so that I could use N processors. I decided that each processor would get 1000/N rows. Well if I did THIS, then the program would would run much faster on a multiprocessor system AND it would still run fine on a uniprocessor since 1000/1 = 10000. The problem is, this is a lot more programming, a lot more work, and it wasn't worth it if only 0.1% of the population actually had two processors.

In fact, if you ran this problem with 1 processor and told it to use 2 threads (thread 1 got 0-500 and thread 2 got rows 501-999) then it would run SLOWER than if we just used 1 thread and gave it 0-999 because the processor would waste time switching back and forth.

As for your example with the game, no games are currently written for 10 threads. At most, some use 2-3 threads. Usually 1 to do game AI and 1 to do game logic and maybe 1 to actually push the graphics to the graphics card. This is just an example there are others, but none actually do 10 threads. In the future this may change, since as more people get multiprocessors, we will have more people PROGRAMMING for multiprocessors. Its kind of a supply and demand thing: people won't program for multiprocessors if no one has multiprocessors, and no one buys multiprocessors if no program is written for multiprocessors.

Lets just say that if the OS could possible figure out how to take 1 thread (one stream of computer instructions) and knew WHERE and HOW to make it 2, then all problems would be solves. But they can't, they're not smart enough, and even if they were, the amount of time it would take to figure it out, we could have just ran it with 1 processor.


I thought we already have dual channel. But clearly that could be a reason why we wont see double performance with doubling cores each time. Fast memory = hot memory. Super computer are hot ? Quad channel memory ? Multichannel Memory with single sim ?

Nope, it was related to the innitial points of cache coherence.

Do the os still use interrupts ? there must be its equivalent; if there is then is it possible to distribute them among the cores and will that make things any faster ? Clearly I am from the old generations.

Are U getting bored ?

Not bored, just not exactly sure what you were asking. Dual channel and other types of new ram, if you look, have not REALLY increased performance in computers because we are often still limited by the bus width and speed.

I fail to see how dual channel, quad channel, etc. related to cache coherence. Can you help me out on what you mean?

-AntonK

Thanks for the effort, I will rarely get someone with your caliber to know all this. Thanks to SciForums.

Okay, well I'll answer each part separately. Yes, this is entirely possible, but I would have to ask the question of why. I think you may be taking the abstraction of what a thread is a little far. Instead, lets look at what a thread (process, whichever, what we're really talking about is the smallest unit of execution for a given OS) really is. A thread is a place in memory with a thread_block. Inside this block, which is in the OS's portion of memory, we store the current PC (program counter) for that thread, its last CPU state (so that we can do a context switch back into the program) and some information about the memory that thread uses, such as page table or virtual memory translation table. So will it make any difference if we could divide physical memory in N partition and have N pagefiles for each N threads. No more switching.

With this in mind, why fixate processes to one core or another? Given that the processors share the exact same physical memory (ram chips), each processor will run a process/thread scheduler. It will look at all 10 (9 if we assume that the other processor is already running one) and choose which will run. This is based on some algorithm usually looking at how long it has run before, how long since it last run, etc. This means that process/thread A may run on processor 1, then be paused, it may start again on processor 2, then pause, start again on processor 2, then pause, etc. But what if we just let the processes talk to eachother instead of mingling with eachothers memory, Ram is cheaper these days, so if we could have say 4 ram sims for each of 4 core with seprate buses then what ?

You may ask yourself, why do we do this run,pause,run,pause? This is what gives a single processor, or even dual processors the illusion of running dozens of things AND getting input from you at the same time. Technically every time you press a key or a packet comes into your ethernet card, your OS has to stop whatever program you're running, switch into OS mode, deal with the new input, then switch BACK to a program. (This of course ignores things such as DMA, but that is another issue). something that doesnt switched seems desirable.



Here, I'm confused on what you mean by "already existing threads" You can't just make up threads.

I meant the existing threading model of programs but without switching and seperate memory allocations;

Agreed that the bus is limited but if memory is divided and the bus fetches data to and from cache equally for each division then there will be no cache coherance, each core should process data simultaneously without eachothers knowledge. The divisions should be OS's headache.

A given program must be build from scratch to use threading, if it wasn't, it will NEVER be able to use more than 1 thread. For instance, I have a program that takes a large matrix, say 1000x1000 in size. I want to sum up every single cell in that matrix. This is a simple loop in a single threaded program, right? Well, if we write the program to just use this single loop, how could the OS ever know how to run the program with 2 threads? It wouldn't know what to do with the other one? If instead I wrote the program so that I could use N processors. I decided that each processor would get 1000/N rows. Well if I did THIS, then the program would would run much faster on a multiprocessor system AND it would still run fine on a uniprocessor since 1000/1 = 10000. The problem is, this is a lot more programming, a lot more work, and it wasn't worth it if only 0.1% of the population actually had two processors.

In fact, if you ran this problem with 1 processor and told it to use 2 threads (thread 1 got 0-500 and thread 2 got rows 501-999) then it would run SLOWER than if we just used 1 thread and gave it 0-999 because the processor would waste time switching back and forth.

As for your example with the game, no games are currently written for 10 threads. At most, some use 2-3 threads. Usually 1 to do game AI and 1 to do game logic and maybe 1 to actually push the graphics to the graphics card. This is just an example there are others, but none actually do 10 threads. In the future this may change, since as more people get multiprocessors, we will have more people PROGRAMMING for multiprocessors. Its kind of a supply and demand thing: people won't program for multiprocessors if no one has multiprocessors, and no one buys multiprocessors if no program is written for multiprocessors.

Lets just say that if the OS could possible figure out how to take 1 thread (one stream of computer instructions) and knew WHERE and HOW to make it 2, then all problems would be solves. But they can't, they're not smart enough, and even if they were, the amount of time it would take to figure it out, we could have just ran it with 1 processor. Thats how thing were designed for single cores I guess.

Not bored, just not exactly sure what you were asking. Dual channel and other types of new ram, if you look, have not REALLY increased performance in computers because we are often still limited by the bus width and speed.

I fail to see how dual channel, quad channel, etc. related to cache coherence. Can you help me out on what you mean?

-AntonK I have personally seen performance of Dual channel and single channel, Dual channel is indeed lot faster as it uses seperate buses.

Okay, I believe I have an idea of what you're talking about now, but what it really is, is basically a bunch of computers sitting next to each other on the same motherboard. Remember though, that in the end, we ARE trying to interact with the system as 1 system. This means that we need a single I/O channel, this would most likely become the bottleneck then.

As for having multiple busses, have you looked at motherboards lately? No room for more busses. As it is, MB makers are having a hard time fitting larger 64 bit wide busses. As for partitioning, it sounds like a good idea until you consider what happens if I'm running a single program? That is not a parallel program but completely single threaded? What if that one program needs more memory than I have allocated to 1 process? It can't use the other processor's memory space? People have tried static partioning schemes, they rarely ever see benefit in real application use. I'll post more later, just thought I'd respond.

I will leave you with this. There are two types of people who work on this. There are people like me who design the hardware systems and how the OS interacts with it, then there are the materials people whose job it is to actually figure out how to build it. We've got PLENTY of ideas and simulations that are killer fast. Problem is, can't physically build a lot of them. No easy solutions, at least not right now.

-AntonK

-AntonK