The argument about call-by-reference vs call-by-value sounds a bit like the argument about monolothic operating systems vs. message passing microkernel operating systems. What's the difference with writing a program written for an operating system simulating multiple threads, vs a program written for an operating system actually running multiple threads on different cores ? Would it be an operating system virtual memory paging problem anyway ? Say 2 threads on different cores access the same virtual memory page, then simultaneous access is possible until a write occurs, and then in some coherence schemes, (e.g. similiar to multiversion databases), it is ok to continue to read a copy of the obsolete page for the non-writer thread, as there is no further writes are going to happen to that page, and synchronization order was the reader was reading the old page first . On Sat, 2007-02-24 at 07:27 +0800, Richard Hosking wrote: > 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 >
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
