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

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

Jon Harrop
> Brandon J. Van Every wrote:
> > A 3D graphics guy has to contend with a large number of numeric
> > problems.  Some of them are cut, dried, and repetitive
> > enough to justify
> > coding up a C routine for them.  For example, transforming a large
> > number of XYZW vectors by a 4x4 matrix is a 'pat' problem
> > that occurs at some point in 3D graphics processing.
>
> If you want high performance, which you seem to want, the
> hardware should be doing those for you.

Well hand me a general purpose GPU with an incredible 2-way memory bus,
smart guy.  Hint: commodity 3D graphics cards are fast when you write to
them, damn slow when you read them, by design.  Shader programming is
exceedingly limited in scope, it is not a general computational
facility.

> In the case of OCaml, the language is there because it is a research
> project. Adding 32-bit floats doesn't count as research these
> days. Not even in France. ;-)

OCaml has a somewhat practical focus, but maybe it's not sufficiently
practical for me.  I do find myself re-evaluating languages in terms of
3 overriding problems:

- the available C++ migration path and its efficiency
- the support of basic 3D graphics types, i.e. 32 bit floats
- ability to work with imperative, object oriented designs and libraries

OCaml currently has 1 out of 3.
See for point of reference, "Why No One Uses Functional Languages."
http://cm.bell-labs.com/cm/cs/who/wadler/papers/sigplan-why/sigplan-why.
ps.gz

1.5 out of 3 if one considers OCaml SWIG to be an available, slow,
optimizeable path.  Must admit I was a little frustrated the other day
when I tried to wrap Nebula2 the other day and immediately got a bunch
of errors.  That's not automated C++ migration, that's an invitation to
everything breaking all the time and fighting with the source
maintainers.  I suppose I should take a further stab and see just how
much of Nebula2 can or can't be wrapped automatically.  Get a sense of
whether it's 3 files and 3 constructs that are problematic, or zillions
of 'em.  Write my own little Python script to emit a lot of redundant,
boring filename.i files with #include filename.h %include filename.h
directives in them.

> > The reality is that 32 bit floats get used in the real
> > world all over the place by 3D graphics guys.
>
> Don't read that, Xavier.

Oh, is that about Xavier exploding if he hears 'real world' again?

> > The last time I tried to talk about 32 bit floats with
> > 'language guys'
> > was the Python crowd.  Generally speaking, that community
> > doesn't have a
> > clue about performance, and hasn't coughed up any significant 3D
> > graphics work either.
>
> I don't believe Python was designed for doing 3D graphics.

It wasn't.  It was designed to be flexible and easy to program, not
fast.  Now that Python is growing in popularity, people are coming in
post-hoc to try to make it fast.  Maybe in 3 years it'll be a good
language in that regard.

Another area where Python is unproven is large scale applications
development.  It has seen wonderful successes in distributed process
control, but large applications are a different beast.  A local guy who
works on the Chandler project says he sees no evidence that Python has
really proven itself in this arena.  Chandler is at the frontier.


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