Browse thread
[Caml-list] Caml productivity.
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Pal-Kristian Engstad <mrengstad@y...> |
| Subject: | Re: [Caml-list] Caml productivity. |
I agree that the C interface is pretty nice. However, how do would you use SIMD math instructions on the x86? Would you always call C-routines just to make use of SIMD or multimedia-instructions? What is the overhead for calling a function that is executing a few assembly instructions? Is it even possible to create a solid division line between "low-level" and "high-level" code? There's something to be said for premature optimizations, but don't you think there's something to be gained from having inline assembly in O'Caml? In C++, one can create inline SIMD floating point vector operations. A.I. and behaviour code constantly use 3D math that would benefit from inline assembly. PKE. --- Travis Bemann <bemann@execpc.com> wrote: > On Mon, Jul 22, 2002 at 10:46:35AM -0700, > Pal-Kristian Engstad wrote: > > Hi, > > > > Nicolas Cannasse seems to believe that > "productivity" > > and "performance" are orthogonal concepts. They > are > > not always. For some tasks the performance of the > > algorithm determins if the program can be put into > the > > application. Hence, if the program executes too > > slowly, the program is useless and the time spent > on > > it was a waste. In other words, there was no > > productivity at all. > > > > I commend Nicolas for trying to use O'Caml in a > games > > setting. We, however, can not afford this - > instead > > the company designed and implemented a specific > > language in order to be able to optimize _and_ be > > productive. This language has high-level > constructs as > > well as low-level constructs --- and they can be > > freely mixed. > > Actually, speed-wise natively compiled OCaml (on at > least x86; I > haven't seen benches for other architectures) is > slightly faster than > C++ compiled by gcc 3.0, and slightly slower than C > compiled by gcc > 3.0. OCaml does have an excellent C binding > facility, which makes it > easy to interface between OCaml and C code (so > therefore one can use C > for extremely speed-critical code while writing most > other code in > OCaml). Thus, I see little advantage to writing a > whole new natively > compiled language (which would require writing a > whole new code > generation and optimization layer, which would be > extremely > time-intensive, unless such a language were > "compiled to C" as things > such as GCL (GNU Common Lisp) do) rather than simply > using OCaml with > speed-critical or otherwise extremely low-level code > in C. > > -- > Yes, I know my enemies. > They're the teachers who tell me to fight me. > Compromise, conformity, assimilation, submission, > ignorance, > hypocrisy, brutality, the elite. > All of which are American dreams. > > - Rage Against The Machine > ATTACHMENT part 2 application/pgp-signature __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.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