From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA15532; Fri, 13 Jun 2003 10:06:51 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA15386 for ; Fri, 13 Jun 2003 10:06:50 +0200 (MET DST) Received: from mail1.tpgi.com.au (mail.tpgi.com.au [203.12.160.57]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h5D86lH22496 for ; Fri, 13 Jun 2003 10:06:48 +0200 (MET DST) Received: from ozemail.com.au (203-219-225-208-syd-ts24-2600.tpgi.com.au [203.219.225.208]) (authenticated (0 bits)) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h5D86fY14152; Fri, 13 Jun 2003 18:06:42 +1000 Message-ID: <3EE98610.6090001@ozemail.com.au> Date: Fri, 13 Jun 2003 18:06:40 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: David McClain CC: caml-list@inria.fr Subject: Re: [Caml-list] FP's and HyperThreading Processors References: <003601c33177$324ecc40$0201a8c0@dylan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ozemail:01 caml-list:01 mcclain:01 smalltalk:01 generational:01 dram:99 toxteth:01 glebe:01 2037,:01 9660:01 0850:01 ocaml:01 lisp:01 cached:01 nsw:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk David McClain wrote: > I suspect, but have yet to prove, that the low utilization is due to a low > CPU to memory bandwidth and to the failure of the L1 and L2 caches to supply > needed operations and data to the CPU. This, I would hypothesize, is going > to be demonstrated by any language that prefers fresh memory allocation for > results, e.g., OCaml, ML, Lisp, Smalltalk, etc. Well, I did think Ocaml used a generational collector that recycled 'young' memory fast. Perhaps the 'youthfulness' can be tuned down to the L2 cache size? FYI: its my understanding there is a new trend. Processor caches in multi-processor systems are a bad idea. Instead, the memory chips should have caches on them. I believe, quite a few do now: DRAM with an SRAM cache. Now that should actually mean that using 'fresh' memory is actually the *fastest* method, since it tends to distribute the load over all the memory chips. In particular .. writes become much faster than reads (since all random writes get cached, whilst some reads still have to wait for the main store). -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners