Doesnt the CPU have a local buffer to prefetch data and instructions?
If this was the case iut could take advantage of parallel processing.
OTOH if the limiting factor is RAM/disc access, then no amount of
speeding up the CPU will help
R
kuang oon wrote:
On 23/02/2007, at 1:44 PM, DP wrote:
I wonder if any egg head here can help me with this question.
One of the limitations of SQL Express 2005, is its limitation to 1 CPU.
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
I can't seem to get clarification if this would affect hyperthreaded
Pentium4s, AMD X2 processors or Core Duo/Core 2 Duo processors.
Can they differentiate between different CPU dies and different CPU
cores ?
Hate to build a new server with a dual core CPU and find SQL is only
using half !
David Pan
Both multi and single core processors have only one interface to
main memory, they all share the same TLB or
*Translation Lookaside Buffer. * The* TLB * is the cache that
contains fragments of the page table, for speeding up virtual memory
address translation to physical addresses .
Most motherboards are socket-compatible with both single and
multi-core processors. If your SQL server process is a memory-bound
application then no matter how many
cores you chuck at, it makes no difference to the performance. Most
server applications are written in OO languages, these programs run on
virtual machines that are memory bound and cannot take advantage of
the multicore processors. There is a futuristic language called
Erlang that has an idiom (functional programming) that handles
multi- threading particularly well. The language design of Erlang
mandates that there is No sharing of memory resources. Each erlang
process has its own 'mailbox' and pid for message sending. For a quad
core, with Erlang, you can get up 1.8 times faster speed compared to
a single core. Until we are all running Erlang, despite the marketing
hype, a hyperfast single core is better than a slower duo if all you
care about is running a particular single memory-bound critical
process well.
HTH
Kuang
------------------------------------------------------------------------
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
