[Ocaml-biz] Let's choose a market

[Brandon J. Van Every]

Brian Hurt wrote:
> Brandon J. Van Every wrote:
>
> > > Rendering farms, crypto- probably not.  These are two places
> > > where even a 10% performance hit isn't acceptable.
> >
> > I'm not believing you here.  If what you said was true,
> > rendering farms
> > would get written in C rather than C++.  I think this is a C FFI /
> > Bigarray issue, not a "can't use a HLL" issue.  ILM uses Python to
> > control its rendering farms.  Of course, that's just the
> > network glue, not the rendering code.
>
> The glue code, yes.  The rendering itself?

Not in Python, of course.  My point is that even slow languages are
useful for rendering farms.

> Most crypto is done in C, when it isn't done in assembler.  As they
> actually do measure the performance of different implementations.

Crypto isn't rendering.  Rendering is inelegant, it has many complicated
cases to consider.  There's a reason I picked OCaml as my successor
language.

> > Several exist at http://caml.inria.fr/humps/caml_Mathematics.html
> > Do any kick sufficient ass per your definitions?
>
> No.  There are a couple of BLAS/LAPACK wrappers.  I want
> something better than BLAS/LAPACK.

But do others?  I mean, from a brand identity standpoint, BLAS/LAPACK
has a strong one.


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

When no one else sells courage, supply and demand take hold.