From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA14060; Thu, 1 Aug 2002 18:55:37 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA14404 for ; Thu, 1 Aug 2002 18:55:36 +0200 (MET DST) Received: from str12.sobor.org (adsl-63-198-183-99.dsl.snfc21.pacbell.net [63.198.183.99]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g71GtYr28461; Thu, 1 Aug 2002 18:55:34 +0200 (MET DST) Received: from localhost (localhost.localdomain [127.0.0.1]) by str12.sobor.org (Postfix) with ESMTP id 8559899860; Thu, 1 Aug 2002 09:55:10 -0700 (PDT) Date: Thu, 01 Aug 2002 09:55:09 -0700 (PDT) Message-Id: <20020801.095509.08350866.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. From: "Alexander V.Voinov" In-Reply-To: <3D49640B.7050500@ozemail.com.au> References: <200208011536.RAA0000012229@beaune.inria.fr> <3D49640B.7050500@ozemail.com.au> X-Mailer: Mew version 2.2 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 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 > >> > > > >>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