I suppose Richard means that for the purposes of electronic medical records, the limiting problems is still going to be the time it takes to get the medical records of the disk, or if we happen to have 32 GB of ram, the time it takes to get it from the ram cache of the medical records, and the time it takes to get across the motherboard card, onto the lousy 100Mbits network card, through the piggy backed 4 and 8 port 100Mbit el-cheapo switches , up the lousy 100Mbit workstation network card, onto our ageing workstations 1.5 GHz single processors, up through our badly performing windows implementation of TCP/IP stacks, and cross-the-fingers, up into our new EMR which is using a simple single TCP connection in a client-server message passing relationship, instead of trying to share files across a network. On Sat, 2007-02-24 at 08:59 +1100, 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
