<div>No, I don't even mean dealing with generated code (as I almost never compile my Agda). This is about optimizing the typechecker so that our compile-time normalization runs in reasonable time.<div><br></div><div>Take Fin, indexed by naturals. Now say you take the bitvector library that Eric Mertens and I wrote, that represents machine words of arbitrary bit lengths. Clearly these should be isomorphic to Fin (2 ^ n). Attempting to even begin to typecheck a proof of that is completely intractable in current Agda, though. Apparently there are quadratic numbers of conversions (quadratic in the <i>value</i> of the number) to and from unary naturals and GMP integers during the typechecking and that's what makes this so unpleasant.</div>
<div><br></div><div>So when I say I welcome optimizations to Agda's special treatment of naturals, I mean during normalization, not compilation. Large naturals can be represented intelligently, and even open terms (suc (suc (suc (suc (suc (suc (blah blah blah))))))) could be represented internally as an addition to avoid exponential blowup of terms in memory. I think there's a lot of potentially very useful work to be done here, completely independently of compiler backends. I do think that your bindings work is also important for real backends, but I don't think it makes any of James's work any less necessary or important.</div>
<div><br></div><div>Dan</div><div><br></div><div class="gmail_quote">On Thu, Apr 19, 2012 at 12:09 PM, Alan Jeffrey <span dir="ltr"><<a href="mailto:ajeffrey@bell-labs.com" target="_blank">ajeffrey@bell-labs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm quite happy with optimizing the representation of Agda's primitives, but I'd rather do something that's not specific to naturals.<br>
<br>
The approach I took with the JS back-end was to allow (essentially) view patterns in datatype bindings, which allow Agda datatypes to be bound to any native type.<br>
<br>
Doing this for Haskell, we'd have something like:<br>
<br>
data Nat : Set where<br>
zero : Nat<br>
suc : Nat -> Nat<br>
<br>
{-# COMPILED_VIEW view inv Integer Zero Suc #-}<br>
<br>
where Haskell defines:<br>
<br>
data View = Zero | Suc Integer<br>
<br>
view :: Integer -> View<br>
view 0 = Zero<br>
view n = Suc (n-1)<br>
<br>
inv :: View -> Integer<br>
inv Zero = 0<br>
inv (Suc n) = n+1<br>
<br>
then the compiler just has to insert "view" and "inv" functions into the current translation, and hey presto Agda naturals are bound to Haskell integers.<br>
<br>
Stick in some optimizations (view (inv x) == x) and (inv (view x) == x) and you should get a run-time that's as good as putting integer-specific trickery into the compiler.<br>
<br>
A.<div><br>
<br>
<br>
On 04/19/2012 10:46 AM, Daniel Peebles wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
I would welcome patches to the compiler, though. It's doing some fairly<br>
strange inefficient stuff with Nats (converting to and from GMP integers<br>
way too often) right now, and it'd be nice to speed up everything that<br>
used them.<br>
<br>
<br>
On Thu, Apr 19, 2012 at 10:36 AM, Alan Jeffrey <<a href="mailto:ajeffrey@bell-labs.com" target="_blank">ajeffrey@bell-labs.com</a><br></div><div>
<mailto:<a href="mailto:ajeffrey@bell-labs.com" target="_blank">ajeffrey@bell-labs.com</a><u></u>>> wrote:<br>
<br>
You might want to have a look at the agda-data-bindings project up<br>
on Github...<br>
<br></div>
<a href="https://github.com/agda/agda-__data-bindings" target="_blank">https://github.com/agda/agda-_<u></u>_data-bindings</a><div><br>
<<a href="https://github.com/agda/agda-data-bindings" target="_blank">https://github.com/agda/agda-<u></u>data-bindings</a>><br>
<br>
It has bindings for a bunch of low-level Haskell types, including<br>
Naturals. There's mappings ! and % back and forth from Agda's<br>
naturals to Haskell naturals.<br>
<br>
There is also a datatype:<br>
<br>
data Strict (A : Set) : Set where<br>
! : A -> Strict A<br>
<br>
whose constructor is strict in Haskell, so evaluates its argument to<br>
whnf. This was enough for me to get efficient naturals in the<br>
streaming I/O library, for example a word-count transducer that runs<br>
in constant space.<br>
<br></div>
<a href="https://github.com/agda/agda-__system-io" target="_blank">https://github.com/agda/agda-_<u></u>_system-io</a><div><br>
<<a href="https://github.com/agda/agda-system-io" target="_blank">https://github.com/agda/agda-<u></u>system-io</a>><br>
<br>
It might be that these libraries (or something like them) could be<br>
used in your case without patching the compiler.<br>
<br>
A.<br>
<br>
<br>
On 04/18/2012 03:48 PM, James Deikun wrote:<br>
<br>
I've been playing around with an (unproven; even<br>
un-termination-checked<br>
in places) implementation of the Sieve of Eratosthenes to see<br>
how well<br>
Agda's compile-time evaluator can stack up in the best cases. The<br>
call-by-name evaluation model and the fundamentally unary nature of<br>
builtin Naturals present substantial difficulties, but it seems<br>
eminently practical to determine primes as high as the 400th<br>
(2741) if<br>
not higher. The code is located at<br></div>
<a href="http://github.com/xplat/__potpourri/" target="_blank">http://github.com/xplat/__<u></u>potpourri/</a><div><div><br>
<<a href="http://github.com/xplat/potpourri/" target="_blank">http://github.com/xplat/<u></u>potpourri/</a>><br>
under the Primes directory.<br>
<br>
In order to achieve reasonable performance for operations on Nats I<br>
created a small library, FastNat.agda, which binds a couple of<br>
unbound<br>
builtins and redefines basic auxiliary datatypes, like _≤_, as<br>
well as<br>
many of the functions and proofs. It aims at allowing small, fast<br>
representations by using naturals and their equalities to<br>
represent all<br>
induction and indexing in the datatypes (since naturals can be<br>
represented as literals and equalities are constant size; see also<br>
below). _≤_ is represented as follows:<br>
<br>
record _≤_ (m n : Nat) : Set where<br>
constructor le<br>
field<br>
k : Nat<br>
m+k≡n : m + k ≡ n<br>
<br>
<br>
Needless recursion when building or verifying equalities is<br>
prevented<br>
using the following function, which throws away its argument while<br>
requiring a suitable proof of said argument's existence:<br>
<br>
hideProof : {a : Level} {A : Set a} {x y : A} -> x ≡ y -><br>
x ≡ y<br>
hideProof eq = trustMe<br>
<br>
<br>
By careful use of this primitive and builtins such as NATEQUALS and<br>
NATLESS it should be possible to build, say, a DecTotalOrder<br>
with all<br>
operations executing on literals in time logarithmic in the<br>
magnitude of<br>
the numbers; this has been verified for all operations but total<br>
(which<br>
still uses a raw trustMe) and no serious difficulties are<br>
anticipated.<br>
<br>
FastNat does, however, require a small patch (attached) to Agda to<br>
achieve its advertised speed.<br>
<br>
The pairing heap (Heap.agda) and sieve (Sieve.agda)<br>
implementations use<br>
pattern-matching as a sequentialization measure to control<br>
duplication<br>
of unevaluated thunks, which can cause an exponential slowdown.<br>
Aside<br>
from that they are largely straightforward implementations of the<br>
respective data structure and algorithm, the latter following "The<br>
Genuine Sieve of Eratosthenes" by M.E. O'Neill.<br>
<br>
Comments and improvements gratefully accepted.<br>
<br></div></div>
______________________________<u></u>___________________<br>
Agda mailing list<br>
<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>><br>
<a href="https://lists.chalmers.se/__mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/__<u></u>mailman/listinfo/agda</a><br>
<<a href="https://lists.chalmers.se/mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/<u></u>mailman/listinfo/agda</a>><br>
<br>
<br>
</blockquote>
</blockquote></div><br></div>