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] Caml productivity.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-26 (21:46)
From: Chris Hecker <checker@d...>
Subject: Re: [Caml-list] Caml productivity.

 > What is the
 > overhead for calling a function that is executing a
 > few assembly instructions?

I don't think inline assembly is a very valuable feature at this 
point.  Function call overhead on modern processors is very small, and 
enabling inline asm messes up a lot of compiler optimizations for 
surrounding code.

It's going to be another generation or two before a higher level language 
like caml is going to be appropriate for console games, and I don't think 
there's any way around that.  I think it's just starting to be okay for PC 
games, but even the next gen consoles are going to be too memory 
constrained and it's always much more cost-effective to super-optimize a 
console game (both memory- and cpu-wise), at least for the next few ship 

On the original topic of this thread, I am still withholding judgment on 
caml for game programming until I actually finish my game, but I sincerely 
doubt it will be anywhere near 3x as productive for the kind of imperative 
simulation-y code that makes up a game.  If any game company could actually 
get 3x productivity out of their programmers, they'd retrain everybody in 
an instant.  3x is huge.  I think caml is definitely more fun to program 
with, but if it's at all more productive, it's going to be in the 10-40% 
range at best (and most of that is going to come from the gc).


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