DEV Community: No Saved DATA

Deep Learning from Scratch in 1400 Lines - Neve & Frost Framework

No Saved DATA — Fri, 11 Sep 2026 03:22:32 +0000

The title literally means: "I have parallel dataloaders, GPU kernels and a high-performance computing programming language all expressed in a framework with 1400 lines of code".

You may run the ResNet-18 benchmark yourself
(github.com/NoSavedDATA/Neve_benchmarks)

I released the Neve programming language a while ago. Now, this is the release of the Frost deep learning framework, alongside with the first benchmark.

Other results for Neve:

Close to Python/SentencePiece in text processing + Byte-Pair Encoding (BPE) training;
Competitive with NumPy and OpenBLAS in CPU matrix multiplicaton, but with pure high-level SIMD code. Check exsisting (implementations)

Currently working in a better GPU programming interface, towards the implementation of flash-attention.

Neve documentation (neve-lang.dev)

Neve repo (github.com/NoSavedDATA/Neve).

Youtube for updates (youtube.com/@nosaveddata3994).

Discord for extensive talks/suggestions (discord.gg/hP5feM7cV)

Too lazy to read? Check the video version

────────────────────────────────────────

Introduction

Once day I was reading some papers, and a very interesting paper was published. It was the sophia optimizer. I took a glance in an unnoficial (code) for it, and I questioned myself why did it have to be so difficult to add new optimizers in PyTorch. I experimented the optimizer, and the results were quite bad with a lot of NaNs. Turns out another paper published later claimed this and other optimizers had overstated claims.

Imagine wasting hours studying a 10 pages of a paper, then hardly trying to debug it and asses whether other person discoveries are true. All that code reading complexity makes this a challengeful task.

Problem 1: even optmizers are hard to understand in PyTorch.

Few weeks later, (flash attention) was released, and the algorithm actually achieved a speed-up of 2x. The problem, it was C++ CUDA. Most high-level GPU kernel frameworks were imature to the point the flash attention author chose not to use them.

Now take a look what is necessary for adding C++ code in PyTorch

from setuptools import setup, Extension
from torch.utils import cpp_extension

setup(name="extension_cpp",
      ext_modules=[
          cpp_extension.CppExtension(
              "extension_cpp",
              ["muladd.cpp"],
              extra_compile_args={
                  "cxx": [
                      # define Py_LIMITED_API with min version 3.9 to expose only the stable
                      # limited API subset from Python.h
                      "-DPy_LIMITED_API=0x03090000",
                      # define TORCH_TARGET_VERSION with min version 2.10 to expose only the
                      # stable API subset from torch
                      "-DTORCH_TARGET_VERSION=0x020a000000000000",
                  ]
              },
              py_limited_api=True)],  # Build 1 wheel across multiple Python versions
      cmdclass={'build_ext': cpp_extension.BuildExtension},
      options={"bdist_wheel": {"py_limited_api": "cp39"}}  # 3.9 is minimum supported Python version
)

That comprehends problem 2: lack of high-level CUDA code and hard interoperability.

For my Bachelor's thesis, I implemented the (BBF) Reinforcement Learning for Atary. A bit before that, I took a glance code of the (Efficient Zero) reinforcement learning model. It has a parallelism that PyTorch does not handle, and the implementation required using Cython packages for having threads (literaly coding in C, then just calling C functions from Python). Later, I realized PyTorch also needed to implement its data worker threads in C, another workaround over Python Global Interpreter Lock (GIL). Not only that, even preprocessing implementations like the BPE are made in C, C++, Rust, etc...

That leads us problem 3, lack of parallelism. That is when I decided to create a programming language, a few months before finishing my Bachelor's, which matured to my Master's project

Summing up, currently, people must choose between languages like Python for high-level productivity, C and relatives for compute efficiency, Lua/Julia for advanced interoperability and other languages for concurrency. Thus, since in my job I had to wait hours for my neural networks to train, I decided to create a programming language in the time in between trainings. One language that had all these features, which are of high value for deep learning research. Nowadays, I believe it matured to such a point that it may be extended to other complex problem domains.

────────────────────────────────────────

Thoughts in Other Languages

Julia

Julia makes dynamic typying speed reach close to C++ speeds. It also has a mark sweep and channels for parallelism. The idea is very interesting. Let's take a look a in its cuda kernels.

function mma_kernel!(Z::CuDeviceMatrix{Float32}, 
                     X::CuDeviceMatrix{BFloat16}, 
                     Y::CuDeviceMatrix{BFloat16})

    # Grid and block indices
    bx = blockIdx().x
    by = blockIdx().y

    # Thread and warp indices
    tid  = threadIdx().x
    lane = (tid - 1) % 32
    warp = (tid - 1) ÷ 32

STOP!! Why am I seeing blockIdx().x in my code? Was this supposed to be a high-level scientific language or CUDA in C++28?

Besides, it does not expose intrisics like the cp_async, which is crucial for high-speed matrix multiplication. They must be explicitly added throgh interop intrisics. And it has the "end" keyword, which in my opinion incurs a lot of code pollution.

Mojo

Mojo has a Python interop, so it did not have to build all libs and frameworks from scratch +1 point. It has (Byte-Pair Encoding benchmarks)!! +1. It is only the BPE inference, no traning -1 point. It has (flash-attention gpu kernels) +1 point.

It runs MAX, which allows GPU code portability across different hardware, +2 points.

It lacks channels, so I would hardly try to make a parallel dataloader in it. -2 points. It uses Rust ownership +0 points. Has mutable/imutables -1 point.

Now let's look at Mojo kernels for the flash attention.

@always_inline
def fused_attention_cpu[
    BN: Int, BD: Int
](
    Q: LayoutTensor,
    K: LayoutTensor,
    V: LayoutTensor,
    O: LayoutTensor[mut=True, ...],
):
    comptime N = K.shape[0]()
    comptime D = K.shape[1]()

    comptime for tile_n in range(N // BN):
        var Q_tile = Q.tile[BN, D](tile_n, 0)

        comptime for tile_d in range(D // BD):
            var m_1 = (
                LayoutTensor[Q_tile.dtype, Layout(BN, 1), MutAnyOrigin]
                .stack_allocation()
                .fill(Scalar[Q_tile.dtype].MIN)
            )

            var l_1 = (
                LayoutTensor[Q_tile.dtype, Layout(BN, 1), MutAnyOrigin]
                .stack_allocation()
                .fill(0)
            )

            var O_i = (
                LayoutTensor[
                    Q_tile.dtype, Layout.row_major(BN, BD), MutAnyOrigin
                ]
                .stack_allocation()
                .fill(0)
            )

            comptime for tile_n_idx in range(N // BN):
                var K_tile = K.tile[BN, D](tile_n_idx, 0)
                var V_tile = V.tile[BN, BD](tile_n_idx, tile_d)

                var S = matmul_b_transpose(Q_tile, K_tile)
                var m_2 = max(m_1, rebind[type_of(m_1)](max[axis=1](S)))

Quite interesting. It has layouts and tiling, inspired by CuTe and Cutlass. It actually inspired the way Neve layouts and tiles work. Nevertheless, it still has a heavy syntax. Note the keyword comptime appears frequently (a sort of metaprogramming). This adds some cognitive overhead. And the layouts are quite verbose. The layout fill() and stack_allocation() can be simplified.

Triton

Triton has layouts/tiling similar to Mojo, but is dynamically typed and has no comptime headaches. The problem is that Triton does not make Python Dataloaders easier to implement from the systems programming language perspective. We actually need a complete new programming language for this.

@triton.jit
def _attn_fwd_inner(
[...]
K_block_ptr = tl.advance(K_block_ptr, (0, lo))
    V_block_ptr = tl.advance(V_block_ptr, (lo, 0))

    # loop over k, v and update accumulator
    for start_kv in range(lo, hi, BLOCK_SIZE_KV):
        # Just let the compiler know that start_n is a multiple of BLOCK_N, so the compiler can do optimizations
        start_kv = tl.multiple_of(start_kv, BLOCK_SIZE_KV)

        # -- compute qk ----
        K_block = tl.load(K_block_ptr)
        QK_block = tl.dot(Q_block, K_block)

        if STAGE == 2:
            mask = offs_q[:, None] >= (start_kv + offs_kv[None, :])
[...]
    # A LAYOUT
    Q_block_ptr = tl.make_block_ptr(
        base=Q + qvk_offset,
        shape=(SEQ_LEN, HEAD_DIM),
        strides=(stride_Q_seq, stride_Q_dim),
        offsets=(block_index_q * BLOCK_SIZE_Q, 0),
        block_shape=(BLOCK_SIZE_Q, HEAD_DIM),
        order=(1, 0),
    )
[...]
        # Algebra
        # -- compute qk ----
        K_block = tl.load(K_block_ptr)
        QK_block = tl.dot(Q_block, K_block)

Neve

Let's see how Neve GPU matrix multiplication looks like.

gpu void @(
            layout<bf16,m,n> x, layout<bf16,p,n> y,
            layout<float,m,p,smem> z
        )
    int warp_rows = min((m+63)//64, 4)
    int wx = warp%warp_rows, wy = warp//warp_rows

    var smem_a = layout<bf16,256,2,16,smem>()
    var smem_b = layout<bf16,128,2,16,smem>()

    int warp_m = min(m//16*16, 64), warp_p = min(p//16*16, 64)

    int m_tiles = warp_m//16
    int p_tiles = warp_p//8


    var c = layout<int,4,8,4>()


    int m_cp_tiles = min(m//16,4)
    [0..m_cp_tiles] i
        cp_async16(smem_a{256,8}(wx*m_cp_tiles+i, lane),
                        x{256,8}(wx*m_cp_tiles+i, lane))

    int p_cp_tiles = min(p//16,4)
    [0..p_cp_tiles] i
        cp_async16(smem_b{256,8}(wy*p_cp_tiles+i,lane),
                        y{256,8}(wy*p_cp_tiles+i,lane))

    cp_commit_group()
    cp_wait_group(0)


    syncthreads()

    var a = layout<int,4,4>()
    var b = layout<int,8,2>()

    [0..m_tiles] i
        int row = (wx*m_tiles+i)*16+lane%16
        int col = lane//16*8
        ldmatrix_x4(
                a{i,0},
                smem_a{row, col})

    [0..p_tiles] i
        int row = (wy*p_tiles+i)*8+lane%8
        int col = ((lane//8)%2)*8
        ldmatrix_x2(
                b{i,0},
                smem_b{row, col})


    [0..m_tiles, 0..p_tiles] i, j
        mma_16x8x16(c{i,j,0},
                    a{i,0},
                    b{j,0})

    syncthreads()



    [0..m_tiles, 0..p_tiles, 0..4] i, j, k
        int global_row = bx*256+ (wx * m_tiles + i) * 16 + (lane // 4) + (k // 2) * 8
        int global_col = by*128+ (wy * p_tiles + j) * 8  + (lane % 4) * 2 + (k % 2)

        if global_row<m and global_col<p
            z[global_row * p + global_col] = c[i, j, k]

    syncthreads()


kernel void mma_kernel(bf16[] x, bf16[] y, float[] z, int M, int N, int P)
    var v = layout<bf16, M, N>(x)
    var u = layout<bf16, P, N>(y)


    z += v[256,N](bx,0) @ u[128,N](by,0)

Did you like it? It took me one month to replicate the (HGEMM) repo to the beta version of frost, which used C++ CUDA kernels instead of Neve. Currently, I still need to do the benchmarks, but I will wait until I finish flash attention.

Here you see CUDA instructions like mma_16x8x16, cp_async and syncronizations. These are all mandatory when we pretend to implement SOTA matrix multiplications. Now look at the second function, it is almost z += v @ u, but with tiling. The whole previous function is successfully reduced into a new gpu operator.

There is also the new multi-loop expression

    [0..m_tiles, 0..p_tiles] i, j

When it comes to writing, Neve syntax is more pythonic than Julia (yes to "class" and no to "struct", floating methods and the "end" word) and Mojo (no comptime headache keywords, no ownership transfer expressions). It is not dynamically typed as Triton, but allows to define dataloaders from scratch. And strong typying is seem as a benefit in systems programming.

Neve has high-level kernel algebra, while simultaneously allowing CUDA intrinsics in different hierarchies of complexity.

Now let's look at the budget for each programming language.

Let's talk about some other features. The optmizer, the backpropagation and parallelism.

────────────────────────────────────────

Optimizers

Optimizers declaration can hardly be more compressed than this Frost implementation.

kernel void AdamW_k(float[] param, float[] d, float[] m, float[] v,
                    float lr, int n, float beta1, float beta2,
                    float beta1_correction, float beta2_correction,
                    float eps, float wd)
    int i = bx*256 + tx
    if i>=n
        return

    float m_i = (1-beta1)*d[i] + beta1*m[i]
    float v_i = (1-beta2)*(d[i]*d[i]) + beta2*v[i]
    m[i] = m_i
    v[i] = v_i

    m_i/=beta1_correction
    v_i/=beta2_correction

    param[i] -= lr*( m_i / (sqrt(v_i) + eps) + wd*param[i] )

class AdamW
    float lr, beta1, beta2, wd, eps
    array<gpu_tensor> m, v
    int ts

    ctor(float lr, float beta1, float beta2)
        self.lr = lr
        self.beta1 = beta1
        self.beta2 = beta2
        self.ts = 1
        self.wd = 0.01
        self.eps = 0.0000001

    def float step()
        int i=0
        for param in $optim_info.params
            if i+1>self.v.size()
                self.m.append(new gpu_tensor(param.dims, "zeros"))
                self.v.append(new gpu_tensor(param.dims, "zeros"))

            float beta1_correction = 1.0-pow(self.beta1, self.ts)
            float beta2_correction = 1.0-pow(self.beta2, self.ts)

            launch [param.dims_prod/|256] [256] AdamW_k(param.ptr offby 0, param.d offby 0,
                                     self.m[i].ptr offby 0, self.v[i].ptr offby 0,
                                     self.lr, param.dims_prod, self.beta1, self.beta2,
                                     beta1_correction, beta2_correction, self.eps,
                                     self.wd
                                 )
            param.d=nil
            i=i+1
        self.ts = self.ts+1
        $optim_info.params.clear()
        tarena_reset()

PyTorch comparison (AdamW). Torch does not even have the kernel in the same code.

────────────────────────────────────────

Backpropagation

All it took were 60 lines
(Backprop youtube shorts)

────────────────────────────────────────

Parallelism

# count primes in 10 threads
def int is_prime(int n)
    for i=2, i<(n//2+1)
        if n%i==0
            return 0
    return 1

def int count_prime_vec(array<int> input_numbers, channel<int,10> ch)
    int num_primes = 0
    for i in input_numbers
        num_primes = num_primes + is_prime(i)

    print("Found num primes ", num_primes, " on thread ", tid)
    ch <- num_primes

main
    array<int> v = arange_int(2,250001)
    channel<int,10> ch

    finish
        # split v across 10 threads
        asyncs 10 count_prime_vec(>v, ch)

    var primes = ch.sum()
    print("Total primes: ", primes)

Here we see two important parallel expressions. The first is the ">" operator inside the "asyncs". It splits v across 10 segments and send each one to different threads in count_prime_vec. The second fathoms the channels. Here, it is used to store the results from the sums of primes for each thread. Then, the main thread uses .sum() to aggregate all results. Neve channels are implemented with lock-free structures. They may block threaded operations if their capacity is full (capacity 10 in the example). This adds room for a lot of possibilities.

────────────────────────────────────────

Data Loader

    def float worker()
        print("Start worker")
        int yield_ptr, bs=self.batch_size
    print("worker ", tid)

        while self.load_ch.alive()
        yield_ptr = self.increment_yield_ptr()

        for b=0, b<bs
        self.getitem_w(yield_ptr+b, b)

        self.load_ch <- tid
        self.x.switch()
        self.y.switch()

    def tuple<gpu_tensor,gpu_tensor> batch()
    int w <- self.load_ch

    var x = self.x.load(w)
    var y = self.y.load(w)
    x = x.view([$cfg.bs, 3, 32, 32])

        return x, y
[...]
    finish
        asyncs $cfg.num_workers ds.worker()

        [0..steps] i
                    optimize_logic()

Here channels were used to signal when a worker finished processing its batch. Once the main thread starts processing the batch, it flips its pointer value inside a ping-pong memory buffer, so it may process new data in parallel with data consumption.

────────────────────────────────────────

Results

3 seeds in a RTX 4090.

Language	Acc	Time	Backend
Neve	65.46%+-0.37	592s+-6s	Naive Kernel
Neve	65.46%+-0.45	261s+-9s	Partial cuDNN
PyTorch	74.82%+-1.27	64s+-6s	cuDNN

Older Neve results surpassed PyTorch ( (old NSK paper) ). It won't take too long until the kernels get corrected and optimized.

────────────────────────────────────────

More about (Neve Syntax)

Neve - Towards a Unified Programming Model for the Complete Deep Learning Stack

No Saved DATA — Thu, 03 Sep 2026 22:23:27 +0000

Hi folks, this is No Saved DATA. I dedicate this post to describe some of the features I put in Neve to make it an expressive high-level language (close to Python/PyTorch syntax), while also allowing efficient low-level code. I am sharing this now, because I believe the language has already strongs traits that allow it to be extended to other problem domains.

Current results:

Close to Python/SentencePiece in text processing + Byte-Pair Encoding (BPE) training;
Competitive with NumPy and OpenBLAS in CPU matrix multiplicaton, but with pure high-level SIMD code;
It was able to train a CIFAR Resnet faster than PyTorch, but I did not debug whether this was due to better CPU or GPU orchestration. But the LSTM was slower (mine lacked kernel fusion and other optimizations). Also, that old Neve deep learning framework was mostly implemented in C++. I am now changing it to be mostly implemented in Neve. That is, compute intensive preprocessing, automatic differentiation, parallel dataworkers and GPU kernels all in high-level.

Besides, I recently added GPU Kernels code interface. However, the complete framework will still take some more months.

The current state is an evolution of a post I made in r/ProgrammingLanguages some months ago (https://www.reddit.com/r/ProgrammingLanguages/comments/1ql585o/brand_new_nsk_programming_language_python_syntax/)

You can check the documentation (https://neve-lang.dev)

Official repository (https://github.com/NoSavedDATA/Neve).

Youtube for updates (https://www.youtube.com/@nosaveddata3994).

Discord for extensive talks/suggestions (https://discord.gg/hP5feM7cV)

────────────────────────────────────────

Intro

I started creating Neve after seeing the code of the Efficient Zero reinforcement learning model. It has a parallelism that PyTorch does not handle, and the implementation required using Cython packages for having threads (literaly coding in C, then just calling C functions from Python). Later, I realized PyTorch also needed to implement its data worker threads in C, another workaround over Python Global Interpreter Lock (GIL). Not only that, even preprocessing implementations like the BPE are made in C, C++, Rust, etc...

So, currently, people must choose between languages like Python for high-level productivity, C and relatives for compute efficiency, Lua for advanced interoperability and other languages for concurrency. Thus, since in my job I had to wait hours for my neural networks to train, I decided to create a programming language in the remaining time. One language that had all these features, which are of high value for deep learning research. Nowadays, I believe it matured to such a point that it may be extended to other complex problem domains.

Since Python syntax is very simple and has most of the users, I chose it as the basis. But it run a LLVM JIT in its background. Now I will explain important expressions and features in Neve.

────────────────────────────────────────

Finish/Async and Data Split

I experimented Jax deep learning framework for a while. During this period, I learned an expression that would take a tensor or a vector as inputs. It could vectorized the function over the first dimension. A threaded adaptation I made for Neve is:

    def int foo(array<int> v)
        print("Thread ", tid, " has vector:")
        v.print()

    main
        array<int> u = arange_int(2,20)
        finish
            asyncs 3 foo(>u)

This splits a vector across three threads, so it can be processed in parallel. This is useful when you have a list of files, and want a function to process the files across N threads.

────────────────────────────────────────

Channels

I saw fireship videos a long time ago about Elixir and Erlang. These languages have actor-message passing, which were used in scaling applications to massive concurrency. Then, this year, my advisor suggested me to study Go and Rust, so I could see the tendencies about modern languages. I got surprised by Go channels expressions, which I thought to be an evolution of the actor-message model (but in the end they solve different problems). Go also applies channels to green-threads (concurrency within a single OS thread), but I was happy with using it for standard threads.

Once I finally adapted Go channels to Neve, I was able to reduce some five lines of code in data loaders. Even if it was only five lines less, it got much cleaner.

      def float worker()
          print("Start worker")
          int yield_ptr, bs=self.batch_size
          print("worker ", tid)

          while self.load_ch.alive()
              yield_ptr = self.increment_yield_ptr()

              for b=0, b<bs
                  self.getitem_w(yield_ptr+b, b)
                  self.load_ch <- tid

              self.x.switch()
              self.y.switch()

      def tuple<gpu_tensor,gpu_tensor> batch()
          int w <- self.load_ch

          var x = self.x.load(w)
          var y = self.y.load(w)

          x = x.view([$cfg.bs, 1, 28,28])
          return x, y

These are functions from the dataloader class. The channel communicates which threads have data ready to be consumed. Then, the cpu tensors (self.x and self.y) can process and yield data using ping-pong buffers. It is much lower level than PyTorch, but without the need of implementing the underlying parallelism in C++. That gets rid of boilerplate mutexes and more than 100 lines of C++ code. Posteriorly, once Neve gets inheritance and interfaces, most of the parallel logic may be hidden, so it can be even closer to PyTorch.

The training code is already similar to PyTorch

            ...
          gpu_tensor a, b
          a, b = ds.batch()
          var y_hat = model.forward(a)
          ce_loss(y_hat, b)

          $backprop.backward()

────────────────────────────────────────

Anonymous Functions

This expression is crucial for mapping tensor operations to their respective backward ops.

    def int add(int x, int y)
        return x+y

    def int mult(int x, int y)
        return x*y

    main
        map<str, Function<int, int, int>> m
        m["add"] = add
        m["mult"] = mult
        print(m["mult"](3,4))

────────────────────────────────────────

Generics

    def T bar<T, U>(T x, U y)
        print("bar x: ", x)
        print("bar y: ", y)
        return x

    main
        int z = bar(3,4)
        z = bar(5,"$%*OU")
        print("z ", z)

Generics may yield complex code, but may also save hundreds of lines when the same matrix multiplication function should be implemented for different data types (int4, int8, float16, bf16, etc...) (I still didn't test the generics in this scenario :p).

────────────────────────────────────────

Operation Overload

Defining new operations for data types is simple.

    def gpu_tensor @(gpu_tensor a, gpu_tensor b)
    ...

Which works thanks to generics. The operation is consumed as:

    var z = x @ y

For gpu_tensor types.

────────────────────────────────────────

Globals

Neve has no primary data type globals. Instead, global values can only be defined as unique instances of classes.

    class Backprop
        array<BackNode> ops
        def float register(gpu_tensor l, gpu_tensor r,
                           gpu_tensor out, str op)
            self.ops.append(new BackNode(l, r, out, op))

This defines the global Backprop class that holds the backs (backward function definitions). Then, any tensor operation may use the global instance of Backprop to keep track of the operations to execute later.

    def gpu_tensor @(gpu_tensor a, gpu_tensor b)
        ...
        $Backprop.register(a, b, ret, "mma")

Once Neve finds an "$", it automatically inserts in the main an instruction to create a new instance of that class, so it can be used everywhere. Althought standard global values are not supported, this expression forces global variables to belong to a common scope. It helps preventing pollution/confusion versus standard global vars. For example, you could put all your globals inside a class named Config, then use any of its values.

    $Config.ip

It is straightforward to spot it belongs to a global scope.

────────────────────────────────────────

GPU Kernels

    import nsk_cuda

    gpu void @(
            layout<bf16, m, n> x, layout<bf16, p, n> y,
            float[] z
            )
        ...

    kernel void mma_kernel(bf16[] x, bf16[] y,
                           float[] z,
                           int M, int N, int P)
        var v = layout<bf16, M, N>(x)
        var u = layout<bf16, P, N>(y)

        z += v[256,N](bx,0) @ u[128,N](by,0)

This one tiles z, v and u, storing the matrix multiplication result in the tiled z positions. The operator overload recovers a function that has shared memory async copies, which are overlapped with tensor core operations, all described in Neve itself.

The layout expression is subject to change, but it won't be too much different from the current.

────────────────────────────────────────

Interoperability and Libraries Support

In the early stage I was very inexperient with programming languages, so I tried to implement all my important functions and composite data types in C++, and call the functions from Neve. The negative side was that the quick sort was orders of magnitude slower than Python. The positive, I made a C++ tokenizer and parser to extract LLVM bindings.

NSK had a heavy focus in using C++ bindings for functionalities. Now it is almost unnecessary, as basically everything can be designed in Neve itself.

Use C++ interop when you:

- Need system calls only found in C++ (you may create a library that maps these calls to Neve);

- Want a custom memory allocator (I used this one for GPU mallocs/memory arena).

The way Neve adopts C++ functions:

    extern "C" int float_cpu_print(Scope_Struct *scope_struct,
                               void *tensor, DT_array *vec) {

After compiling and importing, the functions map naturally to Neve functions and data types. For example, the expression:

x.print()

Will call any function named float_cpu_print, given that x is a float_cpu. That implementation could either be defined in C++ or Neve.

Functions that have composite data types require explicit prototypes in Neve, in order to extract the nested type. But if a function takes a composite data type as argument, it is better to define it in Neve when possible.

It also allows adding LLVM extension functions in C++, which enable using LLVM for generating IR directly. Besides, it is possible to add new LLVM data-types.

C++ and LLVM functions must be compiled to dynamic libraries, and their make require linking system packages. The documentation has a in-depth guide on how to make them work, and the youtube channel has some tutorials about it as well.

Overall, I recommend building libraries in Neve itself. You can import libraries using imports in the current directory.

    import my_nv_file
    import my_lib/my_nv_file

These import other .nv files. It is also possible to turn them into packages if you organize them under ~/.local/neve/lib/, then import as:

    import my_pkg_name

If you get into the my_pkg_name folder, you can commit it to github, then anyone can install it with

nsm install <my_git_user>/<my_pkg_name>

Nsm is automatically installed along with neve when executing the bash install. It works for both Neve and C++ compiled packages (more testing is necessary).

────────────────────────────────────────

Other Features

JIT: it feels like Python to execute code - no need for compiling files. Meanwhile, it has the JIT speed benefit;
Packet manager;
Concurrent garbage collector;
Syntax highlight for vim and vscode;
Very simple/incomplete LSP, tested in neovim only.

────────────────────────────────────────

Limitations

There are still very rare crashes in large codebases, like in the BPE after executing it many times (due to that stupid concurrent garbage collector);
Works in Linux only, because I couldn't get LLVM to work in Windows;
Still lacks inheritance and interfaces.

────────────────────────────────────────

I hope you enjoyed the tour. Ready to test?

wget -qO- https://github.com/NoSavedDATA/Neve/releases/download/neve-bin/install.sh | bash

I have been building this entirely solo so far. Let me know what you think of the syntax choices, especially the approach to parallelism and GPU kernels!

Do you think Neve can help you in your domains?