[Caml-list] 32 bit floats, SSE instructions

[Caml-list] 32 bit floats, SSE instructions

[Brandon J. Van Every]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

Game developers do tons of stuff with 32 bit floats.  How difficult to
add these to OCaml?  I'm not saying, "do it for me," I'm asking how
difficult it would be to add to the language.  If it were feasible, then
this mod could be distributed as a patch, until such a time as it is
accepted as A Good Thing.  (Anyone already tried this?)

Does the lack of operator overloading pretty much prevent this support
in practice?  If there's only one +. operator available, and it's for 64
bit floats, whaddya gonna do?

SSE instructions I imagine would be more involved.  The data type I'm
interested in is a vector of 4 32 bit floats.  Sounds like another job
for operator overloading.


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
 

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2216 bytes --]

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

[Christophe TROESTLER]

On Mon, 7 Jun 2004, "Brandon J. Van Every" <vanevery@indiegamedesign.com> wrote:
> 
> Game developers do tons of stuff with 32 bit floats.  How difficult
> to add these to OCaml?

The Int32 module is not enough for you?  Please explain why.

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

[Christophe TROESTLER]

> On Mon, Jun 07, 2004 at 01:32:12PM +0200, Christophe TROESTLER wrote:
> > On Mon, 7 Jun 2004, "Brandon J. Van Every" <vanevery@indiegamedesign.com> wrote:
> > > Game developers do tons of stuff with 32 bit floats.  How difficult
> > > to add these to OCaml?
> > 
> > The Int32 module is not enough for you?  Please explain why.
> 
> I think he needs floats, not ints...

OOOps, read too fast.

If you need a selected number of routines using 32 bits floats,
implement them in C and interface them to OCaml.  But this could be
slow depending of what you want to do -- i.e. maybe you want to use
OCaml for higher level stuff?  Could you please provide more details ?

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

[brogoff]

On Mon, 7 Jun 2004, Brandon J. Van Every wrote:
> Game developers do tons of stuff with 32 bit floats.  How difficult to
> add these to OCaml?  I'm not saying, "do it for me," I'm asking how
> difficult it would be to add to the language.  If it were feasible, then
> this mod could be distributed as a patch, until such a time as it is
> accepted as A Good Thing.  (Anyone already tried this?)

Bigarray supports 32 bit floats (note to Christophe, he said 32 bit floats, not
32 bit ints!). Since the main use of Bigarray is to interface to C and Fortran,
you can take this as an implicit suggestion to write those parts of your
code in C. Sorry.

I don't think the lack of true overloading (GCaml, where art thou?) is the
problem, you can always make up some new operators for 32 bit floats. Yes,
I'd prefer overloading, but that isn't a showstopper. In any case, certain
members of the Caml cabal have commented that they are in favor of
overloading, but as usual, they want to do it right, so we may need to wait
quite a while before we see it. There is already a GCaml branch in the CVS
tree.

I think the real problem with floats (pun intended) and doubles and chars and
all that is that you frequently get unwanted boxing in OCaml and other such
languages. This will of course lead to reduced performance, which, if I
understand the game programming realm, is generally unacceptable.

I don't think that problem is insurmountable. I spoke with Stephen Weeks about a
year ago and he was interested in doing an OCaml front end for MLton, but since
he's a lean fellow and needs to eat, he was also interested in remuneration. In
case you don't know, MLton is a whole program optimizing compiler for SML which
supports

    "Untagged native integers and words of many sizes, unboxed reals, and
     unboxed arrays."

which I think is what you want for coding some of the high performing parts of
games and many other apps.

> Does the lack of operator overloading pretty much prevent this support
> in practice?  If there's only one +. operator available, and it's for 64
> bit floats, whaddya gonna do?

+@, -@, etc., etc.

> SSE instructions I imagine would be more involved.  The data type I'm
> interested in is a vector of 4 32 bit floats.  Sounds like another job
> for operator overloading.

C doesn't support this either, yet people get by. I'm not making excuses for the
lack of a desirable (IMO too) feature, just pointing out that the absence of
overloading isn't the big problem here.

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

[Brandon J. Van Every]

Christophe TROESTLER wrote:
>
> If you need a selected number of routines using 32 bits floats,
> implement them in C and interface them to OCaml.  But this could be
> slow depending of what you want to do -- i.e. maybe you want to use
> OCaml for higher level stuff?  Could you please provide more details ?

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.

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

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'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.  I guess quite a lot of high level languages aren't
interested in widespread industrial application, just ease of compiler
implementation.  The reality is that 32 bit floats get used in the real
world all over the place by 3D graphics guys.  That has something to do
with it being a core capability of many CPUs and an IEEE standard.  64
bit floats cost twice as much memory, are much slower for division and
square rooting, and in many applications the extra precision is not
needed.

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.


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

[Nicolas Cannasse]

> 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'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.  I guess quite a lot of high level languages aren't
> interested in widespread industrial application, just ease of compiler
> implementation.  The reality is that 32 bit floats get used in the real
> world all over the place by 3D graphics guys.  That has something to do
> with it being a core capability of many CPUs and an IEEE standard.  64
> bit floats cost twice as much memory, are much slower for division and
> square rooting, and in many applications the extra precision is not
> needed.

The main problem with float's - whatever if they are 32 or 64 bits - is
their boxing . OCaml runtime value representation is efficient but a float -
even 32 bits - cannot be carried in a register as it could be in C.
(actually some unboxing can be performed locally by ocamlopt). This is
mainly because OCaml is an high-level language, with a garbage collector,
and so needs to keep the track of what is being allocated in an efficient
way. Did you imagine having an higher level programming language for free ?
So yes maybe OCaml is not the best language to perform floating point
operations, although the cost of boxing is actually quite small compared to
the power of implementing easily more efficient algorithms. That's why you
should perform batched operations in C - using 32bits float if you want -
and manipulate your 64-bits vectors on the Ocaml side.

> 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 guess that people who're refcounting don't care about performances :)

Nicolas Cannasse


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

[Richard Jones]

Is there not any work on allowing inline asm in OCaml?

Since ocamlopt can inline code from modules, would it be possible to
create a 'fake' .cmx/.o file which would actually contain direct
assembler code to be inlined?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

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

[Jon Harrop]

On Mon, 7 Jun 2004, Richard Jones wrote:
> Is there not any work on allowing inline asm in OCaml?
>
> Since ocamlopt can inline code from modules, would it be possible to
> create a 'fake' .cmx/.o file which would actually contain direct
> assembler code to be inlined?

Can we not do more to integrate OCaml with BCPL? Just kidding...

Seriously though, would there be any value in, and would it be easy to,
make the OCaml backend, particularly the optimiser, pluggable to avoid the
copyright issues of reabsorbing code in the core OCaml distribution?
Then effort spent writing more mundane optimisers (from a research point
of view) could be done by third parties.

Personally, I'd like to see much more efficient handling of arbitrary
precision numbers and better optimisation of a handful of small routines
(which could be special cased) at the assembler 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

[Chris Clearwater]

Have you looked at MLTon (www.mlton.org)?  It supports unboxed {32,64}
bit floats and {8,16,32,64} bit integers. Arrays of these are unboxed
as well and can be of size 2 ** 31 - 1. It also has a very fast C FFI
with preliminary bindings to OpenGL.

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

On Mon, 7 Jun 2004, Brandon J. Van Every wrote:

> Game developers do tons of stuff with 32 bit floats.  How difficult to
> add these to OCaml?  I'm not saying, "do it for me," I'm asking how
> difficult it would be to add to the language.  If it were feasible, then
> this mod could be distributed as a patch, until such a time as it is
> accepted as A Good Thing.  (Anyone already tried this?)

The biggest problem you'd have is that you couldn't unbox them, so every 
individual fp number would be 8 bytes (at least- 12 bytes on 64-bit 
systems).

No, what game developers use a lot of is 3- and 4-element vectors, and 3x3 
and 4x4 matricies.  Dealing with them as vectors and matricies instead of 
individual floats would be a lot better- now, a 3-vector would take only 
16 or 20 bytes of memory.  Actually, I'd be inclined to go one step 
higher, and deal with arrays of vectors in what Intel calls SoA order 
(i.e. structure of arrays, instead of array of structures- so an array of 
3-vectors would be represented by three arrays- the first array is the x 
values of all vectors, the second is the y values, etc.).  This makes 
maximizing the utilization of the SSE units a lot easier.

> 
> Does the lack of operator overloading pretty much prevent this support
> in practice?  If there's only one +. operator available, and it's for 64
> bit floats, whaddya gonna do?

Use some other operator.  While you can't overload operators, you can 
define new ones.

Just my $0.02.

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

[Brandon J. Van Every]

Brian Hurt wrote:
> Actually, I'd be inclined to go one step
> higher, and deal with arrays of vectors in what Intel calls SoA order
> (i.e. structure of arrays, instead of array of structures- so
> an array of
> 3-vectors would be represented by three arrays- the first
> array is the x
> values of all vectors, the second is the y values, etc.).  This makes
> maximizing the utilization of the SSE units a lot easier.

At the cost of inverting almost everyone's software architecture.  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?  If you only want to do SoA "for some array length, then
start over," just how segmented did you think I wanted my programming
model to be?

SoA might make sense if a language implementation did it totally behind
the scenes, presenting a seemingly AoS interface to programmers.
Exposing / locking into SoA is dumb, and yes, Intel is damn dumb.  You
don't think they're dumb, look at their chips.  They're good at fab and
marketing, they make lousy tack-on "kitchen sink" chips.


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

[Brandon J. Van Every]

Nicolas Cannasse wrote:
>
> The main problem with float's - whatever if they are 32 or 64
> bits - is
> their boxing . OCaml runtime value representation is
> efficient but a float -
> even 32 bits - cannot be carried in a register as it could be in C.
> (actually some unboxing can be performed locally by ocamlopt). This is
> mainly because OCaml is an high-level language, with a
> garbage collector,
> and so needs to keep the track of what is being allocated in
> an efficient
> way. Did you imagine having an higher level programming
> language for free ?

Sounds like someone decided to pay for efficiency with uncleanliness.
That is not the only way to pay for things.  One could instead, for
instance, pay with a more difficult implementation.

> So yes maybe OCaml is not the best language to perform floating point
> operations, although the cost of boxing is actually quite
> small compared to
> the power of implementing easily more efficient algorithms.

The old "ah, let the algorithm deal with it!" saw.  Yawn.

> That's why you
> should perform batched operations in C - using 32bits float
> if you want -
> and manipulate your 64-bits vectors on the Ocaml side.

Since when are all numeric problems batch problems?  Batching in C is
only practical when problems are simple and highly repetitive.  What a
3D graphics guy often really wants, is the ability to inline a bunch of
function "pipeline" stages into one fairly complicated function.  The
transitions between pipeline stages should all be optimized together.


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

[Keith Wansbrough]

> The main problem with float's - whatever if they are 32 or 64 bits - is
> their boxing . OCaml runtime value representation is efficient but a float -
> even 32 bits - cannot be carried in a register as it could be in C.
> (actually some unboxing can be performed locally by ocamlopt). This is
> mainly because OCaml is an high-level language, with a garbage collector,
> and so needs to keep the track of what is being allocated in an efficient
> way. Did you imagine having an higher level programming language for free ?

Oh, come on.  GHC has no problems with garbage-collecting floats in
the heap.  It also has no problems unboxing them, and does a
reasonable job (IIRC) of storing them in registers, just as in C.
Haskell has both Float (32 bit) and Double (64 bit).  Just because
OCaml doesn't handle them, doesn't mean no high-level programming
language can.

> Nicolas Cannasse

--KW 8-)

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

On Mon, 7 Jun 2004, Brandon J. Van Every wrote:

> At the cost of inverting almost everyone's software architecture.  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?  If you only want to do SoA "for some array length, then
> start over," just how segmented did you think I wanted my programming
> model to be?
> 
> SoA might make sense if a language implementation did it totally behind
> the scenes, presenting a seemingly AoS interface to programmers.
> Exposing / locking into SoA is dumb, and yes, Intel is damn dumb.  You
> don't think they're dumb, look at their chips.  They're good at fab and
> marketing, they make lousy tack-on "kitchen sink" chips.
> 

You're right.  The only computations which are a) regular enough and b)  
common enough to make it *possibly* worthwhile to consider the contortions
SoA order would entail are if you are doing openGL in software.  At which
point the guy who is just handing those computations over to his $60
graphics card is stomping your butt.

Forget I said that.

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

[art yerkes]

On Tue, 8 Jun 2004 10:05:12 -0500 (CDT)
Brian Hurt <bhurt@spnz.org> wrote:

> On Mon, 7 Jun 2004, Brandon J. Van Every wrote:
> 
> > At the cost of inverting almost everyone's software architecture.  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?  If you only want to do SoA "for some array length, then
> > start over," just how segmented did you think I wanted my programming
> > model to be?
> > 
> > SoA might make sense if a language implementation did it totally behind
> > the scenes, presenting a seemingly AoS interface to programmers.
> > Exposing / locking into SoA is dumb, and yes, Intel is damn dumb.  You
> > don't think they're dumb, look at their chips.  They're good at fab and
> > marketing, they make lousy tack-on "kitchen sink" chips.
> > 

On this topic, you can easily make a C-accessible array of unboxed 32-bit
floats using bigarray.

-- 
Hey, Adam Smith, keep your invisible hands to yourself!

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

[Jon Harrop]

On Tuesday 08 June 2004 06:42, Brandon J. Van Every wrote:
> ... What a
> 3D graphics guy often really wants, is the ability to inline a bunch of
> function "pipeline" stages into one fairly complicated function.  The
> transitions between pipeline stages should all be optimized together.

Can you give an example of this?

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

[Jon Harrop]

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 <cache sized 
regions) the performance must necessarily suffer regardless of the data 
structure. For sequential algorithms over sequences of any reasonable size, 
the performance will be virtually the same.

> 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

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

[Brandon J. Van Every]

Jon Harrop
> Brandon J. Van Every wrote:
> > [SoA is performed]
> > 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.

What utter nonsense!  You ever written a 3D device driver?  You do *not*
engineer your most basic data structures for infinite flexibility.
Almost nobody has the luxury of defining things so abastractly that they
can switch SoA for AoS whenever they like.  It's a highly invasive
change of programming model.

The experiment of SoA has been tried in the 3D graphics industry and
found wanting.  All the HW is AoS.  The SoA methodology is possible with
the 3D APIs.  As one poster hinted, it's probably borne of the software
rendering era mentality.  I distinctly recall when the DirectX 5.0 guys
were implementing those features, shortly after the OpenGL guys did
IIRC.  That would have been a 1997 timeframe.  They were thinking how
"neat" it would all be.  Seen from the vantage of 2004, it all gave way
to AoS and programmable shaders.  All your data for one vertex or one
pixel at a time.

> 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

Oh, the 'only' algorithms.  Crikey.  You ever written a 3D graphics
pipeline???  You think it's all based on handing over some huge matrix
that could jolly well be in whatever order?  Get real.  The vast
majority of 3D graphics processing is accept / reject testing.  You want
your data here, now, so you can decide what to do with it.  So you can
retire it once you're done deciding, and not have it pollute your cache
any further.


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

[Brandon J. Van Every]

Jon Harrop
Brandon J. Van Every wrote:
> > ... What a
> > 3D graphics guy often really wants, is the ability to
> > inline a bunch of
> > function "pipeline" stages into one fairly complicated
> > function.  The
> > transitions between pipeline stages should all be optimized
> > together.
>
> Can you give an example of this?

I'm feeling mentally challenged on specifics rigth now.  Generally
speaking, 3D graphics problems are pipelines with N stages you might
turn on or off.  This creates 2^N path possibilities.  Often you'd like
to coalesce the operations at the various stages.


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

[Jon Harrop]

On Tuesday 08 June 2004 20:24, Brandon J. Van Every wrote:
> ...
> What utter nonsense!

Yo Mama.

> You ever written a 3D device driver? 

Are you trying to write a device driver in OCaml?

> You do *not* 
> engineer your most basic data structures for infinite flexibility.

You appear to be approximating the two in "two transpose formats" with 
infinity. Are you an astrophysicist?

> Almost nobody has the luxury of defining things so abastractly that they
> can switch SoA for AoS whenever they like.  It's a highly invasive
> change of programming model.

I think you are exaggerating cost of the "abstraction" of reordering the 
arguments of a function.

> The experiment of SoA has been tried in the 3D graphics industry and
> found wanting.  All the HW is AoS.

Apart from that "CPU" thing. ;-)

> The SoA methodology is possible with 
> the 3D APIs.  As one poster hinted, it's probably borne of the software
> rendering era mentality.  I distinctly recall when the DirectX 5.0 guys
> were implementing those features, shortly after the OpenGL guys did
> IIRC.  That would have been a 1997 timeframe.  They were thinking how
> "neat" it would all be.  Seen from the vantage of 2004, it all gave way
> to AoS and programmable shaders.  All your data for one vertex or one
> pixel at a time.

My point is that there are likely to be much more productive, higher-level 
optimisations that you could be doing.

> > 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
>
> Oh, the 'only' algorithms.  Crikey.

Are you saying that most of your algorithms require random access of that 
form? Can these algorithms not be transformed so that they access more 
coherently?

> You ever written a 3D graphics pipeline???

I have dabbled in 3D graphics.

> You think it's all based on handing over some huge matrix 
> that could jolly well be in whatever order?

That is the objective, yes.

> Get real. 

Well, you're hardly going to be using complex numbers to represent vertex 
coordinates... ;-)

> The vast 
> majority of 3D graphics processing is accept / reject testing.  You want
> your data here, now, so you can decide what to do with it.  So you can
> retire it once you're done deciding, and not have it pollute your cache
> any further.

I'd like more, specific examples here. What determines the accept or reject? 
What is the consequence of an accept or reject?

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

The task of optimising 3D graphics software is to design your approach such 
that you don't need the results back, and all further computation occurs on 
the card. You make as much of the data available as possible and control data 
flow through the pipeline at the highest level with state changes.

If your programs are bottlenecked by lots of very low-level arithmetic over 
huge, flat data structures then you will almost certainly benefit from using 
more structured, hierarchical (ideally, multiresolution) representations. 
Derive the (possibly asymptotic) complexities of any suitable algorithms and 
make an educated decision on the basis of that quantification. This is likely 
to give you much better performance than very low-level optimisations such as 
fiddling with 32-bits floats.

> Hint: commodity 3D graphics cards are fast when you write to 
> them, damn slow when you read them, by design.

In general, you can't read the results of T&L from the card (sorry for being 
so off topic, guys) so the driver resorts to software T&L in OGL feedback 
mode.

If you absolutely must use flat data structures then perhaps you should 
consider using the GPU as a CPU.

> 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

Why C++? Is your objective to always prototype in OCaml and convert to C++?

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

Why not "ease of use of trees, graphs etc."? Algorithmic optimisations are so 
much more productive...

> - ability to work with imperative, object oriented designs and libraries

OO is overrated, IMHO. Imperative is excusable for UI level things but I'd 
prefer a functional style for everything but the simplest of algorithms. 
OCaml can play with libraries fairly well but, yes, it takes a lot of time to 
get some things working. That isn't the fault of the OCaml creators though, 
of course, it's the fault of those dim-wits at Bell Labs...

> 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

Speak of the devil.

> 1.5 out of 3 if one considers OCaml SWIG to be an available, slow,
> optimizeable path.

Given the huge differences between C/C++ and OCaml (like safety), it would be 
overly optimistic to expect migration of code from OCaml to C to be much more 
efficient than it is now.

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

Yes, but the OCaml bit of SWIG is very alpha, AFAIK. SWIG wasn't even designed 
to deal with languages like OCaml.

Just out of curiosity, do you use the STL much? An interface to the STL might 
be interesting. I wouldn't use it any more though - I no longer have any need 
for C++.

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

Yes. Personally, I think the INRIA are doing a superb job with OCaml. It is an 
excellent implementation of an excellent language. I do all of my work in 
OCaml now. I'm getting offered jobs because I am so much more productive as a 
consequence. The programs I write whilst doing my 3D graphics research are 
more robust and faster than ever now that they have been converted entirely 
into OCaml from C++.

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

I'm no expert, but I suspect there are numerous, rigorous theoretical reasons 
why it can't be made much more efficient (at least not by people who choose 
to program in Python ;-).

> > ...
> > Can you give an example of this?
>
> I'm feeling mentally challenged on specifics rigth now.  Generally
> speaking, 3D graphics problems are pipelines with N stages you might
> turn on or off.  This creates 2^N path possibilities.  Often you'd like
> to coalesce the operations at the various stages.

So you've got a large quantity of data in flat containers like arrays which 
you want to perform a sequence of algorithms on?

What sort of data is in the containers and what sorts of algorithms are you 
performing?

Is the problem that you would like to hoist the inner loops of all of the 
algorithms so that each datum has each algorithm applied to it rather than 
feeding all of the data through each algorithm in turn (i.e. deforestation)?

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

[Caml-list] 3D graphics debate

[Brandon J. Van Every]

I'm gonna break this into 2 posts, 'cuz I think the 3D graphics debate
should be separated and then die.

Jon Harrop wrote:
> Brandon J. Van Every wrote:
> > ...
> > What utter nonsense!
>
> Yo Mama.

Yo mamma duzn' like yu an dressus yu funny.

> > You ever written a 3D device driver?
>
> Are you trying to write a device driver in OCaml?

3D device driver problems are indicative of graphics problems in
general.  There's not much 'new' at any level of the game.  Just things
that have been committed to HW vs. things that are still waiting to be
committed to HW, with some interrupting complexities in between.
Traversing a cell grid database is no different from rasterizing a
triangle.  3D graphics is one giant self-similar fractal.

> > You do *not*
> > engineer your most basic data structures for infinite flexibility.
>
> You appear to be approximating the two in "two transpose
> formats" with infinity. Are you an astrophysicist?

I don't know why on Earth you'd describe "transposing a matrix" as
representative of implementation options for arbitrary classes of
algorithms.

> > Almost nobody has the luxury of defining things so
> > abastractly that they
> > can switch SoA for AoS whenever they like.  It's a highly invasive
> > change of programming model.
>
> I think you are exaggerating cost of the "abstraction" of
> reordering the arguments of a function.

And I'm thinking you've never done high performance anything in a big
architecture for a living.  Prove me wrong.

> > The experiment of SoA has been tried in the 3D graphics industry and
> > found wanting.  All the HW is AoS.
>
> Apart from that "CPU" thing. ;-)

I suppose you think CPU approaches are divorced from the realities of
what underlying HW expects?  You want to retire things quickly, you
don't spread them out all over memory.  Not unless you've got some kind
of super duper programmer visible scatter-gather DMA, and I'm not aware
of anyone building PCs in such configurations.

> My point is that there are likely to be much more productive,
> higher-level optimisations that you could be doing.

It is a wasted point.  Performance jock do that *and* the low-level
optimizations.  The key is sane architecture so you don't have to do
more than a handful of low-level optimizations.

>
> > > 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
> >
> > Oh, the 'only' algorithms.  Crikey.
>
> Are you saying that most of your algorithms require random
> access of that form?

No, I said that *in addition to* that rather common class of algorithms,
even sequential processing is usually accept / reject.  Let's say you've
got SoA for a 4-field vector.  When you accept, you're going to be
touching all 4 arrays.  If you often accept, then your cache is going to
be polluted by all the rejects.  You have made your problem 4 times less
cache coherent than it otherwise would be.  The reality of 3D graphics
processing is you usually need all that info in the structure.  That's
why it's a structure.

> Can these algorithms not be transformed so that they
> access more coherently?

No, dammit!  You Just Don't Get It [TM].  When someone tells you
something is "an invasive programming model," they're telling you
they're not looking for the opportunity to rewrite their whole software
architecture from scratch just because you personally think SoA might be
more kewl than AoS.

> > You ever written a 3D graphics pipeline???
>
> I have dabbled in 3D graphics.

Great, a dabbler.  I hope you just have a penchant for understatement.
Otherwise, you're wasting our time.

> > The vast
> > majority of 3D graphics processing is accept / reject
> > testing.
>
> I'd like more, specific examples here. What determines the
> accept or reject?
> What is the consequence of an accept or reject?

I don't have time to educate you on the fundamentals of 3D graphics
processing.  You can find all the classical, basic information via
newsgroups such as comp.graphics.algorithms.  If you want to save a lot
of time going up the learning curve, you could post something like "AoS
or SoA?" and see what people say.  Or Google the archives for them.

> If your programs are bottlenecked by lots of very low-level
> arithmetic over
> huge, flat data structures then you will almost certainly
> benefit from using
> more structured, hierarchical (ideally, multiresolution)
> representations.

So was it 'dabbler' or not then?  I suppose you think that the
implementation complexity of multiresolution representations is
desireable in an industry where a significantly faster card ships every
6 months?


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

[Brandon J. Van Every]

Jon Harrop wrote:
> Brandon 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
>
> Why C++? Is your objective to always prototype in OCaml and
> convert to C++?

No, my objective is to use OCaml on top of extant C++ libraries, such as
the Nebula2 3D engine.  "Borgging" some of the engine over time may be
possible, but against that, is the implementation reality that the rest
of the Nebula2 developers are implementing in C++.

> > - the support of basic 3D graphics types, i.e. 32 bit floats
>
> Why not "ease of use of trees, graphs etc."? Algorithmic
> optimisations are so much more productive...

Am I allowed to just scream at you every time someone utters this
drivel?  Compare how Xavier feels about the 'real world'.  I think all
the 'exterior constant' O() theory guys should be hung from the rafters.

> > - ability to work with imperative, object oriented designs
> > and libraries
>
> OO is overrated, IMHO.

It may very well be.  There is still the reality that when you plan to
use extant libraries, that have ongoing development, with programmers
attached to them, all of whom are working in an imperative OO paradigm,
that you have to communicate successfully with them.  If you're going to
convert them, your religion has to be compelling.  And you may not be
able to convert them, you may have to settle for interoperating with
them.  The alternative is to write everything for OCaml from scratch and
that's just not industrial reality.  One of OCaml's strengths as far as
gaining language converts, actually, is that it doesn't immediately
force C++ people to abandon an imperative, OO mode of thinking.

> Imperative is excusable for UI level things but I'd
> prefer a functional style for everything but the simplest of
> algorithms.
> OCaml can play with libraries fairly well but, yes, it takes
> a lot of time to
> get some things working. That isn't the fault of the OCaml
> creators though,
> of course, it's the fault of those dim-wits at Bell Labs...

The "Worse Is Better" school of technological development has won.  You
have to deal with that reality if you want to benefit from it.
Otherwise, have fun writing all your own code from scratch.

> > ...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.
>
> Yes, but the OCaml bit of SWIG is very alpha, AFAIK. SWIG
> wasn't even designed to deal with languages like OCaml.

I didn't say I had any faith in the industrial robustness of the
solution.  I haven't heard of anyone using OCaml SWIG besides its
author.  I'm also aware that SWIG was designed to bind scripting
languages, not for native-native code linkage.

> Just out of curiosity, do you use the STL much? An interface
> to the STL might be interesting.

I don't.  I've totally avoided it, and I despise the thought of having
to deal with it.  I went looking for higher level languages rather than
worry about STL.  Thanks for reminding me that there's a dimension of
the C++ migration problem I hadn't considered.  I don't make much use of
templates... but they're germane to the C++ idiom, they won't be
'optional'.

> I'm getting offered jobs because I am so much more
> productive as a consequence.

So where are you finding these OCaml jobs?  Clue us in.

> The programs I write whilst doing my 3D graphics
> research are
> more robust and faster than ever now that they have been
> converted entirely into OCaml from C++.

*Now* you're a 3D graphics researcher.  Oy vey!


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] 3D graphics debate

[Jon Harrop]

> > Are you trying to write a device driver in OCaml?
>
> 3D device driver problems are indicative of graphics problems in
> general.  There's not much 'new' at any level of the game.

I would contest that, but then I am trying to make some "new" stuff...

> Just things 
> that have been committed to HW vs. things that are still waiting to be
> committed to HW, with some interrupting complexities in between.
> Traversing a cell grid database is no different from rasterizing a
> triangle.  3D graphics is one giant self-similar fractal.

Ironically, I would say that more things should be done hierarchically, e.g. 
octrees rather than cell grids. :-)

> > I think you are exaggerating cost of the "abstraction" of
> > reordering the arguments of a function.
>
> And I'm thinking you've never done high performance anything in a big
> architecture for a living.  Prove me wrong.

Oh ok then - I've just passed my PhD in computational and theoretical physics 
from the University of Cambridge. While I was there I developed numerous high 
performance programs, both for simulation (condensed matter physics) and 
visualisation (using OpenGL). I also invented and published research on 
wavelets so I've studied a lot of multiresolution analyses and hierarchical 
data structures...

I also did some fun projects which, I believe, are valid research into the 
usefulness of hierarchical data structures over flat ones in the context of 
2D and 3D graphics.

One is a multiresolution representation of a planet which is dynamically 
tesselated to give just enough detail for rendering:

http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/lod/index.html

if the planet were represented to enough detail using flat data structures 
(equivalent to the cell grid) for that demo it would require 2^80 floats. Had 
I known OCaml at the time, this would have been a much smaller and faster 
program. :-)

Another ongoing project of mine is a 2D vector graphics renderer which takes a 
similar, hierarchical approach to the rendering of 2D graphics (which are 
quite different to 3D because you're now interested in rendering the interior 
defined by a manifold, rather than the manifold itself):

http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/smoke/index.html

I have converted that C++ version into OCaml and optimised it so that it is 
now much faster, more robust and better behaved wrt real-time rendering. It 
is about 100 times faster than every other general purpose vector graphics 
renderer that I have ever come across. Of course, because it is 
multiresolution, it can render 1Gb vector graphics files in real-time whilst 
all the other programs fall over. This makes it uniquely suitable for 
real-time, interactive graphics which is why I intend to commercialise it...

So yes, I've dabbled. :-)

> > Apart from that "CPU" thing. ;-)
>
> I suppose you think CPU approaches are divorced from the realities of
> what underlying HW expects?  You want to retire things quickly, you
> don't spread them out all over memory.  Not unless you've got some kind
> of super duper programmer visible scatter-gather DMA, and I'm not aware
> of anyone building PCs in such configurations.

If you want to retire things quickly, you use a hierarchical representation 
which allows you to retire things in O(ln n) rather than O(n) time. Who 
knows, it may even let you reduce your storage from O(n^2) to O(n).

> > My point is that there are likely to be much more productive,
> > higher-level optimisations that you could be doing.
>
> It is a wasted point.  Performance jock do that *and* the low-level
> optimizations.  The key is sane architecture so you don't have to do
> more than a handful of low-level optimizations.

Ideally. But the vast majority of "performance jocks" ignore the mathematical 
proofs and stick to twiddling 32-bit floats.

> No, I said that *in addition to* that rather common class of algorithms,
> even sequential processing is usually accept / reject.  Let's say you've
> got SoA for a 4-field vector.  When you accept, you're going to be
> touching all 4 arrays.  If you often accept, then your cache is going to
> be polluted by all the rejects.  You have made your problem 4 times less
> cache coherent than it otherwise would be.  The reality of 3D graphics
> processing is you usually need all that info in the structure.  That's
> why it's a structure.

Aren't we talking about a 4xn matrix rather than an nx4 matrix?

> > Can these algorithms not be transformed so that they
> > access more coherently?
>
> No, dammit!  You Just Don't Get It [TM].  When someone tells you
> something is "an invasive programming model," they're telling you
> they're not looking for the opportunity to rewrite their whole software
> architecture from scratch just because you personally think SoA might be
> more kewl than AoS.

Well, if you want to optimise your program and you wrote it badly the first 
time... ;-)

> > I'd like more, specific examples here. What determines the
> > accept or reject?
> > What is the consequence of an accept or reject?
>
> I don't have time to educate you on the fundamentals of 3D graphics
> processing.  You can find all the classical, basic information via
> newsgroups such as comp.graphics.algorithms.  If you want to save a lot
> of time going up the learning curve, you could post something like "AoS
> or SoA?" and see what people say.  Or Google the archives for them.

I would say that I am somewhat familiar with the concepts involved. My concern 
is that I have only ever come across your optimisation problems in the 
context of shoehorning algorithms into using flat containers.

> So was it 'dabbler' or not then?  I suppose you think that the
> implementation complexity of multiresolution representations is
> desireable in an industry where a significantly faster card ships every
> 6 months?

Absolutely. It separates the men from the boys...

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

[Caml-list] RE: 3D Rendering pipeline

[Brian Hurt]

Ignoring the flamefest for a bit, I actually have a question for people
who do 3D rendering pipelines.  Over in Extlib (plug:
http://sourceforge.net/projects/ocaml-lib/) we have "enumerators"- 
basically Java or C++ STL Iterators.  Except that we have lazy mapping and 
filters- basically, as each element is iterated, all the currently 
applicable maps and filters are applied to it.

So my question is: would this be a better paradigm to experiment with a 
graphics pipeline in?  What other tweaks or features might make it more 
usefull?

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

[Jon Harrop]

On Wednesday 09 June 2004 02:33, Brandon J. Van Every wrote:
> Am I allowed to just scream at you every time someone utters this
> drivel?  Compare how Xavier feels about the 'real world'.  I think all
> the 'exterior constant' O() theory guys should be hung from the rafters.

I used to be like that. Now I see multiresolution representations everywhere.

> ... One of OCaml's strengths as far as
> gaining language converts, actually, is that it doesn't immediately
> force C++ people to abandon an imperative, OO mode of thinking.

Yes, just look at Skaller. ;-)

> The "Worse Is Better" school of technological development has won.  You
> have to deal with that reality if you want to benefit from it.
> Otherwise, have fun writing all your own code from scratch.

I understand that there are sectors where this has to be the case. A long time 
ago, I worked in one such area. I hated it. Now I avoid it like the plague. I 
much prefer inventing new maths and flogging it to people for lots of money.

> > Just out of curiosity, do you use the STL much? An interface
> > to the STL might be interesting.
>
> I don't.  I've totally avoided it, and I despise the thought of having
> to deal with it.

Interesting. Before I learned OCaml, I spent a long time writing 
partially-specialised code by abusing the C++ template system. I also made 
judicious use of the STL as well. I always thought that it was the only 
aspect of the language which made using it worthwhile.

Incidentally, I eventually abandoned this because there were so many bugs and 
missing features in gcc. That was 2.95, IIRC, the new ones seem to have the 
same numbers of bugs and missing features albeit in different areas?!

> I went looking for higher level languages rather than 
> worry about STL.

I think that is for the best. Although the STL was the only well-designed bit 
of C++ code that I've ever seen (including mine ;-).

> Thanks for reminding me that there's a dimension of 
> the C++ migration problem I hadn't considered.  I don't make much use of
> templates... but they're germane to the C++ idiom, they won't be
> 'optional'.

Yes, I'd like some partial specialisation in OCaml. Oh how I yearn for a 
native-code MetaOCaml compiler. It's not all important though.

> > I'm getting offered jobs because I am so much more
> > productive as a consequence.
>
> So where are you finding these OCaml jobs?  Clue us in.

Basically, anywhere that people are used to writing in C/C++ or, dare I say 
it, FORTRAN. Most of them have never seen a tree, let alone a language which 
can manipulate them without segfaulting. There are lots of applications in 
science, engineering, maths etc. which currently use flat data structures 
because they are easy to write in C and FORTRAN. People have tweaked (and 
corrected!) these programs for decades. But much simpler, multiresolution 
methods written in languages like OCaml are so much more robust, elegant and 
efficient on large inputs (which is where the money and supercomputers are) 
that they're always sold immediately.

IMHO, this is decidedly ironic. Physical scientists have mocked biologists 
since the beginning of time because they don't apply mathematics when they 
should. Stereotypical biologists argue until they are blue in the face about 
whether or not the ions flow inwards or outwards. But physical scientists 
make an equivalent mistake with respect to programming and, so, computer 
scientists laugh at them. Physical scientists ignore complexity theory and 
everything related to it and just stick to programming in FORTRAN because it 
lets you iterate over flat containers slightly more quickly. Talk about 
low-hanging fruit.

It's very timely to have a PhD in this stuff. Soon, the whole world will be 
multiresolution (and mine). :-)

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

[skaller]

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

> I'm feeling mentally challenged on specifics rigth now.  Generally
> speaking, 3D graphics problems are pipelines with N stages you might
> turn on or off.  This creates 2^N path possibilities.  Often you'd like
> to coalesce the operations at the various stages.

What you need here is a partial evaluator.
Getting one that *also* has 'real world' interfacing
AND supports very low level code is not going to be
so easy: macro processors are the best available tool
with all 3 properties that I know of :(

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

[skaller]

On Wed, 2004-06-09 at 10:25, Jon Harrop wrote:
> On Tuesday 08 June 2004 20:24, Brandon J. Van Every wrote:
> > ...
> > What utter nonsense!
> 
> Yo Mama.
> 
> > You ever written a 3D device driver? 
> 
> Are you trying to write a device driver in OCaml?

He is. But we're not talking about 'Unix' concept
of a device driver.

his problem is real time generation of graphics
images from models for a *specific* card.
(only you'd like to port the code to other cards too).

Particular cards have particular capabilities and
you have to know when to lose your abstraction
and get specific.

You also need to do things like flick a switch
to turn off Perspective, choose shading models,
etc (Diablo is unplayable on my 500 MHz PIII
unless I turn ALL the fancy graphics off .. and it
still runs way too slow to be playable at advanced levels).

In theory, graphics can ALL be done with

'get_pixel', 'set_pixel'

there is nothing else to do. Its all very nice
and abstract .. and of course that kind of
solution is totally and utterly untenable
even for a GUI .. let alone a game or
instrument demanding 10-40 frames per second
continuous guarranteed thruput.

-- 
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] 3D graphics debate

[Brandon J. Van Every]

For the uninitated, what you are about to witness is best described as a
'culture clash'.  On the one hand you have Mr. PhD, represented by John
Harrop.  On the other you have an almost totally self-taught erstwhile
optimization jock, represented by yours truly.

Jon Harrop wrote:
> Brandon J. Van Every wrote:
> > Joh Harrop wrote:
> > >
> > > I think you are exaggerating cost of the "abstraction" of
> > > reordering the arguments of a function.
> >
> > And I'm thinking you've never done high performance
> > anything in a big
> > architecture for a living.  Prove me wrong.
>
> Oh ok then - I've just passed my PhD in computational and
> theoretical physics from the University of Cambridge.

Thank you for finally showing your true colors.  It is irritating to
waste time with people who give the appearance of knowing nothing about
3D graphics performance, yet have lotsa suggestions about why AoS vs.
SoA "really doesn't matter."  Frankly, you either know why it matters
and have been pulling my leg, or you are too far into the abstractions
of your problem domain to care about the performance implications of low
level 3D operations.  I suspect that happens frequently to researchers
whose products never become industrially mature, and consequently never
have code monkeys seeking to tweak the hell out of their basic
architectures.  You prototype, you ain't optimizing.

> One is a multiresolution representation of a planet which is
> dynamically tesselated to give just enough detail for rendering:
>
> http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/lod/index.html
>
> if the planet were represented to enough detail using flat
> data structures
> (equivalent to the cell grid) for that demo it would require
> 2^80 floats. Had
> I known OCaml at the time, this would have been a much
> smaller and faster program. :-)

I've obsessed about rendering planets the size of Mars (roughly 1/4
surface area of Earth) down to 10 km/hex detail on a GeForce2.  With
each hex containing unique type data, not some fractal repetitive thing.
It is too much detail to actually see and use in a game (your website
indicates interest in games).  I am not impressed with your argument
about "flat data structures," at least not from what you have given
above.  To make a game is about controlling visualization and zoom, so
that the data is actually usable.  I've worked on hierarchical methods,
compatible with spherical hexified icosahedral topologies.  Too much
hierarchy, you ain't gonna get through the rendering or the game.

If you consider the terrain mapping of *real* planets, with real unique
surface data, you have a lot more to consider.  My planet was only a
game planet, at a relatively coarse resolution, but it was all unique
data.

All of your subtriangle stuff is stuff I've considered and abandoned as
too complex in the real world to implement a game, after reams and reams
of paper expended, and some code too.  A *game* surface has to be
addressable and fundamentally usable as a programming API for other
things, like the AI code.  I went with Barycentric coordinates and that
proved to be a mistake.  Too complex.  My next attempt will not be based
on the polygonally segmented icosahedron, but rather, upon a generalized
error reduction mesh with a simple grid for rapid lookup.

> Aren't we talking about a 4xn matrix rather than an nx4 matrix?

I don't even know why the hell you started talking about matrix
anything.  The vast majority of problems I've encountered in 3D graphics
are ad hoc accept / reject processing.

> > > Can these algorithms not be transformed so that they
> > > access more coherently?
> >
> > No, dammit!  You Just Don't Get It [TM].  When someone tells you
> > something is "an invasive programming model," they're telling you
> > they're not looking for the opportunity to rewrite their
> > whole software
> > architecture from scratch just because you personally think
> > SoA might be more kewl than AoS.
>
> Well, if you want to optimise your program and you wrote it
> badly the first time... ;-)

"Your program?"  Have you simply never worked in an industrial capacity?
Where did you get this UberDesigner control over "your program?"

> I would say that I am somewhat familiar with the concepts
> involved. My concern
> is that I have only ever come across your optimisation
> problems in the
> context of shoehorning algorithms into using flat containers.

Maybe you just don't think very well in terms of flat containers and
that's Your Nature [TM].  It is certainly not my nature to envision 3D
graphics problems as hierarchies, unless they're exceedingly flat
hierarchies.  I can definitely point to some problems where my approach
is appropriate and yours isn't.  In other scenarios it's a matter of
personal style, and I generally put my money on "simple implementation,
rely on 3D HW to speed up linearly."  For instance, a simple grid for
planetary addressing in buckets rather than your elaborate hierarchical
lookups.

> > So was it 'dabbler' or not then?  I suppose you think that the
> > implementation complexity of multiresolution representations is
> > desireable in an industry where a significantly faster card
> > ships every 6 months?
>
> Absolutely. It separates the men from the boys...

In terms of "I'm some badass algorithm guy," or in terms of "I can
actually ship product and make profit?"  Here we separate the ivory
tower from industrial reality.


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

[Caml-list] The multiresolution business model

[Brandon J. Van Every]

Jon Harrop wrote:
> Brandon Van Every wrote:
> >
> > So where are you finding these OCaml jobs?  Clue us in.
>
> Basically, anywhere that people are used to writing in C/C++
> or, dare I say
> it, FORTRAN. Most of them have never seen a tree, let alone a
> language which
> can manipulate them without segfaulting. There are lots of
> applications in
> science, engineering, maths etc. which currently use flat
> data structures
> because they are easy to write in C and FORTRAN. People have
> tweaked (and
> corrected!) these programs for decades. But much simpler,
> multiresolution
> methods written in languages like OCaml are so much more
> robust, elegant and
> efficient on large inputs (which is where the money and
> supercomputers are)
> that they're always sold immediately.

Ok, so multiresolution maths for science and engineering is your
business model.  Sounds like a valid one for your problem domain.  It's
only your multiresolution planet stuff *for games* that I'm unimpressed
with.  As a game designer I'm very aware of the complexity limits of
games, of what a user can actually deal with and enjoy.  Simillarly, the
vast majority of films are only 90 minutes long and obey Three Act
Structure.  It is a pity that I want to be a world class game designer,
not a world class multiresolution maths guy.  Sounds like you will make
far more money far more easily than I will.

Still, I will keep trying to think how I might use higher level
languages such as OCaml for valid business models.  I definitely don't
think financial grunt coding is where it's at.  Corporate
industrialization is the province of Java and C#.  I've been led to
OCaml via 3D graphics and AI problems.  Maybe the latter might be more
fruitful for me.


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

[Christophe TROESTLER]

On 09 Jun 2004, skaller <skaller@users.sourceforge.net> wrote:
> 
> his problem is real time generation of graphics images from models
> for a *specific* card.  (only you'd like to port the code to other
> cards too).

I am pretty naive with this subject but would an approach like the one
used by FFTW (i.e., combining "codelets") be possible?

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

[Richard Jones]

On Mon, Jun 07, 2004 at 10:00:53PM +0100, Richard Jones wrote:
> Is there not any work on allowing inline asm in OCaml?
> 
> Since ocamlopt can inline code from modules, would it be possible to
> create a 'fake' .cmx/.o file which would actually contain direct
> assembler code to be inlined?

OK, I just tried this and it doesn't work.  It seems (without looking
at the ocamlopt source anyway ...) that the .cmx file carries a
high-level representation of the code which is actually assembled in
the .o file.  When I replaced just the .o file with a similar one
carrying my assembler, OCaml inlined the original code which therefore
must have come from the .cmx.

I'm guessing that people would object to extending OCaml to allow
inline asm because it would break bytecode compilation?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MOD_CAML lets you run type-safe Objective CAML programs inside the Apache
webserver. http://www.merjis.com/developers/mod_caml/

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

[David Brown]

On Tue, Jun 08, 2004 at 03:23:21PM +0100, Keith Wansbrough wrote:

> Oh, come on.  GHC has no problems with garbage-collecting floats in
> the heap.  It also has no problems unboxing them, and does a
> reasonable job (IIRC) of storing them in registers, just as in C.
> Haskell has both Float (32 bit) and Double (64 bit).  Just because
> OCaml doesn't handle them, doesn't mean no high-level programming
> language can.

GHC's execution model is also slower than ocaml's, and I'm not just
referring to the lazy evaluation aspect.  31-bit tagged integers in
ocaml is a great tradeoff for many applications.  It allows the GC to be
exact, but the compiler doesn't need to explicitly register all
variables at every stack frame.  Unfortunately, it forces 32-bit
quantities to be boxed.

GHC is also much easier to bind with C, both because of how FFI is done,
and that 32-bit values are actually 32-bit values.

BTW, GHC boxes almost everything, and leaves selective unboxing to the
optimizer.

Dave

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

[Keith Wansbrough]

> BTW, GHC boxes almost everything, and leaves selective unboxing to the
> optimizer.

I'm not quite sure how you distinguish between "GHC" and "the 
optimizer" here.  GHC is an optimising compiler.

GHC has a pretty good strictness analysis, and anything it can prove is 
needed strictly it will try to unbox.  This generally means that lots 
of things are never boxed.

You can also annotate something (in Haskell) to say "this is strict" - 
this will usually cause it to be unboxed - and in GHC you can also say 
"this must be unboxed" - this will always cause it to be unboxed.

--KW 8-)

-------------------
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 Fri, 2004-06-11 at 01:20, Keith Wansbrough wrote:

> You can also annotate something (in Haskell) to say "this is strict" - 
> this will usually cause it to be unboxed - and in GHC you can also say 
> "this must be unboxed" - this will always cause it to be unboxed.

Does that work with polymorphic functions?
eg: cause the function to be specialised every call?

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

[Keith Wansbrough]

> On Fri, 2004-06-11 at 01:20, Keith Wansbrough wrote:
> 
> > You can also annotate something (in Haskell) to say "this is strict" - 
> > this will usually cause it to be unboxed - and in GHC you can also say 
> > "this must be unboxed" - this will always cause it to be unboxed.
> 
> Does that work with polymorphic functions?
> eg: cause the function to be specialised every call?

No, but you can tell it to specialise a function to a particular type
(or any finite number of types), and it will automatically use the
specialised one if available.

(You can't automatically specialise in general if you're doing
separate compilation - well, you could, but it wouldn't really be
separate compilation, it would be more like using the function as a
macro).

--KW 8-)

-------------------
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 Fri, 2004-06-11 at 02:23, Keith Wansbrough wrote:

> No, but you can tell it to specialise a function to a particular type
> (or any finite number of types), and it will automatically use the
> specialised one if available.
> 
> (You can't automatically specialise in general if you're doing
> separate compilation - well, you could, but it wouldn't really be
> separate compilation, it would be more like using the function as a
> macro).

Ah .. i seem to recall a discussion on this on comp.lang.functional
now? Regarding partial specialisation where some type vars
are specialised and some not?

BTW: the notion of 'separate compilation' is pretty fuzzy these
days I think.

For example one could argue that it means 'avoiding recompilation
of common parts  of multiple programs' and in this sense
C and C++ don't have separate compilation :)

-- 
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] Re: [Ocaml-lib-devel] RE: 3D Rendering pipeline

[Nicolas Cannasse]

> Ignoring the flamefest for a bit, I actually have a question for people
> who do 3D rendering pipelines.  Over in Extlib (plug:
> http://sourceforge.net/projects/ocaml-lib/) we have "enumerators"-
> basically Java or C++ STL Iterators.  Except that we have lazy mapping and
> filters- basically, as each element is iterated, all the currently
> applicable maps and filters are applied to it.
>
> So my question is: would this be a better paradigm to experiment with a
> graphics pipeline in?  What other tweaks or features might make it more
> usefull?

I have been working on 3D rendering pipelines, and I think that ExtLib enums
can provide a good way of mixing algorithms together in an efficient way.
However, the level of abstraction of enums is quite high (closures), so if
runtime is needed and if you're performing on a large set of inputs, you
might need additionnal features such as inlining which cannot cross the
abstract closure barrier.
In conclusion, enums are nice to implement test/rejects clipping algorithms
on an object basis (since you have only few hundreds/thousands of objects to
test) but are not appropriate to do basic operations such as real time
deformation on a vertex basis.

Regards,
Nicolas Cannasse

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

[Evan Martin]

On Thu, Jun 10, 2004 at 05:23:33PM +0100, Keith Wansbrough wrote:
> > Does that work with polymorphic functions?
> > eg: cause the function to be specialised every call?
> 
> No, but you can tell it to specialise a function to a particular type
> (or any finite number of types), and it will automatically use the
> specialised one if available.

It would seem to me that a polymorphic function would only need to be
specialized for a small set of, uh, "sizes" of data:  bytes, ints,
(and pointers, doubles, longs, depending on the architecture).

Do these compilers really pass larger types by value?  Or does
specialization need more information than the sizes of the types?

-- 
Evan Martin
martine@danga.com
http://neugierig.org

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