Hi

There is a concept of 'soft realtime', where one can't ignore the
concept of 'deadlines', but the latter may not be that crucial. For
example, if a database transaction is not completed before such a
deadline, it's just rolled back and a failure is reported. This
failure may not be as disastrous as in the case of a spacecraft, but
you have to face it and process properly at a higher level. This is
very different to an 'ordinary' situation where you don't care at all
how much time it takes to complete the transaction.

If there was a version of OCaml (or a runtime switch) to impose such a
'transaction deadline' on the workings of GC, OCaml would be quite
acceptable for soft realtime.

Alexander

From: John Max Skaller <skaller@ozemail.com.au>
Subject: Re: ocaml, simd, & fftwgel RE: [Caml-list] Caml productivity.
Date: Fri, 02 Aug 2002 02:38:35 +1000

> Damien Doligez wrote:
> 
> >>From: John Max Skaller <skaller@ozemail.com.au>
> >>
> >
> >>Huh? Which parts of a real time interactive game aren't real time??
> >>The whole thing, from gameplay interaction to graphics and sound,
> >>must be done in 'real-time'.
> >>
> >
> >I'd say no part of a real-time interactive game is real-time.  To me,
> >real-time means something like the Ariane 5 rocket, where you have a
> >deadline every 36ms for the 12 hours of the mission.  And if you miss
> >even one deadline your 100M$ rocket will crash.
> >
> Heh! I suppose I have to agree. My Real Time work involved phase control 
> lighting systems,
> where timing is even tighter than your Ariane's 36ms. Surprisingly, 
> switching phase controlled
> lighing circuits require precision measured in microseconds -- a single 
> machine extra instruction
> on a 2Mhz microcontroller can turn an acceptable performance into an 
> unacceptable one.
> 
> >With Objective Caml on a fast machine, if you're not doing heap
> >compaction, GC pauses should be somewhere between 1 and 10
> >milliseconds.  Quite workable for an interactive game, I'd say, but
> >then again it's not the future of my company that is at stake.
> >
> Well, games like Diablo freeze for much longer than that: Baal's 
> minions, 5-15 second lockup,
> fighting Diablo with perspective on, on a 800Mhz machine: frame rate of 
> 1 frame per second
> or worse with a lag of up to 5 seconds. ARGGG!!! Totally unacceptable: 
> lag is responsible
> for at least half the deaths on the internet servers.
> 
> As I commented in another post, Ocaml could only improve the quality of 
> these games
> by allowing the programmers to actually get the structure of the real time
> operation right.
> 
> -- 
> John Max Skaller, mailto:skaller@ozemail.com.au
> snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
> voice:61-2-9660-0850
> 
> 
> 
> 
> -------------------
> 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