From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3QJUOYs008585 for ; Tue, 26 Apr 2011 21:30:24 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwCAJ0ct03RVdQ2kGdsb2JhbACYBIY+AYcYCBQBAQEBCQkNBxQEIYhwojGKeIInhUs0iF4BAQMGhXAEggaMO4d3giA6g1E X-IronPort-AV: E=Sophos;i="4.64,270,1301868000"; d="scan'208";a="98123828" Received: from mail-vw0-f54.google.com ([209.85.212.54]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Apr 2011 21:30:22 +0200 Received: by vws18 with SMTP id 18so1360029vws.27 for ; Tue, 26 Apr 2011 12:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vWV0fA0tX0hRDKKqr/s7q3skSIXFfX0QPuJ78tblvYA=; b=YMaudVJctC5mRWUrvV7a0kdGXoVnvExmdW7nl3BNnV71xDR3e6kQQ9BUzt1LOAihJk DLwsOdyCVeHo3jTVAfZsXT79qhiptuh9krRlUcKigTpcWkm3bh7xHxsz4cbDpiiYuE0O WLCWNFM2SEqWa028FCBBkPHgc1OjYj7DtGimo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=IVqYv2Bb6UlZ03VmhGmT1+b3RlS0FkT3cUi0Yh+onaS0y6LGq9umB5BUz72LSL5S1e iAfRpfDD2ygU+vqYNTKkW7jJHaUP3rMZNGKo9Vh7fkITbhak9WgDZjS9jFxLKDYG3PDM X/WQIYBxokILBk6XseXmZ3bNrggocIlbRtSgM= Received: by 10.52.73.195 with SMTP id n3mr382498vdv.28.1303846220063; Tue, 26 Apr 2011 12:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.181.198 with HTTP; Tue, 26 Apr 2011 12:30:00 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Tue, 26 Apr 2011 21:30:00 +0200 Message-ID: To: Peter Ronnquist Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=20cf3071c8dec9e2c504a1d75a44 Subject: Re: [Caml-list] f#/mono vs ocaml runtime system - open gl animation screen tearing. --20cf3071c8dec9e2c504a1d75a44 Content-Type: text/plain; charset=ISO-8859-1 Given the complexity and general fragility of the graphic stack on GNU/Linux, I would suppose this issue can come from anywhere. It may be related to the GC pauses (and the difference in GC behavior might be mainly correlated to boxing/unboxing decisions), but it may as well come from a lot of other things. Are you positive the language runtime system is the only change between your two setups ? For example, would a simple animation written in C and OCaml and F# perform differently ? It may also be an issue with the OpenGL FFI binding (I would trust the OCaml GC more than a hairy mix of OCaml/C code binding a large library). I have absolutely no expertise in this domain, and your initial idea may very well be correct, but still you should make sure you're really investigating the real problem, and not something completely unrelated, before going into something as specialized and difficult than runtime implementation considerations. On Tue, Apr 26, 2011 at 9:15 PM, Peter Ronnquist wrote: > Hi all, > > I have been experimenting with f# and mono on debian linux and > compared it with ocaml. > I am interested in visual presentations for example games and in my > tests f# + mono + opentk was able to make completely smooth animations > using opengl (opentk) on debian 6.0 (squeeze). > > Ocaml + lablgl gives "stutters" in the animation within the period of > a couple of seconds. The animation runs smooth for a couple of seconds > and then the animation update is disturbed with the result that the > image is "teared". The tearing lasts only for a fraction of second but > is visible for a trained eye. > > I suspected that the GC could be a cause for this and I tried to > manipulate the GC settings but I could not get a completely smooth > animation for a longer period of time. > > This is completely acceptable for many applications but for making a > game or for the meticulous graphical applicaton user it is not ideal. > > My thought is that maybe f#/mono unboxes more values than ocaml and in > this way the GC doesn't need to work as hard? > > My question really is if you think it is worthwhile to investigate the > runtime system for mono and compare it with the runtime system for > ocaml to locate the differences that might influence the animation and > then even update the ocaml runtime system to use a similar strategy > as the f# runtime system? > > I would be interested in this but it would be nice to first hear from > the list if this is a good idea. I also read in the Jane Street blog > (http://ocaml.janestreet.com/?q=node/89) that ocamlpro might work on > the ocaml runtime system (including unboxing). > > Best Regards > Peter Ronnquist > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > --20cf3071c8dec9e2c504a1d75a44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given the complexity and general fragility of the graphic stack on GNU/Linu= x, I would suppose this issue can come from anywhere. It may be related to = the GC pauses (and the difference in GC behavior might be mainly correlated= to boxing/unboxing decisions), but it may as well come from a lot of other= things. Are you positive the language runtime system is the only change be= tween your two setups ? For example, would a simple animation written in C = and OCaml and F# perform differently ?
It may also be an issue with the OpenGL FFI binding (I would trust the OCam= l GC more than a hairy mix of OCaml/C code binding a large library).
I have absolutely no expertise in this domain, and your initial idea may v= ery well be correct, but still you should make sure you're really inves= tigating the real problem, and not something completely unrelated, before g= oing into something as specialized and difficult than runtime implementatio= n considerations.

On Tue, Apr 26, 2011 at 9:15 PM, Peter Ronnq= uist <pet= er.ronnquist@gmail.com> wrote:
Hi all,

I have been experimenting with f# and mono on debian linux and
compared it with ocaml.
I am interested in visual presentations for example games and in my
tests f# + mono + opentk was able to make completely smooth animations
using opengl (opentk) on debian 6.0 (squeeze).

Ocaml + lablgl gives "stutters" in the animation within the perio= d of
a couple of seconds. The animation runs smooth for a couple of seconds
and then the animation update is disturbed with the result that the
image is "teared". The tearing lasts only for a fraction of secon= d but
is visible for a trained eye.

I suspected that the GC could be a cause for this and I tried to
manipulate the GC settings but I could not get a completely smooth
animation for a longer period of time.

This is completely acceptable for many applications but for making a
game or for the meticulous graphical applicaton user it is not ideal.

My thought is that maybe f#/mono unboxes more values than ocaml and in
this way the GC doesn't need to work as hard?

My question really is if you think it is worthwhile to investigate the
runtime system for mono and compare it with the runtime system for
ocaml to locate the differences that might influence the animation and
then even update the ocaml runtime system to use a similar strategy
as the f# runtime system?

I would be interested in this but it would be nice to first hear from
the list if this is a good idea. I also read in the Jane Street blog
(htt= p://ocaml.janestreet.com/?q=3Dnode/89) that ocamlpro might work on
the ocaml runtime system (including unboxing).

Best Regards
Peter Ronnquist

--
Caml-list mailing list. =A0Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--20cf3071c8dec9e2c504a1d75a44--