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

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

[Jon Harrop]

This post of mine seems to have gone walkies:

On Mon, 7 Jun 2004, 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.

> However, lotsa 3D problems are exploratory in nature.  For those you
> want to use an efficient high level language, i.e. OCaml.  You'd like to
> code it up once, have it be pretty fast, and not ever worry about
> futzing with C <--> OCaml bureaucracy.  There isn't necessarily an
> 'array version' of the problem, and you may not wish to figure it out in
> any event.

If you don't want to "figure out" optimisations then you can't expect to
get efficient programs.

> C interfaces carry overhead, i.e. you'd rather have stuff go
> straight down to machine code without any function calls, if all you're
> doing is twiddling a few floats.

I'm not sure you would rather do that. Can you give an example of where
ocamlopt is so inefficient that a whole program could benefit
significantly from optimising such a piece of code?

> Basically it's not an answer to say "Ah, yes, look at this great
> language OCaml!" when in practice all you're ever doing is writing C.

I would expect to be dropping to C for only a tiny piece of (trivial to
write) code. If you want to do anything complicated (which is where all
the important optimisations are) then OCaml would be a much better choice.

> I'm not exactly sure why language designers think 32 bit floats "don't
> count."  Quite a number of high level languages make the choice of
> blowing them off.

Typically because the language designers know that other aspects of the
run-time will degrade performance significantly more.

> I guess quite a lot of high level languages aren't
> interested in widespread industrial application, just ease of compiler
> implementation.

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. ;-)

> 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.

> 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.

Most people want to write 3D graphics programs which run in real-time. In
order to even attempt to satisfy this design criterion it is necessary to
be close to the hardware - you need to know what it is capable of doing
and how quickly. This goes directly against one of the fundamental design
criteria of ML which is to "abstract from the machine".

On the other hand, well designed graphics software can generically make
very efficient use of modern, consumer graphics hardware from a high-level
language such as OCaml. When used correctly, the OpenGL API is quite
high-level. Also, it is much more effective (and interesting!) to spend
your time performing algorithmic optimisations rather than tweaking your
code at the 32-bit float level.

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

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

[Brandon J. Van Every]

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

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

[skaller]

On Wed, 2004-06-09 at 05:59, Brandon J. Van Every wrote:

> 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.

Felix does all three .. by design.
high level operations (eg closure formation,
pattern matching) are currently slower than Ocaml.
Low level ones are faster (because they just generate
raw C).

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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

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

[Brian Hurt]

Dropping into advocacy here.  I'd have taken this off-list but your email 
server doesn't like me.

On Tue, 8 Jun 2004, Brandon J. Van Every wrote:

> 
> 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

No language I am aware of that isn't specifically designed to be 
interfaced with C++ can interface with C++.  I'd imply that C++ was 
specifically deisgned to be hostile to other languages, but that would 
imply the standards committee was actually thinking through the 
implications of their decisions.  This includes, by the way, C.

Heck, even C++ compilers have trouble with C++.  Take a look at this paper 
comparing the conformance levels of various C++ compilers:
http://www.cs.clemson.edu/~malloy/projects/ddj/paper.pdf
The *best* compilers are still only 90% compliant.  And this isn't even 
touching the issue of name mangling differences.

I'll go a step farther than that, and state that it is *impossible* to 
write correct code in C++.  What gets churned out is reams of C++ code 
that simply isn't obviously broken.  Let's play a game, spot the bug.  Can 
you spot the bug hidding in these two lines of C++ code?  (and yes, 
Virginia, this bug *has* bitten me)
	char * buf1 = new char[100];
	char * buf2 = new char[100];

Interface with *C*, no problem.  Heck, how can a language do even the 
simplest of I/O without interfacing to C?  But C++?  I'm not sure I'd want 
to program in a language with a good interface to C++.

Oh, and by the way, in the opinion of every C++ advocate I know, you're 
not programming in C++ unless you're using both templates and the STL.  C 
with classes, after all, is just too much like C.

If the library you absolutely need (and can't rewrite) is written in C++,
then you probably should write the program in C++.  If you can use J2EE,
you should probably use Java.

> - the support of basic 3D graphics types, i.e. 32 bit floats

Hmm.  Silly me, I thought the basic 3D graphics types were vectors, 
matricies, and quaternions.

> 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

Let's see.  Been a while since I've read this paper.  His reasons are:

1) Compatibility.  By which he means with C and C++, and mainly, it seems, 
with C.  Ocaml is quite compatible with C.  As for C++, see above.

2) Libraries.  This is primarily a function of either a) rampant 
popularity, or b) major corporate backing.  In other words, functional 
languages are not popular because they're not popular.

3) Portability.  Having actually written portable C-89 code that ran
unmodified and without #ifdefs on everything from 8-bit embedded
controllers to supercomputers, this isn't as easy as people think it is.  
Of course, throw C99 into the mix and this level of portability goes out
the window (pop quiz: without ifdef's, how do you print out a size_t value
without truncation that works on both C89 and C99?  Remember that on C89
you doen't have inttypes.h, and on C99 sizeof(size_t) > sizeof(unsigned
long) is a distinct possibility- in fact, on 64 bits windows that is the
case). 

Note that this is for a language in which 100% conformance to the standard
is basically assumed.  C code isn't *portable*, it's simply *ported*.  
Where the mines are in this particular minefield are simply well known to 
those of who've ported C code.

4) Availability.  This seems to break down into three complaints: first, 
that installing Haskell is hard (it may very well be, I've never tried it.  
Compiling and installing Ocaml from scratch was a breeze even the first 
time I tried it).  Second is that there isn't a company to give money to.  
Which, I bet, is a function of popularity.  Were an open source compiler 
to become popular (like, oh, say GCC), companies would no doubt spring up 
to support it for money (like, oh, say, Cygnus).  And third, that the 
languages are still under active development.  Given C++'s history with 
standards, I'd consider C++ more of a moving target than Ocaml.

5) Packability.  Ocaml has it.  So does Haskell, by the way.

6) Tools.  Ocaml has a debugger and a profiler.  Fancy tools that cost 
$2000 a seat Ocaml doesn't have yet (and I question wether Ocaml needs).  
But the existence of $2000 a seat tools is a function of popularity- which 
means holding this lack against Ocaml is yet another case of Ocaml not 
being popular because Ocaml isn't popular already.

7) Training.  Most programmers don't already know functional programming 
languages, so they refuse to learn them.  Yet another variation on Ocaml 
not being popular because Ocaml isn't popular already.

8) Popularity.  Where he comes out and says Functional languages aren't 
popular because they aren't popular already.

Which raises the question of why *isn't* Ocaml more popular than it is?  
My theory is the following reasons:

1) Big words.  Most of the Ocaml books I've seen so far introduce topics 
like currying, higher order functions, and lambda calculus way to early.  
This scares off your average programmer.

2) Not Invented Here.  Specifically, Not Invented in Industry.  Eww-
research cooties!  The implicit assumption of your average programmer is
that people in academia never do "real" work, and wouldn't know it or
understand it if it bit them on the ass.  Never mind that writting and
maintaining a cross-platform optimizing compiler qualifies as real work,
they're certain that no one in academia would ever do something like that.  
At most, they think, an academic would just write a proof of concept,
allowing them to handwave past minor problems, and then promptly abandon
the code and return to writting proofs and journal papers.

3) Marketing.


> That's not automated C++ migration, 

When I was thinking of C++ integration, I wasn't even thinking 
automatically C++ integration.  I'm not sure that's possible in any sort 
of sane way even to C-  consider the memory management aspects.  Plus all 
the C++ specific problems, like templates.

> "We live in a world of very bright people building
> crappy software with total shit for tools and process."
>                                 - Ed Mckenzie

... and who are violent opposed to improving them.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
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

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

[skaller]

On Wed, 2004-06-09 at 14:08, Brian Hurt wrote:

> Which raises the question of why *isn't* Ocaml more popular than it is?  

Would you pay me to write come Ocaml code please???

> When I was thinking of C++ integration, I wasn't even thinking 
> automatically C++ integration.  I'm not sure that's possible in any sort 
> of sane way even to C-  consider the memory management aspects.  Plus all 
> the C++ specific problems, like templates.

Of course it's possible. Flxcc is already processing template
free C++ (not correctly though). Sure it targets Felix at the moment
but I don't see any real issue targetting Ocaml.

To a large extent C++ is just syntactic sugar for C,
so what's the big deal? Exceptions are just about the only
really nasty feature, and wrappers can fix that easily
if you're willing to be a bit bloody minded about them.
[try .. catch (..) abort(1) :]

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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

[Caml-list] popular for being popular

[Brandon J. Van Every]

Brian Hurt wrote:
>
> Oh, and by the way, in the opinion of every C++ advocate I
> know, you're
> not programming in C++ unless you're using both templates and
> the STL.  C with classes, after all, is just too much like C.

I did tons of complicated multiple inheritance templates with virtual
base classes back in 1993, to the limit of what the language was capable
of at the time.  I made no money from it and concluded that I had
completely wasted my time.  Years later, this has affected my
willingness to swallow STL.  The accident of history is I never learned
STL, because back in the day it wasn't so standard.

> > - the support of basic 3D graphics types, i.e. 32 bit floats
>
> Hmm.  Silly me, I thought the basic 3D graphics types were vectors,
> matricies, and quaternions.

You don't do any DirectX programming do you?  Nor shader programs
either, I imagine.  32 bits is "the really accurate stuff."  The high
resolution rendering frontier is 128-bit color.  It's not and ain't
gonna be 256-bit color for the next 10 years at least.

> 2) Not Invented Here.  Specifically, Not Invented in Industry.  Eww-
> research cooties!  The implicit assumption of your average
> programmer is
> that people in academia never do "real" work, and wouldn't know it or
> understand it if it bit them on the ass.  Never mind that writting and
> maintaining a cross-platform optimizing compiler qualifies as
> real work,
> they're certain that no one in academia would ever do
> something like that.
> At most, they think, an academic would just write a proof of concept,
> allowing them to handwave past minor problems, and then
> promptly abandon
> the code and return to writting proofs and journal papers.

Forget theory, where's proof?  There's no OCaml 3D graphics engine out
there.  I'm on the frontier.  There's nothing proving OCaml's any good
at 3D graphics at all.  I just have some faith in it because of its
performance capabilities in other areas.

OCaml is proven at language transformation problems.  Nobody in industry
cares about this.

Academics *don't* do real work.  They do research problems, and real
(i.e. boring) work is regarded as uninteresting.  (And rightly so.)  It
isn't pursued to the degree necessary for industrial support.  Frankly
you gotta just pay people to do that kind of gruntwork, it's not fun.
Ideally one would look to have an academic-industrial partnership.  I
believe we've been over this ground before, on the subject of core
language capabilities vs. standard libraries.  I hope someone has the
energy to move forwards on that... I don't.  I'm worried about 3D
graphics engines, not (boring) industrial support.

There's the impulse to do research, and then there's the impulse to
achieve widespread industrial relevance.  They are not the same impulse.

> 3) Marketing.

So where's the Marketing?  If you've got zero marketing, then nobody
cares about you.  I've been through it with the Python crowd about
marketing.  They're way farther along the evolutionary succession of
marketing than you guys are, and they still totally suck.  Hopefully you
don't have anything remotely resembling Guido's foibles though.  If he
would just refrain from exercising his prejudicial aesthetic judgement
on language logos and just get the hell outta the way of people who
actually have talent for the enterprise... but it didn't happen, and it
won't happen.  Nobody's going to try again with those PSF Dilberts for a
few years yet.

I don't think open source techies are even vaguely capable of marketing.
In this arena I'm utterly contemptuous of them.  Aside from personal
experience, I see abundant evidence in Myers-Briggs Type Indicators as
to why they're this way.  A technology simply has to advance,
technologically, among techies, until it's finally worth enough money to
suits that they step in and take over.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

---
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

Re: [Caml-list] popular for being popular

[Brian Hurt]

On Wed, 9 Jun 2004, Brandon J. Van Every wrote:

> > 2) Not Invented Here.  Specifically, Not Invented in Industry.  Eww-
> > research cooties!  The implicit assumption of your average
> > programmer is
> > that people in academia never do "real" work, and wouldn't know it or
> > understand it if it bit them on the ass.  Never mind that writting and
> > maintaining a cross-platform optimizing compiler qualifies as
> > real work,
> > they're certain that no one in academia would ever do
> > something like that.
> > At most, they think, an academic would just write a proof of concept,
> > allowing them to handwave past minor problems, and then
> > promptly abandon
> > the code and return to writting proofs and journal papers.
> 
> Forget theory, where's proof?  There's no OCaml 3D graphics engine out
> there.  I'm on the frontier.  There's nothing proving OCaml's any good
> at 3D graphics at all.  I just have some faith in it because of its
> performance capabilities in other areas.
> 

I will cop to not having a lot of experience in 3D graphics.  On the other
hand, I talk to people in a lot of different areas of the computing
industry.  First off, the vast majority of programmers have no need for
floating point numbers at all.  Second, I have two nuclear-family members
who work in the CAD-CAM industry, and a third who does numeric simulations
(for the military, btw).  And (this issue having come up before), none of
them bother to use single-precision floating point except when an external
API (directX) demands it.  So while the games industry may be all over
single-precision, other users of 3D rendering aren't.

> OCaml is proven at language transformation problems.  Nobody in industry
> cares about this.

Yep.  There being no money in compilers.


> Academics *don't* do real work.  They do research problems, and real
> (i.e. boring) work is regarded as uninteresting.  (And rightly so.)  It
> isn't pursued to the degree necessary for industrial support.  Frankly
> you gotta just pay people to do that kind of gruntwork, it's not fun.
> Ideally one would look to have an academic-industrial partnership.  I
> believe we've been over this ground before, on the subject of core
> language capabilities vs. standard libraries.  I hope someone has the
> energy to move forwards on that... I don't.  I'm worried about 3D
> graphics engines, not (boring) industrial support.
> 
> There's the impulse to do research, and then there's the impulse to
> achieve widespread industrial relevance.  They are not the same impulse.
> 

Obviously my dripping saracasm wasn't dripping enough.  Frankly, I 
consider writting a multi-platform optimizing compiler (like, say, 
ocamlopt) and maintaining it for a decade or more to be more "real" work 
than writting some game that'll have a six month shelf life (if you're 
lucky).

And this is *exactly* the attitude I was talking about.  "Academics can't 
do real work- if they could, they'd be doing real work and not research!"

> > 3) Marketing.
> 
> So where's the Marketing?  If you've got zero marketing, then nobody
> cares about you.  I've been through it with the Python crowd about
> marketing.  They're way farther along the evolutionary succession of
> marketing than you guys are, and they still totally suck.  Hopefully you
> don't have anything remotely resembling Guido's foibles though.  If he
> would just refrain from exercising his prejudicial aesthetic judgement
> on language logos and just get the hell outta the way of people who
> actually have talent for the enterprise... but it didn't happen, and it
> won't happen.  Nobody's going to try again with those PSF Dilberts for a
> few years yet.
> 
> I don't think open source techies are even vaguely capable of marketing.
> In this arena I'm utterly contemptuous of them.  Aside from personal
> experience, I see abundant evidence in Myers-Briggs Type Indicators as
> to why they're this way.  A technology simply has to advance,
> technologically, among techies, until it's finally worth enough money to
> suits that they step in and take over.

Perl and python have gained widespread adoption despite not being
corporate financed.  I go down to my local book store, and what do I see?  
Shelf after shelf of books on C++, Java, Perl, C#, and VB.  If I go
hunting for it, I might find a book on lisp or scheme tucked away in a
corner- I have yet to go into a bookstore and find a book on Ocaml (I
look).  I go to the magazine rack, and what do I see?  Half a dozen (or
more) magazines on C++ and Java programming, 2-3 each on VB and Perl, and
an increasing number on C#.

This is advertising.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
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

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

[Xavier Leroy]

> > 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.

I must stay I've stopped reading a while ago :-)

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, mention what
could conceivably be done in OCaml at minimal implementation costs,
discuss SSE2 a bit, and generally answer the OP's initial questions.

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, on top of the usual Felix advertising and C++ discussions.

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.

- Xavier Leroy

-------------------
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

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

[Christophe TROESTLER]

On Wed, 9 Jun 2004, Xavier Leroy <xavier.leroy@inria.fr> 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, mention
> what could conceivably be done in OCaml at minimal implementation
> costs, discuss SSE2 a bit, and generally answer the OP's initial
> questions. [...] Then I decided not to post.

Please consider to do it for those, like me, who always learn a lot
from this kind of posts.

Cheers,
ChriS

-------------------
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

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

[Daniel Ortmann]

Yes, please.  I also would like to read your reply.


Christophe TROESTLER <Christophe.Troestler@umh.ac.be> writes:

> On Wed, 9 Jun 2004, Xavier Leroy <xavier.leroy@inria.fr> 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, mention
> > what could conceivably be done in OCaml at minimal implementation
> > costs, discuss SSE2 a bit, and generally answer the OP's initial
> > questions. [...] Then I decided not to post.

> Please consider to do it for those, like me, who always learn a lot
> from this kind of posts.

-- 
Daniel Ortmann, LSI Logic, 3425 40th Av NW, Suite 200, Rochester MN 55901
work: Daniel.Ortmann@lsil.com / 507.535.3861 / 63861 int / 8012.3861 gdds
home: ortmann@venturecs.net / 507.288.7732, 2414 30Av NW #D, Rochester MN 55901
gpg/pgp public key: http://wwwkeys.us.pgp.net
jabber: daniel_ortmann@jabber.org / dortmann@jabber.co.lsil.com

-------------------
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

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

[Kenneth Knowles]

I'll add my vote; I find Xavier's occasional comments to be the highlight of the
mailing list.  Kind of like some zen priest who disarms an angry mob with a
single phrase...

On Wed, Jun 09, 2004 at 01:15:09PM -0500, Daniel Ortmann wrote:
> Yes, please.  I also would like to read your reply.
> 
> 
> Christophe TROESTLER <Christophe.Troestler@umh.ac.be> writes:
> 
> > On Wed, 9 Jun 2004, Xavier Leroy <xavier.leroy@inria.fr> 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, mention
> > > what could conceivably be done in OCaml at minimal implementation
> > > costs, discuss SSE2 a bit, and generally answer the OP's initial
> > > questions. [...] Then I decided not to post.
> 
> > Please consider to do it for those, like me, who always learn a lot
> > from this kind of posts.
> 
> -- 
> Daniel Ortmann, LSI Logic, 3425 40th Av NW, Suite 200, Rochester MN 55901
> work: Daniel.Ortmann@lsil.com / 507.535.3861 / 63861 int / 8012.3861 gdds
> home: ortmann@venturecs.net / 507.288.7732, 2414 30Av NW #D, Rochester MN 55901
> gpg/pgp public key: http://wwwkeys.us.pgp.net
> jabber: daniel_ortmann@jabber.org / dortmann@jabber.co.lsil.com
> 
> -------------------
> 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

-------------------
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

RE: [Caml-list] popular for being popular

[Brandon J. Van Every]

Brian Hurt wrote:
>
> So while the games industry may be all over
> single-precision, other users of 3D rendering aren't.

Your analysis is correct.  However, games were a $31 billion industry
last I looked a couple of years ago, so to pooh pooh its industrial
concerns is silly.  Actually, what really puzzles me the most is why
Microsoft hasn't added 64-bit floats to the DirectX API.  It's all
they'd need to chase the high end markets and put OpenGL to bed.  Maybe
it's XBox politics... they don't want DirectX on the PC to get too far
ahead of DirectX on the XBox.

> > Academics *don't* do real work.  They do research problems, and real
> > (i.e. boring) work is regarded as uninteresting. (And rightly so.)
> >
> > There's the impulse to do research, and then there's the impulse to
> > achieve widespread industrial relevance.  They are not the
> > same impulse.
>
> Obviously my dripping saracasm wasn't dripping enough.  Frankly, I
> consider writting a multi-platform optimizing compiler (like, say,
> ocamlopt) and maintaining it for a decade or more to be more
> "real" work
> than writting some game that'll have a six month shelf life
> (if you're lucky).

Newsflash: a six month shelflife is more industrial relevance than OCaml
has achieved.  I wouldn't suggest to industrial game programmers that
they're not doing 'real' work.  They're usually pretty stressed out
after their 10..14 hour days and wouldn't take it too well.  A lot of
people out there are obeying the dictates of the product cycle.
Cutting code, shipping product is what most of the real world of boring
gruntwork amounts to.

If you had made your comparison in terms of 'sustained work' or 'high
quality work', I'd have a basis for agreeing with you.  The game
industry is definitely throwaway and dysfunctional, which is why I'm not
part of it.

> And this is *exactly* the attitude I was talking about.
> "Academics can't
> do real work- if they could, they'd be doing real work and
> not research!"

It's calling a spade a spade.  Industrialists aren't operating on
assumptive theory like you suggest.  They're looking at what academics
have actually gotten done, and seeing that their products are wanting in
key respects.  An industrialist wants to know, "Does it work?  Does it
solve my problem?"  If your answer is 'no', don't make excuses about it.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

---
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

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

[Brandon J. Van Every]

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

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

[John Carr]

> I'll add my vote; I find Xavier's occasional comments to be the
> highlight of the mailing list.

I think it's clear where he was headed: a general purpose 32 bit float
type with 32 bit floating point arithmetic is not sufficiently useful
to justify the implementation effort.  As a general rule, on modern
processors operations on 32 bit floats are not faster than operations
on 64 bit floats.  32 bit float scalars do not save much space.

32 bit floats would be useful for three reasons:

1. If vector operations could be done on 32 but not 64 bit
quantities.  Scalar is about the same speed.  SSE could be
helpful but I think you would need significant work in the
code generator.

2. To save space in large data structures.  Bigarray is already
available for this purpose.

3. To save space when many medium-size structures are allocated.
A float32 record/array type would be helpful.

-------------------
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