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 TAA15352; Tue, 8 Jun 2004 19:12:18 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA15439 for ; Tue, 8 Jun 2004 19:12:17 +0200 (MET DST) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i58HCGEV011790 for ; Tue, 8 Jun 2004 19:12:16 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay02.plus.net with esmtp (Exim) id 1BXk92-000IaW-7Z for caml-list@inria.fr; Tue, 08 Jun 2004 17:12:16 +0000 From: Jon Harrop Organization: University of Cambridge To: "caml" Subject: Re: [Caml-list] 32 bit floats, SSE instructions Date: Tue, 8 Jun 2004 18:10:52 +0100 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200406081810.52526.jdh30@cam.ac.uk> X-Miltered: at nez-perce with ID 40C5F370.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 floats:01 2004:99 brandon:99 hardcoded:01 stupid:01 routines:02 necessarily:02 affected:03 macros:03 wrote:03 interface:03 library:03 algorithms:03 algorithms:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tuesday 08 June 2004 06:27, Brandon J. Van Every wrote: > At the cost of inverting almost everyone's software architecture. If you've hardcoded your routines to a particular way of accessing memory then that's hardly INRIA's fault. Even if it is with C macros, you should have structured your code so that your data structures could be changed later. > This > is ridiculous / stupid in the real world. It's also baloney on > theoretical grounds: for just how many problems do you think it's worth > destrying memory coherence by putting structure elements very far apart > in memory? Storing a matrix in transpose format is hardly going to "destroy" coherence. The only algorithms which would be significantly affected are those for which accesses are to (x_i, y_i, z_i) for random "i" rather than to (x_i, x_i+1, x_i+2) in which case (assuming the random accesses aren't to SoA might make sense if a language implementation did it totally behind > the scenes, presenting a seemingly AoS interface to programmers. I think it should be done in a library, not in the language. Cheers, Jon. ------------------- 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