Yes I guess thats true - it seems to be standard practice in most
programming languages to manipulate variables by pointers or references
rather than by the value itself. This is said to be more efficient
programming and memory wise - are you saying that due to the extra
lookup step from pointer to variable that it slows the processor?
R
kuang oon wrote:
Hi Richard,
Before the rash of multi-core processors we had a single core with
hyperthreading (HT) like you alluded to. An OS which supports
symmetric multiprocessing
treats a single processor with HT as 2 logical processors. It is
claimed that you get 20-30% performance increase running all those OS
native threads. If you have a quad core,if each of the quad has HT,
you end up with 8 logical processors. The current crop of duo and
quad core cpu do not have HT for each core as each HT gobbles up 5%
real estate and generates
too much heat.
At this point the consumer pays for what he gets, but he is helping
industry by seeding/normalizing the field with multiprocessors.
The software we write today does not exploit multi processing yet,
things will change.
The programs we write today are totally memory bound, they have this
habit of "call by reference to memory locations" instead of "call by
values" for simple tasks such as string manipulations. This memory
boundness (call by reference ) totally wreck concurrent processing
based on multi core architectures.
Digressing, say as we move from a 32-bit to a 64-bit environment,
our memory bound programs significantly slow down because it takes
longer to work out the memory locations.
So the speed of execution of a single memory bound application
written in a traditional language is still predicated on a single
fast core plus minus HT.
Cheers
kuang
docle systems
On 23/02/2007, at 10:51 PM, Richard Hosking wrote:
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
_______________________________________________
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
