From: "Alexander V.Voinov" <avv@quasar.ipa.nw.ru>
To: skaller@ozemail.com.au
Cc: damien.doligez@inria.fr, caml-list@inria.fr
Subject: Re: ocaml, simd, & fftwgel RE: [Caml-list] Caml productivity.
Date: Thu, 01 Aug 2002 09:55:09 -0700 (PDT) [thread overview]
Message-ID: <20020801.095509.08350866.avv@quasar.ipa.nw.ru> (raw)
In-Reply-To: <3D49640B.7050500@ozemail.com.au>
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
next prev parent reply other threads:[~2002-08-01 16:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-01 15:36 Damien Doligez
2002-08-01 16:38 ` John Max Skaller
2002-08-01 16:55 ` Alexander V.Voinov [this message]
2002-08-01 16:45 ` Jonathan Coupe
-- strict thread matches above, loose matches on Subject: below --
2002-08-02 2:56 Gurr, David (MED, self)
2002-08-02 9:57 ` Noel Welsh
2002-07-30 17:58 Gurr, David (MED, self)
2002-07-31 1:29 ` Travis Bemann
2002-07-31 8:09 ` Xavier Leroy
2002-07-31 8:39 ` Noel Welsh
2002-08-01 15:22 ` John Max Skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020801.095509.08350866.avv@quasar.ipa.nw.ru \
--to=avv@quasar.ipa.nw.ru \
--cc=caml-list@inria.fr \
--cc=damien.doligez@inria.fr \
--cc=skaller@ozemail.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox