Clojure JIRAhttp://dev.clojure.org/jira
This file is an XML representation of an issueen-us4.464925-07-2011[LOGIC-144] Extending cljs.core.logic with all of the functionality from clojure.core.logic http://dev.clojure.org/jira/browse/LOGIC-144
core.logic<p>Repo I've been working from is here: <a href="https://github.com/aamedina/cljs.core.logic">https://github.com/aamedina/cljs.core.logic</a></p>
<p>I've followed the code layout in clojure.core.logic pretty much verbatim, compensating for ClojureScript necessities, moved macros into sister .clj files. I have no hard opinions about the best way to organize the macros for each file, the way I do it is just the way I've found easiest, because then you don't have to namespace qualify every syntax quoted form that references a function in the sister .cljs file. </p>
<p>Additionally I ported all of the clojure.core.logic tests with clojurescript.test. </p>LOGIC-144Extending cljs.core.logic with all of the functionality from clojure.core.logic EnhancementMajorOpenUnresolvedDavid NolenAdrian MedinaTue, 19 Nov 2013 21:05:39 -0600Wed, 4 Dec 2013 12:18:08 -060001<p>So I've updated the repo to reflect a more faithful adherence to the existing cljs.core.logic code conventions and organization. I'd appreciate any insight into how to potentially optimize the code to run more on par with the JVM. </p><p>What kinds of performance problems are you observing? Do you have a particular benchmark that you're running?</p><p>Appendo and membero are particularly slow. </p>
<p>(dotimes <span class="error">&#91;i ie5&#93;</span> (run* <span class="error">&#91;q&#93;</span> (== q true))) takes around ~4500ms, which is about 10x slower than the JVM.</p>
<p>After profiling, I've discovered the problem - pretty standard recursion optimizations are necessary, it's re-walking (by reunifying) lvars recursively as the code is executed. E.g.,<br/>
for appendo, (run 5 <span class="error">&#91;q&#93;</span> (fresh <span class="error">&#91;x y&#93;</span> (appendo x y q))) will expand into something like..</p>
<p>((_0) (_0 . _1) (_0 _1 . _2) ... ))</p>
<p>and it's slow because every new list is actually re-walking every previously unified lvar again. </p>
<p>I'll have more time to investigate this over the weekend, but I think it might be as simple as not generating unique lvars by default, since then the identical? for unification check should catch any attempted walk. </p>Global Rank