RE: [Caml-list] 32 bit floats, SSE instructions

["Brandon J. Van Every" <vanevery@indiegamedesign.com>]

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