akuli / asda Goto Github PK

something that detects reference cycles and destroys objects that have no other references to them than what the cycle does

what is needed as soon as possible: something that runs when the interpreter exits, for checking whether there are missing decrefs or other reference-counting bugs i did this

what may be needed later: something that runs at other times than interpreter exiting (I have no idea when is good)

this exists in pyasda (the python interpreter) but not yet in asdar (the zig interpreter)

Hey @Akuli! 🕺

I've been looking into the performance issues you reported today in our IRC channel

I started by running this simple asda example based on the one you posted:

# assumes that x and y are positive, and something else that i'm not sure about
let divisible = (Int x, Int y) -> Bool:
    let x_copy = x    # this is a bug in asdac, this shouldn't be required

    #       x divisible by y
    # <=>   there exists an integer n so that x = n*y
    # <=>   if x = n*y + r, where 0 <= r < y, then r=0
    #
    # trying to find the r
    while TRUE:
        for let r = 0; r != y; r = r+1:
            if x_copy == y + r:
                return (r == 0)

        # exists n so that x = n*y  <=>  exists m so that x-y = m*y
        x_copy = x_copy - y

let and = (Bool a, Bool b) -> Bool:
    if a:
        if b:
            return TRUE
    return FALSE

let fizzbuzz = (Int n) -> Str:
    if (n `divisible` 3) `and` (n `divisible` 5):
        return "Fizzbuzz"
    if n `divisible` 3:
        return "Fizz"
    if n `divisible` 5:
        return "Buzz"
    return n.to_string()

print(fizzbuzz(5))

I utilize this shell script to create a performance graph using gprof2dot and callgrind

#!/usr/bin/env bash

set -exo pipefail

file=asdar/fizzbuzz.asda

pushd ..
python3 -m asdac "$file"
mv "asda-compiled/${file}c" asdar/
popd

rm -v ./*callgrind*

make -j8

valgrind --tool=callgrind ./asdar ./fizzbuzz.asdac
gprof2dot callgrind.out.* --format=callgrind --output=callgrind.dot
dot -Tpng ./callgrind.dot -o graph.png
feh graph.png &

I've not looked too much into the resulting graph due to time constraints, however I have identified one thing: this code-base allocates a lot.

It seems that bytecode parsing is allocation-heavy and the program spends 25% of execution time just parsing. I've identified struct Link to be a linked-list, which allocates a lot and I'm not sure we really need to utilize it.

I will look further into the graph and the code and start creating PRs to improve performance.

One other idea I had is a "peephole" optimizer, i.e. optimizing the bytecode itself by recognizing patterns and introducing specialized opcodes (e.g. jump if not, assign add, ...)

the zig interpreter uses Gnu GMP for its integers now

these features could be useful for some things:

• Int / Int division that returns a float of some sane size (maybe f64 or something... and yes float objects should be added)
• math.floordiv(Int, Int) or something: C-style integer division
• math.remainder(Int, Int): like % in other languages
• math.pow(Int, nonnegative Int)
• bit shifts (I don't want special syntax for these because x << y looks confusing if you haven't seen it, but something like math.shift_left(x, y))

defining functions doesn't work in the zig interpreter

should be able to run examples/import.asda and examples/export.asda

both work in pyasda

If NDEBUG is defined, assert is a no-op, leading to potentially UB in many places where assert(0) is used. Here's all the usages I grepped for

src/runner.c:		default: assert(0);
src/asdafunc.c:		assert(0);
src/asdafunc.c:		assert(0);
src/partialfunc.c:	assert(0);
src/module.c:			assert(0);
src/utf8.c:			assert(0);
src/utf8.c:				assert(0);
src/import.c:		assert(0);  // asda compiler shouldn't allow doing anything else
tests/test_utf8.c:			assert(0);
tests/test_utf8.c:			assert(0);
src/objects/bool.c:	assert(0);
src/objects/string.c:			assert(0);

It may be wise to replace these with something else.