From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id ACADE7F747 for ; Tue, 19 Aug 2014 15:14:26 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of nils.becker@bioquant.uni-heidelberg.de) identity=pra; client-ip=129.206.100.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nils.becker@bioquant.uni-heidelberg.de"; x-sender="nils.becker@bioquant.uni-heidelberg.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of nils.becker@bioquant.uni-heidelberg.de) identity=mailfrom; client-ip=129.206.100.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nils.becker@bioquant.uni-heidelberg.de"; x-sender="nils.becker@bioquant.uni-heidelberg.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@relay.uni-heidelberg.de) identity=helo; client-ip=129.206.100.212; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nils.becker@bioquant.uni-heidelberg.de"; x-sender="postmaster@relay.uni-heidelberg.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjICAGtN81OBzmTUnGdsb2JhbABZhzOzbZ1aAYELFhABAQEBAQgLCQkUKYQEAQQBIwRRAQULCxoCBRYLAgIJAwIBAgFFBgEMAQcBAYg2CKxLlTYXgSyOIAeCeYFTAQSEUo1Oh1KJdZE9gzkBAQE X-IPAS-Result: AjICAGtN81OBzmTUnGdsb2JhbABZhzOzbZ1aAYELFhABAQEBAQgLCQkUKYQEAQQBIwRRAQULCxoCBRYLAgIJAwIBAgFFBgEMAQcBAYg2CKxLlTYXgSyOIAeCeYFTAQSEUo1Oh1KJdZE9gzkBAQE X-IronPort-AV: E=Sophos;i="5.01,894,1400018400"; d="scan'208";a="89845851" Received: from relay.uni-heidelberg.de ([129.206.100.212]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2014 15:14:25 +0200 Received: from ix.urz.uni-heidelberg.de (cyrus-portal.urz.uni-heidelberg.de [129.206.100.176]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id s7JDEGTB015368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2014 15:14:17 +0200 Received: from extmail.urz.uni-heidelberg.de (extmail.urz.uni-heidelberg.de [129.206.100.140]) by ix.urz.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s7JDEGTi011577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Aug 2014 15:14:16 +0200 Received: from bqdyn245_008.bioquant.uni-heidelberg.de (bqdyn245_008.bioquant.uni-heidelberg.de [129.206.245.24]) (authenticated bits=0) by extmail.urz.uni-heidelberg.de (8.13.4/8.13.1) with ESMTP id s7JDEEQt028569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2014 15:14:15 +0200 Message-ID: <53F34D78.3060806@bioquant.uni-heidelberg.de> Date: Tue, 19 Aug 2014 15:13:28 +0200 From: Nils Becker User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= , becker.nils@gmx.net CC: caml-list@inria.fr References: <1B358C457E1445C0A76B9491809C4C6D@erratique.ch> In-Reply-To: <1B358C457E1445C0A76B9491809C4C6D@erratique.ch> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 on 129.206.100.176 X-Validation-by: nils.becker@bioquant.uni-heidelberg.de Subject: Re: [Caml-list] using React for -- reactions thanks daniel, > If it's wide at the *primitive* level then this is a good property > for performance since an update will have little needless work to do. > If it is wide just *after* the primitive for no good reason, i.e. > single primitive with huge number of dependents that filter the > primitive and then short dependencies, you may want to express the > first level of dependents as a primitive if the filtering nodes > entails that only a few of them trigger on an update. yes, it's wide at the primitive level. initially i did have an E.select over O(N) events somewhere which slowed it down a lot, but that is already repaired, as you explain. right now, i should not have any combinators that filter out a lot of unneccessary dependencies, so that should be fine. > >> bottom line: can a React based simulation possibly compete with >> manual, in-place update of arrays, let's say within a factor of 2? >> if yes what do i need to pay attention to? > > No idea. Basically you need to pay attention to the topology of your > graph. so i guess i need to make the update chains a short as possible. at the moment, i update the external heap by events which produce (heap -> heap) updater functions; they each have exactly one daughter event in which the function is applied to the actual heap. this structure is just a by-product of how i initialize the simulation. i guess by streamlining this into just one event i could potentially shorten the dependency chain and speed it up? > Is your code published somewhere ? no, it's pretty messy still. if you'd like to have a look i could put it on bitbucket.. n.