API choices here are Cython-style decorator

@module.function(Long, x=Long, y=Long)
@nitrous.cdivision
def foo(x, y)
    z = x / y

or a context manager

@module.function(Long, x=Long, y=Long)
def foo(x, y):
    with nitrous.cdivision:
        z = x / y

It would be convenient to have a way to get basic profiling data for a module. Eg,

@function(x=Pointer(Double))
def foo(x):
    ...

m = module([foo], profile=True)

x = (Double.c_type * 1000)(...)
m.foo(x)

from nitrous.profile import stats, callgraph

# Print basic stats
p = stats(m.foo)
print p.calls, p.cumulative

# Show profile graph
callgraph(m.foo)

Similar to scalar types,

from nitrous.module import Module
from nitrous.types import Double, Structure

m = Module(__name__)

# * Tuples rather than kwargs since order is important.
Coord = Structure(("x", Double), ("y", Double), ("z", Double))

...

# Allocate space for 100 coordinates
coords = (Coord.c_type * 100)()

There are a couple of issues with how array system is set up.

• Pointers have N-dimensional indexing which is weird
  1. The only reason is a rather specific performance edge case where we have N-dimensional index with all dimensions known at compile time except the major one. The current "DynamicArray" incurs overhead with its struct and "StaticArray" needs to have all dimensions known.
  2. Ideally we'd like to keep pointers for C interop but disallow any sort of element access or arithmetic
• Dynamic/Static arrays are bad nomenclature. The word "Dynamic" here really means "selected dimensions are static, but only known at compile time".

The following is the attempt to borrow from Go language Array/Slice system with two exceptions:

1. Slices/arrays get to have multiple dimensions.
2. Slices/arrays will be passed by reference. While making few things seductively consistent (ie. assignment always means copy of the right hand side expression result), it would be a large divergence from how Python objects and data behave. Additionally, it would be a bet on how well LLVM optimizer eliminates unnecessary copies during function inlining.

From rough benchmarks, using dynamic arrays in performance edge case mentioned above, with pointer aliasing disallowed, results in ~ 5% hit, which is tolerable. There are a number of things that can be done, for instance allowing Array to have its first dimension unknown (still a hack, but at least a better nomenclature than Pointer)

This particular function in spectral norm benchmark code looks less than ideal

def eval_AtA_times_u(u, out, tmp):
    eval_A_times_u(u, tmp)
    eval_At_times_u(tmp, out)

Aggregate return values would turn it back into more familiar

def eval_AtA_times_u(u):
    return eval_At_times_u(eval_A_times_u(u))

The current candidates are arrays of fully defined shape and structs.

It may be possible to avoid writing temporary .so files altogether by using JIT execution engine. Find a way to convert the result of ExecutionEngine::getPointerToFunction() to ctypes function object.

At the very minimum, it should be possible to to emit debug symbols with

m = module([a, b, c], debug=True)

so that we can meaningfully run python process through GDB.

Should be able to use constant attributes without assigning them to a temporary first. Example from vector module:

def store(T):

    # FIXME only directly named constants are currently resolved.
    N = T.n

    @function(v=T, p=Pointer(T.element_type))
    def store_(v, p):
        for i in range(N):
            p[i] = get_element(T)(v, i)

    return store_

Provide support for configurable width and element type. Should support pointers to vectors as well. Provide a way to access vector elements with [] notation.

from nos.types import Vector, Double

# Type declaration
Coord = Vector(Double, 3)

# Inside function
pos = Coord(1.0, 2.0, 3.0)
pos[0] += 5.0

Currently, decorating a function leaves a number of __n2o_* attributes attached to it. Instead, leave the function unchanged and return a separate wrapper object.

The plan is to have the following

from nitrous.module import module
from nitrous.function import function, options


@function(Long, a=Long, b=Long)
def add(a, b):
  return a + b


@function(Long, a=Long, b=Long, c=Long)
def add3(a, b, c):
  return add(a, add(b, c))


m = module([add3])

print m.add3(4, 2, 10)

Only functions passed to module() builder will get interfaced to Python; the rest are not regularly callable, but will be privately pulled and compiled in. This decoupling provides a good model to build libraries.

Implement an interface that would be familiar to numpy.array user

@module.function(None, a=Array(Long, 2), b=Array(Long))
def flatten2d(a, b):
    # a.ndim == 2
    # b.ndim == 1
    k = 0
    for i in range(a.shape[0]):
        for j in range(a.shape[1]):
            b[k] = a[i, j]
            k += 1

In the following example

add_5 = False
add_any = True

@m.function(Long, a=Long)
def f(a):
    if add_any and add_5:
        a += 5
    return a * 2

the if block should be eliminated from the resulting function altogether since the test result can be resolved to False at compile time.

Currently documentation is clearly lacking. Provide a proper introductory manual and API docs via http://readthedocs.org/

Makes sense to start with stack allocated fixed-size arrays of scalars and structures.

from nitrous import Float, Pointer

Vec3f = Pointer(Float, shape=(3,))

@m.function(e0=Float)
def func(e0):
    v = Vec3f()
    v[0] = e0