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 VAA32148; Wed, 9 Jun 2004 21:46:07 +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 VAA31938 for ; Wed, 9 Jun 2004 21:46:06 +0200 (MET DST) Received: from outbound28-2.lax.untd.com (outbound28-2.lax.untd.com [64.136.28.160]) by nez-perce.inria.fr (8.12.10/8.12.10) with SMTP id i59Jk4EV015704 for ; Wed, 9 Jun 2004 21:46:05 +0200 Received: from outbound28-2.lax.untd.com (smtp04.lax.untd.com [10.130.24.124]) by smtpout06.lax.untd.com with SMTP id AABANQ4GYA6GQ5BS for (sender ); Wed, 9 Jun 2004 12:45:26 -0700 (PDT) Received: (qmail 7587 invoked from network); 9 Jun 2004 19:44:42 -0000 Received: from 66-52-239-100.sttl.dial.netzero.com (HELO vangogh) (66.52.239.100) by smtp04.lax.untd.com with SMTP; 9 Jun 2004 19:44:42 -0000 From: "Brandon J. Van Every" To: "caml" Subject: RE: [Caml-list] 32 bit floats, SSE instructions Date: Wed, 9 Jun 2004 12:54:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040609182602.D17538@pauillac.inria.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-ContentStamp: 14:7:2078141882 X-UNTD-OriginStamp: CI84cOLHFqh7Zd2QWkwvEFvwyO3T/pIsPQZphDk9MRiYJ8WvbR76fAemGJgOd2Te X-Miltered: at nez-perce with ID 40C768FC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; brandon:99 caml-list:01 floats:01 floats:01 quoting:01 scalar:01 intel's:01 starved:99 caml-list:01 flamefest:01 implemented:01 successor:01 unfolds:01 physicist:01 reusing:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Xavier Leroy wrote: > > I was about to post a long and detailed reply explaining the > difference between computational types and storage types, why I think > 32-bit floats might be useful as the latter but not at the former, > quoting cycle counts from various processor manuals, Xavier, you're one smart guy, and people are grateful for your efforts, but... ...frankly, if you don't think 32-bit floats are a useful computational type on performance grounds, you don't have both paddles in the water. 64-bit types take twice as long to perform division and square rooting on Intel hardware. You know, like, the most prevailent hardware. Converting back and forth between 32-bit and 64-bit representations is one PITA slowdown in a SSE context. Considering that SSE can, at a minimum, provide 8 more scalar registers to Intel's starved architecture, that matters. I've written out all those conversion scenarios by hand, I know what the cycle counts are. Have you really done enough homework on these floating point issues to reach your conclusions? If so, you have strange conclusions. > mention what > could conceivably be done in OCaml at minimal implementation costs, > discuss SSE2 a bit, and generally answer the OP's initial questions. I'd be interested in that. > Then I looked again at my caml-list inbox and saw this ridiculous > flamefest about who is / isn't qualified to talk about computer > graphics, One of the implicit meta-points of that discussion, lost in the heat, is that industrial 3D engines are going to be implemented in C++ using 32-bit floats for the forseeable future. A language such as OCaml either figures out a good way to talk to them, or it will never be an important, successor language in the game industry. That's the strategic long view of how it all unfolds. What we were arguing about, is who cares about what kind of algorithmic and implementation style. Game programmer vs. supercomputing physicist. Industrialist reusing libraries vs. academician inventing new maths and softwares from scratch. > on top of the usual Felix advertising and C++ discussions. On top of the OCaml SWIG discussions. OCaml has few libraries. If OCaml can't talk to the plethora of C++ libraries out there, it's going to gain few adherants. Your only other growth route is to write everything from scratch and try to advance "on technical merit." Lotsa languages try do do that, you're just one player. Also, "technical merit" is often a matter of how fast people can implement stuff. Using stuff that's already implemented is an awfully powerful strategy for implementing stuff quickly. > Then I decided not to post. > > I long for the days when the caml-list had about one message per > day, but it was actually relevant to Caml. If you want industrial relevance, you have to deal with other people's problems and approaches. All languages go through a predictable growth cycle of who's talking about them, what voices are heard, the characteristics of the din. I alluded to my experience with Guido the Dilbert. Not just my experience, a whole class of business oriented programers' experience. Lotta people who had done a lotta work got really pissed off, threw up their hands and took their toys home. The 'suit' input as to how to advance Python simply didn't happen. There's simply no will in the Python Software Foundation to face the marketing music, they're too techie. They will simply have to flounder and save the language from themselves for a few more years. Although I can't change your feelings about your baby, I would suggest that you shouldn't sigh when people have 'alternate' discussions in and around OCaml. They are a sign of potential growth. You might get other people working on "the dumb stuff" out of the bargain. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA "We live in a world of very bright people building crappy software with total shit for tools and process." - Ed Mckenzie --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.693 / Virus Database: 454 - Release Date: 5/31/2004 ------------------- 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