From owner-freebsd-chat Sun Jan 5 12: 7: 0 2003 Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 373C737B401; Sun, 5 Jan 2003 12:06:59 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99E1343EA9; Sun, 5 Jan 2003 12:06:58 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0092.cvx40-bradley.dialup.earthlink.net ([216.244.42.92] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18VH2s-0005Cf-00; Sun, 05 Jan 2003 12:06:55 -0800 Message-ID: <3E18900D.10F82814@mindspring.com> Date: Sun, 05 Jan 2003 12:05:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rahul Siddharthan Cc: Brett Glass , Greg 'groggy' Lehey , chat@FreeBSD.org Subject: Re: Bystander shot by a spam filter References: <3E18073C.68182FE4@mindspring.com> <4.3.2.7.2.20030104201251.029387d0@localhost> <4.3.2.7.2.20030104112015.026a5530@localhost> <4.3.2.7.2.20030104201251.029387d0@localhost> <4.3.2.7.2.20030104202908.03c3b100@localhost> <20030105073804.GA72674@wantadilla.lemis.com> <20030105074923.GA4956@papagena.rockefeller.edu> <3E18073C.68182FE4@mindspring.com> <4.3.2.7.2.20030105120224.029377d0@localhost> <20030105192556.GA526@papagena.rockefeller.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43b400d5d0d573557d78eb5f8630ca72a387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Rahul Siddharthan wrote: > It is interesting, in fact, that gcc does well in all such problems. > It doesn't do very well in Gauss-Siedel relaxation (which is a fairly > straightforward iterative method) and does quite badly in a > monte-carlo integration (which is basically just one long loop with > calls to a random number generator and the function evaluator). Monte Carlo is where I've personally noticed a difference, FWIW. There are a number of packages commonly used in physics work, out of both Berkeley and LBL, which perform Monte Carlo generation of relativistically invariant P-N and N-N collisions, for the purposes of pair production. You then use your theoretical physics to constrain the resulting allowable values, which then simulates what you can expect, according to your theory, were you to run a physical experiment in a large accelerator/collider. It's a useful way of testing theories vs. observed data, to see where they fall down (or not -- one hopes...). In any case, the Intel compiler gives significantly better numbers. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message