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 1E4FC7EE11 for ; Wed, 20 Aug 2014 11:11:35 +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.210.211; 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.210.211; 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@relay2.uni-heidelberg.de) identity=helo; client-ip=129.206.210.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nils.becker@bioquant.uni-heidelberg.de"; x-sender="postmaster@relay2.uni-heidelberg.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0BAEBl9FOBztLTnGdsb2JhbABZhzOzTZ1bAYEOFhABAQEBAQgLCQkUKYQEAQQBIw8BRQEQCxoCBRMDCwICCQMCAQIBKxoGAQwBBwEBiDYIBKwslUsXgSyOIAeCeYFTAQSEUo1Oh1KJdpFAgzkBAQE X-IPAS-Result: An0BAEBl9FOBztLTnGdsb2JhbABZhzOzTZ1bAYEOFhABAQEBAQgLCQkUKYQEAQQBIw8BRQEQCxoCBRMDCwICCQMCAQIBKxoGAQwBBwEBiDYIBKwslUsXgSyOIAeCeYFTAQSEUo1Oh1KJdpFAgzkBAQE X-IronPort-AV: E=Sophos;i="5.01,901,1400018400"; d="scan'208";a="89980145" Received: from relay2.uni-heidelberg.de ([129.206.210.211]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2014 11:11:34 +0200 Received: from ix.urz.uni-heidelberg.de (cyrus-portal.urz.uni-heidelberg.de [129.206.100.176]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s7K9BLEe028466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2014 11:11:21 +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 s7K9BKEr018689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Aug 2014 11:11:20 +0200 Received: from NMBA.local (HSI-KBW-46-223-211-128.hsi.kabel-badenwuerttemberg.de [46.223.211.128]) (authenticated bits=0) by extmail.urz.uni-heidelberg.de (8.13.4/8.13.1) with ESMTP id s7K9BJGg004482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 11:11:19 +0200 Message-ID: <53F46636.4070402@bioquant.uni-heidelberg.de> Date: Wed, 20 Aug 2014 11:11:18 +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> OpenPGP: id=AF475A7D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 >> 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. one data point: i removed one linear dependency and saw 15% speedup, so this seems to be the way to go. the code was similar to this: let signal_1 = S.merge f init_val {bunch of other signals} in let signal_2 = S.map g signal_1 actually i'm not interested in signal_1 in itself. it is the result of a list fold with f. its values are pairs that still contain an auxiliary accumulator variable. in the second step i post-process this result to give the meaningful signal_2. nothing else depends on signal_1. i now got rid of signal_2 by putting the post-processing into the downstream dependents of signal_1. this makes the structure of the program a bit less nice since i now use the half-finished signals, but it removes one trivial dependency. i think this is the cause of the speedup. this is actually a general pattern i find myself using: a combinator does not quite do all of the transformations i need, so i make another signal/event directly downstream which completes the processing. another example is let evt_1 = E.select {bunch of events} (* not interested in evt_1 *) let signal_2 = S.accum evt_1 init_val (* except for making this *) it now turns out this pattern is not really for free since it makes dependency chains longer. it would be cool to have a way to 'contract' these trivial links in the dependency graph. ie. to produce the result of signal_2 directly, with only a single node in the graph. or to 'block' them together in the dependency resolution in some way. is there already a way to do this that i missed? n.