Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Bigarray is a pig
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brandon J. Van Every <vanevery@i...>
Subject: RE: [Caml-list] Bigarray is a pig
Brian Hurt wrote:
> Brand*n wrote:
> >
> > To C/C++ programmers interested in performance, this
> > defeats the purpose of using unboxed array elements.  If I
> > wanted to pay
> > function call overhead per element, for instance when
> > communicating with OpenGL, I'd simply call functions.
> Function calls aren't that expensive.

I'm pretty aware, from many years of experience, what the performance
characteristics of C/C++ arrays are vs. function call access to
comparable data, over millions of iterations.  Unless ocamlopt has a way
of avoiding EXTERN Bigarray declarations, we are talking about C code.

In other words, yes function calls are expensive in C compared to the
cost of just accessing an array element.

> A function call to a known function takes 1-2 clock cycles.

Not on any CPU I've worked on.  Generally speaking, you must save state
when you make function calls, and that is never a 1-2 clock cycle
operation.  If you have ways to inline stuff, great, but generally
speaking you can't do that with EXTERN C library stubs.  I don't know if
OCaml has great compiler technology that other languages don't have.
"It's not inlineable" is the drill in the C/C++ universe.

Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed!  Overhead!  Wondering!  chant chant chant...

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: