Software and Dual Processor Servers
-
We are working on a project to install some 3rd party software on a server. The server we purchased has 2 dual core processors, which meets the softwares minimum hardware requirements no where did they specify the maximum requirements. Now the vendor is saying that the software cannot run with dual processors or hyperthreading. I would think if the software was not built to run on a dual processor machine you would just get the same performance of a single processor machine. I am guessing it has something to do with multi-threading, but I am not 100% sure, but why would this cause problems with the software?
Mike Lasseter
Thread synchronization errors are more likely to occur on multiple core/processor systems, but they still occur on single processor systems. Windows is still a preemptively multitasking os on a single processor system. Any well written application should run no worse on a multiprocessor system, at the very worst it might run slower because of things like cache updates, but running with more processors isn't going to cause problems unless the bugs are already there.
This blanket smells like ham
-
We are working on a project to install some 3rd party software on a server. The server we purchased has 2 dual core processors, which meets the softwares minimum hardware requirements no where did they specify the maximum requirements. Now the vendor is saying that the software cannot run with dual processors or hyperthreading. I would think if the software was not built to run on a dual processor machine you would just get the same performance of a single processor machine. I am guessing it has something to do with multi-threading, but I am not 100% sure, but why would this cause problems with the software?
Mike Lasseter
Don't use their crap software - problem soved. If they can't get their multi-threaded app to work on a multi-proc machine, they're in serious trouble as a software vendor.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Don't use their crap software - problem soved. If they can't get their multi-threaded app to work on a multi-proc machine, they're in serious trouble as a software vendor.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Unfortunately this is Telecom software for which they are the only vendor that supports there hardware.
Mike Lasseter
-
We are working on a project to install some 3rd party software on a server. The server we purchased has 2 dual core processors, which meets the softwares minimum hardware requirements no where did they specify the maximum requirements. Now the vendor is saying that the software cannot run with dual processors or hyperthreading. I would think if the software was not built to run on a dual processor machine you would just get the same performance of a single processor machine. I am guessing it has something to do with multi-threading, but I am not 100% sure, but why would this cause problems with the software?
Mike Lasseter
mr_lasseter wrote:
I am guessing it has something to do with multi-threading, but I am not 100% sure, but why would this cause problems with the software?
As mentioned, the primary cause of problems with multi-threaded software is thread synchronization, parallel data access and reentrant issues. These happen with any pre-emptive multi-tasking system, but happen more often with true parallel systems such as multi-core and multi-processor. On a single processor to switch threads in execution: 1) you preempt the current thread 2) place current thread on "hold" 3) retrieve the other thread from hold 4) start the other thread where you last left it. This is true multi-threading, and suffers from "most" of the errors of multi-threaded programming synchronization issues. BUT, you can never truly be accessing the same location at the same time because one thread or another is always on hold. In a true parallel system, all things may be happening at all times (to the limit of the number of cores), unless you prevent it. A good programmer will build to this model, or protect the poorly written areas. I generally encourage the rewriting of poorly written parallel code that requires mutex blocking, but I am also experienced enough to release the rest of my team ignores me in this. You will never fully escape mult-threaded blocking and synchronization controls: some 3rd party code was just never written for parallel access. The key is recognizing when you have to use synchronization protection and when you are just being lazy and saying, "hey my code crashes in a thread, so rather than find the problem, I'll just mutex it and go on." In these folks case, sounds like they are being lazier still... and saying, don't use multi-core/multi-processor because true parallel systems show all our errors in coding.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
mr_lasseter wrote:
I am guessing it has something to do with multi-threading, but I am not 100% sure, but why would this cause problems with the software?
As mentioned, the primary cause of problems with multi-threaded software is thread synchronization, parallel data access and reentrant issues. These happen with any pre-emptive multi-tasking system, but happen more often with true parallel systems such as multi-core and multi-processor. On a single processor to switch threads in execution: 1) you preempt the current thread 2) place current thread on "hold" 3) retrieve the other thread from hold 4) start the other thread where you last left it. This is true multi-threading, and suffers from "most" of the errors of multi-threaded programming synchronization issues. BUT, you can never truly be accessing the same location at the same time because one thread or another is always on hold. In a true parallel system, all things may be happening at all times (to the limit of the number of cores), unless you prevent it. A good programmer will build to this model, or protect the poorly written areas. I generally encourage the rewriting of poorly written parallel code that requires mutex blocking, but I am also experienced enough to release the rest of my team ignores me in this. You will never fully escape mult-threaded blocking and synchronization controls: some 3rd party code was just never written for parallel access. The key is recognizing when you have to use synchronization protection and when you are just being lazy and saying, "hey my code crashes in a thread, so rather than find the problem, I'll just mutex it and go on." In these folks case, sounds like they are being lazier still... and saying, don't use multi-core/multi-processor because true parallel systems show all our errors in coding.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Yeah, on a single processor system it really depends on how often your trouble spots get split up on multiple quanta, which is more of a timing/kernel preemption issue then actual multiple thread execution, but it still happens enough.
This blanket smells like ham
-
A software 99% cannot be "incompatible" with multi-core or multi-processor machines. In the worst scenario it just uses one core without taking advantage of the others, but that's it.
If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe - but not a personality. - Charlie Brooker My Blog - My Photos - ScrewTurn Wiki
alot of gaming software initially had problems with AMD dual cores. IIRC the biggest issue was that the power saving implementation could vary clockspeeds of the cores independently and induce thread sync problems when N ticks on core 1 wasn't equal to N ticks on core 2. AMD/microsoft eventually released driver/os patches to fix this specific problem,
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
-
Yeah, on a single processor system it really depends on how often your trouble spots get split up on multiple quanta, which is more of a timing/kernel preemption issue then actual multiple thread execution, but it still happens enough.
This blanket smells like ham
Andy Brummer wrote:
but it still happens enough.
very true. But the difference is two fold: 1) multi-processor just doubles, quadrouples or octuples your chances 2) you don't have as much over-head of the hold-restore since 2-4-8 things are happening simultaneously. All in all, it simply multiplies your chance of discovering an existing problem by the number of cores. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Andy Brummer wrote:
but it still happens enough.
very true. But the difference is two fold: 1) multi-processor just doubles, quadrouples or octuples your chances 2) you don't have as much over-head of the hold-restore since 2-4-8 things are happening simultaneously. All in all, it simply multiplies your chance of discovering an existing problem by the number of cores. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Right, but while this statement is correct.
El Corazon wrote:
you can never truly be accessing the same location at the same time because one thread or another is always on hold.
Getting the right/wrong quanta running your thread makes it appear to your thread that another thread has concurrent access, so it's really kind of a fine distinction to make. It's just that on a single processor system the quanta are almost always long, unless something happens on the hardware level cut one off. That means there is a large jump in synchronization error between single and dual since they happen for different reasons on single processor systems. Anyway, it's probably been years since you've written code that runs on anything below a dual processor system anyway. :laugh:
This blanket smells like ham
-
Right, but while this statement is correct.
El Corazon wrote:
you can never truly be accessing the same location at the same time because one thread or another is always on hold.
Getting the right/wrong quanta running your thread makes it appear to your thread that another thread has concurrent access, so it's really kind of a fine distinction to make. It's just that on a single processor system the quanta are almost always long, unless something happens on the hardware level cut one off. That means there is a large jump in synchronization error between single and dual since they happen for different reasons on single processor systems. Anyway, it's probably been years since you've written code that runs on anything below a dual processor system anyway. :laugh:
This blanket smells like ham
Andy Brummer wrote:
Anyway, it's probably been years since you've written code that runs on anything below a dual processor system anyway.
;P Probably right... I am struggling to reproduce customer problems on dual core/dual-proc since all my systems are quad now. ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Andy Brummer wrote:
Anyway, it's probably been years since you've written code that runs on anything below a dual processor system anyway.
;P Probably right... I am struggling to reproduce customer problems on dual core/dual-proc since all my systems are quad now. ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I feel for you, I really do.
This blanket smells like ham
-
I feel for you, I really do.
This blanket smells like ham
Andy Brummer wrote:
I feel for you, I really do.
some things we must just suffer through... and be better for the effort... ;) hey, I do only have a hyperthread laptop. So I am not only high-tech. ;)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Don't use their crap software - problem soved. If they can't get their multi-threaded app to work on a multi-proc machine, they're in serious trouble as a software vendor.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Dave Kreskowiak wrote:
If they can't get their multi-threaded app to work on a multi-proc machine, they're in serious trouble as a software vendor.
I would agree
-
mr_lasseter wrote:
I am guessing it has something to do with multi-threading, but I am not 100% sure, but why would this cause problems with the software?
As mentioned, the primary cause of problems with multi-threaded software is thread synchronization, parallel data access and reentrant issues. These happen with any pre-emptive multi-tasking system, but happen more often with true parallel systems such as multi-core and multi-processor. On a single processor to switch threads in execution: 1) you preempt the current thread 2) place current thread on "hold" 3) retrieve the other thread from hold 4) start the other thread where you last left it. This is true multi-threading, and suffers from "most" of the errors of multi-threaded programming synchronization issues. BUT, you can never truly be accessing the same location at the same time because one thread or another is always on hold. In a true parallel system, all things may be happening at all times (to the limit of the number of cores), unless you prevent it. A good programmer will build to this model, or protect the poorly written areas. I generally encourage the rewriting of poorly written parallel code that requires mutex blocking, but I am also experienced enough to release the rest of my team ignores me in this. You will never fully escape mult-threaded blocking and synchronization controls: some 3rd party code was just never written for parallel access. The key is recognizing when you have to use synchronization protection and when you are just being lazy and saying, "hey my code crashes in a thread, so rather than find the problem, I'll just mutex it and go on." In these folks case, sounds like they are being lazier still... and saying, don't use multi-core/multi-processor because true parallel systems show all our errors in coding.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
He said it was Telecom software which I'm sort of familiar with in general from a previous incarnation and I suspect that the software company may not be at fault, it could easily be the driver company because some of that telecom hardware is pretty complex but has a tiny market and I can easily see them making drivers 10 years ago and never wanting to touch them again.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
Unfortunately this is Telecom software for which they are the only vendor that supports there hardware.
Mike Lasseter
Then you're screwed, aren't you?! Seriously, they have to figure out how to write code. In this day, with multi-core proc's being the norm, they simply have no choice but to fix their crap.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007