From owner-freebsd-chat Sun Jan 5 11:41:21 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 5BC3837B401; Sun, 5 Jan 2003 11:41:20 -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 CEF8F43EC2; Sun, 5 Jan 2003 11:41:19 -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 18VGe5-0001v2-00; Sun, 05 Jan 2003 11:41:18 -0800 Message-ID: <3E188A0D.EBF00CD5@mindspring.com> Date: Sun, 05 Jan 2003 11:39:57 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rahul Siddharthan Cc: Greg 'groggy' Lehey , Brett Glass , chat@FreeBSD.ORG Subject: Re: Bystander shot by a spam filter References: <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> <20030105133439.GA55543@papagena.rockefeller.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4cad1cd31d5cb9472b705ced3dff15281350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: > > That's about the only place that g++ beat Intel C++; almost all > > other cases, the Intel averages 20% faster, and that number goes > > up to 100% faster for some benchmarks on the P4. > > The point is, sparse matrix operations and LU decomposition are > exactly the cases Brett is talking about. > > > I guess people should read the referenced page, instead of trusting > > summaries in mailing list postings. ;^). > > I guess people should read my posts properly and do their research There's a huge variance, and the code in the microbenchmark you want us to reference (while ignoring all the other microbenchmarks there) assumes an implementation of sparse matrix math. In my experience, the correct approach to sparse matrix math is to transform the matrix into one that's less sparse, do the math, and then transform back (if a transform back is even needed). Depending on the math package being used, the microbenchmark in question is not necessarily going to be representative of the real-world performance you can expect out of it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message