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

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

[Ennals, Robert]

[snip]

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

I assume you are referring to the way in which OCaml reserves one bit in
each word to use as a tag that indicates whether the word represents a
pointer or not (which is also the reason for ints being 31 bits).

While a GC does need to have some way to distinguish between pointers
and data, this is not the only way that this can be done. Another
approach (used by GHC) is to dispense with tag bits and instead store a
bitmask for each datatype and each stack layout, indicating which fields
are pointers.

I don't know much about the relative advantages/disadvantages of the two
approaches, but there is definitely a design space to be explored, and
it is definitely possible to have native 32 bit floats in a garbage
collected language.

[snip]

-Rob


-------------------
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 Tue, 2004-06-08 at 18:10, Ennals, Robert wrote:
> [snip]

> While a GC does need to have some way to distinguish between pointers
> and data, this is not the only way that this can be done. Another
> approach (used by GHC) is to dispense with tag bits and instead store a
> bitmask for each datatype and each stack layout, indicating which fields
> are pointers.
> 
> I don't know much about the relative advantages/disadvantages of the two
> approaches, but there is definitely a design space to be explored, and
> it is definitely possible to have native 32 bit floats in a garbage
> collected language.

Felix uses an array of offsets to locate pointers.
And in Felix all types are fully expanded (except in sums
due to a design stupidity in C++).

A disadvantage of the offsets approach is that
Felix pointers and C pointers can't be mixed
in polymorphic functions operating on pointer to T:
the distinction is entirely static. In Ocaml, the
check is done at run time -- meaning less code bloat
and a small performance hit.

Expanded types provide superior efficiency
in some cases, and of course include boxing (pointers)
as a special case and so subsume systems that only box.

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

[John Carr]

> While a GC does need to have some way to distinguish between pointers
> and data, this is not the only way that this can be done. Another
> approach (used by GHC) is to dispense with tag bits and instead store a
> bitmask for each datatype and each stack layout, indicating which fields
> are pointers.

ocamlopt marks values in stack frames for the benefit of the
garbage collector.  This code is in the individual emit.mlp
files rather than the portable compiler.

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

> While a GC does need to have some way to distinguish between pointers
> and data, this is not the only way that this can be done. Another
> approach (used by GHC) is to dispense with tag bits and instead store a
> bitmask for each datatype and each stack layout, indicating which fields
> are pointers.

ocamlopt does that for stack frames, but not for heap-allocated
blocks.  I used the approach you describe (heap blocks containing
mixtures of pointers and raw data) in the Gallium experimental
compiler (which later morphed into ocamlopt), but it makes GC
significantly slower, which is a pity given that this feature is
rarely used: especially in symbolic computation, where GC times are
critical, most data structures are "pointers only" or "raw bits only".

Heap-allocating 3- or 4-vectors or 3x3- or 4x4 matrixes of floats is
quite reasonable, however, and probably what the OP really wants
although he denies it vehemently :-)

- 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

[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

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

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

> 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

[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

[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

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

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

[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

[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

[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

[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

[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

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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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